purge --dry-run reports itself very badly,
- not recording itself as a dry run,
- seemingly deleting much more than instructed to,
- but giving no actual details on the subject.
It would be great to fix this.
Secondly I have a question: if I purge a tree from the latest backup, but don’t remove it from my configuration, will that tree get completely re-added during the next backup?
Software/environment: Duplicati 22.214.171.124_beta_2021-05-03 on a Synology NAS running DSM 6.2 and Mono 126.96.36.199-16.
I recently realised that my backups were including a host of frequently-changing big files I didn’t want backed up, so after removing the relevant paths from my backup config I was pleased to discover the
purge command would allow me to get rid of the previously backed-up copies of these files. Being cautious, I thought I’d try a dry run, and since my first few tests (using wildcards in
--include) didn’t seem to work, I then tried a simpler example:
TMPDIR=<A-SPACIOUS-TMPDIR> \ /volume1/@appstore/mono/bin/mono-sgen \ /volume1/@appstore/Duplicati/Duplicati.CommandLine.exe purge \ --dry-run \ [various send-mail options] \ '--dbpath=<BLAHBLAHBLAH>.sqlite' \ <TARGET-URL> \ --include=<TEST-PATH> \ --exclude=<TEST-PATH-SUBDIRECTORY> \ --version=0 \ --passphrase=<ETC>
… two days later (!! note that during this time I couldn’t run any backups!!) the command finished, with no output on stdout/stderr. That’s unhelpful. Luckily I had included those email switches, so I got an email. However the email was terrifying: it said it had removed 750,000 files and 1.2TB from the backup — it appeared to have made a hugely disproportionate live change, including replacing the real fileset, with no hint that this was a dry run. The <TEST-PATH> specified above includes only 3.4GB.
Now, it looks as if that email is wrong, as I’ve been able to successfully run a restore from that backup version, from files both in the included <TEST-PATH> and the excluded <TEST-PATH-SUBDIRECTORY>. Also, looking at the backup destination, the original fileset is still there, while the replacement that the email claims to have created is not.
- The stdout/stderr reporting for
purge --dry-runis non-existent. Unless this was implicitly turned off by my using email switches, then that would be nice to improve.
- The email from
purge --dry-runsays nothing about its being a dry run. This is terrifying, and would be nice to fix.
- The email report from
purgeseems very broken: I cannot understand how removing one version of a 34,000-file/3.4GB tree (<TEST-PATH> above) from a backup can purge 750,000 files and 1.2TB of data (essentially, my entire dataset). But perhaps my command line demonstrates a misunderstanding of the switches?
- Purge is a very grave/critical command, with serious consequences: I would be inclined to list all files purged in any reporting, and to have reporting turned on by default. As it is, having executed a dry run I have no idea what files it would have removed and have zero confidence in executing a live run of the command.