Mirroring and/or pushing a repository to multiple backends

[cyphar]

At the moment, restic ties a repository to the backend which it is stored in. While this is okay if you assume that your backup provider will be around forever and will never lose your data, it is generally recommended to keep more than one backup with different services (to quote a common adage "If you don't have at least three copies of your data it doesn't exist.")

At the moment I have two options for how to mirror my repositories:

1. Mirror them manually, outside of restic. This requires hooking up some other scripts around my existing backup workflow to be able to effectively rsync the two mirrors. Obvious concerns with this scheme is how to correctly mirror deletions, and the fact that my backups are temporarily inconsistent before I complete the rsync.

2. Create two separate repositories on both backends (with the same password so they can be accessed by the same script) and then just backup to each. This is obviously inefficient, as backing up a /very/ large repository takes a while and we would be doubling all of the backup overhead rather than just pushing the same blobs to two different stores. Not to mention that comparing the integrity of both stores is no longer really doable in a trivial way.

Would it be possible for restic to support pushing to multiple backends and then being able to round-robin when pulling from multiple backends? The idea would be you could specify something like restic -r b2:some-bucket:my-backup1 -r /some/backup2 -r sftp:user@blah:some/backup3. Then restic would push blobs synchronously to all three backup stores when doing backups, and when doing a restore it will try to pull blobs in the given order (if b2:some-bucket:my-backup1 fails, then it will fall-back to /some/backup2 in the above example).

Is this something you'd be interested in, or do you feel this is outside of the scope of restic and I should just stick to cloning repositories with a higher-level script?

[fd0]

Hey, thanks for raising this issue. This function is something that I can see in restic, but not in the short term (we have more urgent issues/features to implement). For now, you need to stick to a third-party program/script around restic.

What works great (as far as I've heard) is using restic to backup to a local repository, and then use rclone to sync that to some cloud storage (or sftp or whatever). I think you can configure rclone to first sync new files, and only afterwards delete files remotely that have been deleted locally. This way, the repo will be consistent for at least all previous snapshots, but maybe not the current one, so you can always restore the snapshot before.

I'll keep this issue open as a reminder.

[fd0]

A related issue is #323

[alphapapa]

rsync is also useful when rclone isn't necessary, and it may be faster. rsync -az --delete should be appropriate for this case over a network.

[dimejo]

What happens if the local repository is changed (e.g. through backup or forget) while it is copied to another location? Can restic recover from that?

[fd0]

In a restic repo, files are never modified, only deleted and replaced by files with different names. So in this case it'll be repaired automatically by the next rsync run.

[scoddy]

Another related issue is #265, which I believe can be closed as duplicate as we discuss this in the related issues #323, #391, #1545.

One thought could be to either allow writing backups to multiple destinations at the same time (of the same backend type or different backends) or implement a copy/sync feature to replicate a snapshot over. For the latter case, I believe it could be important that we support the same set of backends that we support for regular backups. The distinction is whether you write it to different repositories (and possibly different backends) during the backup or after.

[fd0]

I'm closing this issue as a duplicate of #265, thanks for the hint!

[StarPicard]

rsync is also useful when rclone isn't necessary, and it may be faster. rsync -az --delete should be appropriate for this case over a network.

@fd0 Sorry to reopen this discussion, but I'm trying to find out if I can simply mirror my restic repository to a second remote disk with rsync and if the above command is sufficient. If so, I think it would be a great idea to include this option in the documentation. (If there is an official way to do this, I would be willing to do that 😉 ).

[fd0]

Yes, you can just copy all files/dirs to another location use that directly. The repository format is the same for every backend.

I think it's a good idea to include this in the documentation. You can open a Pull Request, the docs are below docs/, and there's a Makefile which helps compiling the docs. You'll need Sphinx do to that.

[StarPicard]

👍 Thanks, you just got a new restic user. I'll see when I can find the time in the next few days for including this into the docs.

[Neob91]

This way of mirroring repositories doesn't seem right - if the main repo is corrupted, all the mirrors will be as well. Just keep that in mind :-)

[sebastiandanconia]

In a restic repo, files are never modified, only deleted and replaced by files with different names. So in this case it'll be repaired automatically by the next rsync run.

Does this apply to the config file in the backup repository? config appears to be the only file whose name isn't the hash of its content. Or do we have a guarantee that config is never modified after creation, even by new versions of Restic?