I know, I should hang my head in shame. I’m still using v0.30 on a box running ubuntu 16.04 (if I recall). I never got around to upgrading as the whole OS needed to be upgraded. I’m now ready to make the jump. I have regular local backups of the data. Is there a good guide somewhere for upgrading using the data backup?
Make a new 22.04 instance and follow the guide for fresh install and importing the backup to the fresh install >> Mail-in-a-Box Maintenance Guide
Depending on your cloud provider do make sure you reserve your old instance IPV4/IPV6 addresses and after you create the new instance reassign them to the new one. That is it!
I’m not so sure. If you’re still on v0.30, which is on 14.04, you might need to first install a new 18.04 instance, then do the backup import spiel. This way you’ll upgrade to v57.
Then you need to do the whole thing again using a 22.04 instance to upgrade to MiaB v68.
@KiekerJan He can try. The restore should be backward compatible. It is just easier to try directly to restore to Ubuntu 22.04. If the restore from a full Duplicity backup of his old duplicity ver. 0.6 works with the latest duplicity then it will save him a lot of time.
v0.40 (January 12, 2019)
Duplicity is upgraded (0.6=>0.7).
@Rickenbacker Please choose how you intend to proceed and report back if it was successful. 
Oh no.
This likely is not going to be pretty.
OP @Rickenbacker was your Ubuntu 14.04 instance’s OS updated to the last version of 14.04? If not, you’re sunk.
Honestly, depending on the number of users you have you may find it much simpler simply recreating the users and migrating the maildir’s with rsync.
Ive had good luck going from 18.04 LTS to 22.04LTS just moving the /home/user-data/ directory and then essentially “installing” miab via the install script.
Everything showed up fine once it was ‘installed’ I wonder if the same would happen from from v0.30-> v0.68
I think the right way is to import as per guidelines, i.e. restore with
sudo -E duplicity restore
@stylnchris Please describe in detail how you made a carbon copy of your mailboxes? Any cp -rp involved. The files have their own permissions?
Thanks
The “right way” would be to use duplicity – but as stated above there’s versioning stuff to worry about.
basically what I’ve done in the past is something like this:
tar -czvf user-data.tar.gz /home/user-data/
Then scp that file to the new server.
scp user-data.tar.gz root@1.1.1.1:/home/
Where 1.1.1.1 is your ip address of the new box
Then decompress it with
tar -xvf user-data.tar.gz
If you need to move it around because you decompressed it in the wrong spot you can always do a
mv /user-data/ /home/user-data
then just run the installer, you’ll want to use the exact same “box name” as you had before, and the same master email address. once you log in with that after setup is complete you will notice all the other usernames are there, aliases, domains, etc. Mail for the master email (and other email addresses) will be there also…
curl -s https://mailinabox.email/setup.sh | sudo bash
yeah - this is unsupported, but so is moving from 0.30 to 0.68… I bet it would work though
I’m not sure how much has changed in the users.sqlite file in /home/user-data/mail between 0.30 and 0.68 but I’m betting on – not a lot if anything.
I intend to use this method again once I figure out how to get another box from 18.04 LTS (quota’s fork) to 22.04LTS with quotas.
Talking to a developer to see if he can help me rework jrsupplee’s quota fork back into 22.04LTS (v0.68+) and not clobber files and hopefully merge with head of this main project.
1 Like
I guess this would be an alternative way if restore fails. Thanks!
The users.sqlite file one of the two issues. The other is owncloud/nextcloud.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.