Procédure de backup VM VMware ESXi · Proxmox · Hyper-V

Le backup de l\'appliance on-prem relève de la responsabilité du client. Les procédures ci-dessous décrivent la stratégie de snapshot recommandée pour chaque hyperviseur supporté, avec un objectif RTO 4h et RPO 24h.

Quoi sauvegarder

L\'appliance stocke tout ce qui compte sur le disque data séparé (le disque système est remplaçable en un redéploiement OVA). Un snapshot consistent du seul disque data suffit à restaurer le service.

  • Disque data : datastore Postgres, stockage objet, secrets, état licence, journal d'audit. Indispensable.
  • Disque système : OS + binaires Natalia. Récupérable en redéployant la même OVA signée — backup facultatif.
  • Métadonnées hyperviseur : configuration VM (vCPU, RAM, network, VLAN). Exporter le fichier de config VM à côté du snapshot.

VMware ESXi / vSphere

  1. Utiliser un produit de backup compatible VMware (Veeam, NAKIVO, Vembu, etc.) ciblant la VM dans son ensemble.
  2. Activer le quiescing VSS si disponible (appelle fsfreeze sur l'appliance pour des snapshots crash-consistent).
  3. Planifier un full quotidien du disque data + un incrémental toutes les 6h.
  4. Conserver : 7 quotidiens + 4 hebdomadaires + 3 mensuels (GFS).
  5. Destination de backup hors-host (NAS, datastore séparé, stockage objet S3-compatible).

Proxmox VE

  1. Configurer un job de backup quotidien via Datacenter → Backup ciblant la VM.
  2. Choisir le mode snapshot mode (profite des snapshots qcow2, crash-consistent).
  3. Activer la compression Zstd pour diviser par 2 la taille du backup.
  4. Destination : Proxmox Backup Server (PBS) sur un host séparé, ou bucket S3 PBS. Conserver 7 quotidiens + 4 hebdomadaires + 3 mensuels.
  5. Pour un RPO 5 min : utiliser la réplication ZFS entre deux hosts Proxmox.

Hyper-V

  1. Utiliser un produit de backup compatible Hyper-V (Veeam, Altaro, Azure Backup Server) — Windows Server Backup ne suffit pas en production.
  2. Activer les VSS Integration Services dans les paramètres VM (fournit des snapshots crash-consistent + application-consistent).
  3. Full quotidien + incrémental toutes les 6h.
  4. Destination : serveur de backup sur un VLAN séparé, idéalement avec réplication hors site (bucket Wasabi / S3 Glacier immuable).

RTO/RPO indicatifs

Stratégie de backup RTO RPO Coût
Snapshot quotidien seul4h24h€
Quotidien + incrémental 6h2h6h€€
Réplication ZFS / Storage 5 min30 min5 min€€€

Le RTO suppose que le disque système OVA est disponible localement (pas besoin de re-download). Le RPO ne compte pas le buffering CDR côté PBX : en pratique, les PBX OXE / OXO retiennent les CDR plusieurs heures et Natalia rattrape automatiquement au restore.

Test de restore (trimestriel)

Un backup qui n\'a jamais été restauré n\'est pas un backup. Planifier un test de restore trimestriel dans un VLAN isolé :

  1. Restaurer le dernier full + le dernier incrémental sur une VM de test isolée.
  2. Démarrer en mode dégradé (pas de connexion PBX, pas d'exposition MCP).
  3. Vérifier l'intégrité Postgres : natalia-cli check-integrity.
  4. Vérifier la hash chain du journal d'audit (natalia-cli audit verify).
  5. Comparer les comptes CDR au jour ouvré précédent : doit coller à ±0.5 % près.
  6. Détruire la VM de test.