Minimal restore over low bandwidth

I have a host with an slightly-old copy of my filesystem that I’d like to restore to the latest backup copy (which is in B2). The host has a very limited network connection, and it seems a shame to download/restore every file, when nearly all the files are already present on the host.

I may be missing something - is it possible to do “restore” of the form “Do the minimal set of downloads and local file updates/deletions to make the local disk directory identical to the backup snapshot”? Conceptually, I’m thinking something like “rsync” semantics for the restore:

# restic restore-rsync -a --delete b2:my-bucket:my-host%latest:/etc /etc

Does anything like this functionality already exist?

1 Like

Hey, welcome back!

Something like this isn’t implemented yet, but you could try that using rsync together with restic mount:

  • Mount the repository on a host which has enough bandwidth available
  • On that host, run rsync [...] -a --delete-after [...] /path/to/mounted/repo/snapshots/1234[...] otherhost:/target/folder

This way, rsync running on the host with a lot of bandwidth will download all data needed from the repository and hash it locally. It will then only transfer the changed data to the other host which has not a lot of bandwidth.

Does that make sense? :slight_smile:

2 Likes

Thank you for the rapid reply! I have to think about if we’re willing to spin up a VPS close to the B2 repo, and have the data decrypted on that VPS prior to being sent to otherhost over rsync’s ssh tunnel. If it is not acceptable to allow the unencrypted data to live on a 3rd party cloud server, this wouldn’t suffice.

The workaround would be to just have Backblaze mail a harddrive containing the entire encrypted repo bucket to the remote location. Sneakernet FTW.

1 Like

You could always create a LUKS volume on the VPS if you want to have the temporary data on disk encrypted.