Faut-il mettre en pause les conteneurs d’applications ou utiliser des sauvegardes d’applications avant un instantané NAS ?

L’approche sûre consiste à traiter le choix spécifique à la charge de travail entre une sauvegarde de l’application, une mise au repos coordonnée ou un arrêt propre avant l’instantané comme une séquence de points de contrôle observables, et non comme une simple commande.

Pour des applications conteneurisées sur un NAS compatible avec les instantanés, le risque pratique vient de l’incertitude quant à la capacité d’un instantané NAS en fonctionnement à restaurer de manière cohérente des conteneurs avec état. Consignez l’identité actuelle et le point de récupération, commencez par le discriminateur le moins intrusif, interprétez les résultats de réussite et d’échec avant de modifier une autre variable, et arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable risque d’être exposée. Le flux de travail ci-dessous ne se termine qu’une fois que la charge de travail d’origine fonctionne ou que les éléments disponibles atteignent un seuil d’escalade.

Prenez la décision de cohérence avant de toucher à la pile

Utilisez une sauvegarde native de l’application lorsque celle-ci ou la base de données en fournit une. Utilisez un hook coordonné de mise au repos et d’instantané uniquement lorsque la base de données prend en charge ce flux de travail, et utilisez un arrêt propre lorsqu’une brève interruption est acceptable. Considérez une simple mise en pause du conteneur comme cohérente après incident au mieux, et non comme automatiquement cohérente avec l’application.

Cette distinction est importante, car le comportement de mise en pause de Docker gèle les processus sans exécuter leur procédure normale d’arrêt et de vidage. Cela peut empêcher de nouvelles écritures pendant un instantané très court du système de fichiers, mais ne peut pas prouver que les tampons, journaux, pièces jointes et services dépendants de la base de données représentent un état applicatif restaurable.

Consignez le moteur de base de données, la fonctionnalité de sauvegarde de l’application, les chemins des volumes, les chemins de téléversement, les secrets, la version de l’image et la durée d’interruption acceptable. Si un composant avec état est inconnu, la décision reste en suspens et l’instantané ne doit pas être promu au rang de sauvegarde testée.

Choisissez la méthode valide la moins perturbatrice

Pour PostgreSQL, MariaDB et les autres bases de données de service, privilégiez leur processus pris en charge d’export ou de sauvegarde physique. Pour SQLite, utilisez l’export de l’application ou la sauvegarde en ligne SQLite lorsqu’elle est disponible. Capturez les fichiers téléversés et la configuration dans la même fenêtre de récupération afin que la base de données ne fasse pas référence à des fichiers manquants ou futurs.

Lorsqu’aucune méthode en ligne prise en charge n’existe, arrêtez d’abord les processus d’écriture, puis arrêtez proprement la base de données et vérifiez que les processus se sont terminés avant de prendre l’instantané. La mise en pause peut servir de solution transitoire étroite uniquement si la documentation et un test de restauration montrent que la récupération après incident suffit pour cette charge de travail précise ; elle ne remplace pas de manière générale une sauvegarde applicative.

Une petite pile de serveur domestique peut suivre les sauvegardes cohérentes de conteneurs de base de données voisines pour les exports natifs des bases de données et les copies après arrêt propre. Gardez la portée de cet article plus étroite : il détermine l’action précédant l’instantané, tandis que le guide associé couvre le contenu de l’ensemble de sauvegarde plus large.

Exécutez une fenêtre d’instantané coordonnée

Suspendez les tâches planifiées et les écritures des utilisateurs, exécutez la préparation sélectionnée de l’application ou de la base de données, puis vérifiez sa réussite avant de créer l’instantané du système de fichiers. Créez rapidement l’instantané, puis mettez fin à la mise au repos ou redémarrez la pile ; copiez ou répliquez ensuite l’instantané afin que la durée d’interruption ne soit pas égale au temps de transfert.

Ajoutez un mécanisme d’interception des erreurs à chaque hook personnalisé. Si la préparation échoue, ne prenez pas l’instantané ; si sa création échoue, reprenez toujours l’application ; si la reprise échoue, empêchez les utilisateurs d’y accéder et rétablissez délibérément le service. Consignez chaque transition afin qu’un délai d’expiration silencieux du hook préalable ne produise pas une tâche de sauvegarde faussement réussie.

La procédure est réussie lorsque l’application revient à la normale, que l’instantané possède l’horodatage et les jeux de données attendus, et qu’aucune dépendance n’a été capturée en dehors de la fenêtre. Annulez l’automatisation si un conteneur reste en pause ou si la base de données signale une récupération lors de chaque instantané de routine.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prouvez la validité du choix avec une restauration isolée

Restaurez l’instantané ou la sauvegarde native dans un projet jetable utilisant des ports et des chemins de stockage différents. Démarrez d’abord la base de données, exécutez son contrôle d’intégrité, puis connectez l’application et inspectez les enregistrements récents, les utilisateurs, les pièces jointes, les tâches planifiées et les autorisations. N’effectuez pas le test sur la base de données de production.

Une réussite exige davantage qu’un démarrage propre du conteneur : l’application doit pouvoir lire et mettre à jour l’état restauré, les fichiers associés doivent correspondre aux références de la base de données et un deuxième redémarrage doit rester propre. Comparez ce résultat avec une restauration à partir d’une sauvegarde native si vous prévoyez de vous fier à des instantanés cohérents après incident.

N’utilisez la méthode par instantané qu’une fois que la charge de travail d’origine a réussi ce test. Si la récupération fondée sur la mise en pause est intermittente, si une réparation de la base de données est nécessaire ou si un composant ne peut pas être rattaché au même point de récupération, passez à une sauvegarde native de l’application ou à un arrêt propre et conservez l’instantané défaillant comme élément de preuve au lieu de l’écraser.