I am terribly and utterly sorry for making a ticket about this but I have nowhere else to go, no one to turn to. Basically, I had a Mailcow installation. Ubuntu 18.04 LTS. Works superb. I tried to migrate this installation to a new server just to make sure. You know, a backup is only a backup if you verify it works.
So I did my backup with the script.
./helper-scripts/backup_and_restore.sh backup all
And then I pick a folder such as /out/.
Then I move all my files over to an FTP location and then grab them from the new server. Verified SHA values, it's all good. On the new server I install Ubuntu 18.04 LTS, update it. Docker, Docker-compose goes up. Again, everything is normal.
Install Mailcow, it starts up, works. At this point I copy over the backup, verify the files are intact and then use the script to restore. It copies a lot of files and I see progress in the terminal. However once it's done, it's either stuck in "Waiting for database" or it rejects my admin password. Upon using the password reset I can log in, I see the queue but the domain list, mailbox is empty.
tl;dr: The backup process always fails in one way or another. I cannot restore at all.
I've been trying to migrate for a few days now. I tried copying over the .conf directly. Restore/backup while Mailcow is down, while it's up. Use all kinds of commands such as docker-compose down -v. Didn't help. Tried running update.sh, hoping it would clear things out. Nope.
What am I doing wrong? I did "RTFM", but it just says "use the script" and that's pretty much the documentation. Upon reading a dozen tickets here I tried a few more things without luck.
Please help?
Ps.: Of course I am willing to provide any logs and information you might need.
Hi,
This is not a ticket system. :)
https://mailcow.github.io/mailcow-dockerized-docs/i_u_m_migration/
It says much more than "use the script". :) It may fail, when source and destination have different mailcow "versions".
You should also always post logs, when you ask for help.
I recommend to always migrate using rsync.
Thank you @andryyy .
I will try this "manual" method in a moment. I have used this method https://mailcow.github.io/mailcow-dockerized-docs/b_n_r_restore/ but as I explained it is not really capable of migration/restoration.
Both Mailcow are the latest version, I ran update.sh before doing a backup and before restore as well. Both systems are very "pure", they only run Docker, have docker-compose and pretty much all the packages are the same. Nothing fancy, they are both fairly fresh 18.04 machines.
Do you recommend just doing a cron backup script of this /var/lib/docker/volumes/ instead of using the backup_and_restore.sh then?
Ps.: How do I include all the logs? Like is there a way to just dump them all out for such purposes? If it helps, I do see the dkim list. But the domain list is empty, the account list is empty, and I had to reset the admin password.
The backup script should also work fine. Not sure what the problem is. :) I think it will work with the rsync method. If not, I can check it remote on the destination host, if you want me to.
Thank you very much for your help and again sorry for messing up the issue tracker.
The direct restore worked fine. I am a rebel so I used .tar.gz with pigz to make a fast dump of both source folders, dumped them to the backup ftp, and then copied them over to the new server. Extracted them in place, started server, works superb.
I mean, I really don't know what to say, if you are curious I can show you the backup/setup/process through Teamviewer or whatever you prefer, maybe you can spot an error somewhere. I don't mean to make you work for free, I mean maybe there is a bug somewhere or issue or something. Like I really tried to dump the backup when Mailcow was online, when it was offline. I tried updating it. Rebooted the host. Tried everything. But it just never managed to restore itself.
Can I maybe grab some logs somewhere that could help you find out what the problem is with the backup script? I'd still love to rely on the script instead of doing hand backups of the full Docker volume dir + mailcow.
Hm, I'd need some logs right after you restored (something like docker-compose logs -f after the first start).
But I will try to reproduce it here!
jsut an fyi.. none of the restores work for me.. neither the rsync nor the copy..
i mean it copies the docker images and all that and it starts them all up on the target machine but all mailboxes are gone and the "admin" user is reverted to a default admin with default password.
so, it kinda seems to lose the db or smthg..
@awunder Make sure to install Mailcow on the new machine. Wait for it to start up. Then kill it with docker-compose down. Once it's totally gone, THEN remove the mailcow folder from /opt, and the volumes from docker. Copy the backup ones in place, go back to mailcow folder and just start it with docker-compose up -d.
Also make sure the stack/mailcow is down on the donor machine before you attempt to create the backup. This worked superb for me. I mean, it should, because you are basically just making a 100% copy of the existing install. Let me know how it goes.
@Balls0fSteel thank you.. i got on the phone with @andryyy yesterday.. there seemed to be a hickup in the restore process (or at least thats what he told me, maybe he was just too kind to tell me i fucked up.. ;) )
however, i (read: he) got it working now
@awunder So did he use the backup_and_restore.sh? And he managed to do a full backup + restore with that?
i have no idea.. he said some containers need to be up and some down during restore.. somehow my db wasnt restored or so.. he promised to update the docs
he as kind enough to help me out but it was already like 9pm, so i didnt wanna press it out of him.. looking forward to the updated docs though, as i am also pretty curious what actually went wrong
he used the backup from the backup_and_:restore.sh script though.. i made that backup from the source machine
mailcow needs to be running, when restoring the backup. Run down and up -d after restoring. :)
The script is a helper and comes with no support (well, besides mailcow support via servercow.de).
aaah.. so, a bit counter intuitive for the non-docker-envs but still a pretty noob-mistake..
thx for pointing it out
@andryyy I tried either ways but I will make a record for you and send it to you if that's okay.
@awunder Tried it that way as well, didn't help. The mailboxes/domains are missing that way, and you need to reset admin pw.
Male sure you also copied the mailcow.conf
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Most helpful comment
Thank you very much for your help and again sorry for messing up the issue tracker.
The direct restore worked fine. I am a rebel so I used .tar.gz with
pigzto make a fast dump of both source folders, dumped them to the backup ftp, and then copied them over to the new server. Extracted them in place, started server, works superb.I mean, I really don't know what to say, if you are curious I can show you the backup/setup/process through Teamviewer or whatever you prefer, maybe you can spot an error somewhere. I don't mean to make you work for free, I mean maybe there is a bug somewhere or issue or something. Like I really tried to dump the backup when Mailcow was online, when it was offline. I tried updating it. Rebooted the host. Tried everything. But it just never managed to restore itself.
Can I maybe grab some logs somewhere that could help you find out what the problem is with the backup script? I'd still love to rely on the script instead of doing hand backups of the full Docker volume dir + mailcow.