I attempted to move my existing 0.30 install to 0.40. I am using digitalocean so I simply did a system rebuild with ubuntu 18.04 as the new OS. After rebuilding install went smoothly and then I copied over my backup folder(encrypted) and put it in the user-data folder. Then I reran the setup guide.
After doing so though none of my settings are restored. For instance prior to upgrading to v0.4 I had 2 domains setup along with user accounts. Since upgrading all of that is wiped/gone.
You stated that you copied the encrypted backup folder over, but did you actually restore the backup?
If you were using the default backup method, which stores backups on the box itself, then you should have already copied the backup files and encryption key off the old box to somewhere safe. Using any SFTP program like FileZilla (or scp if you know how) copy your backups from wherever you stored them to somewhere on your new machine.
Then restore the files:
export PASSPHRASE=$(cat /path/to/secret_key.txt)
sudo -E duplicity restore --force file:///path/to/backup /home/user-data/
Please note that the backup files need to be stored somewhere other than where they are going to be restored to.
@alento just to clarify so your saying I have to copy over the encrypted folder to a new location like just /home and then run the following
export PASSPHRASE=$(cat secret_key.txt)
sudo -E duplicity restore --force file:///home/encrypted /home/user-data/
Is that above correct for how I would run it? I found the instructions not very clear. I also just assumed which is my fault, that it would be a similar restore process then what I used prior to 0.3 which was more or less just copy/pasting the folder and key over.
You also have to specify where your secret_key.txt file is located, too.
Yes. Although I wouldn’t expect your system to have a user named encrypted, so perhaps a better location would be /tmp/encrypted
Basically, yes. From the command line you would enter:
export PASSPHRASE=$(cat /path/to/secret_key.txt)
and
sudo -E duplicity restore --force file:///tmp/encrypted /home/user-data/
@alento if I copy/paste the folder /encrypted to /home then I would use the following command
sudo -E duplicity restore --force file:///home/encrypted /home/user-data/
I tried again using the above and again it did not work. Its still missing my second domain for instance but it did seem to restore the ssl cert so I assume it semi worked. Are there other steps I need to follow for restoring with multiple domains?
What was the output generated by the duplicity restore command? Were there any errors shown?
And did you run the sudo mailinabox command again after the duplicity restore? That was noted in the original instructions, but I failed to copy it into this thread. Sorry.
The whole backup + restore process is also documented at https://mailinabox.email/maintenance.html#moving-boxes in our maintenance guide.
Your files are back in place, but you must re-run Mail-in-a-Box setup one more time to set up all of your domains and other settings.
Run:
sudo mailinabox
After that, your new box should be operating correctly.
Im not sure of the exact output(I closed it after running it and didnt log it) but it looked/seemed like it worked.
Yes I ran the sudo mailinabox command afterwards. This is when I actually thought it worked as it said restoring #1 of 2 mailinbox accounts which I took to assume to mean restoring 2 domain configurations, but after logging in only 1 was there.
Sorry for the delay in response, I have been testing it on the same machine and then if/when it doesnt work I have been reverting it back to a snapshot so it continued to work in the mean time.
So, it seems that you may have some issue happening with the backup+restore process. Might I suggest that you follow the steps in the link posted above to determine that the process makes sense and works for you. It is also possible that you are working with a corrupted backup, so testing by creating a brand new droplet may help weed out that type of issue. I know that the first time I did a backup+restore/move of one of my MiaB servers, it was a pain in the backside because I really hadn’t done it before.
The KEY things are that you have a fresh backup (and copy of the secret_key.txt file when you are ready to upgrade and that your current MiaB is running the latest version v.0.30.
On a personal note, I would not copy the /encrypted folder to /home on the new installation. I would copy it somewhere such as /tmp/encrypted or to a user home dir, but not to the root of the home directory. This may not be an issue, but is just something I have a gut feeling about.
Well testing with a new droplet is a bit of a pain as I dont have another domain to try with it. So im not sure how I would really test things. I had done backups/restores prior to this but they seemed a lot easier and just worked. Im open to any other suggestion you might have on how to resolve this but for now atleast I wont be upgrading to 0.4
It could be a corrupted backed but I thought when I run the steps and create a new one, that should remove any corrupt ones, but maybe Im wrong. Is there anyway to check the integrity of a backup?
Yeah as the folder /encrypted I can move it somewhere else and try but have little faith. I just wanted to make things simple and be 100% I was doing things right.
You would not need another domain. You are testing the backup/restore process, You would not be making this droplet live. So there are parts of the process that you would skip and ignore.
From what you said in previous posts, I am at a loss on how the prior backup+restores you did actually worked. It has always been more than copy/pasting the encrypted files over, so I am just at a loss how you managed to accomplish this.
There is a process where you can completely start from scratch with a new backup:
That could be, subject to the amount of data to backup, a high resource consuming task then, before to proceed recommended to take a snapshot of your server.
To delete OLD encrypted backup files if stored locally, use:
rm /home/user-data/backup/encrypted/*
To manually recreate a new full encrypted backup use:
/root/mailinabox/management/backup.py --full
I am not certain what method exists to check the integrity of a backup other than the procedure of restoring it would be.
Thanks, that seems to have done the trick, it took about a minute to make a new fully encrypted backup and then restoring(this time putting the files in /tmp) it restored with all my data.
After rebooting after everything was installed though I got the following email dated about 10mins prior. Im thinking its maybe related to when I installed mailinabox with my backup on another droplet to test it, but wanted to be 100% sure before I just ignore it. Email below,
Postfix SMTP server: errors from unknown[Some Unknown IP Here]
Transcript of session follows.
Out: 220 box.domain.here ESMTP Hi, I’m a Mail-in-a-Box (Ubuntu/Postfix; see
https://mailinabox.email/)
In: EHLO [Same Unknown IP from subject]
Out: 250-box.domain.here
Out: 250-PIPELINING
Out: 250-SIZE 134217728
Out: 250-VRFY
Out: 250-ETRN
Out: 250-STARTTLS
Out: 250-ENHANCEDSTATUSCODES
Out: 250-8BITMIME
Out: 250-DSN
Out: 250 SMTPUTF8
In: STARTTLS
Out: 454 4.7.0 TLS not available due to local problem
Session aborted, reason: lost connection
For other details, see the local mail logfile
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.