Quicker interrupted backup resumption

[alexweiss]

@onionjake

Something that maybe hasn’t been considered before is to store the necessary data for the ‘incomplete’ snapshot locally only (don’t upload it to the backend). That would keep the complexity out of the main repository, but still enable the next backup that is started to skip re-chunking files.

This is already possible. Just create a local repository with identical chunking parameters, make your initial backup to this local repo and then run restic copy to copy this initial snapshot to your remote repo.

restic copy does not need to scan or (re-)chunk any local file, it simply copies each needed blob (i.e. chunks and the tree structure) that is not yet contained in the destination repo. If restic copy is cancelled at some point, all blobs that are saved (and contained in a saved index) will be skipped, if you restart it.

The only issue with restic copy is that the copying of blobs is not (yet) parallelized, see

Copy restic-rclone vs rclone alone

I recently changed my ISP which increased my upload speed from 2Mbps to 42 Mbps. I am currently using Dropbox to store a 2nd copy of my primary restic backup to a local attached USB drive. I use the restic (rclone) copy command to duplicate the USB repo to Dropbox. What I found was that restic cannot take full advantage of the new upload speed. However, if I use the rclone copy command outside of restic, it WILL take full advantage of the increased upload speed. My question: what is the dis…

EDIT: Of course it also works to use rclone or something similar which supports resuming uploads to directly upload the local repo to a remote destination.