# Purge dry run terror

**URL:** <https://forum.duplicati.com/t/purge-dry-run-terror/12708>\
**Category:** Support\
**Tags:** bug\
**Created:** [July 14, 2021, 9:39am UTC](https://forum.duplicati.com/t/purge-dry-run-terror/12708 "2021-07-14T09:39:17Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![conrad](https://forum.duplicati.com/letter_avatar_proxy/v4/letter/c/ebca7d/32.png) [@conrad](https://forum.duplicati.com/u/conrad)\
**Post date:** [July 14, 2021, 9:39am UTC](https://forum.duplicati.com/t/purge-dry-run-terror/12708/1 "2021-07-14T09:39:17Z")

</div>

# 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:

```plaintext
  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.