Stratégies de sauvegarde Proxmox : snapshots, vzdump et Proxmox Backup Server

D'abord la réponse : la stratégie en trois niveaux

Pour un hôte Proxmox qui compte pour vous, la stratégie qui fonctionne est la suivante :

1. Des snapshots pour l'heure qui vient : prenez-en un avant les changements risqués (mises à jour, interventions sur la configuration), revenez en arrière si ça tourne mal, supprimez-le ensuite. Les snapshots vivent sur le stockage de la VM : ils protègent contre vos propres erreurs, pas contre l'hôte lui-même.
2. Des sauvegardes vzdump planifiées pour le mois qui vient : des sauvegardes en mode snapshot selon un calendrier, avec des règles de rétention, vers un stockage qui n'est pas les mêmes disques que ceux sur lesquels tournent les VM.
3. Proxmox Backup Server quand les volumes grossissent : des sauvegardes dédupliquées, incrémentales, chiffrées, vérifiées vers une seconde machine, synchronisées hors site. C'est là que des sauvegardes quotidiennes à historique complet de chaque invité deviennent assez abordables pour être vraiment faites.

Et la règle qui transforme tout cela en protection réelle plutôt qu'en simple façade : une sauvegarde que vous n'avez pas restaurée est une hypothèse. Planifiez des tests de restauration comme vous planifiez les sauvegardes.

Les snapshots ne sont pas des sauvegardes

Ça vaut la peine d'être précisé, car l'interface place « Snapshot » dangereusement près de « Backup ». Un snapshot de VM fige un instant sur le même stockage que celui où vit la VM : le stockage meurt, le snapshot meurt avec lui. Les snapshots à longue durée de vie dégradent aussi les performances et compliquent le stockage à mesure que les deltas s'accumulent.

Ce pour quoi les snapshots sont excellents, c'est justement ce pour quoi les sauvegardes sont trop lentes : un bouton d'annulation instantané autour d'un changement risqué. Prenez-en un, faites la chose dangereuse, confirmez, supprimez le snapshot. Une durée de vie de quelques minutes à quelques heures : le conseil de notre guide de mise à niveau Debian, « décidez d'abord de votre plan de rollback », rendu concret en un clic. (Le RAID, pour être complet, n'est ni des snapshots ni des sauvegardes : c'est de la disponibilité, une troisième chose.)

Niveau 2 : vzdump, bien configuré

vzdump est le moteur de sauvegarde intégré de Proxmox : il produit une archive complète et autonome d'un invité, restaurable sur n'importe quel hôte Proxmox. La différence entre « on fait tourner vzdump » et une vraie stratégie tient à quatre réglages.

Mode : snapshot, avec le guest agent

Utilisez le mode snapshot pour les plannings de routine : il sauvegarde les invités en cours d'exécution avec au pire une brève interruption. Sa cohérence dépend d'une chose que beaucoup négligent : le guest agent QEMU dans chaque VM (le paquet qemu-guest-agent, plus la case à cocher dans les options de la VM). Grâce à lui, vzdump gèle les systèmes de fichiers de l'invité (fs-freeze/fs-thaw) au moment de la capture, si bien que l'archive contient une image crash-consistent (ou mieux) plutôt qu'une image incohérente. Réservez le mode stop aux invités pour lesquels la certitude d'une copie à froid vaut l'arrêt planifié, et pour les bases de données, le principe de la ceinture et des bretelles s'applique toujours : un dump au niveau applicatif (pg_dump, etc.) selon un planning à l'intérieur de l'invité coûte peu et permet des restaurations que ne permet pas une image disque.

Planning et rétention

Configurez cela sous Datacenter → Backup : quels invités, quand (chaque nuit, échelonné si le stockage est partagé), et (la partie qui évite à la fois la perte de données et les disques pleins) la rétention. Proxmox purge selon des règles : keep-daily=7, keep-weekly=4, keep-monthly=6 vous donne par exemple un mois de granularité quotidienne et une traîne de deux saisons, purgée automatiquement. N'importe quelle règle de rétention vaut mieux que les deux réglages par défaut que les gens font vraiment tourner : « tout garder jusqu'à ce que le disque soit plein » et « en garder 1 ».

Cible : pas les mêmes disques

Une sauvegarde sur le stockage qu'elle protège n'est qu'un snapshot compliqué inutilement. Cible minimale viable : tout stockage qui tombe en panne indépendamment, un second array local, du NFS ailleurs, ou (niveau 3) un datastore PBS sur une autre machine.

Fleecing : pour les cibles lentes

