Sauvegarder les machines virtuelles Proxmox VE

Ce que vous allez mettre en place

BackupZit sauvegarde les machines virtuelles (QEMU) et les conteneurs (LXC) de Proxmox VE sans rien installer dans les invités. Un petit agent tourne sur chaque nœud Proxmox, prend un snapshot temporaire de chaque invité, lit ses disques et les enregistre sur le stockage de votre choix. Une console web planifie les tâches, conserve l’historique et lance les restaurations.

• Prérequis
• 1. Console
• 2. Stockage
• 3. Agent sur le nœud
• 4. Tâche de sauvegarde
• 5. Sauvegardes cohérentes
• 6. Copie externe
• 7. Tests de restauration
• Restauration
• Configuration de l’hôte
• Limites

Prérequis

• Un ou plusieurs nœuds sous Proxmox VE 7, 8 ou 9 (basés sur Debian, le paquet Debian de l’agent convient donc).
• Un emplacement pour la console BackupZit : une petite VM Linux avec 2 vCPU, 2–4 Go de RAM et un disque de 16–20 Go. La console ne stocke elle-même aucune donnée de sauvegarde ; elle peut donc tourner comme VM dans le même cluster.
• Un stockage de sauvegarde hors du nœud Proxmox — par exemple un serveur Linux ou un NAS en SFTP, un partage SMB, un bucket compatible S3 ou un dépôt renforcé BackupZit (hardened repository). Les agents y écrivent directement.
• Réseau : les agents joignent la console sur le port TCP 8443.

Étape 1 — Installer la console

Le plus rapide sur Proxmox est l’image d’appliance prête à l’emploi backupzit-appliance.qcow2 de la page de téléchargement (Debian, PostgreSQL et la console, déjà configurés) :

1. Créez une VM sans disque : 2 vCPU, 2–4 Go de RAM, réseau VirtIO.
2. Copiez backupzit-appliance.qcow2 sur le nœud et importez-le comme disque de la VM (remplacez <vmid>) :

   qm importdisk <vmid> backupzit-appliance.qcow2 local-lvm

3. Attachez le disque importé en SCSI, faites-en le disque de démarrage et activez le QEMU guest agent dans les options de la VM.
4. Démarrez la VM. Son écran affiche l’adresse de la console web et le mot de passe initial de l’utilisateur admin. Ouvrez https://<adresse>:8443, connectez-vous et changez le mot de passe.

Sur l’écran de la VM, connectez-vous en bzadmin pour définir une adresse statique, le nom du serveur et le fuseau horaire (l’appliance démarre en UTC, et les planifications suivent le fuseau horaire de la console). Vous préférez un serveur Debian, Ubuntu, AlmaLinux ou Rocky Linux existant ? Le script d’installation en une ligne de la page de téléchargement fait la même chose.

Étape 2 — Ajouter une cible de stockage

Dans la console, ouvrez Stockage et ajoutez une cible. Choix courants pour les sauvegardes Proxmox :

Laissez Chiffrer les sauvegardes (AES-256) activé (par défaut) : tout est chiffré en AES-256-GCM sur le nœud avant de le quitter. La console affiche alors une clé de récupération — imprimez la fiche de récupération ou placez la clé dans un gestionnaire de mots de passe, loin des sauvegardes. Avec la clé, l’emplacement du stockage et ses identifiants, vous pouvez restaurer même si la console est perdue ; sans la clé, personne ne peut lire les sauvegardes.

Étape 3 — Installer l’agent sur chaque nœud

1. Dans la console, ouvrez Agents et cliquez sur Créer un jeton d’inscription. Vous obtenez un code d’inscription (BZ1-…) valable 7 jours et utilisable sur un nombre illimité de machines.
2. Téléchargez le paquet Agent Linux — Debian / Ubuntu depuis la page Agents sur le nœud et exécutez :

   apt install ./backupzit-agent_*.deb
   backupzit-agent enroll --code "BZ1-..."
   systemctl enable --now backupzit-agent

3. En moins d’une minute, le nœud apparaît sur la page Agents avec le badge Proxmox VE · N guests.

L’agent utilise les outils du nœud (qm, pct, pvesm, LVM, ZFS, Ceph). Aucun jeton d’API Proxmox ni mot de passe root n’est stocké dans la console. Dans un cluster, installez l’agent sur chaque nœud.

Étape 4 — Créer la tâche de sauvegarde

