Table of Contents

Restoring Backups - restore data

The restore script

Restore data

Post-restore steps

Clean-up

More script examples

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/mcRestore
```
Note 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
```