This is really stressing me out that I have no information at all about the GnuPG stuff.
root@box:~# export PASSPHRASE="$(cat /home/user-data/backup/secret_key.txt)"
root@box:~# duplicity restore --force file:///root/encrypted /home/user-data/
Synchronizing remote metadata to local cache...
Copying duplicity-full-signatures.20200412T070002Z.sigtar.gpg to local cache.
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
gpg: decryption failed: Bad session key
===== End GnuPG log =====
The other issue I was running into trying to practice the restore on the 14.04 install was
root@box:~|⇒ export PASSPHRASE="$(cat /home/user-data/backup/secret_key.txt)"
root@box:~|⇒ duplicity restore --force file:///root/encrypted /home/user-data/
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Sun Apr 12 03:00:02 2020
Error '[Errno 17] File exists' processing ssl/ssl_certificate.pem
Any ideas what I’m doing wrong so I can potentially proceed in the upgrade?
Hi @Ruseen
Please tell me what the status of your original Ubuntu 14.04 MiaB server is. Is it still up and running normally? Or has it been overwritten to make way for the new version? Also which provider are you using?
I am not an expert on duplicity by any means, but my best guess is that you are using the wrong secret_key.txt file.
Currently I have both the test server running for testing the migration and the original server still running. So I have an 18.04 on DigitalOcean and a 14.04 on OVH. I really wonder if there is anything stopping me from just rsync’ing over the home directories.
Currently I’ve managed to get past the gpg problem but now I’m running into
Error '[Errno 17] File exists' processing ssl/ssl_certificate.pem being my new problem on the destination.
Now it seems I got it “migrated” however NextCloud is struggling with the upgrade.
No, it really is the path of least resistance. But it is a little bit more involved than just rsync’ing the directories. After /home/user-data/ is rsynced you need to delete the contents of the /home/user-data/ssl/ directory, then run sudo mailinabox.
Did you run sudo mailinabox after you ‘got it migrated’ ?
Yeah so I was trying to reinstall my VPS for MailInABox and I really can’t be any more frustrated with OVH their panel is undergoing live development for whatever reason and it nuked the wrong VPS on me so not only was I in the middle of rebuilding my entire MailInABox server but this piece of trash management panel just nuked one of my clients entire VPS’s what a great day. Seems that I’ve sorted out what wasn’t documented in the migration guide with the ssl/ directory.
Resolved, there seemed to be two articles on migrating from 14.04 and I’d apparently started out on the wrong one. The newer one of the two is more complete and includes better restoration instructions. It mentions that you need to install a fresh copy of MiaB, then you need to move the /home/user-data/ directory over to /home/user-data.old/ then you’re to run the duplicity restoration from the snapshot data and then re-run the mailinabox installer. That seems far more comprehensive than what I was reading in the other one.
I’m not really entirely certain why these functions aren’t included with a couple of tests in a mailinabox restore or whatever function because there are far more complex features that require way more coding than this would take and it would make the migration feature almost perfect in one shot. But I don’t really understand a lot of the underlying tools here so I can’t really contribute[PR] my own solution.
