Quelle méthode de sauvegarde permet de maintenir la cohérence d'un conteneur de base de données en fonctionnement sur un NAS domestique ?

Pour la plupart des utilisateurs de NAS domestiques et de serveurs auto-hébergés, la valeur par défaut la plus sûre est une sauvegarde logique native de la base de données créée pendant que la base de données fonctionne, suivie d’une sauvegarde normale de ce dump avec la configuration du conteneur et les fichiers de l’application. Utilisez une copie de conteneur arrêté courte lorsque le temps d’arrêt est acceptable, et utilisez un instantané coordonné du système de fichiers uniquement lorsque la base de données est vidée, verrouillée, checkpointée ou autrement préparée pour l’instantané. Une simple copie d’un volume de base de données en direct n’est pas une méthode de sauvegarde cohérente.

Définir « Cohérent » comme une restauration acceptée par la base de données

Une sauvegarde cohérente n’est pas seulement un arbre de dossiers complet. Après restauration, le moteur de base de données doit démarrer, récupérer correctement les transactions, passer les contrôles d’intégrité et présenter un état à un instant donné que l’application peut utiliser. Sur un serveur domestique exécutant Immich, Nextcloud, Paperless-ngx, Home Assistant ou une autre application auto-hébergée, cela signifie que la base de données, les téléchargements, la configuration et les secrets doivent être en accord les uns avec les autres.

La persistance du conteneur explique seulement où vivent les fichiers. Elle ne rend pas une base de données en fonctionnement sûre à copier. Une base de données peut avoir des transactions actives, des pages en cache, des journaux d’écriture anticipée, des fichiers temporaires ou des métadonnées qui changent pendant que le logiciel de sauvegarde NAS lit le volume.

Méthode 1 : Utiliser un dump logique natif de la base de données comme valeur par défaut du NAS domestique

Un dump logique demande au moteur de base de données d’exporter une représentation cohérente des schémas et des enregistrements. Pour un conteneur PostgreSQL ou MariaDB modeste sur un NAS familial, c’est généralement la méthode la plus simple à planifier, inspecter, copier hors site et restaurer dans un conteneur de remplacement propre. Un guide actuel de sauvegarde Docker illustre ce modèle en exécutant des dumps natifs de base de données depuis un conteneur de sauvegarde planifié.

Écrivez le dump dans un répertoire de sauvegarde dédié en dehors du volume de données en direct. Ensuite, laissez la tâche de sauvegarde NAS protéger le dump, le fichier Compose, le modèle d’environnement, la configuration de l’application et les données téléchargées. Ne divulguez pas les mots de passe de production dans le nom du fichier dump ou dans des journaux non protégés.

Méthode 2 : Arrêter brièvement la base de données avant de copier son volume

Une copie de conteneur arrêté est simple et physiquement complète. Arrêtez d'abord les processus d'écriture de l'application, arrêtez proprement la base de données, confirmez que le processus est terminé, copiez l'intégralité du volume persistant ou du répertoire de base de données monté en liaison, puis redémarrez la pile. Un guide Docker et MariaDB décrit les copies de volumes physiques comme rapides mais dépendantes de la version et normalement liées au temps d'arrêt.

Cette méthode fonctionne bien pour un petit NAS domestique où quelques minutes de maintenance sont acceptables et la restauration utilisera une version compatible de la base de données. Elle est moins portable qu'un dump logique et peut prolonger le temps d'arrêt lorsque le volume est important. Conservez le tag de l'image de la base de données et la disposition du stockage avec la sauvegarde afin de ne pas restaurer des fichiers physiques dans une version de moteur incompatible.

Méthode 3 : Coordonner un instantané rapide avec la base de données

Les systèmes d'instantanés ZFS, Btrfs, LVM et NAS peuvent capturer rapidement un volume de base de données important, mais l'instantané doit être coordonné avec la base de données. Pour MariaDB ou MySQL, cela peut signifier une courte fenêtre de verrouillage ou de vidage ; pour PostgreSQL, cela peut signifier le processus de sauvegarde ou de point de contrôle pris en charge par la base de données ; pour une base de données gérée par une application, cela peut signifier un hook pré-instantané.

Une discussion sur les instantanés de base de données explique que une copie en direct sur disque peut être incohérente en interne à moins que la base de données soit figée ou que l'instantané soit pris de manière atomique. L'intervalle de verrouillage ou de mise en pause doit être court : préparer la base de données, créer l'instantané, libérer les écritures, puis copier l'instantané plus tard.

Cette méthode est utile lorsque la base de données est trop volumineuse pour des dumps logiques fréquents ou lorsque vous avez besoin d'un intervalle de point de récupération plus court. Elle nécessite un scriptage plus minutieux et des tests de restauration plus rigoureux qu'un simple workflow de dump pour serveur domestique.

Ne pas considérer l'image Docker ou l'exportation de conteneur comme une sauvegarde de base de données

L'image du conteneur contient le runtime de l'application, pas nécessairement les données persistantes en direct. L'exportation ou la validation du conteneur peut omettre les volumes nommés et ne demande pas à la base de données de créer un point de récupération cohérent. Un compte rendu de sauvegarde de conteneur PostgreSQL conclut que Docker save et commit ne remplacent pas les techniques de sauvegarde spécifiques à PostgreSQL.

