Documentation

Sauvegardes et restauration

Sous Administration → Sauvegarde et restauration, vous créez et gérez les sauvegardes.

Ce qui est sauvegardé

• base de données MySQL/MariaDB
• stockage des blobs (pièces jointes et corps des messages)
• réglages du serveur (optionnel)
• clés DKIM (optionnel)

Ce qui n'est pas sauvegardé

• L'index de recherche plein texte. Il est dérivé et est reconstruit après une restauration — voir l'étape 4 plus bas. Sans cette étape, la recherche ne trouve rien, même si toutes les données sont présentes.
• Le certificat TLS. Sur une nouvelle machine, le serveur en obtient un nouveau dès que les entrées DNS pointent vers elle.

Restauration via l'interface

1. Téléversez l'archive de sauvegarde.
2. Choisissez la cible de restauration (complète ou sélective).
3. Le serveur redémarre après la fin, si nécessaire.

Restauration via la ligne de commande

C'est la voie pour le cas d'urgence. L'interface cesse d'exactement répondre au moment où vous en auriez le plus besoin — base de données hors service, version à moitié déployée, répertoire supprimé.

La commande fonctionne sans serveur en cours d'exécution et refuse de s'exécuter tant qu'un serveur répond. C'est voulu : pendant que le dump est chargé, un service en cours travaille sur les mêmes tables, et le résultat est un mélange de deux états qui ne se remarque que des jours plus tard.

# Afficher les sauvegardes disponibles
sudo annexgroup restore-backup --list

# Arrêter le service
sudo systemctl stop annexgroup

# Restaurer
sudo annexgroup restore-backup annexgroup-backup-20260831-090000.tar.gz

Déplacement vers une autre machine

La raison la plus fréquente d'une restauration n'est pas un sinistre, mais un déménagement : l'ancienne machine doit disparaître. Le déroulement est le même, avec quatre ajouts.

1. Créer une base de données vide. Sur la nouvelle machine, avec le même jeu de caractères :

CREATE DATABASE annexgroup CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'annexgroup'@'localhost' IDENTIFIED BY '<mot de passe>';
GRANT ALL PRIVILEGES ON annexgroup.* TO 'annexgroup'@'localhost';

2. Transférer l'archive et la configuration. L'archive va dans le répertoire de sauvegarde de la nouvelle installation (<répertoire de données>/backups). Vérifiez dans la configuration les chemins data_dir et database_dsn — sinon ils pointent vers des répertoires qui n'existent pas sur la nouvelle machine.

3. Restaurer, comme ci-dessus, le service arrêté.

4. Reconstruire l'index de recherche — le service toujours arrêté :

sudo annexgroup reindex-search
sudo systemctl start annexgroup

Dans cet ordre, pas l'inverse. L'index de recherche n'accepte qu'un seul rédacteur. Si le service tourne déjà, il détient le verrou, et reindex-search s'interrompt avec un message à ce sujet.

Ensuite, comptez, n'espérez pas. Une restauration n'est prouvée que lorsque vous avez comparé les deux côtés : connectez-vous via IMAP et via l'interface web, ouvrez un message avec pièce jointe, et cherchez un mot dont vous savez qu'il apparaît.

Remarque : testez régulièrement les sauvegardes dans un environnement séparé. Une sauvegarde qui n'a jamais été restaurée est une supposition, pas une protection.