Proxmox peut-il sauvegarder un conteneur LXC pendant que sa base de données est en cours d'exécution ?

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Oui, Proxmox peut créer une sauvegarde pendant qu'un conteneur LXC est en cours d'exécution. Cela ne signifie pas automatiquement que la base de données à l'intérieur du conteneur est cohérente du point de vue de l'application au moment de la capture.

Considérez un instantané de conteneur en fonctionnement comme cohérent après incident, sauf si la base de données est exportée, mise en pause ou autrement coordonnée avec la sauvegarde. Le choix approprié dépend du moteur de base de données, du taux d'écriture, du temps d'arrêt acceptable et de l'inclusion de tous les chemins de données.

Distinguer la capture du conteneur de la cohérence de la base de données

Une sauvegarde de conteneur peut capturer son système de fichiers tandis que les pages, journaux et index de la base de données sont en cours de modification. Après la restauration, le moteur peut rejouer correctement son journal de transactions, mais cela correspond à une récupération après un arrêt brutal et ne prouve pas l'existence d'un point de contrôle applicatif propre.

Les montages bind et les jeux de données externes nécessitent une attention particulière. Une archive Proxmox peut être valide alors que le véritable répertoire de données de la base, le magasin d'objets ou les fichiers importés se trouvent en dehors du système de fichiers racine sauvegardé.

Pour un service peu critique utilisant une base de données avec journalisation, une récupération après incident testée peut être acceptable. Pour les données irremplaçables, ajoutez un export natif de la base de données, un point de contrôle de réplication ou une courte fenêtre de maintenance.

Choisir le niveau de protection à partir de signaux observables

Vérifiez si la base de données signale des points de contrôle propres, si les exports se terminent sans erreur et si le journal des tâches Proxmox inclut chaque volume prévu. Une latence d'écriture élevée ou un WAL qui augmente rapidement pendant la sauvegarde indique qu'une récupération plus importante sera nécessaire après la restauration.

Planifiez l'export natif peu avant la sauvegarde du conteneur et stockez-le dans un chemin inclus dans la sauvegarde. Pour les moteurs qui prennent en charge les API de sauvegarde en ligne, utilisez-les plutôt que de copier des fichiers de données actifs.

Classez le résultat à l'aide du tableau ci-dessous et inscrivez cette classification dans les notes de la tâche afin qu'un futur opérateur sache ce que l'archive peut garantir.

État observé Verdict Action suivante
Export natif plus archive LXC Voie de récupération prenant en compte l'application À privilégier pour les bases de données importantes
Instantané uniquement ; tests de restauration réussis Cohérent après incident À accepter uniquement avec un risque documenté
Chemin de données externe omis Incomplet Arrêter et élargir le périmètre de sauvegarde

Créer une tâche de sauvegarde coordonnée

Exécutez une étape préalable qui crée un export de base de données horodaté ou demande un point de contrôle. Vérifiez le code de sortie de la commande et l'espace disponible ; un export de zéro octet doit faire échouer la tâche plutôt que d'autoriser un badge de sauvegarde vert et rassurant.

Capturez le LXC après l'étape de cohérence, puis exécutez une vérification post-sauvegarde qui enregistre l'ID de l'archive et la somme de contrôle de l'export. Conservez une politique de rétention distincte pour les sauvegardes natives de la base de données afin qu'une archive de conteneur défectueuse n'efface pas la dernière bonne copie logique.

Le guide de sauvegarde Proxmox de ZimaSpace couvre la planification de la récupération des VM et des conteneurs.

Les recommandations indépendantes sur les sauvegardes Proxmox cohérentes du point de vue de l'application expliquent pourquoi un instantané en cours d'exécution et une sauvegarde prenant en compte l'application offrent des garanties différentes.

-15% OFF

Valider l'archive avec une restauration sous charge

Restaurez-la avec un ID de CT isolé et un réseau déconnecté afin d'éviter tout conflit avec la production. Démarrez la base de données, examinez les journaux de récupération, exécutez les contrôles d'intégrité et interrogez un enregistrement connu écrit près de la fenêtre de sauvegarde.

Répétez le test pendant que la production est soumise à sa charge d'écriture normale. Une sauvegarde qui se restaure uniquement lors d'un test en laboratoire au repos n'a pas validé la condition à risque à l'origine de la question.

Poursuivez les sauvegardes LXC en fonctionnement lorsque tout le stockage est inclus et que le moteur récupère régulièrement ou qu'un export natif est inclus. Arrêtez-vous et utilisez une mise en pause ou un arrêt coordonné si les contrôles d'intégrité échouent, si des montages externes sont manquants ou si l'application ne peut pas tolérer une récupération après incident.

Assistance et conseils

Plus à lire

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.