1. Ouvrez Tâches de sauvegarde, créez une tâche et sélectionnez l’agent du nœud.
2. Choisissez Machines virtuelles (Proxmox VE, Hyper-V, VMware), puis Toutes les VM (et conteneurs) de l’hôte — les invités créés plus tard sont inclus automatiquement — ou cochez des invités précis.
3. Choisissez la cible de stockage de l’étape 2.
4. Définissez une planification, par exemple chaque jour ouvré à 22 h. Une tâche peut aussi se répéter toutes les 15 minutes à 12 heures, tourner une fois par mois ou démarrer après une autre tâche.
5. Définissez la rétention. Exemple : 3 plus récentes, 7 quotidiennes, 4 hebdomadaires, 6 mensuelles gardent environ six mois d’historique avec une vingtaine de points de restauration.

Ce qui se passe à chaque exécution :

1. Un snapshot Proxmox temporaire (backupzit_…) est pris ; l’invité continue de tourner.
2. Chaque disque est lu depuis le snapshot par blocs de 1 Mio. Les blocs vides ne sont pas stockés et les blocs déjà présents dans le dépôt ne sont pas renvoyés — après la première sauvegarde, seules les données modifiées passent sur le réseau. Chaque sauvegarde reste un point de restauration complet.
3. Le snapshot est supprimé. La configuration de l’invité (CPU, mémoire, réseau, disques) est enregistrée avec la sauvegarde.

Comme les données inchangées ne sont stockées qu’une fois, une longue rétention coûte peu d’espace supplémentaire.

Quels disques peuvent être sauvegardés à chaud

Les invités arrêtés peuvent être sauvegardés sur tous ces stockages. Les disques marqués Backup: no (backup=0), les disques physiques en passthrough et les bind mounts sont ignorés et signalés par un avertissement.

Étape 5 — Des sauvegardes cohérentes au niveau applicatif

Si le QEMU guest agent tourne dans une VM et est activé dans ses options, Proxmox gèle les systèmes de fichiers de la VM pour le snapshot : bases de données et applications sont capturées dans un état propre. Sans lui, la sauvegarde est cohérente après crash — comme après une coupure de courant.

Dans une VM Debian ou Ubuntu :

apt install qemu-guest-agent
systemctl enable --now qemu-guest-agent

Dans les VM Windows, installez les VirtIO guest tools. Activez ensuite l’agent pour la VM sur le nœud (effectif après le prochain arrêt complet et redémarrage de la VM) :

qm set <vmid> --agent enabled=1

La page de chaque exécution indique, par invité, quels disques ont été lus et comment l’invité a été capturé.

Étape 6 — Garder une copie externe (3-2-1)

La règle 3-2-1 : trois copies de vos données, sur deux supports différents, dont une hors site. Ajoutez une deuxième tâche de type Copie de sauvegarde, avec la tâche Proxmox comme source et une cible externe, par exemple un bucket S3 avec Object Lock ou un dépôt renforcé dans un autre bâtiment.

• L’agent copie les sauvegardes existantes ; les VM ne sont pas relues.
• Seules les données absentes de la destination sont envoyées, chiffrées avec la clé de la destination.
• Par défaut, la copie s’exécute après chaque sauvegarde de la tâche source ; toute planification est possible, par exemple une fois par nuit sur une ligne lente.
• La copie a sa propre rétention, par exemple 7 quotidiennes sur le NAS et 12 mensuelles dans le cloud.

Les VM se restaurent depuis la copie comme depuis l’original — VM entières, fichiers isolés et restauration instantanée. Plus d’informations sur les copies immuables dans la protection contre les ransomwares.

Étape 7 — Prouver que les sauvegardes démarrent

Des blocs lisibles ne prouvent pas qu’une VM démarre encore. Sous Paramètres → Tests de restauration, activez le Test de démarrage pour les sauvegardes de VM Proxmox. Le test de restauration démarre alors chaque VM de la sauvegarde la plus récente, l’une après l’autre, sur le nœud de la tâche, directement depuis la sauvegarde, avec un nouvel ID et ses cartes réseau déconnectées pour ne pas entrer en conflit avec l’original — puis la supprime.

• Une VM réussit quand son QEMU guest agent répond à temps, c’est-à-dire que le système a démarré. Les VM sans guest agent réussissent si elles tournent pendant une minute et sont affichées comme en marche plutôt que démarrées.
• Le nœud a besoin de mémoire libre pour une VM supplémentaire pendant le test.
• En plus, un contrôle des données (mensuel par défaut) lit chaque donnée stockée et la vérifie par rapport à sa somme de contrôle, pour détecter les dégâts sur le stockage lui-même avant que vous ayez besoin de la sauvegarde.

Restauration

Ouvrez une exécution de sauvegarde (depuis la page de la tâche ou Activité) et choisissez Restaurer une VM ou un conteneur.

VM ou conteneur entier

