Something is wrong with the backup:

Just a note on this. I use snaps a lot in my primary servers. They work, reliably and well, but I can see why someone with a rich toolkit of scripts to work at the apt and dpkg level would shy away from snapcraft - it takes a very different approach.

But I think that underlying to the problem we’ve seen here and before is what I’ve heard about Python-dependancy hell. If you don’t cookk up anything in Python yourself having stuff that’s written in it has a better chance of not going wrong, but if you start having version preferences or dependencies for your own code base that can and apparently often does clash with the runtime environment other Python packages encounters on your and some machines.

That’s why snaps makes things better. Snaps controls the entire environment for the package and while it goes to some lengths to avoid duplication, it keeps different packages from geting in each other’s way.

Howdy

When dupe broke, I just spent some time at my keyboard searching for an archive of previous releases of duplicity and downloaded and installed it. Issue resolved. It didn’t take long to find the dist. I provided a link and it all worked for me on my 3 mail servers:

  1. Download 3.0.4 version .deb from:
    https://code.launchpad.net/~duplicity-team/+archive/ubuntu/duplicity-release-git/+files/duplicity_3.0.4-ppa202502081832~ubuntu22.04.1_amd64.deb

I reckon that the MIAB install should mark duplicity “hold” for all updates by default and as long as the author/devs highlight that, no-one can come back and complain about this fine and amazing mail server product. Users of Josh’s project can take some responbility i feel. perhaps have a staging server somewhere in a VM to test all updates?

That spending time at the keyboard part is the piece of magic I failed to pull so could you share a) how you actually went about that, and/or b) whether what you found would have been a once-off find or perhaps something that can be either automated or written down as a repeatable set of instructions to follow when the chips are down and the brain is in crisis mode?

@JoshData about that, I run my 2 MiaB servers on my own hardware at home behind redundant fibre links as a side-show to self-hosting the root cluster for my app. Running another miab server or two for testing should not tax my resources much so the cost will be absorbed into my sunken costs. I’d be more than happy to offer that towards a type of staging/testing platform if it would help you and the rest of the community.

1 Like

@MarthinL i literally did a deep dive and persevered with google searching for a repository somewhere of old versions of duplicity and one cam up trumps. I wasnt prepared to wait for a new release to try. I wanted to roll back. In essence I am not a Linux person, however I am very good at problem solving and finding solutions. I will admit it was only on the second attempt that i managed to find a solution. The right answer now that it is all working is to put duplicity on hold for updating and wait for a few weeks after the release is dont before applying it, and apply to a staging servers on a VM to ensure it works. I am adamnt that as its email I will never run without a current backup.

sure brother there probably you ran apt clean, thats it but am happy it helped other way, have great day

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 :shield::floppy_disk:

  • 23 July 2025

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! :rocket:


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. :weary:


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. :triumph:


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. :tada:

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! :shield::sparkles:

2 Likes

I’m probably also going to add a paragraph on apt hold.

1 Like

3.0.5.1 worked.