For the record, I had a trouble-free upgrade, with some different steps from the “official” guide:
I have migrated my MIAB from v57a to v60.1 without any difficulties. I followed a plan derived from the above outline, but more closely mimicing the duplicity restore, and with a couple of additional steps.
Dual boot server
In order to preserve my IP address I configured the server to be dual boot Ubuntu – either 18.04 with my existing v57a MIAB, or 22.04 with the fresh v60.1 MIAB install with exactly the same configuration (/etc/mailinabox.conf) and the initial admin email account, but otherwise no users or data.
There were (brief) downtimes for the 18.04/v57a email server any time I was booted into the 22.04/v60.1 distro. While doing such work I disabled all ports in the firewall except 22, 80, and 443 in order to prevent any bogus rejections of email to the primary domain. I ran /usr/local/bin/mailinabox a couple of times, and logged into the admin page to sanity check that MIAB plumbing was working, albeit hobbled.
Verifications
The existing 18.04/v57a server had the disk for the 22.04/v60.1 server mounted at /mnt/new so I could perform the following steps while the existing MIAB was operational.
I verified that the UID and GID for the www-data user and group were the same in /etc/passwd and /mnt/new/etc/passwd. I similarly verfied the user-data user and group. This seems like an important check. In an earlier upgrade attempt my 22.04 Ubuntu distro included an ubuntu user which caused the user-data user and group to have a different IDs from those in my existing 18.04/v57a MIAB (which has no ubuntu user).
Instead of populating /mnt/new/home/user-data from my backups (11GB, rsynced to a remote host) I copied /home/user-data onto the fresh /mnt/new/home/user-data, using rsync.
Before doing so I ran some diffs in order to see the set of files in the 22.04/v60.1 installation that would not be overwritten by 18.04/v57a files. In addition to the timestamped files in the ssl directory that are implicitly implicated as troublesome in Moving to a New Box / Testing Backups, I found keyfiles in dns/dnssec that looked like they could be similarly confusing to runtime components. I decided to remove them too.
Changes and copying files
rm -r /new/home/user-data/ssl/*
rm -r /new/home/user-data/dns/dnssec/*
# Copy credentials used for rsync backup
cp /root/.ssh/id_rsa_miab /root/.ssh/id_rsa_miab.pub /mnt/new/root/.ssh/
# Initial copy of user-data on live user-data tree -- took several mintues
rsync -av /home/user-data/ /mnt/new/home/user-data/ > ./migrate-prep-$(date '+%Y-%m-%d-%H%M-%S').log1
Any inconsistencies from running that initial rsync on a live system are corrected in the subsequent rsync below.
I then ran the following script on the old MIAB system:
#!/bin/bash
set -eu
ufw --force reset
# Just in case anything fails
ufw allow 22
ufw --force enable
(cd /root/mailinabox ; management/backup.py)
service postfix stop
service dovecot stop
service php7.2-fpm stop
service spampd stop
service postgrey stop
service mailinabox stop
# this time it's fast
rsync -av /home/user-data/ /mnt/new/home/user-data/ > ./migrate-prep-$(date '+%Y-%m-%d-%H%M-%S').log2
shutdown -h now
Updated server
I then rebooted the server to 22.04/v60.1, logged in, ran mailinabox, and then checked up on status and used my email client. Everything looked good. In my email, a few recent emails were marked as unread even though I had read them shortly before the final backup, rsync, and shutdown. Otherwise, nothing untoward in the past 36 hours, and “everything seems to work” from a couple of power users.