Should you instead include all folders/files you want to backup and run in a single command $restic backup content/dir1 content/dir2 so everything is available in the latest snapshot ?
Note: my real folders are actually on different roots that’s why I’m not simply specifying content/
If you can do differently, how to run backup in a separate command and avoid the mentioned issue when restoring ?
Given that I already uploaded a lot of datas on the repo but most of them aren’t in the latest snapshot (like dir1 in the example), how to restore dir1 without specifying the latest snapshotID every time ? Another solution ?
I would. Why would you separate them into multiple snapshots? You have your set of paths that you want to back up, so back them up
To restore dir1 you use the restore command with the snapshot that dir1 is in, and you can use the --include option to only restore dir1 and nothing else in that snapshot (if needed).
Since the operation can last hours and can only run when my computer is on, I thought I could just do this to have part of my backup available after I finish dir1. But now I know restic supports resuming operations.
To restore dir1 you use the restore command with the snapshot that dir1 is in, and you can use the --include option to only restore dir1 and nothing else in that snapshot (if needed).
This means to download and upload again, correct ? It’s what I wanted to avoid. Also dir1 is still available locally.
So I’ve just created another backup and I’m uploading the files back again…
Yes. If you start a backup, then cancel it or it terminates half way for some reason, then the next time you run the same backup command restic will already have uploaded the data that hasn’t changed, and will continue by uploading the data that has changed or that wasn’t uploaded the previous run.
I don’t understand what you mean by this. The restore command restores files from your restic backup repository, to your local disk. Not sure why you think that will upload stuff.
All in all, it’s pretty simple. If you want to back up the paths /foo and /bar, then run a backup command with those two paths listed. No need to split them up into separate snapshots.
To make the repository be like I want, I need to “download” aka “restore” and then “upload” aka “backup” /dir1 .
All in all, it’s pretty simple. If you want to back up the paths /foo and /bar, then run a backup command with those two paths listed. No need to split them up into separate snapshots.
Right. But it wasn’t mentioned in the doc (or was it ?) maybe because it is an obvious part.
If what you mean is that you have currently only backed up dir2 and not dir1, then you can just run a backup with both dirs in it. Restic will add dir1 to the new snapshot and reference the already backed up dir2 in the same snapshot. It will only upload what has not already been uploaded in previous snapshots.
Oh yeah this seems to work indeed. However It is reading the local files for comparison which still takes some time but much less than uploading everything again.
I did not know about this behavior of restic. Nor I could notice it during my local tests
I was confused because at first you mentioned the restore for that problem… I myself said “restore” which was confusing, I meant to have dir1 back in the latest snapshot without uploading its content again.
As a solution summary:
You can backup files that are present in the repository but not in the parent snapshot - by simply running a backup that includes the files you want back along with all files you want.
It does not scan all the files and their contents when you back up the same paths as in a previous snapshot - it then only scans their metadata to check which have changed since the last backup of those same paths (according to e.g. mtime - see restic help backup for options to affect this).
You can specify a snapshot to use explicitly using backup --parent <snapshot ID> for the case where the paths you are asking restic to back up changed, like in your example here. You’d then give it the snapshot ID of the one where you already backed up one of the two paths.
It does not scan all the files and their contents when you back up the same paths as in a previous snapshot - it then only scans their metadata to check which have changed since the last backup of those same paths (according to e.g. mtime - see restic help backup for options to affect this).
It seems to 1. take some time to process even a single file 2. I see the disk usage being at maximum 3. Network usage at minimum - by the restic process… So I assumed it was checking the content in this case ? (which won’t be the best indeed). Anyway…
Well, it probably did not find the parent snapshot, since you gave it different paths this time. As I mentioned you can use --parent to change this. But to keep things simple, just let it run and finish the backups, subsequent ones for the same paths should be faster and not require reading all the files.
