Third Attempt: moving from armhf to arm64. Backups restore not working

[wbk]

@seedrick

Synapse (I would rather not lose our chat history)

...
2024-08-10 01:12:31,655: DEBUG - + '[' bullseye == bullseye ']'
2024-08-10 01:12:31,655: DEBUG - + pip3 install --upgrade setuptools==60.8.2 wheel pip
2024-08-10 01:12:31,659: WARNING - ../settings/scripts/_common.sh: /opt/yunohost/matrix-synapse/bin/pip3: /opt/yunohost/matrix-synapse/bin/python3: bad interpreter: No such file or directory
2024-08-10 01:12:31,661: DEBUG - + ynh_exit_properly
...
2024-08-10 01:12:33,191: ERROR - Could not restore synapse: An error occured inside the app restore script

Synapse is somewhat finicky when being restored from backup, in my experience. In cases there are warnings/errors, they can, with some trouble, mostly be resolved in the end.

• Are you able / willing to try to restore the backup on the original host?
• Is pip3 contained at /opt/yunohost/matrix-synapse/bin ?

For comparison, pip3 on my YNH:

# pip3 --version
pip 20.3.4 from /usr/lib/python3/dist-packages/pip (python 3.9)
# /opt/yunohost/matrix-synapse/bin/pip3 --version
pip 24.3.1 from /opt/yunohost/matrix-synapse/lib/python3.9/site-packages/pip (python 3.9)
#

I had hoped to find a log of a previous restore from backup for Synapse, but was only able to find an upgrade log. If things are broken anyway, with the backup still available, I would try running pip3 install setuptools and see what happens (it will of course take your /usr/lib/python3/dist-packages/pip, instead of the one in non-existing matrix-synapse, and possibly not 60.8.2)

@seedrick

• Nextcloud is also an issue.

Does it work if you manually create the missing directory?

edit: by the way,

@seedrick

@orhtej2

It seems like you created backup archive with BACKUP_CORE enabled, so data directory was not transferred over.

if by “full backup” you mean every box checked in the Web UI, that’s what I did. All apps AND config.

“Full backup” in case of BACKUP_CORE relates to data-heavy apps (such as Nextcloud), where an upgrade only touches app logic, not data. You’d be backing up 300GB of data for example, to upgrade the 2 GB ‘core’ of the app.

This is not the same as ticking the selection box in the “Create a backup” screen.

Completely different approach

How much data is involved in this migration? Are both systems ‘live’, running online and being actively used? Can you boot them from an alternative medium, so that the system is in rest?

Depending on the situation, running rsync between the two may be a valid alternative. Boot both systems from alternative media and mount the partitions at a convenient location:

root@old_recovery:~# rsync -aAXvz --progress --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/backup/*"} /mnt/old_ynh_root root@new_vps:/mnt/new_ynh_root

You may have multiple partitons before running the sync, depending on your /mnt/fstab.