Sauvegardes chiffrées de mailcow sur Google Drive : rétention, vérification et restauration

mailcow fournit un script de sauvegarde solide, mais c’est une commande que vous lancez à la main. Rien ne le planifie, rien ne le chiffre, rien ne le copie hors du serveur, et la restauration suppose de répondre à ses questions dans le shell. Cela fonctionne jusqu’au jour où vous en avez vraiment besoin, généralement au pire moment.

Ce tutoriel explique comment transformer ce script en service que vous configurez une seule fois dans Système → Backup : exécutions planifiées avec le backup_and_restore.sh de mailcow, chiffrement GnuPG (AES-256, avec protection d’intégrité) avant que quoi que ce soit n’atteigne le disque, une copie locale et, en option, une copie sur Google Drive, la vérification sans restauration et la restauration par composant depuis la page. Le produit est Backup pour mailcow ; la référence complète se trouve dans le guide utilisateur.

Avant de commencer

• mailcow-dockerized sous Linux avec docker compose et systemd.
• Le mailcow Toolkit 0.7.0 ou plus récent de MediaLab Works — ce module est l’un de ses produits, avec sa propre licence.
• Un accès root sur l’hôte pour lancer l’installateur du Toolkit, et un accès HTTPS sortant vers medialab.works pour la vérification de licence.
• GnuPG sur l’hôte. S’il est absent : apt install gnupg.
• De l’espace disque libre dans le dossier local pour environ deux sauvegardes — une est construite pendant que les précédentes sont conservées.
• Facultatif, pour Google Drive : un compte Google et un client OAuth qui vous appartient dans Google Cloud.

Étape 1 — Installer le module

Sur l’hôte mailcow, en root, lancez l’installateur du Toolkit comme d’habitude :

sudo ./install.sh --mailcow-dir /opt/mailcow-dockerized --name <instance>

Si le Toolkit est déjà installé, mettez-le à jour depuis Système → Updates (Toolkit) à la place. L’installateur copie data/web/mlw-backup/, installe le script hôte /usr/local/sbin/mlw-mailcow-backup-<instance>, crée la table d’historique et installe le timer mlw-mailcow-backup-<instance>.timer, qui vérifie toutes les 5 minutes si une sauvegarde est due. Ouvrez ensuite Système → Backup dans le menu d’administration de mailcow.

Étape 2 — Activer la licence

Ouvrez Système → Updates (Toolkit) et trouvez la carte Backup pour mailcow : collez la clé et activez-la, ou démarrez l’essai de 30 jours. Depuis le shell, vous pouvez faire de même avec php /web/mlw-toolkit/cli.php activate mailcow-backup <KEY> dans php-fpm-mailcow.

Bon à savoir : sans licence valide, les sauvegardes planifiées et les envois vers Google Drive s’arrêtent, mais la vérification, la restauration et la suppression continuent de fonctionner. Vos données ne sont jamais prises en otage.

Étape 3 — Choisir le dossier local

Dans Settings → Local folder, saisissez un chemin absolu sur l’hôte, idéalement sur un autre disque que mailcow — par exemple /srv/backup/mailcow ou un disque monté. Le dossier est créé lisible par root uniquement. Prévoyez de la place pour environ deux sauvegardes.

Étape 4 — Définir la phrase secrète de chiffrement

Dans Encryption, appuyez sur Set avec generated (recommended). La phrase secrète est affichée une seule fois : conservez-la hors du serveur, dans un gestionnaire de mots de passe ou sur papier. Ou choisissez my own et saisissez-en une d’au moins 12 caractères deux fois.

Chaque sauvegarde devient un fichier .tar.gpg plus un manifeste JSON (composants, tailles, SHA-256, identifiant de phrase secrète, versions de mailcow et du Toolkit). Elle se déchiffre aussi avec gpg seul, sans mailcow : gpg -d mailcow-…tar.gpg > backup.tar demande la phrase secrète et redonne le dossier de sauvegarde habituel de mailcow.

Étape 5 — Planification, composants et rétention

Toujours dans Settings :

• Scheduled backups activé ou non, avec Times en heure du serveur (plusieurs possibles, par exemple 03:15, 15:15) et Days. Une sauvegarde manquée pendant que le serveur était éteint s’exécute une fois au redémarrage, et les exécutions planifiées utilisent une priorité CPU et disque basse.
• What is backed up : courrier (vmail), clés de chiffrement (crypt — nécessaires pour lire le courrier chiffré), redis, rspamd, postfix et base de données (SQL). Tous sont activés par défaut ; choisissez ce dont vous avez besoin.
• Local copies kept et Copies kept on Drive : les N plus récentes restent, les plus anciennes sont supprimées après chaque sauvegarde.
• Compression threads pour le script de mailcow.
• E-mail : en cas d’échec uniquement (par défaut), après chaque sauvegarde, ou jamais. Une adresse vide signifie l’adresse de notification du Toolkit.

