StateWarden protège les machines virtuelles Proxmox VE sans installer le moindre logiciel dans les systèmes invités. L'agent StateWarden s'exécute directement sur l'hôte Proxmox et protège chaque VM de cet hôte via la couche hyperviseur. Ce guide explique le fonctionnement de la protection sans agent, la façon dont les sauvegardes des VM en cours d'exécution ou à l'arrêt sont produites, ainsi que les trois chemins de restauration : restauration sur place, clonage en nouvelle VM et Instant Boot.
Prérequis : l'hôte Proxmox VE exécute l'agent en version 1.2.0 ou ultérieure, installé et appairé comme n'importe quel autre appareil Linux. Maintenez l'agent de l'hôte à jour - la version 1.6.1 a corrigé un échec de sauvegarde qui affectait certaines VM multi-disques.
1. Ce que signifie la protection sans agent
La protection sans agent repose sur un modèle d'exploitation simple :
- Installez l'agent sur l'hôte Proxmox VE lui-même (voir Installation de l'agent) et appairez-le à votre Realm (voir Appairage de votre premier appareil).
- L'hôte s'enregistre dans le Dashboard en tant qu'hyperviseur. Ses machines virtuelles apparaissent automatiquement comme appareils enfants de l'hyperviseur - aucune étape d'appairage, aucun identifiant invité, aucune empreinte à l'intérieur de la VM.
- Chaque VM dispose de sa propre vue d'appareil, qui présente sa configuration matérielle virtuelle (vCPU, mémoire, disques virtuels) et son état d'alimentation. Les sauvegardes, restaurations et montages se gèrent par VM, depuis les mêmes vues du Dashboard que pour les appareils physiques.
Comme tout le travail s'effectue au niveau de la couche hyperviseur, le système d'exploitation invité est sans importance pour la protection : Windows, Linux et les appliances sont traités de la même manière.
2. Fonctionnement des sauvegardes de VM
VM en cours d'exécution : snapshots sans interruption
Pour une VM en cours d'exécution, l'agent communique avec le processus QEMU de la machine virtuelle via le QEMU Machine Protocol (QMP) et crée un overlay QCOW2 temporaire (une technique appelée fleecing). L'invité continue d'écrire dans l'overlay pendant que l'agent lit l'image de base figée. Le résultat est un snapshot figé avec précision et cohérent au niveau applicatif, pris sans mettre la VM en pause ni la figer - le système invité n'est pas interrompu et ne remarque rien.
Sauvegardes incrémentales : suivi des blocs modifiés
Les sauvegardes de VM utilisent les dirty bitmaps de QEMU pour le Changed Block Tracking (CBT). L'hyperviseur enregistre quels blocs de disque ont changé entre deux exécutions de sauvegarde, et l'agent ne lit que ces blocs pour les transmettre au moteur de déduplication. La première sauvegarde d'une VM constitue la référence complète ; les suivantes sont incrémentales. Pour la façon dont le CBT interagit avec les planifications et la conservation en général, voir Maîtriser Smart CBT : sauvegardes incrémentales.
VM hors tension
Les VM éteintes au niveau de l'hyperviseur restent entièrement visibles et gérables dans le Dashboard. Vous pouvez planifier et exécuter des sauvegardes d'une VM à l'arrêt sans réveiller le système invité ; ces sauvegardes sont cohérentes en cas de crash (crash-consistent), c'est-à-dire qu'elles reflètent l'état des disques virtuels au repos.
VM multi-disques
Les VM dotées de plusieurs disques virtuels sont entièrement prises en charge. Tous les disques sont capturés avec des couches d'écriture isolées par disque, de sorte que des disques parallèles issus de la même sauvegarde ne peuvent pas interférer entre eux. La configuration matérielle de la VM est capturée avec les données des disques, afin que les restaurations reproduisent la machine d'origine à l'identique.
3. Options de restauration
Ouvrez la VM dans le Dashboard, choisissez un point de restauration et sélectionnez l'une des trois cibles de restauration.
Option A : restauration sur place (écrasement de la VM d'origine)
L'agent arrête la VM proprement (avec escalade vers un arrêt forcé si l'invité ne s'éteint pas à temps), réécrit le contenu du point de restauration sur les disques virtuels de la VM, puis la remet sous tension.
C'est le chemin le plus rapide pour ramener une VM cassée ou compromise à un état sain connu. Elle est destructive : l'état actuel de la VM est remplacé par le point de restauration.
Option B : clonage en nouvelle VM
L'agent provisionne une machine virtuelle entièrement nouvelle sur l'hyperviseur à partir du point de restauration. La VM d'origine n'est pas touchée. Un identifiant de VM libre est attribué automatiquement, et vous sélectionnez le datastore cible pour les nouveaux disques.
Pour permettre à un clone de fonctionner côte à côte avec l'original, StateWarden modifie automatiquement les identifiants matériels intégrés à la machine restaurée :
- un nouvel UUID système (
smbios1), - un nouvel identifiant de génération (
vmgenid), - des adresses MAC régénérées sur toutes les interfaces réseau virtuelles.
Cela garantit que le clone n'entre pas en collision avec l'original, ni sur le réseau ni lors des vérifications d'identité côté invité. Si la VM d'origine est toujours en cours d'exécution et que vous souhaitez une protection supplémentaire, utilisez l'option d'isolation réseau au moment de la restauration : le clone démarre alors sans aucune interface réseau virtuelle attachée, et vous pourrez le connecter à un réseau plus tard depuis l'interface Proxmox.
Option C : Instant Boot
Instant Boot démarre la VM directement depuis le flux de sauvegarde en quelques secondes, sans attendre une copie complète des données. L'agent expose le point de restauration à l'hyperviseur sous la forme d'un Network Block Device (NBD) ; les lectures sont diffusées à la demande depuis la sauvegarde dédupliquée, et les écritures sont absorbées par une couche Copy-On-Write locale. La sauvegarde elle-même n'est jamais modifiée.
Les VM Instant Boot sont visiblement marquées TEMPORARY dans le Dashboard. Elles sont prévues pour deux situations : vérifier qu'une sauvegarde démarre, et assurer la continuité pendant qu'un stockage d'origine est indisponible.
Lorsque la VM doit rester, utilisez l'action Rendre permanente affichée sur la VM. Elle effectue une migration de stockage à chaud : le contenu des disques est copié vers un stockage physique de l'hyperviseur (un datastore que vous sélectionnez, par exemple local-lvm) au moyen d'une tâche QEMU blockdev-mirror, pendant que le système invité continue de fonctionner et de servir le trafic. Une fois la copie terminée, les E/S basculent sur le disque physique et la couche NBD temporaire est démantelée - sans aucune interruption pour l'invité.
Pour une récupération au niveau fichier plutôt qu'une machine complète, montez un disque de VM individuel depuis un point de restauration au lieu de le démarrer ; voir Instant Mount : récupération de fichiers via iSCSI natif.
4. Notes d'exploitation
Quota d'appareils
Les machines virtuelles ne consomment pas le quota d'appareils du Realm. Seul l'hôte hyperviseur appairé compte comme un appareil, quel que soit le nombre de VM qu'il héberge. Le stockage écrit par les sauvegardes de VM compte dans le quota de stockage du Realm comme toute autre sauvegarde. Voir Comprendre les quotas et le Fair Use.
Politiques de réponse sur les hyperviseurs et les VM
Les politiques de réponse aux ransomwares se comportent différemment dans un contexte de virtualisation :
- Les remplacements par VM sont inertes. Une VM n'a pas d'agent propre ; elle est gérée par l'agent de l'hôte parent, c'est donc la politique effective de l'hyperviseur qui s'applique. Un agent applique une seule politique.
- Le verrouillage réseau et la mise hors tension ne sont jamais exécutés sur les hôtes hyperviseurs. Si la politique de l'hôte prévoit l'une de ces actions, l'agent consigne un avertissement à la place, afin qu'une action de réponse ne puisse pas couper toutes les VM invitées d'un coup.
Les détails de configuration sont traités dans Ransomware Protection : politiques de réponse.
Protégez l'hyperviseur lui-même
La protection sans agent couvre les invités, pas le système d'exploitation propre de l'hôte. Protégez l'hôte Proxmox comme n'importe quel autre appareil Linux : attribuez-lui une politique de sauvegarde couvrant ses disques système, afin que l'installation de l'hyperviseur elle-même puisse être reconstruite par une restauration bare metal en cas de panne de l'hôte. La procédure est décrite dans le Guide Bare Metal Recovery.
StateWarden : la résilience par l'ingénierie.