Stratégie 3-2-1-1-0 avec PBS : local, distant, bande, S3, immuable¶
Une stratégie 3-2-1-1-0 garantit qu'un sinistre unique (panne, incendie, ransomware, erreur humaine) ne détruit jamais toutes vos copies : avec PBS, elle se construit avec un PBS local, une copie synchronisée vers le PBS du MSP et, selon le besoin, une copie hors ligne (bande ou disque amovible) ou objet (S3). Cette page explique chaque chiffre et le traduit en briques PBS concrètes.
La règle, chiffre par chiffre¶
| Chiffre | Exigence | Traduction PBS dans l'offre MSP |
|---|---|---|
| 3 copies | Production + 2 sauvegardes | VM en production, PBS local, PBS du MSP |
| 2 supports | Au moins deux technologies ou systèmes distincts | Stockage PVE (Ceph, ZFS, SAN) et datastore PBS sur un serveur dédié |
| 1 hors site | Une copie dans un autre lieu | Sync job vers le PBS du MSP |
| 1 hors ligne ou immuable | Une copie qu'un attaquant ayant les droits admin du client ne peut pas effacer | Copie MSP sous droits séparés ; en option bande LTO exportée ou datastore amovible déconnecté |
| 0 erreur | Sauvegardes vérifiées et restaurations testées | Verify jobs + test de restauration mensuel avec PV |
Architecture de référence¶
flowchart LR
PVE["Cluster PVE<br/>(copie 1 : production)"] -->|"vzdump 22:00"| L["PBS local<br/>(copie 2)<br/>rétention courte"]
L -->|"sync job<br/>nuit"| M["PBS MSP<br/>(copie 3, hors site)<br/>droits séparés<br/>rétention longue"]
L -.->|"option"| T["Bande LTO<br/>exportée au coffre"]
L -.->|"option"| R["Datastore amovible<br/>(USB / disque) déconnecté"]
M -.->|"option"| S["Datastore S3"]
Les briques disponibles dans PBS 4.x¶
| Brique | Ce qu'elle apporte | Limites |
|---|---|---|
| PBS local | Restauration rapide, live-restore, restauration de fichiers | Même site, même domaine d'administration que la production |
| Sync job vers PBS distant (pull, ou push depuis PBS 3.3) | Copie hors site incrémentale, seuls les chunks manquants transitent | Si remove-vanished est actif, une suppression locale se propage |
Bande LTO (proxmox-tape) |
Copie réellement hors ligne, longue conservation, WORM possible | Matériel, rotation manuelle des cartouches, restauration lente |
| Datastore amovible (depuis PBS 3.3) | Disque monté pour la sync puis déconnecté | Discipline de rotation, disque à stocker ailleurs |
| Datastore S3 | Stockage objet, éventuellement avec verrouillage côté fournisseur | Technology preview en PBS 4.0 et 4.1, pris en charge officiellement à partir de PBS 4.2 ; coûts de requêtes et de sortie de données |
| Snapshot protégé | Exclu du prune et de la suppression via PBS | Un administrateur du PBS peut retirer la protection : ce n'est pas de l'immuabilité |
Pourquoi la copie MSP compte comme « immuable »¶
L'immuabilité ne vient pas d'un format de fichier mais de la séparation des droits :
- En mode pull, le PBS du MSP vient lire le PBS local avec un compte en lecture. Le client ne possède aucun identifiant sur le PBS du MSP.
- En mode push, le PBS local écrit chez le MSP avec un jeton API limité au rôle
DatastoreBackupsur son namespace : il peut créer des sauvegardes, pas en supprimer (le droitDatastore.Prunen'est pas accordé,remove-vanishedreste désactivé). - La rétention et la garbage collection du datastore MSP sont pilotées par le MSP seul.
Un attaquant qui prend le contrôle du PVE et du PBS du client peut détruire les copies 1 et 2. Il ne peut pas effacer la copie 3. Ce modèle est détaillé dans le lab ransomware.
Rétentions types¶
| Usage | PBS local | PBS MSP |
|---|---|---|
| Contrat standard | keep-last 3, keep-daily 14, keep-weekly 8 | keep-daily 14, keep-weekly 8, keep-monthly 12 |
| Données réglementées | keep-daily 14, keep-weekly 8, keep-monthly 3 | keep-monthly 12, keep-yearly 5 à 10, ou bande annuelle |
Les valeurs exactes figurent dans votre dossier d'exploitation. L'impact sur la capacité se calcule avec le calculateur PBS.
Ce que fait le client, ce que fait le MSP¶
| Action | Client | MSP |
|---|---|---|
| Jobs de sauvegarde PVE, ajout de VMs | Oui | N3 |
| Prune, GC, verify du PBS local | Oui (N1) | N2, N3 |
| Rétention, GC, droits du PBS MSP | Non | Oui |
| Test de restauration mensuel | Oui, avec PV | Contrôle du PV, N3 : exécution |
| Restauration depuis la copie MSP | Ticket iTop | Oui (RB-15) |
Pièges vus en support
- PBS installé comme VM sur le cluster qu'il sauvegarde, sans autre copie : panne du cluster égale perte des sauvegardes.
remove-vanishedactivé sur la sync vers le MSP : unpruneagressif ou un attaquant sur le PBS local vide aussi la copie distante.- Même compte administrateur (ou même annuaire AD) pour PVE, PBS local et PBS distant : un seul vol d'identifiants suffit à tout effacer.
- Clé de chiffrement uniquement sur le cluster PVE : la copie MSP existe mais reste illisible après sinistre.
- « 0 erreur » réduit au voyant vert du verify : un verify valide l'intégrité des chunks, pas le démarrage de l'application.
Testez-vous¶
-
Un client a PBS local + bande hebdomadaire laissée dans le lecteur. Quel chiffre de la règle n'est pas respecté ?
Réponse
Le « 1 hors ligne » et le « 1 hors site » : une cartouche restée dans le lecteur est en ligne et sur le même site. Elle doit être éjectée et stockée ailleurs.
-
Pourquoi le mode pull depuis le MSP protège-t-il mieux contre un ransomware que le push ?
Réponse
En pull, aucun identifiant du PBS MSP n'est stocké chez le client. En push, un jeton existe sur le PBS local ; il doit donc être limité à la création de sauvegardes, sans droit de suppression.
-
Un snapshot protégé est-il une sauvegarde immuable ?
Réponse
Non. Il échappe au prune, mais un administrateur du PBS peut lever la protection puis supprimer. L'immuabilité réelle vient de droits séparés ou d'un support hors ligne.
-
Le datastore S3 est-il adapté en production avec PBS 4.0 ?
Réponse
Il était en technology preview en PBS 4.0 et 4.1. Il est pris en charge à partir de PBS 4.2 : vérifiez la version en place et validez coûts et performances en lab avant de l'utiliser.