Sauvegarde et restauration d'un serveur domestique — un petit exercice de restauration

Un code de sortie de sauvegarde réussi ne garantit pas qu'un service puisse redémarrer à partir des données sauvegardées. Distinguez la restauration des fichiers, la lisibilité de la base de données et les opérations applicatives nécessaires. Commencez par un exercice qui n'accède jamais aux données de production.

Définir une récupération réussie

Diagram 1 · Use the button to switch views

Un service de photos nécessite des relations entre les images et les enregistrements de la base de données. L'authentification peut également dépendre de la configuration et des clés de chiffrement. Définissez la fenêtre de perte de données acceptable (RPO) indépendamment de la durée de récupération acceptable (RTO). La fréquence de sauvegarde et le temps de restauration sont des mesures différentes.

Exécuter un exercice isolé

Enregistrez restore_lab.py et exécutez python3 restore_lab.py . Ce script utilise la bibliothèque standard Python 3.12.3. Chaque exécution crée un nouveau répertoire temporaire, un fichier texte et un enregistrement SQLite. Il n'arrête ni ne supprime aucun service ou jeu de données existant.

Le script utilise l'API de sauvegarde de SQLite pour copier la base de données, la compresse avec le fichier texte dans un fichier ZIP et la restaure dans un autre répertoire vide. Il vérifie les hachages SHA-256, PRAGMA integrity_check et une requête SQL connue. Consultez la explication officielle de l'API de sauvegarde de SQLite.

file_hashes: pass
sqlite_integrity: pass
application_read: pass
scope: synthetic fixture only

Les trois vérifications ont été réussies le 7 septembre 2026. Ici, la lecture par l'application fait référence à la requête SQL connue, et non au lancement d'Immich ou de Nextcloud. Le fichier directory imprimé contient la preuve conservée. Le fichier ZIP présent dans ce répertoire temporaire est un artefact d'exercice, et non une protection contre la perte du périphérique de stockage.

Capture cohérente des services réels

La simple copie de fichiers de base de données en production peut ne pas garantir la cohérence nécessaire à la récupération. Pour PostgreSQL, consultez les exigences des méthodes telles que les vidages SQL. La cohérence entre l'instantané de la base de données et les fichiers externes référencés est un point distinct.

La correspondance des hachages établit l'égalité avec la copie capturée. Elle ne prouve pas que l'application était entièrement cohérente au moment de la capture.

Contrôles supplémentaires avec restic

La procédure suivante s'applique à un environnement où restic est déjà installé ; restic n'a pas été exécuté dans cet exercice. Configurez le référentiel et les informations d'identification séparément et notez restic version. Sélectionnez un instantané et restaurez-le dans un emplacement vide.

restic snapshots
restic check --read-data
restic restore SNAPSHOT_ID --target /path/to/empty-restore

Remplacez l'ID et le chemin d'accès par ceux de votre environnement. La restauration et la vérification du référentiel répondent à des questions différentes. Prévoyez les coûts d'exécution et de transfert lors de la lecture des données stockées avec --read-data.

Conserver un historique de la récupération

Enregistrez l'heure de capture, le début et la fin de la récupération, le volume de données, les versions, les résultats de la vérification des fichiers et les opérations de l'application. Effectuez une vérification dans un environnement isolé avant de remplacer les données de production, en désactivant les e-mails sortants et les webhooks. L'authentification et les contrôles de lecture des fichiers transforment ce simple exercice en une procédure spécifique au service pour la plateforme serveur domestique.