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

What type of hardware are you using: Raspberry Pi 3, 4+
What YunoHost version are you running: 11.3.0.2
How are you able to access your server: The webadmin
SSH
Direct access via physical keyboard/screen
Other(?)
Are you in a special context or did you perform specific tweaking on your YunoHost instance ?: Yes, some custom postfix, fstab, symlinks

Describe your issue

I’m having trouble with a migration I need to do.
I’m making fresh backups now but I have Yunopastes for the last failed attempt.
Old thread here for reference:

Share relevant logs or error messages

  • Transmission (not the biggest deal, there’s not much config to do if I have to start form scratch)
  • Synapse (I would rather not lose our chat history)

Some recovered services are having issues:

  • *arr are giving me radarr.service: Failed to execute /var/www/radarr/Radarr: No such file or directory
  • same as above for vaultwarden
  • Syncthing isn’t telling me anything useful
  • My Trilium backup is ancient. Can I extract the db file from the archive and use that on a new install of the app?

EDIT:

...
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)

Does it work if you manually create the missing directory?

edit: by the way,

“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.

@wbk I guess an rsync could work? I have both systems running on my LAN. Basically what’s going on is my initial system was a Pi3, so 32-bit. The same disk is now in a Pi 4 but a bunch of stuff is broken not only due to upgrading from a 32-bit system but also me wrecking the environment by using it for dev. I just want to start fresh from an OS/system perspective but not toss any app data. A lot of stuff I’m doing by symink to a NAS as well.

I’ll try the specific things you recommended here shortly.

Ok so for synapse:

  • Tried restore on original system, here’s the yunopaste: Yunopaste
  • There’s no matrix-synapse directory in /opt/yunohost
  • Running the setuptools install just tells me all requirements satisfied.

Nextcloud:

  • I ran sudo mkdir /var/log/nextcloud on the target system. Result. Did you mean make the folder inside the archive?
  • I do have the data backed up separately but it’s encrypted! Worst case I can use the decryption tools but I need to config.php for those.

Hi, sorry for not replying any sooner.

You could have a look what you can find there. On my Yunohost/Debian 12, it is a newer version:

$ sudo ls /opt/yunohost/matrix-synapse/lib/python3.11/site-packages/ |grep cffi
cffi
cffi-1.17.1.dist-info
_cffi_backend.cpython-311-x86_64-linux-gnu.so

You could try installing cffi manually (even though it lists 1.17 above, apt provides 1.15 which may be the case on Debian 11 and may be sufficient for your needs)

Sorry, looking at the log, it seems that warning was expected.

No, I thought of the actual target. You ran sudo, so it will be owned by root. You could try chown nextcloud:nextcloud, but maybe the user does not exist prior to the restore. In that case chmod 777 so that the restore has access, and correct afterwards : chown nextcloud:nextcloud /var/log/nextcloud && chmod 750 /var/log/nextcloud

You mean config.php from Nexctloud, don’t you? That can be found in Yunohost’s backup.

For your prior post:

Reading the mess you’re in, I can imagine :rofl:

When reinstalling, at least use the Yunohost system backups to restore the user IDs. If not, your backed up data will have mismatched (numerical) user IDs, giving permission errors in your system and headaches in your head.

Ok, I managed to decrypt all the nextcloud files, so a from scratch install for that is actually fine at this point. No point chasing it further. I’ve also figured out how to manually backup what I need from most the individual apps that aren’t restoring, mostly through the apps themselves.

So now it’s down to synapse alone.
Tried installing cffi with pip3 and sudo pip3, same thing.

Thanks a million for helping me thoough this!

“same”, as in “no good”?

You could try activating the backports repository in your sources.list, and installing matrix-synapse via apt after updating. Just to see that it is installable; don’t run apt upgrade, that will pull in newer packages for many more applications.

If installing worked, remove it again, and try restoring the backup once more. Perhaps having the backports repository available, some little bit newer versions will help you get across the line.

Take note, I wouldn’t suggest this if:

  • your server was not messed up yet
  • you did not intend to reinstall from scratch

Having the backports activated may interfere with the tested upgrade path for Yunohost, but once you got the data you are looking for and made a backup, you could try running the migration to Yunohost 12 once more.

@wbk
I found a method to do that manually too so I’ll try that.

Now I installed a fresh copy of the RPi image on the second machine. I restored the system no problem and did all my custom config stuff. AdGuardHome won’t recover through Yuno but no problem, very easy to do manually…if I could get the damn app to install.

https://paste.yunohost.org/raw/egeriyupaq

Apparently the system backup comes with app permissions? Again, this is the new system with 0 apps. No idea why it’s whining about vaultwarden permissions.