Purge dry run terror

Support
1

Summary

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?

Details

Software/environment: Duplicati 2.0.6.1_beta_2021-05-03 on a Synology NAS running DSM 6.2 and Mono 5.20.1.34-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.

Observations

  1. The stdout/stderr reporting for purge --dry-run is non-existent. Unless this was implicitly turned off by my using email switches, then that would be nice to improve.
  2. The email from purge --dry-run says nothing about its being a dry run. This is terrifying, and would be nice to fix.
  3. The email report from purge seems 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?
  4. 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.