Dry Run for backups

Hi,

I am playing with using includes and excludes to optimize Restic. One flag that I noticed that we have for restic forget is --dry-run, but this does not apply to restic backup. I would love something similar for restic backup where I could use it to test my rules before actually running backups. Is there a way to do this that I am missing?

Side note - docs commentary:

This documentation section is called “Include and Excluding Files.” The details are great, but they only talk about excluding files and there is no mention of including them… If the section is only about excluding it should be titled as such. This does also raise the question of how you include files which is not mentioned in the section.

TIA

With restic you can’t do --dry-run for backups. If you’re using any unix-like system, you can use du utility. I know it is silly but I ended up adding a flag to my bash script for “dry-run” using this utility. It will take the backup directory and exclusions already configured just to see the files that would be added to the repository and the size. Obviously, it would be great to have this feature in restic itself but I don’t think it exists for backup.

2 Likes

Yes, there is no --dry-run for backups. I am familiar with du and missed the fact that its exclude file uses the same format as restic’s. That is an excellent workaround, and I will use that. It would still be nice for restic to provide a dry-run option though. Thank you!

1 Like

I agree that the backup function should have a --dry-run parameter.

The highest utility of this would be to determine how many bytes will be added to the repository, and to see which objects in the repository will be updated.

Note that calculating this can require hashing all or some local files, so this isn’t necessarily a lightweight operation.

Repository objects are never modified.

Note that calculating this can require hashing all or some local files, so this isn’t necessarily a lightweight operation

Agreed. But the principal goal isn’t to be lightweight (although it’s desirable where possible). The principal goal is to simulate the execution of the function without actually making any changes.

and to see which objects in the repository will be updated.

Repository objects are never modified.

objects^H^H^H^H^Hblobs
modified^H^H^H^H^H^H^Hadded

Various additional statistics are reported by the backup function, depending upon the verbosity level (how many/which files have changed in the source, Data vs Tree blobs created, etc.)

In short: The dry-run feature should do what dry-run features always do: Faithfully execute the function without actually changing the destination.