Appuyez sur Back up now dans la carte Status pour lancer la première sauvegarde ; la progression et le journal s’affichent en direct.

Étape 6 — Ajouter Google Drive (facultatif)

Le module utilise votre propre client OAuth Google, ainsi l’accès à votre Drive reste sur votre serveur :

1. Dans la Google Cloud Console, créez ou choisissez un projet et activez l’Google Drive API.
2. OAuth consent screen : type External, votre e-mail comme contact support et développeur, puis Publish app (« In production »). En mode test, Google expire l’accès au bout de 7 jours.
3. Credentials → Create credentials → OAuth client ID, type Web application, avec l’URI de redirection affichée sur la page : https://<your mailcow UI host>/mlw-backup/oauth.php.
4. Collez le Client ID et le client secret dans Google Drive sur la page, Save, puis Connect Google Drive et autorisez l’accès. Google peut avertir que l’application n’est pas vérifiée — c’est la vôtre, continuez.
5. Dans Settings, activez Upload every backup to Google Drive et choisissez le nom du dossier.

Le scope est drive.file : le module ne voit que les fichiers qu’il a créés, jamais le reste de votre Drive. Les envois se font par parties de 32 MiB et reprennent après une erreur réseau. Test liste le dossier ; Disconnect révoque l’accès et les sauvegardes restent sur Drive.

Étape 7 — Vérifier sans restaurer

Dans Backups, chaque sauvegarde indique où elle se trouve (locale, Drive ou les deux). Verify déchiffre et lit toute l’archive — en la téléchargeant depuis Drive si elle n’est pas locale — sans rien restaurer. Lancez-la après la première sauvegarde puis périodiquement : c’est le moyen le moins coûteux de découvrir qu’une phrase secrète ou un envoi s’est mal passé.

Étape 8 — Restaurer par composant

Restore… vous permet de cocher les composants nécessaires, de saisir RESTORE et de confirmer. Le SHA-256 de l’archive est comparé à son manifeste, elle est déchiffrée et ses chemins sont vérifiés, puis chaque composant est restauré selon les étapes de la restauration de mailcow : les conteneurs concernés sont arrêtés puis redémarrés. La base de données arrête tout mailcow pendant quelques minutes et reprend les identifiants SQL du mailcow.conf de la sauvegarde. Ce qui a changé dans ces composants après la date de la sauvegarde est perdu. Aucune resynchronisation forcée du courrier n’est lancée ; si une boîte aux lettres semble incorrecte ensuite :

docker exec $(docker ps -qf name=dovecot-mailcow) doveadm force-resync -A '*'

Passer à un nouveau serveur

1. Installez mailcow et le Toolkit, puis activez la licence (ou restaurez sans licence).
2. Encryption → my own : saisissez l’ancienne phrase secrète. Sur un serveur qui en a déjà une, cochez for older backups only — une nouvelle phrase secrète s’applique aux sauvegardes suivantes, et les anciennes restent restaurables.
3. Google Drive : utilisez le même client OAuth et connectez ; les anciennes sauvegardes apparaissent, car le module voit les fichiers créés par son client.
4. Restore… la sauvegarde la plus récente, tous composants.

Conseils et dépannage

• Gardez la phrase secrète hors du serveur. Sans elle, une sauvegarde ne peut pas être restaurée sur un autre serveur. Les secrets propres au module (phrase secrète, accès Google) survivent à une restauration de redis, mais un serveur perdu les emporte avec lui.
• Confidentialité : les sauvegardes contiennent tout votre courrier. Elles ne quittent le serveur que chiffrées, et uniquement vers le compte Google Drive que vous connectez ; rien n’est envoyé à medialab.works hormis la vérification de licence.
• Google expire les applications en mode test au bout de 7 jours — publiez l’application comme décrit ci-dessus.
• Consultez l’historique et les journaux : l’historique complet des sauvegardes, envois, vérifications et restaurations est sur la page et dans la table mlw_bk_run ; la progression en direct est dans data/hooks/phpfpm/.mlw-toolkit/backup/run.json et run.log.
• À la main, en root : MLW_TK_CONF=/etc/mlw-mailcow-toolkit/<instance>.conf mlw-mailcow-backup-<instance> backup|verify NAME|list.
• La désinstallation avec uninstall.sh conserve les sauvegardes locales et celles sur Drive.

Pour conclure

Définissez le dossier et la phrase secrète une fois, choisissez les heures et la rétention, connectez Drive si vous voulez une copie hors site, et laissez le timer faire le reste. Vérifiez de temps en temps, et quand vous aurez besoin d’une restauration, vous cocherez des composants sur une page au lieu de répondre à des questions dans un shell. Pour en savoir plus, consultez le guide utilisateur et le changelog ; vos questions sont les bienvenues via contact ou la base de connaissances.