Does restic *actually* resume initial backups?

Getting Help
1

I’ve read in the docs and a couple of threads here in the forum that restic will always continue interrupted backups. If there was no previous snapshot, restic will have to re-scan files to find the point where it can continue, but (almost) no chunks should be uploaded twice.

Well, it seems like that doesn’t work for me, at least if the output of restic backup --verbose can be trusted. I want to upload ~1TB of data to a remote server which is going to take at least 50 hours on my home connection. I just uploaded 2GB of data in about 10 minutes, then I cancelled the backup and started it again. According to the log, the exact same files were processed again and after another 10 minutes, restic reported 2GB of data in the repo, and so far it didn’t upload any files that it hasn’t seen before. In these 10 minutes during the second attempt, I saw consistent upload speeds of 3-4 MB/s, so if the output on the terminal is correct, restic uploaded the same files again.

What’s going on?

1 Like
2

nevermind, seems like I was too impatient. After a couple of hours, I stopped the backup process again and this time, it skipped over most of the files. How frequently does restic persist uploaded files? Can I change this setting?

1 Like
3

Restic doesn’t delete uploaded stuff unless you run prune. Even forget is just there to “unregister” the snapshot but the uploaded packs etc. will be physically there (they might be used by multiple snapshot) unless prune runs and cleans unused stuff.

1 Like
4

yeah, the files are there, but it seems like restic is unable to use them for deduplication unless an index is written and according to this thread (is there some official documentation on this?) this only happens every so often. It has to be at least 10 minutes before the index is written, otherwise my first experiment would have been successful.

1 Like
5

Restic reports when it writes temporary indices with verbosity on. Maybe add another -v?

1 Like
6

There are two things about resuming:

  • reusing already saved data in the repository. This is done almost automatically due to deduplication. Yes, there might be written pack files for which the index has not yet been written. Running restic repair index before the resumed backup should fix that.
  • reusing metadata to not even re-read already saved files. This is not yet possible with restic. So, when resuming (i.e. re-running) a backup, all files are read and chunked before restic can detect that the chunk is already saved. This re-reading might “feel” like restic does not resume at all…
2 Likes
7

The index uploading reporting has been removed for several years by now.

1 Like