This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
Restoring Backups - restore data
Before restoring data, please ensure you have completed the previous steps. Specifically, ensure that mailcow has been started at least once to create volumes otherwise the restore script will exit with an error. Assuming we’re all good with the previous steps, let’s finish the restore.
The restore script
The restore script has sane defaults and only requires one argument, --backup-location, which is the location of your extracted borg archive on the local system. You can run the script with the --help parameter for a quick overview of all options but, let’s go over them in slightly more detail here:
| parameter | description | default | required? |
|---|---|---|---|
| -b --backup-location |
Directory containing your extracted borg backup archive. | none | YES |
| -l --log |
Path to write log file. If you specify a filename, it will be created in the current directory. If you specify a path ending with a ‘/’, the log file will be created using the default filename in that directory. If you specify a full path, the log file will be saved as such. In any case, the script will attempt to create any paths as needed. |
scriptPath/scriptName.log | NO |
| -v --verbose |
Enable verbose logging. This will output the paths of all processed (restored) files in the log file. Warning: This may lead to a large log file. | false | NO |
| --skip-mail | Skip restoring email and encryption key. | false | NO |
| --skip-sql | Skip restoring mailcow settings database (mySQL). | false | NO |
| --skip-postfix | Skip restoring postfix settings/configuration files. | false | NO |
| --skip-rspamd | Skip restoring rspamd settings, configuration and history. | false | NO |
| --skip-redis | Skip restoring the redis database. | false | NO |
| -d --docker-compose |
FULL path to the docker-compose.yml file used by mailcow. | /opt/mailcow-dockerized/docker-compose.yml | NO |
| -m --mailcow-config |
FULL path to mailcow’s configuration file (mailcow.conf). This path is also assumed to be the main mailcow directory. | /opt/mailcow-dockerized/mailcow.conf | NO |
| -t1 --timeout-start |
Number of seconds to wait for docker-compose to bring the mailcow project up before throwing an error. | 180 | NO |
| -t2 --timeout-stop |
Number of seconds to wait for docker-compose to bring the mailcow project down before throwing an error. | 120 | NO |
| -? -h --help |
Show in-script help (basically this table). | n/a | n/a |
Restore data
Based on the information above, we can restore our data easily as follows:
# run with verbose logging
./restore.sh --backup-location /var/mcRestore --log /var/log/mailcow-restore.log --verbose
# run with standard logging
./restore.sh --backup-location /var/mcRestore --log /var/log/mailcow-restore.log
In this case, I have specified our example backup location and have told the script where to place the log file. In the first example, I’ve requested verbose output so my log file will show each file that was restored and whether or not there is a problem. The verbose option is very useful when testing restore operations but, for a production server you could end up listing hundreds of thousands of mail files in your log which could be overwhelming and not very useful.
That’s it. The script will restore the SQL database then shut down mailcow and copy all the data to the proper volumes before restarting mailcow.
Post-restore steps
As with any restore operation, you should review the log to verify no errors or warnings were issued and you should verify that mailcow restarted properly. Assuming everything worked, your mailcow is fully restored!
N.B. For some reason, the Rspamd console password is not restored. All Rspamd data and history is restored, however, you must manually reset the password for Rspamd via your mailcow admin console.
If someone figures out why this is, I’d love to know!
Clean-up
After you’ve verified your backup was successfully restored, you can remove your extracted borg archive:
rm -rf /var/mcRestore
More script examples
-
Default log filename and location (same directory as restore.sh and named restore.log).
./restore.sh -b /var/mcRestoreNote that if you rename restore.sh, the default name for the logfile will change accordingly. For example, if the restore script is renamed to mailcow-restore.sh, the default logfile will be named mailcow-restore.log.
-
Only restore email, encryption key and mailcow database.
./restore.sh -b /var/mcRestore -l /var/log/mailcow-restore.log --skip-postfix --skip-rspamd --skip-redis -
Restore settings database and settings for all containers, skip email and encryption key. This might be useful if you want a clean-start on a new server with the same email addresses, configuration etc. but no old email.
./restore.sh -b /var/mcRestore -l /logs/mailcow-restore.log --skip-mail -
A very common situation is restoring email, encryption key, mailcow settings and spam database.
./restore.sh -b /var/mcRestore -l /root/mc_restore.log --skip-postfix --skip-redis -
Customized docker-compose file (this does not affect override file processing).
-
./restore.sh -b /var/mcRestore -l /var/log/mc_restore.log --docker-compose /opt/mailcow-dockerized/myMailcow.yml -
Non-standard mailcow location.
./restore.sh -b /var/mcRestore -l /var/log/mc_restore.log --docker-compose /usr/local/mailcow/docker-compose.yml --mailcow-config /usr/local/mailcow/mailcow.conf -
On some systems, docker-compose may need more time to start and/or stop. I’ll show setting both timeouts at the same time, but you can specify only one or the other as needed.
./restore.sh -b /var/mcRestore -l /logs/mcRestore.log --timeout-start 90 --timeout-stop 300