rsync backup repository

[perillo]

Due to the design of the restic repository, it seems that it should be easy to sync the repository to a different location, like another external disk, Google Drive, Dropbox and so on.
This seems to be very important, since restic is not designed (AFAIK) to be robust against random errors, e.g. in case of hardware failure.

Is it safe to just sync the repository files? Should the sync program check for the lock?
Does it make sense to support master/slave sync in restic (calling external programs to do the job), instead of adding more backends in the core?

[fd0]

Due to the design of the restic repository, it seems that it should be easy to sync the repository to a different location, like another external disk, Google Drive, Dropbox and so on.

Indeed, this works really good, at least for one-way sync. I know several people who backup to a local directory but take daily read-only snapshots with zfs.

This seems to be very important, since restic is not designed (AFAIK) to be robust against random errors, e.g. in case of hardware failure.

Could you elaborate? Restic is able to detect these errors, but does not have a way to recover (yet), that's planned (see #256).

Is it safe to just sync the repository files? Should the sync program check for the lock?

Yes, I think it's safe to sync the repository files, as long as you do not modify the repository with restic on both sides and then try to re-sync the repository. Checking for a lock is not so important (at least for the local repository), as long as there is no optimize operation running.

I don't exactly understand what you mean with "Master/Slave Sync", but for the future I'm planning a copy command that can copy the contents of two repositories, see #323.

[perillo]

On Sat, Jan 16, 2016 at 7:20 PM, Alexander Neumann <notifications@github.com

wrote:

Due to the design of the restic repository, it seems that it should be
easy to sync the repository to a different location, like another external
disk, Google Drive, Dropbox and so on.

Indeed, this works really good, at least for one-way sync. I know several
people who backup to a local directory but take daily read-snapshots with
zfs.

This seems to be very important, since restic is not designed (AFAIK) to
be robust against random errors, e.g. in case of hardware failure.

Could you elaborate? Restic is able to detect these errors, but does not
have a way to recover (yet), that's planned (see #256
#256).

It is as you say: restic is able to detect there errors but it can not
recover lost data.
Having mirrors of the repository can help recovering, since you can get
damaged files from the mirrors.

Is it safe to just sync the repository files? Should the sync program
check for the lock?

Yes, I think it's safe to sync the repository files, as long as you do not
modify the repository with restic on both sides and then try to re-sync the
repository. Checking for a lock is not so important (at least for the local
repository), as long as there is no optimize operation running.

I don't exactly understand what you mean with "Master/Slave Sync", but for
the future I'm planning a copy command that can copy the contents of two
repositories, see #323 #323.

The master repository is the local backup repository created by restic.
Each master repository can be replicated on multiple remote slaves.

This makes it easy to add support for additional backends using "plugins",
instead of adding support for them in the restic source code.
As an example, currently restic, in order to support S3, needs credentials
to be stored in environment variables. This is not a good thing, IMHO.

—
Reply to this email directly or view it on GitHub
#391 (comment).

[yatesco]

Chiming in - I do this and it works magnificently. I strongly recommend this model as:

• the backup is isolated from WAN network issues (assuming that the target is far away)
• yet more redundancy can only be a good thing
• restores are significantly quicker
• you care event less about the stability/security of the target allowing cheap-as-chips providers
• rsyncing to multiple destinations feels cleaner (not sure why) than restic'ing to multiple targets

Instead of rsync, you might also consider btsync as well...

[fawick]

@yatesco Have you, by any chance, tried gsutil rsync as well? I'd assume that syncing the repository to a Nearline bucket might be as cheap-as-chips as currently possible.

[yatesco]

I haven't - yeah, this looks great.

Other than being a very satisfied customer I have no affiliation with
them, but I can highly recommend the 'High Volume Storage Servers'
from http://www.time4vps.eu/pricing/. 1TB storage with 4TB bandwidth for
35.91/yr.