Aller au contenu

Stratégie 3-2-1-1-0 avec PBS : local, distant, bande, S3, immuable

Day 0 · ConcevoirNiveau 2 · OpérerCoursRédigé · à valider en lab

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 DatastoreBackup sur son namespace : il peut créer des sauvegardes, pas en supprimer (le droit Datastore.Prune n'est pas accordé, remove-vanished reste 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-vanished activé sur la sync vers le MSP : un prune agressif 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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Pour aller plus loin