- 2.1 Backups Horaires : Bonne ou Mauvaise Idée?
- 2.2 La "Sweet Spot" : Recommandations
- 2.3 Tableau Fréquence vs Coûts
- 2.4 Conclusion : Devrais-je faire de l'Horaire?
- 3.1 Qu'est-ce que PBS?
- 3.2 Modèle de Backup : Incrémental vs Complet
- 3.3 Comment fonctionne PBS
- 3.4 Le Modèle "Full-Incremental"
- 3.5 Optimisation des Performances
- 3.6 Configuration de PBS
- 4.1 Qu'est-ce que la déduplication?
- 4.2 Analogie
- 4.3 Comment ça Marche Concrètement?
- 4.4 L'Effet Cumulé
- 4.5 Exemple Réel
- 4.6 Impact Financier
- 4.7 Indépendance des Backups
- 4.8 Questions Fréquentes
- 5.1 Les 3 Types de Pannes
- 5.2 Plan de Récupération par Criticité
- 5.3 Checklist de Préparation
- 5.4 Outils et Commandes
- 5.5 Calcul RTO/RPO
- 5.6 Validation du Plan
Proxmox propose trois modes de backup pour les machines virtuelles, chacun offrant un équilibre différent entre cohérence des données, temps d'indisponibilité et performance.
- Downtime : ⭐ Aucun (zéro downtime)
- Cohérence : ⭐⭐ Bonne (risque léger)
- Vitesse : ⭐⭐⭐⭐⭐ Très rapide
- Ressources : Faible impact
Le mode snapshot utilise la technologie de live backup de Proxmox :
- La VM reste en ligne et continue de fonctionner pendant tout le backup
- QEMU copie les blocs de données disque pendant que la VM est en cours d'exécution
- Si un guest agent est activé (agent QEMU), le système de fichiers est gelé avant et après la sauvegarde pour améliorer la cohérence
- Les données en RAM (les processus en cours) ne sont pas capturées, comme dans une situation de panne
VM en production
├─ Web servers
├─ API servers
├─ Databases (avec agent)
└─ Services critiques
✅ Zéro interruption du service
✅ Plus rapide (parallelized)
✅ Consomme moins de bande passante
✅ Pas de besoin de stockage temporaire
❌ Données en RAM perdues lors d'une restauration (comme après une panne)
❌ Nécessite un agent guest pour la cohérence optimale sur Windows
vzdump 100 --mode snapshot- Downtime : ⭐⭐ Court (arrêt + redémarrage)
- Cohérence : ⭐⭐⭐⭐⭐ Excellente (garantie)
- Vitesse : ⭐⭐ Lent (arêt gracieux)
- Ressources : Faible impact
Le mode stop effectue un arrêt propre de la VM :
- La VM s'arrête proprement (shutdown gracieux)
- Un processus QEMU en arrière-plan lit les données disque
- Une fois le backup démarré, la VM redémarre automatiquement si elle était en cours d'exécution
- Cohérence du système de fichiers garantie (pas de journaux à rejouer)
- Cohérence des données en vol garantie
- Équivalent à un arrêt/redémarrage standard
VMs semi-critiques
├─ VMs de dev/test
├─ Systèmes de fichiers sensibles
├─ Avant une mise à jour majeure
└─ Test de restauration (DR test)
✅ Cohérence garantie à 100%
✅ Pas de risque de données corrompues
✅ Fiable pour toute restauration
✅ Idéal pour les tests de DR
❌ Downtime d'une dizaine de minutes (arrêt + boot)
❌ Plus lent (lecture séquentielle)
❌ Non adapté aux services 24/7
vzdump 100 --mode stop- Downtime : ⭐⭐⭐ Moyen
- Cohérence : ⭐⭐⭐ Moyenne
- Vitesse : ⭐⭐ Lent
- Ressources : Élevé (stockage temporaire)
Le mode suspend utilise rsync pour une sauvegarde granulaire :
- Phase 1 : Rsync copie toutes les données dans un répertoire temporaire
- Phase 2 : La VM est suspendue (pause)
- Phase 3 : Un second rsync copie les fichiers modifiés
- Phase 4 : La VM reprend (resume) immédiatement
Nécessite de l'espace disque supplémentaire pour stocker la copie temporaire :
Disque original : 100 GB
Espace requis : 100 GB + espace pour les changements
Ce mode est fourni pour des raisons de compatibilité. Comme la suspension entraîne un temps d'arrêt plus long et n'améliore pas nécessairement la cohérence des données par rapport au snapshot, l'utilisation du mode snapshot est recommandée.
✅ Downtime minimal mais garanti
✅ Bonne cohérence
❌ Mode dépréciable Pas d'avantage significatif sur snapshot
❌ Nécessite stockage temporaire
❌ Plus lent que snapshot
❌ À éviter
vzdump 100 --mode suspend| Critère | Snapshot | Stop | Suspend |
|---|---|---|---|
| Downtime | ✅ 0 min | ||
| Cohérence | ✅ Bonne | ✅ Excellente | |
| Vitesse | ✅ Rapide | ❌ Lent | |
| Impact CPU | ✅ Faible | ✅ Minimal | |
| Stockage temp. | ✅ Non | ✅ Non | ❌ Oui |
| Recommandé | ✅ OUI | ❌ Non |
Proxmox Backup Server est un serveur de backup dédié, différent de PVE, qui offre :
- Stockage centralisé et sécurisé
- Déduplication de données
- Incremental native (avec la technologie "dirty-bitmap")
- Compression et encryption côté client
- Synchronisation de datastores pour la géo-redondance
"PBS fait des backups complets et des backups incrémentaux"
PBS utilise un modèle unique : chaque backup est à la fois incrémental ET complet. Les backups sont envoyés incrémentalement au serveur, puis les données sont dédupliquées.
C'est un truc tout bête : si tu as 2 fois le même fichier ou le même bloc de données, tu le stockes qu'une fois.
Imagine un classeur papier :
Sans déduplication (mauvais) :
─────────────────────────────
Backup 1 (jour 1) : Copie complète du fichier "contrats.pdf" (50 pages)
Backup 2 (jour 2) : Copie complète du fichier "contrats.pdf" (50 pages)
Backup 3 (jour 3) : Copie complète du fichier "contrats.pdf" (50 pages)
Classeur occupé : 150 pages (3 copies identiques)
Avec déduplication (bon) :
─────────────────────────
Backup 1 (jour 1) : Stocke "contrats.pdf" pour la première fois → 50 pages
Backup 2 (jour 2) : "C'est pareil que avant" → crée juste une référence
Backup 3 (jour 3) : "C'est pareil que avant" → crée juste une référence
Classeur occupé : 50 pages seulement
(+ 2 petites références qui pointent vers les 50 pages)
PBS divise tout en petits morceaux appelés "chunks" et les indexe.
VM disque : 100 GB
PBS reçoit: 100 GB
PBS stocke: 100 GB en chunks
VM disque : 100 GB (95 GB inchangés, 5 GB modifiés)
Nouveau backup :
- 95 GB inchangés : "Je reconnais ces données" → réutilise
- 5 GB modifiés : "C'est nouveau" → stocke
Réseau transmis : 5 GB seulement (pas les 95 GB!)
Stockage réel : ~105 GB total
(95 GB réutilisés + 5 GB nouveaux + petites références)
VM disque : 100 GB (95 GB identiques au jour 1, 5 GB nouveaux)
Nouveau backup :
- Les chunks du jour 1 inchangés : réutilisés
- Les chunks du jour 2 changent : remplacés
- Nouveaux chunks : stockés
Réseau transmis : 5 GB
Stockage réel : toujours ~105 GB
(La dedup "arrange" les données, pas d'espace perdu)
Sans déduplication (théorique) :
Jour 1 : 100 GB (tout stocké)
Jour 2 : 100 GB (tout stocké) → 200 GB total
Jour 3 : 100 GB (tout stocké) → 300 GB total
...
Jour 30 : 100 GB → 3,000 GB total
Avec déduplication (réel) :
Jour 1 : 100 GB stockés
Jour 2 : 5 GB nouveaux → 105 GB total
Jour 3 : 5 GB nouveaux → 110 GB total
...
Jour 30 : 5 GB nouveaux → 245 GB total (à peu près)
Économie : 3,000 - 245 = 2,755 GB sauvés!
Configuration :
- Code PHP statique (réutilisé tous les jours)
- Base de données (change 10% par jour)
- Images/media (peu de changements)
- Logs applicatifs (quelques MB par jour)
Taille VM : 2.6 GB
Jour 1 : Backup complet
PBS reçoit : 2.6 GB
PBS stocke : 2.6 GB
Jour 2 à 10 : Backups incrémentiels (environ 50 MB de changements)
PBS reçoit : 50 MB × 9 jours = 450 MB envoyé
PBS stocke : 2.6 GB + 450 MB = 3.05 GB
Comparaison :
Sans déduplication : 2.6 GB × 10 jours = 26 GB
Avec déduplication : ~3 GB
Économie : 23 GB (88% de réduction!)
Scénario : Infra de 10 VMs de 100 GB chacune
Calcul SANS déduplication (30 jours) :
100 GB × 10 VMs × 30 jours = 30,000 GB = 30 TB requis
Calcul AVEC déduplication (10% changement/jour) :
Jour 1 : 100 GB × 10 VMs = 1,000 GB
Jour 2-30: 10 GB × 10 VMs × 29 jours = 2,900 GB
Total stocké réellement = ~3.9 TB
Économie de stockage : 30 TB - 3.9 TB = 26.1 TB sauvés
Coût évité : 26 TB × 100€/TB/an = 2,600€ par an!
La déduplication rend chaque backup complètement indépendant :
Système traditionnel (chaîne de dépendances) :
Backup 1 (complet) : 100 GB
Backup 2 (incr.) : 10 GB ← Dépend de Backup 1
Backup 3 (incr.) : 10 GB ← Dépend de Backup 1+2
Backup 4 (incr.) : 10 GB ← Dépend de Backup 1+2+3
Problème : Si Backup 1 se corrompt, tous les autres sont inutilisables ❌
Système PBS avec déduplication :
Backup 1 : Complet et indépendant ✅
Backup 2 : Complet et indépendant ✅
Backup 3 : Complet et indépendant ✅
Backup 4 : Complet et indépendant ✅
Chaque backup peut être restauré seul, peu importe l'état des autres.
Si Backup 1 se corrompt, les autres 3 fonctionnent parfaitement ✅
Pourquoi c'est important :
- Pas de risque en cascade
- Flexibilité de rétention (garder jour 1 et jour 10, oublier jour 5)
- Restauration plus fiable
Non. PBS ne supprime les données que si aucun backup n'en a besoin.
Jour 1 : Backup complet (100 GB)
Jour 2 : Backup avec 95 GB d'anciens + 5 GB nouveaux
Jour 3 : Backup avec 95 GB d'anciens + 5 GB nouveaux
Suppression du Backup jour 1 :
→ Les 95 GB sont conservés (utilisés par jour 2 et 3)
→ Les 5 GB du jour 1 (remplacés le jour 2) sont supprimés
→ Aucun impact sur jour 2 et 3
Dépend du taux de changement :
Cas 1 : Environnement stable (2% changement/jour)
100 GB VM × 30 jours = 3 TB apparents
Avec dédup → ~120 GB réels stockés (96% d'économie)
Cas 2 : Environnement actif (10% changement/jour)
100 GB VM × 30 jours = 3 TB apparents
Avec dédup → ~400 GB réels stockés (87% d'économie)
Cas 3 : Environnement très dynamique (30% changement/jour)
100 GB VM × 30 jours = 3 TB apparents
Avec dédup → ~1.2 TB réels stockés (60% d'économie)
Non, c'est plus rapide.
Bénéfices :
- Backup plus rapide : Seulement 5 GB envoyés au lieu de 100 GB
- Restauration plus rapide : Pas de chaîne à reconstituer
- Moins de travail réseau : Bande passante réduite de 95%
Proxmox VE Proxmox Backup Server
───────────────────── ──────────────────────
Détecte les blocs modifiés
↓
Envoie UNIQUEMENT les
changements
├─ Backup 1 : 50 GB envoyé (première sauvegarde)
├─ Backup 2 : 2 GB envoyé (changements seulement)
├─ Backup 3 : 1.5 GB envoyé (changements seulement)
└─ Backup 4 : 3 GB envoyé (changements seulement)
Technologie utilisée :
- Dirty-bitmap QEMU : Suit les blocs modifiés en temps réel (si VM en marche)
- Lecture complète : Si la VM est arrêtée, tout doit être lu/envoyé
Serveur PBS
─────────────────────
Chunk 1 (4 MB) ← Stocké
Chunk 2 (4 MB) ← Stocké
Chunk 3 (4 MB) ← Déjà existe, référencé seulement
Chunk 4 (4 MB) ← Déjà existe, référencé seulement
Chunk 5 (4 MB) ← Stocké
Backup complet = Tous les chunks (même dupliqués)
Stockage = Chunks uniques seulement
VM : Disque 100 GB
PBS reçoit : 100 GB transmis
PBS stocke : 100 GB de chunks (dédupliqués)
Index : Référence tous les 25 chunks
VM : Disque 100 GB (5 GB modifiés)
PBS reçoit : 5 GB transmis
PBS stocke : 5 GB de nouveaux chunks
Index : Référence 24 chunks existants + 5 nouveaux chunks
Restauration possible avec Backup 1 seul
Restauration possible avec Backup 2 seul
(Pas de chaîne de dépendances)
PBS n'est pas un système de backup différentiel. Chaque backup est complet ET incrémental à la fois. Cela est réalisé par déduplication : chaque snapshot de backup référence tous ses chunks, mais aucun chunk n'est stocké plus d'une fois.
✅ Restauration indépendante : Chaque backup est complet, pas besoin d'une chaîne
✅ Absence de risque : Perte d'un backup n'affecte pas les autres
✅ Efficacité : Économie de stockage par déduplication
✅ Rapidité de restauration : Pas besoin de rejouer les incrémentaux
| Système | Modèle | Problème |
|---|---|---|
| Veeam | Full → Inc 1 → Inc 2 → Inc 3 | Perte d'une bande = Tous les suivants perdus |
| Bacula | Full → Inc 1 → Inc 2 → Inc 3 | Restauration lente (chaîne complète) |
| PBS | Full ← Inc ← Inc ← Inc | Chaque backup = complet indépendant ✅ |
Le support du dirty-bitmap nécessite que la VM soit en marche. Cela permet un mode incrémental ultra-rapide (parfois appelé "fast incremental mode").
Backup avec VM en marche
├─ Dirty-bitmap actif
├─ Seuls 5 % du disque transmis
└─ Backup terminé en ~5 minutes pour 100 GB
Exemple log :
INFO: using fast incremental mode (dirty-bitmap)
INFO: 2.5 GiB dirty of 100 GiB total
INFO: backup was done incrementally, reused 97.5 GiB
Backup avec VM arrêtée
├─ Pas de dirty-bitmap
├─ Lecture complète du disque
└─ Backup lent (centaines GB à lire/envoyer)
Exemple log :
INFO: status: 100% (100 GiB of 100 GiB)
INFO: duration 300s, read: 333 MiB/s
# ❌ Ne pas faire
VM allumée → redémarrage → backup
# Le bitmap est remis à zéro
# ✅ À faire
VM allumée → backup (sans redémarrage)-
Ajouter PBS comme stockage :
Datacenter → Storage → Add Type: Proxmox Backup Server -
Configurer un job de backup :
Datacenter → Backup → Add Storage: votre-pbs Mode: snapshot (recommandé) Schedule: quotidien, par exemple -
Vérifier les logs :
# Sur PVE grep "incremental\|reused" /var/log/vzdump/backup.log # Exemple de succès INFO: backup was done incrementally, reused 95.2 GiB
La déduplication fonctionne au niveau du datastore PBS, pas entre datastores :
Datastore A Datastore B
├─ VM 1: 100 GB ├─ VM 3: 100 GB
├─ VM 2: 100 GB └─ [Dédup entre VM3 et VM1 = ❌]
└─ [Dédup interne ✅]
Si vous avez plusieurs copies identiques :
# ❌ Moins efficace
vzdump 100 --storage pbs1
vzdump 100 --storage pbs2
# ✅ Plus efficace
# Utiliser Sync Jobs de PBS pour géo-redondance
PBS1 (primary) → Sync Job → PBS2 (remote)"Peux-on avoir plus de snapshots, genre chaque heure ?"
Réponse courte : Oui techniquement, mais ce n'est généralement pas une bonne idée.
✅ RTO ultra-court (Recovery Time Objective)
- En cas de problème, vous revenez à max 1h en arrière
- Idéal pour des données critiques qui changent beaucoup
✅ Granularité fine
- 24 backups par jour = historique détaillé
- Chance plus haute de trouver un état "bon" à restaurer
✅ Détection rapide des bugs
- Un bug déployé à 10h sera détecté à 11h (max)
- Permet de rollback avant trop de dégâts
L'utilisation excessive de snapshots peut dégrader les performances. À mesure que les snapshots s'accumulent, ils peuvent introduire une surcharge qui affecte l'efficacité et la réactivité de la VM, ce qui rend crucial une gestion soignée d'entre eux.
En pratique avec PBS (Proxmox Backup Server) :
Backup horaire : 2-5 GB/heure transmis × 24 = 48-120 GB/jour
→ Réseau saturé en heures creuses
→ CPU du PVE utilisé pour compression/backup
→ I/O disk impactée en cas de pics
Avec un volume de 10GB subissant une rotation de 10% par jour, au jour 10 vous aurez besoin de 100% d'espace supplémentaire pour les snapshots. Au 100ème snapshot, votre 10 GB prennent maintenant 110 GB sur le disque.
Exemple réel :
VM: 100 GB (5% churn par jour = 5 GB modifiés/jour)
Jour 1 : 100 GB (complet)
Jour 2 : 105 GB (100 + 5 de changements)
Jour 3 : 110 GB (100 + 10 de changements)
...
Jour 10 : 150 GB (100 + 50 de changements)
Backups horaires = pire cas encore
Scenario : 10 VMs × 24 backups/jour × 30 jours
= 7,200 backups à gérer
= Configuration complexe de prune-backups
= Risque d'oublier des vieux backups
= Coût de stockage énorme
Les utilisateurs choisissent généralement le mode snapshot pour les backups en ligne. Si vous exécutez un cluster, ne sauvegardez pas tous les nœuds à la fois. Utilisez un serveur de backup dédié avec une NIC dédiée.
Avec 10 VMs et backups horaires :
00h00 - VM1, VM2, VM3... lancent
00h15 - VM2 se termine, VM10 commence
00h30 - ...encore 8 VMs en cours
→ Contention réseau/IO constant
- 24 backups/jour × 10 VMs = 240 index files
- Garbage Collection plus lourde
- Verification jobs deviennent impossibles
- Lenteur générale du serveur
Fréquence : 1x par jour
Horaire : 00h (off-peak)
Rétention : keep-daily=7, keep-weekly=4, keep-monthly=12
Mode : snapshot
Stockage : 5 TB pour 10 VMs × 100 GB
Raison : Excellent compromis coût/protection
Durée de backup : 5-10 min par VM
Consommation réseau : Pic unique la nuit
Fréquence : 2x par jour (matin + soir)
Horaires : 02h + 14h
Rétention : keep-daily=14, keep-weekly=8, keep-monthly=24
Mode : snapshot
Stockage : 10 TB pour 10 VMs × 100 GB
Raison : Couvre jour ouvrable complet
RTO : ~12 heures max
Coût : Raisonnable
Stratégie HYBRIDE (recommandée) :
Backups VE :
- Tous les 6 heures (snapshot mode)
- Rétention: keep-hourly=24, keep-daily=7, keep-weekly=4
- Stockage local SSD/NVMe (performance)
Backups PBS :
- 2x par jour (00h + 12h)
- Rétention: keep-daily=30, keep-weekly=52, keep-yearly=5
- Stockage distant (disaster recovery)
Avantage:
✅ Local snapshots = rollback RAPIDE (secondes)
✅ PBS backups = archivage long terme + géo-redondance
✅ Pas de surcharge constante| Fréquence | RTO | Stockage | Réseau | CPU | Recommandé |
|---|---|---|---|---|---|
| Journalier | 24h | ⭐ Bas | ⭐ Bas | ⭐ Bas | ✅ Oui |
| 2x/jour | 12h | ⭐⭐ Moyen | ⭐⭐ Moyen | ⭐⭐ Moyen | ✅ Oui |
| 6 heures | 6h | ⭐⭐⭐ Élevé | ⭐⭐⭐ Élevé | ⭐⭐⭐ Élevé | |
| Horaire | 1h | ⭐⭐⭐⭐ Très élevé | ⭐⭐⭐⭐ Très élevé | ⭐⭐⭐⭐ Très élevé | ❌ Éviter |
| Demi-horaire | 30 min | ⭐⭐⭐⭐⭐ Énorme | ⭐⭐⭐⭐⭐ Énorme | ⭐⭐⭐⭐⭐ Énorme | ❌ Ne jamais |
Voici ce que les utilisateurs réels font :
Approche conservatrice (70% des utilisateurs) :
- ❌ Snapshots horaires en continu
- ✅ Un snapshot avant changement important
- ✅ Suppression après vérification succès
- ✅ Backups quotidiens PBS pour long-terme
Approche automatisée (intelligente) :
- ❌ Pas de backups "horaires" classiques
- ✅ Snapshots auto 6h du script (cv4pve-autosnap)
- ✅ Rétention 3 jours de snapshots
- ✅ Rollback rapide si nécessaire
- ✅ PBS quotidien pour archivage
Approche très granulaire (rare) :
- ✅ Snapshots horaires local (24 derniers backups)
- ✅ Nettoyage quotidien automatique
- ✅ PBS quotidien pour archivage
⚠️ Nécessite de la bande passante + stockage dedié
Espace stockage requis pour X jours de backups horaires :
Stockage = (Taille VM × Jours × 24 heures × Churn rate) + Base
Exemple: VM 100GB, 7 jours, 5% churn/heure
= (100 × 7 × 24 × 0.05) + 100
= 840 + 100
= 940 GB pour UNE VM
Bande passante réseau pendant backup:
= (Taille VM × % churn) / Temps backup
Si 100 GB × 5% = 5 GB en 10 minutes
= 500 MB/s requis → Goulot d'étranglement probable!
Si vous decidez vraiment de faire de l'horaire, voici comment :
# Via CLI PVE
vzdump --schedule "*/1 * * * *" \
--storage pbs-local \
--prune-backups keep-hourly=24,keep-daily=7,keep-weekly=4 \
--mode snapshot \
--bwlimit 100000 \
--performance max-workers=4 \
100# Via interface : Datacenter → Backup → Add Job
Schedule: */1 * * * * # Toutes les heures
Nodes: node1 only # Un seul node!
Storage: pbs-local
Mode: snapshot
Keep-hourly: 24 # Garder 24h
Keep-daily: 7 # + 7 jours complets
Keep-weekly: 4 # + 4 semaines
Performance: max-workers=4
Bandwidth: 100 MB/s # LimiterMonitoring essentials :
# Watch logs
tail -f /var/log/vzdump/backup.log
# Check resource usage
top -p $(pgrep -f vzdump)
iotop -p $(pgrep -f vzdump)
# Check storage
pvesm list pbs-local # Voir croissance| Question | Réponse | Action |
|---|---|---|
| J'ai une petite infra | Non | Reste à journalier |
| Mon client demande de l'horaire | Questionne ses vrais besoins | Propose hybrid |
| Mon stockage a de la place | Pas suffisant | Coûts opérationnels importants |
| Mes VMs changent à la seconde | Peut-être | Considère replicas MySQL/Postgres |
| C'est pour 1-2 VMs critiques | Oui, avec limites | Hybrid local + PBS |
| C'est pour 20+ VMs | Non | Impossibilité opérationnelle |
En résumé :
Faire des snapshots horaires c'est comme faire une photocopie de tous tes documents toutes les heures : possible techniquement, mais c'est très lourd pour peu de bénéfice. Un équilibre 2x/jour + PBS journalier + snapshots ponctuels = parfait. 📊
Backup Mode: snapshot
Storage: PBS (1x)
Schedule: quotidien (00h)
Retention: keep-daily=7, keep-weekly=4, keep-monthly=12Configuration PVE :
mode: snapshot
storage: pbs-local
prune-backups: keep-daily=7,keep-weekly=4,keep-monthly=12Backup Mode: snapshot
Storage: PBS (2x : local + NFS)
Schedule:
- quotidien 00h (PBS local - rapide)
- quotidien 02h (PBS NFS - offsite)
Retention: keep-daily=14, keep-weekly=8, keep-monthly=24, keep-yearly=5Sync Job PBS :
PBS-Local → Sync Job → PBS-Remote (NFS)
Backup Mode:
- snapshot pour services 24/7
- stop pour DR tests (hebdo)
Storage: PBS Cluster (3 nodes)
Schedule:
- snapshot quotidien 00h
- stop quotidien 22h (tests)
- Geo-replication vers remote PBS
Retention: keep-daily=30, keep-weekly=52, keep-monthly=120, keep-yearly=10# /etc/vzdump.conf
mode: snapshot
storage: pbs-primary
prune-backups: keep-daily=14,keep-weekly=8,keep-monthly=12,keep-yearly=5
bwlimit: 50000
ionice: 7
compress: zstd
pigz: 0
zstd: 4
performance: max-workers=16,pbs-entries-max=10000000
notes-template: "Auto backup {{guestname}} ({{vmid}}) on {{node}} at {{cluster}}"# Scheduler : Datacenter → Backup → Add Job
Schedule: 0 0 * * * # quotidien 00h
Nodes: all
Storage: pbs-primary
Mode: snapshot
Keep-daily: 14
Keep-weekly: 8
Keep-monthly: 12
Keep-yearly: 5
Enabled: YesSymptôme : VM ne démarre plus, erreur disque
Cause : Corruption filesystem, secteurs défaillants
Impact : VM inaccessible
Temps d'intervention : quelques minutes
Stratégie de restauration :
Étape 1 : Évaluer l'ancienneté acceptable
- Qu'est-ce qu'on peut perdre comme données? (1h? 1 jour?)
- Quand le problème a-t-il commencé?
Étape 2 : Choisir le backup
Si problème détecté aujourd'hui:
✅ Restaurer depuis hier (moins de risque de restaurer le bug)
✅ Tester dans une clône d'abord
Étape 3 : Restaurer
# En ligne (si PBS)
qmrestore /mnt/pbs/path/backup.vma 100
# Arrêter l'ancienne VM d'abord
Datacenter → node → VM → More → Restore
RTO (Recovery Time Objective) :
- Avec PBS en direct : 5-15 minutes
- Avec stockage local : 10-30 minutes
Symptôme : Tout est off (crash matériel, alim, SSD mort)
Cause : Matériel défaillant
Impact : Toutes les VMs du node perdues
Temps d'intervention : 30 min à plusieurs heures
Stratégie de restauration :
Prérequis : Avoir PBS ou stockage distant (NFS, etc.)
→ Sinon aucune récupération possible
Scénario optimal :
1. Node 1 meurt complètement
2. VMs basculées sur Node 2 (HA si configuré)
3. Restaurer depuis PBS vers Node 2
Étapes :
- Datacenter → Backups
- Sélectionner VM à restaurer
- Choose target node (Node 2)
- Choose new VMID (éviter conflits)
- Restore
RTO :
- Avec HA activé : 5 minutes (basculement automatique)
- Sans HA : 30-60 minutes (restauration manuelle)
RPO (Recovery Point Objective) :
- Dépend du dernier backup (dernières 24h idéalement)
Symptôme : Données supprimées ou corrompues dans la VM
Cause : Mauvaise manip, bug logiciel, ransomware
Impact : VM accessible mais données perdues
Temps d'intervention : quelques minutes (mais découverte longue)
Stratégie de restauration :
Le problème : Vous découvrez le problème 3 jours après!
Options :
1️⃣ Restaurer la VM entière depuis jour X
- RTO : 10-20 min
- RPO : 3 jours (données perdues entre crash et découverte)
- Risque : Perte des 3 derniers jours
2️⃣ Restaurer fichiers individuels (si PBS)
- RTO : 5 min
- RPO : même jour (idéal!)
- Approche chirurgicale : récupère JUSTE le fichier supprimé
3️⃣ Utiliser snapshot local (si disponible)
- RTO : 2 min
- RPO : 6 heures
- Rapide mais limité dans le temps
Approche recommandée :
Jour 1 8h00 : Déploiement d'une malveillance
Jour 3 15h00 : Découverte du problème
Choix 1 (mauvais) : Restaurer complet jour 2
→ Perdre 2 jours de données valides
Choix 2 (meilleur) : Restaurer fichiers depuis jour 1 18h00
→ Récupère exactement ce qui manque
→ 0 donnée perdue (si backup toutes les heures)
PBS permet ceci via : Backups → File Restore
Scenario: App test, dev, documentation
Backup:
Mode: snapshot
Fréquence: 1x quotidien
Rétention: 7 jours
Stockage: NFS distant
En cas de panne:
RTO objectif: 24h (acceptable)
Procédure: Restauration manuelle via interface
Temps réel: 20-30 minutes
Coût: Accepter une journée de downtimeScenario: Base de données, applications métier
Backup:
Mode: snapshot
Fréquence: 2x/jour (00h + 12h)
Rétention: keep-daily=14, keep-weekly=8
Stockage: PBS
Snapshots locaux:
Fréquence: 6h
Rétention: 3 jours (48 snapshots)
Stockage: SSD/NVMe local
En cas de panne:
RTO objectif: 2-4 heures
Procédure rapide:
- Restaurer snapshot local 6h avant → 2 min
- Ou restaurer depuis PBS → 10 min
Procédure complète:
- Diagnostiquer l'ancienneté du problème
- Restaurer depuis dernier bon état
- Vérifier intégrité données
- Basculer vers productionScenario: Services financiers, e-commerce, infra critique
Architecture:
- Cluster HA (3+ nodes)
- PBS redondant (2+ instances)
- Backups 2x/jour + snapshots 6h
- Réplication inter-datacenter
Backup PBS:
Fréquence: 2x/jour
Rétention: keep-daily=30, keep-weekly=52, keep-yearly=5
Stockage principal: PBS-Local
Stockage secondaire: PBS-Remote (géo-redondante)
Snapshots locaux:
Fréquence: 6h
Rétention: 7 jours (168 snapshots)
Stockage: NVMe dédié
Réplication:
- MySQL/Postgres: réplication primaire→secondaire (RTO: ~30s)
- Volumes: réplication PBS entre datacenters
En cas de panne:
Scénario 1 (node muet):
- HA bascule → 2-3 minutes
- VM reprend automatiquement
- Zéro downtime perceptible
Scénario 2 (datacenter entier down):
- Bascul vers datacenter secondaire
- Restauration depuis PBS-Remote
- RTO: 15-30 minutes
Scénario 3 (corruption données):
- Restauration fichiers individuels
- RTO: 5 minutes
- RPO: 6 heures□ Documenter chaque VM critique (dépendances, données sensibles)
□ Tester au moins UNE restauration complète par trimestre
□ Avoir PBS ou NFS distant (pas juste local!)
□ Vérifier que les backups se terminent correctement
□ Avoir 2 copies de chaque VM (primaire + backup)
□ Documenter les SLA (RTO/RPO acceptés)
Tester régulièrement:
□ Restauration VM complète
□ Restauration fichier unique
□ Bascule HA (si applicable)
□ Basculement inter-site (si applicable)
Phase 1 - Évaluation (5 min)
□ Identifier le type de panne (VM? Node? Données?)
□ Vérifier l'état des backups (intégrité, récence)
□ Définir RTO/RPO acceptables pour ce cas
Phase 2 - Décision (5 min)
□ Restauration complète? ou fichiers?
□ Quelle date/heure restaurer?
□ Test d'abord ou direct en prod?
Phase 3 - Restauration (5-30 min)
□ Lancer la restauration
□ Vérifier la progression
□ Tester l'accès
Phase 4 - Validation (5-10 min)
□ Accès application OK?
□ Données présentes et cohérentes?
□ Performances acceptables?
Total : 20-60 minutes
□ Post-mortem : Qu'est-ce qui a échoué?
□ Améliorations : Que faire différemment?
□ Documentation : MAJ procédures/runbooks
□ Tests : Relancer des tests de restauration
□ Alertes : Configurer monitoring pour cette panne
# Lister les backups disponibles
proxmox-backup-client snapshot list
# ou via interface : Datacenter → Backups
# Vérifier intégrité d'un backup
proxmox-backup-client verify backup-id --repository pbs-id
# Prend quelques minutes mais essentiel!# Via interface (plus sûr)
Datacenter → node → Backups → Restore
# Via CLI (avancé)
qmrestore /path/to/backup.vma NEWVMID --pool pool-name
# Avec PBS
qmrestore pbs:backup-id 101
# Récupère depuis le serveur PBS directement# Via interface (PBS obligatoire)
Datacenter → Storage → pbs-storage → Backups
→ File Restore → Navigate → Download
# Via CLI (avancé)
proxmox-backup-client restore backup-id path/to/file# Watch the process
tail -f /var/log/proxmox-backup/restore.log
# Check VM status
qm status VMID
qm monitor VMID
# Check disk usage
df -h /var/lib/vz/Formule : RTO = Détection + Restauration + Test
Détection : 5-15 min (selon monitoring)
Restauration : 5-60 min (selon taille VM et stockage)
Test : 5-10 min
Exemple 1 (VM 100GB, stockage rapide) :
RTO = 10 + 10 + 5 = 25 minutes acceptable
Exemple 2 (VM 1TB, stockage NFS) :
RTO = 10 + 60 + 5 = 75 minutes ← Trop lent!
→ Besoin d'optimiser (PBS, SSD, HA)
RPO = Intervalle entre backups
Backups quotidiens → RPO = 24h (perdre 1 jour max)
Backups 2x/jour → RPO = 12h
Backups 6h → RPO = 6h
Exemple :
Problème découvert jour 3 à 15h
Dernier bon backup : jour 3 à 00h
Données perdues : 15h de travail (RPO=12h acceptable)
Voici comment s'assurer que votre plan fonctionne :
Test 1 : Restauration VM complète (3 mois)
- Prendre une VM quelconque
- Restaurer avec nouveau VMID
- Vérifier que tout marche
- Supprimer la copie test
Test 2 : Restauration fichier (1 mois)
- Choisir un fichier d'un backup
- Restaurer seul
- Comparer avec l'original
Test 3 : Scénario "panne node" (6 mois)
- Désactiver le node en prod
- Restaurer une VM depuis backup
- Mesurer le temps réel
- Comparer au RTO objectif
Test 4 : Audit backup (mensuels)
- Vérifier tous les backups existent
- Vérifier taille cohérente
- Vérifier date cohérente
- Compter les backups vs rétention
| Besoin | Mode |
|---|---|
| Service 24/7 | Snapshot ✅ |
| Cohérence garantie | Stop ✅ |
| À éviter | Suspend ❌ |
| Concept | Réalité |
|---|---|
| Full vs Incremental | Chaque backup = Full + Incrémental |
| Transport | Incrémental (seuls les changements) |
| Stockage | Full (tous les chunks référencés) |
| Indépendance | Oui (pas de chaîne) |
- ✅ Gardez les VMs en marche pendant les backups
- ✅ Utilisez PBS pour l'incrémental natif
- ✅ Schedulez après les pics d'activité
- ✅ Testez les restaurations régulièrement
- ❌ N'arrêtez pas les VMs sans raison entre backup et redémarrage