I’m currently drafting a blog post about this issue, plus the solution. According to my publication schedule, it will be published on 23 July at 12:34 CET.
The URL will be https://amedee.be/?p=1924
This is the text of the blog post: (copypasta messed up the layout a bit)
How I Tamed Duplicity’s Buggy Versions — and Made Sure I Always Have a Backup 
If you’re running Mail-in-a-Box like me, you might rely on Duplicity to handle backups quietly in the background. It’s a great tool — until it isn’t. Recently, I ran into some frustrating issues caused by buggy Duplicity versions. Here’s the story, a useful discussion from the Mail-in-a-Box forums, and a neat trick I use to keep fallback versions handy. Spoiler: it involves an APT hook and some smart file copying! 
The Problem with Duplicity Versions
Duplicity 3.0.1 and 3.0.5 have been reported to cause backup failures — a real headache when you depend on them to protect your data. The Mail-in-a-Box forum post “Something is wrong with the backup” dives into these issues with great detail. Users reported mysterious backup failures and eventually traced it back to specific Duplicity releases causing the problem.
Here’s the catch: those problematic versions sometimes sneak in during automatic updates. By the time you realize something’s wrong, you might already have upgraded to a buggy release. 
Pinning Problematic Versions with APT Preferences
One way to stop apt from installing those broken versions is to use APT pinning. Here’s an example file I created in /etc/apt/preferences/pin_duplicity.pref:
Explanation: Duplicity version 3.0.1* has a bug and should not be installed
Package: duplicity
Pin: version 3.0.1*
Pin-Priority: -1
Explanation: Duplicity version 3.0.5* has a bug and should not be installed
Package: duplicity
Pin: version 3.0.5*
Pin-Priority: -1
This tells apt to refuse to install these specific buggy versions. Sounds great, right? Except — it often comes too late. You could already have updated to a broken version before adding the pin.
Also, since Duplicity is installed from a PPA, older versions vanish quickly as new releases push them out. This makes rolling back to a known good version a pain. 
My Solution: Backing Up Known Good Duplicity .deb Files Automatically
To fix this, I created an APT hook that runs after every package operation involving Duplicity. It automatically copies the .deb package files of Duplicity from apt’s archive cache — and even from my local folder if I’m installing manually — into a safe backup folder.
Here’s the script, saved as /usr/local/bin/apt-backup-duplicity.sh:
#!/bin/bash
set -x
mkdir -p /var/backups/debs/duplicity
cp -vn /var/cache/apt/archives/duplicity_ *.deb /var/backups/debs/duplicity/ 2> /dev/null || true
cp -vn /root/duplicity_ *.deb /var/backups/debs/duplicity/ 2> /dev/null || true
And here’s the APT hook configuration I put in /etc/apt/apt.conf.d/99backup-duplicity-debs to run this script automatically after DPKG operations:
DPkg::Post - Invoke { "/usr/local/bin/apt-backup-duplicity.sh" ; };
How to Use Your Backup Versions to Roll Back
If a new Duplicity version breaks your backups, you can easily reinstall a known-good .deb file from your backup folder:
sudo apt install --reinstall /var/backups/debs/duplicity/duplicity_ <version>.deb
Replace <version> with the actual filename you want to roll back to. Because you saved the .deb files right after each update, you always have access to older stable versions — even if the PPA has moved on.
Final Thoughts
While pinning bad versions helps, having a local stash of known-good packages is a game changer. It’s a small extra step but pays off hugely when things go sideways. Plus, it’s totally automated with the APT hook, so you don’t have to remember to save anything manually. 
If you run Mail-in-a-Box or rely on Duplicity in any critical backup workflow, I highly recommend setting up this safety net.
Stay safe and backed up! 