Comment adapter les modes de sauvegarde Proxmox aux bases de données et aux serveurs de fichiers

Une sauvegarde de VM Proxmox peut être cohérente après incident sans être cohérente au niveau de l’application. Un serveur de fichiers peut récupérer proprement à partir d’un instantané du système de fichiers, tandis qu’une base de données très sollicitée peut nécessiter des hooks de gel via l’agent invité, un dump de l’application ou un bref arrêt pour garantir le point de restauration attendu.

Choisissez le mode en fonction du contrat de récupération de la charge de travail, et non selon une préférence universelle pour l’absence d’interruption. Documentez l’interruption acceptable, la méthode de cohérence, le comportement du stockage et le test de restauration qui valide chaque catégorie. Un journal de tâche réussi constitue un élément utile, mais une restauration isolée de l’application est le véritable test d’acceptation.

Classifiez la charge de travail selon ses exigences de cohérence

Pour chaque VM, indiquez l’application, l’intensité des écritures, le temps d’arrêt maximal acceptable et l’objectif de point de récupération. Un serveur de fichiers principalement statique et une base de données transactionnelle ne doivent pas utiliser le même mode simplement parce qu’ils partagent un nœud.

Déterminez si l’application dispose de son propre mécanisme de sauvegarde ou de dump. Une image de VM peut restaurer la machine, tandis qu’un dump natif de la base de données ou une sauvegarde des journaux peut fournir la récupération au niveau des transactions et la vérification nécessaires au service.

La documentation des sauvegardes Proxmox distingue les comportements snapshot, suspend et stop. Utilisez cette définition du mode avec les propres garanties de cohérence de l’application invitée.

Utilisez le mode snapshot pour les charges nécessitant peu d’interruptions

Le mode snapshot est généralement le point de départ lorsque le temps d’arrêt doit être minimal et que la pile de stockage le prend en charge. Installez et activez l’agent invité QEMU lorsque cela est approprié afin que le processus de sauvegarde puisse coordonner le gel et le dégel du système de fichiers.

La mise au repos du système de fichiers réduit le risque d’écritures en cours, mais ne crée pas automatiquement une sauvegarde de base de données vérifiée au niveau transactionnel. Utilisez des hooks de base de données, un dump préalable à la sauvegarde, la réplication ou une autre méthode prenant en compte l’application lorsque le contrat de récupération l’exige.

Conservez les dumps en dehors des chemins invités temporaires et vérifiez leur achèvement avant le début de la sauvegarde de la VM. Le guide de sauvegarde de la configuration Immich montre pourquoi un dump de base de données généré n’est utile que lorsque sa cohérence et sa procédure de restauration sont vérifiées.

Utilisez le mode stop ou suspend lorsque le compromis est acceptable

Le mode stop fournit l’état hors ligne le plus clair en arrêtant l’invité avant la sauvegarde, puis en le redémarrant ensuite. Il convient aux petits services disposant d’une fenêtre de maintenance acceptée ou aux charges dont la cohérence est difficile à coordonner en ligne.

Le mode suspend met l’exécution en pause, mais peut créer une interruption visible plus longue et ne remplace pas une préparation prenant en compte l’application. Mesurez la durée réelle de la pause sur votre stockage et votre charge de travail avant de l’appliquer largement.

Pour un serveur de fichiers domestique, le mode snapshot associé à la coordination de l’agent invité est souvent suffisant lorsque les clients peuvent réessayer et que le système de fichiers est sain. Choisissez le mode stop lorsque le service est petit, que la fiabilité prime sur la disponibilité ou qu’un test de restauration révèle des problèmes avec la capture en ligne.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Planifiez et validez chaque catégorie de sauvegarde

Créez des tâches distinctes ou des paramètres explicites par VM pour les catégories base de données, serveur de fichiers et service général. Échelonnez les invités lourds afin que la cible de sauvegarde et le datastore de production ne soient pas saturés simultanément.

Après chaque changement de mode, restaurez sur un réseau isolé. Démarrez la VM, vérifiez l’état du système de fichiers, lancez l’application, exécutez un contrôle d’intégrité de la base de données ou une requête d’exemple, puis ouvrez des fichiers représentatifs via le protocole de service habituel.

Une tâche de sauvegarde réussie n’est pas le critère de validation. La catégorie de sauvegarde n’est validée que lorsque la récupération respecte l’exigence documentée en matière d’interruption et de cohérence ; dans le cas contraire, utilisez une méthode de préparation plus robuste ou une fenêtre d’arrêt.

Foire aux questions

L’agent invité QEMU rend-il une sauvegarde de base de données cohérente au niveau de l’application ? Pas à lui seul. Il peut coordonner le gel et le dégel du système de fichiers, mais la base de données peut toujours nécessiter son propre dump, hook, point de contrôle ou mécanisme d’intégration documenté pour les instantanés.

Quel mode dois-je utiliser pour un petit serveur de fichiers domestique ? Commencez par le mode snapshot avec un agent invité fonctionnel, puis validez-le avec une restauration isolée. Utilisez le mode stop si le service tolère les interruptions et que vous avez besoin d’un état hors ligne plus simple.

Puis-je utiliser différents modes dans une même tâche de sauvegarde ? Utilisez des paramètres explicites par VM ou des tâches distinctes afin que chaque charge de travail respecte son contrat documenté de cohérence et d’interruption.