Hello,
I need to upgrade an old Mailcow instance (very old…):

  • mailcow/unbound:1.11
  • commit 11820a4d3a89cac23741932f128724852def6aac (Mon May 18 17:13:44 2020)

My server:

  • Debian 10
  • Docker 19.03.9
  • docker-compose binary v1.25.0
  • docker compose plugin v2.24.7

The Mailcow instance has been started with docker-compose binary v1.25.0 and holds almost 500Gb in mailboxes.

My questions:

  • Can I safely run ./update.sh from this version ?
  • Will the service be down during the upgrade (I guess yes…) ?
  • How long can it take to upgrade ?

Thanks for your help

  • Hello,
    I made the upgrade this morning without any troubles with the update.sh script. Downtime was less than 5min. No errors, all new containers started correctly. My 2024-02 Mailcow is fully functional.

    I think the main point is to have a ready server with Docker up-to-date for latest Mailcow release. That means :

    • Docker Engine & Docker client >= 20.10.2
    • Docker Compose plugin >= 2.0

    That will guarantee good start of containers without errors allowing them to do the “upgrade job” they have to do on their volumes data.

    Then I confirm upgrading from 2020 release to current release is possible.

No that won’t work at all for an instance that old… there were some other posters over the last few weeks who tried and failed. Best approach would be to setup a new mailcow instance, export and import your domains and mailboxes via API and transfer the vmail volume.

And please, update regularly!

Have something to say?

Join the community by quickly registering to participate in this discussion. We'd like to see you joining our great moo-community!

I tried the same upgrade path locally on an empty instance and it worked.

First, it updated the update_script.sh. Then, I relaunched the script with --stable option and it went through the full update process without an error.

I imagine operations on data would have fail ?

    Yes,
    I started an empty instance on the old revision 11820a4d3a89cac23741932f128724852def6aac (2020) and ran the update_script.sh on it.

      franck-grenier then I would suggest creating a full backup on your live instance and restore it on the empty 11820a4d3a89cac23741932f128724852def6aac instance, THEN run the update script. Backup und restore will take their time, but in the end you can check what happens

        Well,
        I copied my old instance volumes locally and started it fully functional (still on 11820a4d3a89cac23741932f128724852def6aac revision) with old docker-compose binary 1.29.2.

        On my up-to-date system (Docker 25.0.4 + Compose plugin 2.24.7), I launched ./update.sh:

        $ ./update.sh
Checking internet connection... OK
Checking for newer update script...
Updated 1 path from 12754a3b
update.sh changed, please run this script again, exiting.

        Second launch:

        $ ./update.sh --stable
WARNING: Please see on GitHub or ask in the communitys if a switch to master is stable or not.
  In some rear cases a Update back to master can destroy your mailcow configuration in case of Database Upgrades etc.
  Normally a upgrade back to master should be safe during each full release. 
  Check GitHub for Database Changes and Update only if there similar to the full release!
Are you sure you that want to continue upgrading to the stable (master) branch? [y/N] y
...
...
...

        And… It worked.

        I’m now on 2024-02 release. All containers are started. The service seems to be fully functional. I found my domains and mail boxes back. Emails are still there. Solr search is working.

        My vmail volume was much lighter than the real one (10%). But I do not think it would make a big difference.

        Hello,
        I made the upgrade this morning without any troubles with the update.sh script. Downtime was less than 5min. No errors, all new containers started correctly. My 2024-02 Mailcow is fully functional.

        I think the main point is to have a ready server with Docker up-to-date for latest Mailcow release. That means :

        • Docker Engine & Docker client >= 20.10.2
        • Docker Compose plugin >= 2.0

        That will guarantee good start of containers without errors allowing them to do the “upgrade job” they have to do on their volumes data.

        Then I confirm upgrading from 2020 release to current release is possible.

          No one is typing