Sauvegarder un site sur un NAS avec Restic

Un volume Docker persistant ou une archive conservée sur le même VPS ne suffit pas. Une vraie sauvegarde doit rester disponible après la perte du serveur principal et sa restauration doit être vérifiée.

L’architecture retenue

Le serveur produit d’abord une copie cohérente de la base, crée une archive contrôlée par SHA-256, puis l’envoie dans un dépôt Restic chiffré sur un NAS distant. Un heartbeat confirme le succès uniquement après la copie distante.

1. Identifier les données à protéger

Listez les bases de données, fichiers envoyés par les utilisateurs, configurations non reproductibles et secrets conservés hors du dépôt. Les images de conteneurs et le code Git sont généralement reconstructibles ; les données applicatives ne le sont pas.

2. Créer une copie SQLite cohérente

Copier directement une base SQLite active peut ignorer les écritures présentes dans le journal WAL. Utilisez l’API de sauvegarde SQLite, puis contrôlez la source et la copie.

python3 - <<'PY'
import sqlite3
source = sqlite3.connect("file:/data/database.sqlite?mode=ro", uri=True)
target = sqlite3.connect("/tmp/database.sqlite")
source.backup(target)
assert target.execute("PRAGMA integrity_check").fetchone()[0] == "ok"
target.close()
source.close()
PY

3. Archiver et vérifier localement

Créez une archive datée et sa somme SHA-256. Cette copie locale facilite une récupération rapide, mais elle reste insuffisante seule.

tar -czf "/var/backups/site/site-$STAMP.tgz" -C /tmp database.sqlite
cd /var/backups/site
sha256sum "site-$STAMP.tgz" > "site-$STAMP.tgz.sha256"
sha256sum -c "site-$STAMP.tgz.sha256"

4. Relier le serveur au NAS sans exposer SSH

Un réseau privé maillé comme Tailscale permet au VPS de joindre le NAS sans redirection publique du port 22. Créez sur le NAS un compte SFTP dédié, limité au dossier de sauvegarde, et utilisez une clé SSH distincte.

5. Initialiser le dépôt Restic chiffré

Conservez le mot de passe Restic et la clé privée hors du dépôt Git, dans des fichiers accessibles uniquement à root. Gardez aussi une copie du mot de passe en dehors du serveur sauvegardé.

restic --repo 'sftp:backup@nas:Backups/site-restic' \
  --password-file /etc/mon-site/restic-password init

restic --repo 'sftp:backup@nas:Backups/site-restic' \
  --password-file /etc/mon-site/restic-password \
  backup /var/backups/site --tag site-web

6. Appliquer une rétention

Une rétention quotidienne limite l’espace utilisé tout en conservant un historique utile. Adaptez-la à votre activité et à vos obligations.

restic forget --tag site-web --keep-daily 30 --prune

7. Envoyer le heartbeat après le succès

Placez l’appel de surveillance en toute fin du script. Si la création de l’archive, la copie Restic ou la rétention échoue, aucun signal ne doit être envoyé.

8. Lire régulièrement toutes les données

Planifiez un contrôle intégral hebdomadaire. Il vérifie les index, les snapshots et le contenu des packs, pas seulement leur présence.

restic check --read-data

9. Tester une vraie restauration

Restaurez le dernier snapshot dans un dossier temporaire, ouvrez les archives, vérifiez leurs sommes et contrôlez l’intégrité de la base restaurée. Supprimez le dossier temporaire seulement après validation.

Les erreurs fréquentes

• considérer un volume Docker comme une sauvegarde ;
• archiver une base SQLite active sans prendre en compte WAL ;
• conserver toutes les copies sur le même VPS ;
• utiliser le compte administrateur du NAS ;
• envoyer le heartbeat avant la copie distante ;
• ne jamais tester la restauration.

Une stratégie simple peut déjà être solide : une copie cohérente, une archive locale, un dépôt chiffré sur une autre machine, une surveillance et un test de restauration. Le résultat attendu n’est pas un fichier créé, mais une récupération prouvée.

Publié le 5 août 2026.