Something is wrong with the backup:

Maintenance
1

Hi to all!
After upgrading to v72, when I visit the Backup Status page a window pops up with the messege: "Something is wrong with the backup: ", just like that. No error code or anything.
Can someone help me how to diagnose this issue?
Thank you in advance!!

2

Check journalctl -u mailinabox It might provide a hint.

3

Seeing failed backups here, too. Journal shows invalid password and logs "Mail-in-a-Box Management Daemon: Failed login attempt from ip … "

There were unattended upgrades to Duplicity and others yesterday:

Start-Date: 2025-06-19 19:10:09
Commandline: apt-get -y upgrade
Upgrade: linux-tools-common:amd64 (5.15.0-141.151, 5.15.0-142.152), duplicity:amd64 (3.0.4-ppa202502081832~ubuntu22.04.1, 3.0.5-ppa202506191602~ubuntu22.04.1), linux-libc-dev:amd64 (5.15.0-141.151, 5.15.0-142.152)
End-Date: 2025-06-19 19:10:18

This is likely the relevant error:

Fatal: reverse password verification check failed: Password mismatch

4

Hi !
Same problem on my system. The last successful backup was yesterday (16-06-2025)

journalctl -u mailinabox tells me the following:

Jun 20 02:17:38 box.oppers.eu start[64037]: Traceback (most recent call last):
Jun 20 02:17:38 box.oppers.eu start[64037]: File “/usr/bin/duplicity”, line 5, in
Jun 20 02:17:38 box.oppers.eu start[64037]: from duplicity.main import dup_run
Jun 20 02:17:38 box.oppers.eu start[64037]: ModuleNotFoundError: No module named ‘duplicity.main’

Something happened yesterday to cause this i guess. No idea what.
My system (ubuntu on a vps) is fully updated and patched and all that. Updates are installed every night (when available).

I read more people having this. Could it be some system or app update that did not play nice with miab? If so, how do i downgrade duplicity to yesterdays state?
I tried running the miab installer (i thought it might overwrite some things maybe), but that didn’t work.
pip install duplicity maybe? it looks like python doesn’t find that module
I have no idea and i really don’t want to mess with my box too much :slight_smile:

:man_shrugging:

5

Probably duplicity has a bug in it’s release again. I recommend holding the duplicity package once this is resolved (apt-mark hold duplicity) I myself forgot to do that :frowning:

6

Since the v72 upgrade I’m getting this error when running backups:

Traceback (most recent call last):
File “/usr/bin/duplicity”, line 5, in
from duplicity.main import dup_run
ModuleNotFoundError: No module named ‘duplicity.main’
Something is wrong with the backup:

A similar message comes from checking duplicity version:
duplicity --version
Traceback (most recent call last):
File “/usr/bin/duplicity”, line 5, in
from duplicity.main import dup_run
ModuleNotFoundError: No module named ‘duplicity.main’

7

Hey guys as a temporary workaround - ‘apt remove duplicity’ and then cd to /var/cache/apt/archives/ and then ‘dpkg -i duplicity_3.0.4-ppa202502081832~ubuntu22.04.1_amd64.deb’ and last ‘apt-mark hold duplicity’ as KiekerJan suggests

8

I could not get a success with "dpkg -i duplicity_3.0.4-ppa202502081832~ubuntu22.04.1_amd64.deb’

However, this worked for me:
apt remove duplicity
snap install duplcity --classic
sudo ln -s /snap/bin/duplicity /usr/bin/duplicity

Backup ran fine after that.

9

See this topic for some more explanation on using Snap instead of the ppa as duplicity source.

10

I have fixed my 3 MIAB Servers as follows:

  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

  2. FTP the .deb to your server home dir

  3. run: sudo dpkg -i duplicity_3.0.4-ppa202502081832~ubuntu22.04.1_amd64.deb

  4. sudo apt-mark hold duplicity

And sit back and wait for the replacement 3.0.5 PPA to come out.

4 Likes
11

May I suggest / lobby for a change for the MiaB installer? Seeing that duplicity is now a repeat offender (of automatically pushing update that breaks it), aren’t we better off having the installer hold duplicity by default and force a change to a known good version only during MiaB version upgrades that’s been tested against the specific version?

When your backup system fails at the wrong moment, as happenend to me this time round, it can get quite hairy.

As it turned out, it wasn’t the MiaB version upgrade that broke it, but the update of duplicity it triggered. For others it broke as a result of unattended updates.

