Aller au contenu

Jobs de sauvegarde, modes snapshot / suspend / stop, fleecing

Day 1 · DéployerNiveau 2 · OpérerProcédureRédigé · à valider en lab

Objectif : créer le job nocturne qui sauvegarde toutes les VMs et conteneurs du cluster vers pbs-local en mode snapshot, sans ralentir les VMs grâce au fleecing, et avec une notification en cas d'échec. Le mode snapshot avec l'agent invité QEMU convient à la quasi-totalité des charges.

Les modes de sauvegarde

Mode VM (QEMU) Conteneur (LXC) Interruption
snapshot Copie des blocs pendant que la VM tourne ; fs-freeze/thaw via l'agent invité s'il est actif Snapshot temporaire du volume (stockage compatible snapshots requis) Aucune (gel d'E/S de quelques secondes)
suspend VM suspendue puis mode snapshot ; conservé pour compatibilité, pas plus cohérent rsync, suspension, second rsync ; nécessite de l'espace temporaire Courte à moyenne
stop Arrêt propre, démarrage de la sauvegarde, redémarrage immédiat de la VM Conteneur arrêté pendant toute la sauvegarde Courte (VM), longue (CT)

Dirty bitmap et fleecing

  • Dirty bitmap : QEMU garde en mémoire la liste des blocs modifiés depuis la dernière sauvegarde vers ce PBS. Seuls ces blocs sont relus et envoyés. Le bitmap est perdu quand le processus QEMU redémarre (arrêt puis démarrage de la VM) : la sauvegarde suivante relit tout le disque, mais n'envoie toujours que les chunks absents du PBS. Le log indique dirty-bitmap status: created new ou OK (… dirty).
  • Fleecing : en mode snapshot, quand la VM écrit sur un bloc pas encore sauvegardé, QEMU doit d'abord copier l'ancien bloc vers le PBS. La VM attend donc le PBS. Le fleecing place ces anciens blocs dans une image temporaire sur un stockage local rapide : les écritures de la VM ne dépendent plus de la vitesse du PBS ou du réseau. Disponible pour les VMs seulement.

Stockage de fleecing conseillé : local, rapide, thin avec discard (LVM-thin, RBD ceph-vm, ZFS avec sparse activé, comme local-zfs). Sur un stockage thick, la taille complète des disques est réservée.

Avant de toucher la prod

  • Stockage pbs-local actif sur tous les nœuds (pvesm status).
  • Agent invité QEMU installé et activé (VM → Options → QEMU Guest Agent) sur les VMs ; VSS fonctionnel sous Windows.
  • Fenêtre de sauvegarde définie (par exemple 21:00 à 05:00), sans chevauchement avec la GC et le verify du PBS.
  • Cible de notification configurée (mail, webhook) dans Datacenter → Notifications.
  • Pour le fleecing : espace libre suffisant sur le stockage choisi.

Étapes

  1. Datacenter → Backup → Add.
  2. Onglet General : Node -- All --, Storage pbs-local, Schedule 21:00, Selection mode All (ou Exclude selected pour écarter des VMs de test), Mode Snapshot, Notification selon votre cible.
  3. Onglet Retention : laisser vide ; la rétention est appliquée par les prune jobs du PBS.
  4. Onglet Note Template : {{guestname}} - {{node}} pour retrouver les sauvegardes facilement.
  5. Onglet Advanced : Fleecing coché, Fleecing Storage local-zfs (ou ceph-vm) ; Repeat missed coché ; pour les conteneurs volumineux, PBS change detection mode Metadata.
  6. Create, puis sélectionner le job → Run now pour un premier passage contrôlé.
pvesh create /cluster/backup --id nuit-pbs --schedule '21:00' --storage pbs-local \
  --all 1 --mode snapshot --fleecing enabled=1,storage=local-zfs \
  --repeat-missed 1 --notes-template '{{guestname}} - {{node}}'
cat /etc/pve/jobs.cfg

# sauvegarde ponctuelle d'une VM
vzdump 101 --storage pbs-local --mode snapshot --fleecing enabled=1,storage=local-zfs
# conteneur avec détection de changements par métadonnées
vzdump 102 --storage pbs-local --pbs-change-detection-mode metadata

Réglages par VM

  • Disque à exclure (disque de cache, swap dédié) : VM → Hardware → disque → Edit → décocher Backup.
  • Base de données sans agent capable de fs-freeze cohérent : script de pré-sauvegarde dans l'invité, ou dump applicatif sauvegardé avec la VM.
  • Sauvegarde exceptionnelle à conserver (avant migration) : VM → Backup → Backup now, puis marquer la sauvegarde Protected dans PBS.

Vérifications

Le log de la tâche (nœud → Task History, type Backup Job) se termine par INFO: Backup job finished successfully. Pour une VM :

INFO: issuing guest-agent 'fs-freeze' command
INFO: issuing guest-agent 'fs-thaw' command
INFO: scsi0: dirty-bitmap status: OK (12.4 GiB of 200.0 GiB dirty)
INFO: backup was done incrementally, reused 187.6 GiB (93%)

Côté PBS : Datastore → pbs01 → Content, une sauvegarde par VM à la date du jour.

Rollback

Job inadapté : Datacenter → Backup → sélectionner le job → Edit ou décocher Enable. Supprimer un job ne supprime aucune sauvegarde. Fleecing problématique : décocher l'option dans Advanced ; les images temporaires sont supprimées en fin de sauvegarde.

Pièges vus en support

  • Pas d'agent invité : sauvegarde crash-consistent seulement. Bases de données à rejouer au redémarrage.
  • Agent installé dans la VM mais option non activée dans PVE (ou l'inverse) : guest-fsfreeze-freeze failed ou timeout (RB-14).
  • PBS lent ou lien saturé sans fleecing : VMs figées pendant la sauvegarde, applications en timeout.
  • Fleecing sur un stockage thick ou presque plein : la sauvegarde échoue, voire remplit le stockage des VMs.
  • Rétention renseignée à la fois dans le job PVE et sur le PBS : deux politiques concurrentes, sauvegardes supprimées de façon inattendue.
  • Mode stop choisi « pour être sûr » : arrêt de la VM toutes les nuits et perte du dirty bitmap à chaque fois.

Quand ouvrir un ticket iTop

VM qui se fige pendant la sauvegarde malgré le fleecing, échec répété sur la même VM, besoin d'une cohérence applicative particulière (SQL, Exchange, SAP) : P3. Échec de tout le job deux nuits de suite : P2. Joindre le log complet de la tâche et cat /etc/pve/jobs.cfg.

Ouvrir un ticket iTop

Pour aller plus loin