Liste de contrôle de sauvegarde d’un serveur domestique Proxmox pour les VM, les conteneurs LXC et la configuration de l’hôte

Une sauvegarde réussie d’un invité Proxmox est incomplète si les montages bind, l’état des applications, la configuration de l’hôte, les clés ou le dépôt partagent le même domaine de défaillance.

Pour un serveur domestique exécutant des VM et des conteneurs LXC, la récupération englobe les disques des invités, les données externes, les bases de données, le réseau, les définitions de stockage, l’état du pare-feu, les mappages de passthrough, les identifiants et le processus de reconstruction d’un hôte vierge. Inventoriez ces couches avant de choisir les modes de sauvegarde, conservez une copie hors de l’hôte et validez à la fois la restauration d’un invité et une procédure de récupération au niveau de l’hôte. Cessez de retirer les anciens points de restauration dès que l’un ou l’autre test révèle une dépendance non documentée.

Cartographiez chaque couche de récupération et chaque domaine de défaillance

Répertoriez chaque VM et chaque LXC, les disques virtuels, les instantanés, les montages bind, les périphériques en passthrough, les bases de données applicatives, les partages NAS externes, les clés de chiffrement et les tâches de sauvegarde. Inventoriez ensuite le réseau de l’hôte, les définitions de stockage, l’état du cluster ou du mode autonome, les règles du pare-feu, les tâches planifiées, les sources de paquets et les notes nécessaires pour recréer les mappages matériels.

Proxmox VE peut écrire les sauvegardes des invités sur des cibles locales, NFS ou CIFS, tandis qu’un serveur de sauvegarde dédié ajoute des fonctions de dépôt. Un guide indépendant sur les choix de cibles pour les sauvegardes d’invités explique cette séparation, mais aucune de ces cibles n’inclut automatiquement les données montées dans un invité depuis un autre emplacement ni l’enregistrement de reconstruction de l’hôte.

Définissez les domaines de défaillance avant de choisir la rétention. Un dépôt situé sur le même hôte, le même pool, le même onduleur ou utilisant les mêmes identifiants administrateur que la production constitue un point de restauration utile, mais pas la copie indépendante nécessaire en cas de perte ou de vol de l’hôte, d’attaque par rançongiciel ou de destruction accidentelle du pool.

Adaptez le mode de sauvegarde à chaque charge de travail

Classez les invités comme étant sans état, serveurs de fichiers, bases de données transactionnelles ou applications mixtes. Notez si le mode de sauvegarde produit un état cohérent avec l’application ou uniquement cohérent après incident, quel agent invité ou hook intervient et quels chemins externes restent en dehors de l’archive.

Utilisez le processus ZimaSpace pour adapter les modes de sauvegarde aux charges de travail afin de choisir entre l’arrêt, la suspension ou le fonctionnement par instantané selon la charge. Une VM de bureau inactive et une base de données qui accepte des écritures ne doivent pas reposer sur la même hypothèse simplement parce que leurs tâches se terminent avec succès.

Pour les montages bind LXC et les partages montés sur l’hôte, créez des sauvegardes explicites des fichiers ou des applications avec le même horodatage de récupération lorsque la cohérence l’exige. Si l’état requis ne peut pas être coordonné, documentez cette lacune et utilisez une fenêtre de maintenance plutôt que de laisser croire que l’archive de l’invité est complète.

Protégez la configuration de l’hôte et le dépôt

Exportez un ensemble lisible de récupération de l’hôte contenant les interfaces réseau, la configuration du stockage, les définitions des VM et des conteneurs, les règles du pare-feu, les fichiers de cluster pertinents, les tâches planifiées, les points de terminaison des dépôts et un inventaire des paquets et des versions. Stockez les secrets et les clés de chiffrement dans un système d’identifiants protégé, et non dans une note de récupération publique.

Une discussion de la communauté Proxmox pose exactement la question qu’en est-il de la configuration du système restante après la configuration des archives des VM et des conteneurs. Considérez cette question comme un avertissement concernant le périmètre : la protection de la configuration de l’hôte est distincte de la sauvegarde des invités et doit être testée comme une aide à la reconstruction.

Exécutez la vérification du dépôt, l’aperçu de la rétention et la copie hors de l’hôte selon des planifications qui ne peuvent pas entrer en concurrence avec une maintenance destructive. Déclenchez des alertes en cas de tâches manquées, d’échec de vérification, de pression sur la capacité ou de dépôt inchangé alors que la production est toujours active.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Restaurez un invité et répétez une reconstruction de l’hôte

Restaurez une VM et un LXC avec des identifiants et des réseaux isolés. Démarrez les bases de données avant les applications dépendantes, rattachez les données copiées des montages bind et vérifiez la connexion, l’état des services, les enregistrements récents, les permissions des fichiers et un second redémarrage. Ne connectez pas les invités de test au stockage de production avec un accès en écriture.

Répétez ensuite une récupération sur hôte vierge avec du matériel de secours ou un hôte imbriqué jetable : installez l’hyperviseur, restaurez délibérément le réseau et les définitions de stockage, rattachez le dépôt et récupérez un invité critique. Notez chaque dépendance non documentée et mettez à jour le guide opératoire.

La liste de contrôle est validée lorsque des copies indépendantes existent, que la vérification est à jour, que les restaurations d’invités fonctionnent et que l’hôte peut être reconstruit sans le disque de démarrage défaillant. Faites remonter les clés manquantes, les bases de données incohérentes, les erreurs de dépôt ou les mappages de passthrough impossibles à reproduire avant de retirer tout ancien point de récupération.