Question: Best parameters to backup restic repos?

Help and Support
1

Hello all,
i have a backup system implemented with about a dozen restic repositories on a Hetzner Storagebox . https://www.hetzner.com/storage/storage-box I want to make a backup, of the backup and plan to use rclone to sync these repositories to another storagebox .

I plan to use sftp and the process works in principle, but I can only open 10 parallel connections to each storage box per account . So I think I should use checkers=3 or something to be on the safe side.

Is this correct ?

The restic files are never updated when ready, but it may well happen that incomplete files are transferred (if a backup process works, while rclone copies. rclone handles this problem already very elegant.

Can I use certain flags to optimize the rclone process because i never update ? Deletion can happen , if a resrtc repository is pruned.

Thanks for considering !

Norbert

2

hi,
i am a big fan of --immutable

i am a very similar case, but the source are veeam backups files and the files goto aws s3 deep glacier and wasabi, s3 clone for hot storage
the source files will never change, and if that happened, then that would be a serious problem, i need to know about asap.
and as a form of protection against ransomware.

3

For an sftp server I would have thought --checkers 2 would be fine. Adjust the number of transfers with--transfers 6 say. That leaves a couple of connections over.

4

Looks good. I tried to set these parameters in the definition of the remote in the conf-file. It gives no error but the setting seems to be ignored.

Is this a bug ?

5

Alas you can't set these parameters in the remote yet. There is a plan, but we haven't done it yet!

6

--immutable does not work in this case unfortunately because it happens that the source file is modified in flight. Some backup process writes a file and is not ready yet while the rclone process copies just this file to the other location.

This situation results in errors like this one here :

May 19 13:04:40 xxxxxxx sh[1708430]: ERROR : audio/data/40/40c8384ab4aa4f119e5d373b3bc7bfcedb90a7821babb609f56198728f7fa554: Source and destination exist but do not match: immutable file modified
7

I am going to give you unsolicited advice. Feel free to ignore completely...

I want to make a backup, of the backup

DON'T DO THIS. Seriously, it is a major risk!

Backup should be as independant of each other as is reasonable and this is not that.

It really comes down to why you want this. Are you concerned that Hetzner will experience data loss or go belly up with no notice? If that is your only concern then sure, back it up.

But on more complex tools like restic, there are a lot more realistic failure modes. Notably, user error and other forms of backup corruption. In this case, it is probable that those failures will happily propagate to your backup of the backup and then you're screwed!

I am not saying the second backup doesn't offer some benefit; just that you are not realizing the gains of another backup fully. Instead, I would use a totally different tool and backup from the source. Since Hetzner can be a Borg target, maybe use Borg to backup to Hetzner and then restic to your second. Or just rclone (with --backup-dir or the like) as a new backup.

Reliability of backups should be your number 1 priority.

Thanks for coming to my TED Talk.

8

that is very interesting. tho i do not really understand that.

anybody?, what does it mean that rclone process copies just this file to the other location.
if a file is in use, rclone delays the copy operation until the file completes or some such logic?

9

So it kind of depends as there are a few factors that get involved.

Generally on a Linux, you won't get a locked file and if rclone copies it and it is fast, it might not notice the size changing of the file and you get a mismatch at the end.

Windows tends to lock files and I believe you get a retry if the file is use (not 100% sure) but generally, it'll fail to copy that file.

On any OS if you have files changing, you'd want to take a snapshot and copy the snapshot to not get into that state.

I don't consider rclone a backup tool at all so I wouldn't use it as one. Many folks do, just not me.

10

thanks, i get all that and agree that rclone is not a backup program.

my question was not clear.
i want to understand how rclone can start to copy an file that is being modified in flight?
that rclone process copies just this file to the other location?

does rclone copy that file to a tmp folder and so something special to upload it?

11

I don't know for every backend, but most don't copy anywhere else. I believe a few backends copy to a tmp location, but I'm not 100% sure.

12

I presume that the filesystem allows it to copy a file while it is modified. The result is faulty but that is of no concern to the filesystem .There is no transactional logic in filesystems that I know of. Transactional integrity is the domain of databases.

13

i know this is off-topic, but trying to understand.

after that faulty is uploaded, does the hash checksum of the source and dest match?

14

I dont think so. But rclone tries again in the next attempt and this is a really nice feature.

15

Thats fine by me !

I agree and see the need to check the backups for consistency and quality. That is a point of ny agenda.

That would be good but i want to keep it simple,

To be honest : I dont believe in a reliable internet in the timeframe of 2 years. I assume major outrages. One backup of the backup is in my house. The first backup is at Hetzner because their network is much faster. If all processes run I have a time gap between backup of backup and the original data of some hours which is no problem in such a situation.

16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.