Si les sauvegardes vers une cible lente (NFS via une liaison étroite, un array HDD très sollicité) rendent les invités lents, c'est que les écritures de l'invité attendent après la cible de sauvegarde. Fleecing (--fleecing enabled=1,storage=local-lvm) met en tampon les anciens blocs sur du stockage local rapide à la place, découplant ainsi les I/O de l'invité de la vitesse de la cible : une fonctionnalité discrète qui règle la plainte la plus courante, « les sauvegardes ralentissent la production ».

Niveau 3 : Proxmox Backup Server

La limite de vzdump est arithmétique : chaque sauvegarde est une archive complète, donc les sauvegardes quotidiennes d'une VM de 200 GB coûtent 200 GB par jour, et la plupart de ces octets sont identiques d'un jour à l'autre. Proxmox Backup Server (un produit compagnon gratuit et open source que vous installez sur une seconde machine) change cette arithmétique :

• Déduplication + transfert incrémental. Les données sont stockées sous forme de content-addressed chunks ; les chunks inchangés ne sont stockés qu'une fois, et les VM en cours d'exécution sont sauvegardées de façon incrémentale grâce aux dirty bitmaps QEMU : seuls les blocs écrits depuis la dernière sauvegarde sont même lus, sans parler d'être envoyés. Effet pratique : après la première sauvegarde, les sauvegardes quotidiennes de VM volumineuses prennent des minutes et coûtent des gigaoctets, pas des centaines. (Les conteneurs ont leur propre accélérateur : le mode de détection des changements metadata ignore les fichiers inchangés en les comparant aux métadonnées du snapshot précédent.)
• Combien fait gagner la dédup ? Proxmox ne publie honnêtement aucun ratio officiel. Cela dépend de la profondeur de rétention et de la ressemblance entre vos invités. Les retours de la communauté se situent généralement dans la fourchette 5–12× avec des sauvegardes quotidiennes et une rétention raisonnable ; un ratio proche de 1× signifie généralement juste que la rétention est réglée sur un seul snapshot.
• Vérification contre le bit rot. Des verify jobs planifiés recalculent les sommes de contrôle des chunks stockés, si bien qu'une corruption silencieuse du stockage est détectée avant la restauration qui aurait eu besoin de ces données. C'est la fonctionnalité discrètement redoutable de PBS : les archives froides pourrissent invisiblement ; les archives vérifiées non.
• Chiffrement côté client (AES-256-GCM) : les sauvegardes sont chiffrées avant de quitter l'hôte PVE, si bien que la machine PBS (ou le bucket S3 derrière elle) ne contient jamais de texte en clair. Protégez bien la clé ; PBS prend en charge une clé maîtresse imprimable sur papier pour les cas d'urgence.
• Synchronisation hors site. Des sync jobs répliquent les datastores entre instances PBS (push ou pull, delta uniquement). Un second PBS dans un autre lieu transforme l'installation en véritable 3-2-1. Depuis PBS 4.2, le stockage objet compatible S3 est un backend de datastore officiellement pris en charge, ce qui fait aussi de la « copie hors site dans un bucket » une option à part entière.
• Ergonomie de restauration : restauration d'un seul fichier (extraire un fichier d'une sauvegarde d'image de VM depuis l'interface) et live-restore (démarrer une VM directement depuis sa sauvegarde pendant qu'elle continue à être transférée en streaming, RTO en quelques minutes pour les impatients).

La forme de déploiement sur des serveurs dédiés est simple : PBS veut sa propre machine (les sauvegardes sur l'hyperviseur ne protègent rien), avec un stockage orienté capacité (côté RAID : territoire raidz2/RAID 6) et une liaison assez large pour que les fenêtres de restauration restent tolérables (le calcul de fenêtre de restauration du guide de dimensionnement s'applique aussi ici : 4 TB sur 1 Gbit/s, c'est ~9 heures ; en 10 Gbit/s, ça passe sous l'heure). Les hôtes PVE reçoivent ensuite chaque nuit une tâche Datacenter → Backup ciblant le datastore PBS, PBS exécute prune + garbage collection + verify hebdomadaire, et (si les données le justifient) un sync job pousse les données vers un second site.

Qu'en est-il de la réplication et de Ceph ?

Deux fonctionnalités voisines sont prises à tort pour des sauvegardes. La réplication ZFS (pvesr) copie les volumes des invités vers un autre nœud selon un planning (jusqu'à chaque minute), excellente pour un failover rapide avec du stockage local, mais elle réplique fidèlement chaque suppression et chaque corruption en quelques minutes ; c'est de la disponibilité, pas de l'historique. Ceph de même : un stockage répliqué autoréparateur qui préservera vos blocs chiffrés par un ransomware avec une redondance sans faille. Les deux se combinent avec les sauvegardes (ils couvrent le cas « le nœud est mort » ; les sauvegardes couvrent le cas « il nous faut l'état de mardi dernier »). Aucun des deux ne les remplace. Plus de détails sur les deux dans le guide cluster et HA.

L'exercice de restauration

Au minimum chaque trimestre : restaurez une VM vers un VMID jetable (qmrestore ou interface, restore-as-new : cela n'écrase pas l'original), démarrez-la, confirmez que l'application fonctionne vraiment, supprimez-la. Vingt minutes qui transforment « on a des sauvegardes » en « on a des restaurations ». Pendant que vous y êtes : chronométrez. Si le chronométrage vous surprend, mieux vaut le découvrir maintenant que pendant un incident : c'est là que vous découvrez si live-restore, plus de bande passante, ou une granularité de rétention plus fine méritent d'être configurés.

Questions fréquentes

Les sauvegardes en mode snapshot d'une base de données en cours d'exécution sont-elles sûres ?

Sûres, mais perfectibles. Comme le guest agent gèle les systèmes de fichiers au moment de la capture, l'image est cohérente au niveau du système de fichiers, et les bases de données modernes (PostgreSQL, MySQL/InnoDB) s'en remettent proprement : c'est équivalent à une reprise après coupure de courant, ce pour quoi elles sont conçues. Ce qu'une image disque ne vous offre pas, c'est la liberté de revenir à un instant précis ou de faire facilement une restauration partielle, donc pour les bases de données qui comptent, ajoutez des dumps au niveau applicatif ou de l'archivage WAL à l'intérieur de l'invité. La combinaison (sauvegardes d'image pour la récupération de tout le système, dumps pour une récupération chirurgicale) est la réponse raisonnable.

À quelle fréquence dois-je sauvegarder ?

Partez à rebours de la question « combien de travail peut-on se permettre de perdre ? » C'est votre intervalle de sauvegarde. Une sauvegarde quotidienne est le plancher standard pour les invités classiques ; avec le modèle de coût incrémental de PBS, plusieurs fois par jour pour des bases de données très sollicitées reste largement abordable (et la réplication pvesr peut en parallèle réduire l'écart de disponibilité à une minute). Le chiffre qui compte tout autant : la profondeur de rétention. La corruption et les ransomwares sont souvent découverts des jours plus tard. Une stratégie ne conservant que trois sauvegardes quotidiennes peut faire migrer les dégâts dans chaque copie avant que quiconque s'en aperçoive.

PBS peut-il sauvegarder des éléments qui ne sont pas des invités Proxmox ?

Oui : le proxmox-backup-client tourne sur n'importe quel hôte Linux et envoie des sauvegardes au niveau fichier vers les mêmes datastores dédupliqués, chiffrés et vérifiés. Si vous faites déjà tourner PBS, c'est un endroit naturel pour la configuration et les données de vos machines non virtualisées aussi : une seule infrastructure de sauvegarde, une seule politique de rétention, un seul endroit où tester les restaurations.

Est-ce que cela protège contre les ransomwares ?

C'est l'essentiel de la réponse, avec deux conditions. D'abord, la séparation : un PBS joignable uniquement via son API avec ses propres identifiants n'est pas chiffrable par un invité compromis, mais les sauvegardes écrites sur un partage NFS que l'hyperviseur monte en lecture-écriture le sont. Ensuite, l'historique et la synchronisation : une rétention qui remonte assez loin pour dépasser l'infection, des verify jobs pour savoir que les chunks sont intacts, et une synchronisation hors site (second PBS ou S3) qu'un site compromis isolé ne peut pas atteindre. Le chiffrement côté client de PBS protège vos sauvegardes du stockage ; la séparation des accès les protège de l'attaquant.

Déployer sur Serverside

Le déploiement PBS naturel ici, c'est un second serveur dédié : une configuration de stockage orientée capacité, sur le réseau privé avec vos hôtes Proxmox pour que le trafic de sauvegarde nocturne ne touche jamais votre bande passante publique, dans un domaine de panne différent de celui de l'hôte qu'il protège. Provisioning en moins d'une minute sur l'ASN 55285, et les mêmes images prêtes pour Proxmox partout.

Le reste de la série : installation initiale, réseau, LXC vs VM, et (là où la réplication et le failover prennent le relais des sauvegardes) clustering et haute disponibilité.