I’m (reasonably) certain I checked that directory on my system and didn’t find that file there.

Plus the listing for 3.0.4 explicitly stated that it was removed from disk. I didn’t know about the +archive in the url to find it there. Good to know.

1 Like
12

I think that is a good plan. Based on the previous issues with duplicity i already keep it on hold. Feels like new release of duplicity are more beta than final versions.

13

Thanks that worked for me I was going crazy wondering why my server wasn’t backing up correctly in my home lab

1 Like
14

I advocated for that back when duplicity blew up on me before. I got told to shut up about it. :face_with_diagonal_mouth:

The stable snap release is the duplicity author’s preferred distribution channel and has been problem-free ever since I swapped. The biggest issue that has cropped up is a nuisance message about the python release being used by the snap release channel.

15

I downloaded and manually installed the 3.0.4 (as described higher up in the comments), and added /etc/apt/preferences.d/pin_duplicity.pref:

Explanation: Duplicity versions 3.0.1* and 3.0.5* have bugs and should not be installed

Package: duplicity
Pin: version 3.0.1*
Pin-Priority: -1

Package: duplicity
Pin: version 3.0.5*
Pin-Priority: -1

You have my vote for holding duplicity to a known and tested stable version.

16

That should have been: sudo snap install duplicity --classic

17

It appears Duplicity 3.0.5.1 is released and it works

Get:1 Index of /duplicity-team/duplicity-release-git/ubuntu jammy/main amd64 duplicity amd64 3.0.5.1-ppa202506251611~ubuntu22.04.1 [404 kB]
Fetched 404 kB in 3s (150 kB/s)
(Reading database … 145817 files and directories currently installed.)
Preparing to unpack …/duplicity_3.0.5.1-ppa202506251611~ubuntu22.04.1_amd64.deb …
Unpacking duplicity (3.0.5.1-ppa202506251611~ubuntu22.04.1) over (3.0.4-ppa202502081832~ubuntu22.04.1) …
Setting up duplicity (3.0.5.1-ppa202506251611~ubuntu22.04.1) …

i will be putting a hold on future updates however

18

It moves the responsibility to us (or to me) to update duplicity if there are security fixes or incompatibilities with other Ubuntu packages that are updated. We take that responsibility already for Roudcube, so we can do that for duplicity, but just keep it in mind it makes things harder.

The next problem is where to get the .deb from. We saw that the version that we wanted in this case had been removed from Launchpad. Is there a place we can reliably download a pinned version from?

2 Likes
19

I can’t comment for anyone else, but I picked up 3.0.4 from launchpad when 3.0.5 broke the backups.

20

Yeah, I’m trying not to be insensitive or demanding about the workload realities, but after a lifetime spent managing production systems I can attest to the fact that backups are exceptionally weird things. When all runs well you need a high degree of discipline to even remember they exist. Then that day arrives where regardless of who was at fault, last night’s backup is all that’s standing between you and the abyss. If at that point your backup software won’t let you even check on the state of your backups, let alone execute on your well-laid plans for using various backups and restores to bring everything back from the brink of extinction you’re staring instant PTSD squarely in the face. I’d argue that no effort spent making the backup solution on which you stake your sanity rock solid would be wasted effort.

That said, from the comments I received on the various posts I made about what happened to me recently when two separate things went wrong at the same time, it would seem to be three possible approaches.

  1. Outright hold on duplicity until someone goes through a battery of tests to clear any new versions for use with MiaB and a forced update during a MiaB version upgrade.

  2. A black-list of known problematic releases, along with a fallback release and where to find it, populated by adverse reports from community members as we’ve now seen with two such releases of duplicity.

  3. A white-list of known good releases, populated based on feedback from potentially several more technically savvy users running modified configs which wildcards the whitelist and reports or their absence as duplicity automatically updates as a result.

As for where to find them, in my panic I was admittedly duped by the launchpad listing stating that the replaced version was deleted from disk (with a date even) because I didn’t know about the +archive option in the url. So the old version was still on launchpad, it just took someone in the know how and where to find it. Perhaps @terrytokyo can help us find the “official” way to get to the archived builds.

It would have made my life that weekend a lot easier if the location of the old file was publisised sooner. For interest’s sake, how I dealt with (not finding the old .deb file) was to restore the duplicity code from a machine backup, made another duplicity backup, fully restored the machine(s) from the machine backup which restored the old duplicty version properly, then held the updates on that and restored the mail backup made earlier. Complicated, and stressful, but it worked.