• Restauration sur n’importe quel nœud doté de l’agent — y compris un nœud d’un autre cluster.
• En tant que nouvel invité avec le prochain ID libre (par défaut) pendant que l’original continue de tourner ; la copie reçoit de nouvelles adresses MAC. Ou avec l’ID d’origine après suppression de l’invité, en remplaçant éventuellement un invité existant.
• Choisissez le nom et le stockage des disques, et si l’invité doit démarrer après la restauration.
• Chaque restauration donne aux VM un nouvel ID de génération (vmgenid), afin que les contrôleurs de domaine Windows détectent le retour en arrière sans risque.

Restauration instantanée : la VM tourne en quelques secondes

Une restauration normale dure le temps de copier les disques. Avec Instantanément, en s’exécutant depuis la sauvegarde, l’agent sert les disques en lecture seule depuis la sauvegarde et démarre une nouvelle VM dont les écritures vont dans des overlays locaux. Quand tout vous convient, Terminer déplace les disques vers le stockage choisi pendant que la VM tourne (qm disk move) ; Abandonner la VM supprime la VM et ses modifications. La VM est aussi rapide que le stockage de sauvegarde : un dépôt sur un disque local ou un partage réseau rapide convient le mieux. La restauration instantanée concerne les VM, pas les conteneurs.

Fichiers isolés

Cliquez sur Parcourir les fichiers dans le tableau des invités d’une exécution. La console lit le disque directement dans la sauvegarde — rien n’est restauré d’abord — et permet de parcourir NTFS, ext2/3/4 et XFS, y compris dans LVM. Téléchargez des fichiers (plusieurs en ZIP) ou restaurez-les dans un dossier sur n’importe quel agent. La navigation dans la console exige une sauvegarde sur un stockage réseau (SFTP, S3, SMB, Azure ou dépôt renforcé).

Répliques pour les invités les plus importants

Sous Avancé dans la tâche, Conserver des répliques des VM maintient à jour après chaque sauvegarde une copie arrêtée de chaque invité sur un autre nœud ou cluster. Seuls les blocs modifiés sont écrits — généralement quelques secondes par sauvegarde. Si un invité est perdu, Démarrer le réplica le lance avec les données de la dernière sauvegarde, sans restauration.

En ligne de commande

Tout fonctionne aussi sans la console, par exemple pour reconstruire un nœud après un sinistre :

backupzit-agent pve list
backupzit-agent pve show    --repo ... latest
backupzit-agent pve restore --repo ... --vmid 100 --new-vmid -1 --storage local-lvm --start latest

Sauvegarder l’hôte Proxmox lui-même

Les invités ne sont que la moitié d’un nœud : définitions de stockage, réseau, utilisateurs, pare-feu, certificats et paramètres de chaque VM et conteneur se trouvent dans sa configuration. Sauvegardez-la avec une tâche Fichiers et dossiers ordinaire sur l’agent du nœud, par exemple chaque jour, avec les chemins /etc (inclut /etc/pve, le réseau et /etc/hosts) et /var/lib/pve-cluster (la base de configuration config.db). Pour une copie entièrement cohérente de la base pendant que le nœud tourne, ajoutez ceci en Commande avant la sauvegarde et sauvegardez aussi /root/pve-config.db :

# one-time: apt install sqlite3
sqlite3 /var/lib/pve-cluster/config.db ".backup /root/pve-config.db"

Pour reconstruire un nœud en panne : installez la même version de Proxmox VE avec le même nom d’hôte et la même adresse, installez l’agent, restaurez /etc/network/interfaces et /etc/hosts, arrêtez le service du cluster (systemctl stop pve-cluster), restaurez config.db dans /var/lib/pve-cluster, redémarrez le service puis restaurez les invités. Dans un cluster, rejoignez de nouveau le cluster avec le nœud réinstallé au lieu de restaurer config.db.

Limites à connaître

• Proxmox VE 7, 8 et 9 sont pris en charge. XCP-ng ne l’est pas.
• Les disques de conteneurs sur des sous-volumes ZFS ne sont pas encore pris en charge.
• Les disques raw sur stockage répertoire, NFS ou CIFS et les disques sur LVM épais ne peuvent être sauvegardés qu’invité arrêté.
• Dans un cluster, une tâche sauvegarde les invités de son propre nœud. Un invité migré vers un autre nœud est signalé par un avertissement — utilisez Toutes les VM (et conteneurs) de l’hôte sur chaque nœud pour que les invités migrés restent couverts.
• Les lecteurs cloud-init ne sont pas stockés ; ils sont recréés depuis la configuration lors de la restauration.

Et ensuite

BackupZit est gratuit et open source (AGPLv3), sans limite de VM ni de nœuds. Téléchargez-le, découvrez toutes les fonctions Proxmox ou lisez le chapitre complet sur Proxmox VE dans le guide intégré à la console. Les questions sont les bienvenues dans les GitHub Discussions. Les entreprises peuvent obtenir un support commercial de MaxZit (en anglais uniquement).