Pour un serveur domestique ZimaOS ou Docker, gardez la définition de déploiement et le plan de protection des données séparés : conservez les fichiers Compose et les tags d’image pour pouvoir reconstruire le service, et préservez la base de données via une méthode cohérente pour pouvoir restaurer son état.

Ne copiez jamais simplement un volume de base de données en cours d’écriture

Le logiciel de sauvegarde NAS peut lire différents fichiers de base de données à différents moments. L’archive résultante peut contenir un fichier de données d’un état de transaction, un journal d’un autre et des métadonnées d’un troisième. Un aperçu des méthodes de sauvegarde SQL open-source avertit qu’une base de données en mouvement peut être capturée à un moment incohérent alors qu’un état important est encore en mémoire.

La récupération après plantage peut réparer certains instantanés capturés atomiquement, mais une copie récursive ordinaire de fichiers n’est pas atomique. Si l’application ne peut pas tolérer d’interruption, utilisez un vidage logique, un outil de sauvegarde physique supporté ou un instantané coordonné.

Traitez les conteneurs SQLite comme des bases de données, pas comme des fichiers ordinaires

De nombreuses applications pour serveurs domestiques utilisent SQLite car il est compact et facile à déployer. Le risque est que les administrateurs voient un fichier .db et supposent qu’il peut être copié pendant que l’application écrit. En mode WAL, les modifications récentes validées peuvent encore être en dehors du fichier principal. Un article pratique sur la récupération SQLite recommande d’utiliser le mécanisme de sauvegarde en ligne ou une copie propre fermée plutôt que de copier un fichier de base de données actif.

Utilisez la sauvegarde intégrée de l’application si elle en dispose. Sinon, utilisez la fonction de sauvegarde en ligne propre à SQLite ou arrêtez proprement l’application avant de copier tout le répertoire de la base de données. Ne copiez pas uniquement le fichier principal de la base de données en laissant son journal ou son état WAL derrière.

Choisissez la méthode selon l’interruption de service, la taille de la base de données et la portabilité de la restauration

Sauvegardez l’application auto-hébergée entière, pas seulement la base de données

Un paquet de récupération utilisable doit inclure la sauvegarde de la base, le fichier Docker Compose, les versions des images, les variables d’environnement ou un paquet de secrets récupérable, les réglages du reverse-proxy, la configuration de l’application, les fichiers téléchargés et toutes les clés de chiffrement. Sauvegarder uniquement le dump SQL peut restaurer les enregistrements mais laisser l’application incapable de trouver photos, documents, vignettes, certificats ou chemins de stockage.

Pour la planification de la récupération d’un serveur domestique, le guide ZimaSpace sur les bind mounts et volumes nommés explique pourquoi les chemins de stockage visibles aident à la récupération mais ne remplacent pas une sauvegarde de base de données cohérente avec l’application.

Validez la méthode en restaurant dans un nouveau conteneur

Créez une pile de test isolée avec un nouveau nom de projet, des ports hôtes différents et un répertoire de données temporaire. Restaurez le dump ou snapshot, démarrez la base, exécutez ses contrôles d’intégrité ou de cohérence, puis connectez une copie test de l’application. Confirmez que les utilisateurs, enregistrements, pièces jointes et transactions récentes sont présents.

Mesurez à la fois le point de récupération et le temps de récupération. Si un dump logique est cohérent mais prend trop de temps à restaurer, conservez-le comme couche de récupération portable et ajoutez un snapshot coordonné plus rapide. Si une copie de volume arrêté restaure rapidement mais seulement vers la même version de base, conservez un dump logique comme solution de secours pour la migration.

FAQ

Mettre en pause un conteneur de base de données suffit-il avant de copier le volume ?

Pas en règle générale. Mettre en pause fige le processus mais ne prouve pas que la base a vidé l’état correct pour une sauvegarde portable. Utilisez un dump natif de la base, un arrêt propre ou une procédure documentée de mise en quiescence et snapshot.

Un snapshot NAS seul suffit-il pour PostgreSQL ou MariaDB ?

Uniquement lorsque le snapshot est atomique et coordonné avec le processus de cohérence supporté par la base de données. Un snapshot non coordonné peut être seulement cohérent en cas de crash, et une copie de fichier non atomique peut être pire.

Que dois-je sauvegarder pour une application serveur domestique basée sur SQLite ?

Utilisez l’export de l’application ou la sauvegarde en ligne SQLite lorsque disponible. Préservez également la configuration de l’application, le fichier Compose, les secrets, les pièces jointes et le répertoire contenant la base de données plutôt que de supposer le principal. .db le fichier est l’application entière.

Recommandation finale

Utilisez des dumps logiques programmés comme valeur par défaut pour la plupart des conteneurs PostgreSQL et MariaDB sur un NAS domestique. Utilisez une copie propre du volume arrêté lorsque des temps d'arrêt courts sont acceptables, et utilisez des snapshots coordonnés ou des outils physiques natifs de la base de données lorsque la base est volumineuse ou que la fenêtre de point de récupération est serrée. Quelle que soit la méthode choisie, restaurez-la dans un nouveau conteneur avant de lui faire confiance.