Aller au contenu

Sync jobs pull et push vers un PBS distant ou MSP

Day 1 · DéployerNiveau 3 · MaîtriserProcédureRédigé · à valider en lab

Objectif : copier chaque nuit les sauvegardes du PBS local vers le PBS du MSP, de façon incrémentale, avec une limite de débit et des droits tels que le client ne puisse pas effacer la copie distante. Un sync job ne transfère que les chunks absents de la cible : après la première synchronisation, seul le volume quotidien dédupliqué transite.

Pull ou push ?

Critère Pull (la cible vient chercher) Push (la source envoie, PBS 3.3 et plus)
Où est configuré le job Sur le PBS du MSP Sur le PBS local du client
Identifiants stockés Chez le MSP : compte en lecture sur le PBS local Chez le client : jeton sur le PBS du MSP
Flux réseau Entrant chez le client (TCP 8007) Sortant du client vers le MSP (TCP 8007)
Résistance au ransomware côté client Maximale : rien chez le client ne donne accès à la copie Bonne si le jeton n'a que DatastoreBackup (pas de suppression)
Usage dans l'offre Par défaut quand le site client accepte un flux entrant Site sans flux entrant possible (NAT, politique de sécurité)

Le mode retenu figure dans votre dossier d'exploitation. Le diagnostic au quotidien est dans RB-15.

Droits nécessaires

Mode Côté source Côté cible
Pull Compte distant avec au moins DatastoreReader sur le datastore source Propriétaire du job : Datastore.Backup sur le datastore cible ; Datastore.Prune seulement si remove-vanished
Push Propriétaire du job : Datastore.Read + Datastore.Audit (ou Datastore.Backup s'il possède les groupes) ; Remote.Audit et Remote.DatastoreBackup sur le remote Compte du remote : rôle DatastoreBackup sur le namespace cible. Pas de Datastore.Prune ni Datastore.Modify

Avant de toucher la prod

  • Mode (pull ou push), datastore et namespace cible communiqués par le MSP.
  • Identifiant et secret du jeton, empreinte du certificat du PBS distant reçus par un canal sûr.
  • Flux TCP 8007 ouvert dans le bon sens et testé (nc -zv pbs-msp.example.net 8007).
  • Débit autorisé et fenêtre horaire validés (calculateur) ; première sync (seeding) planifiée.
  • remove-vanished : décision explicite (désactivé par défaut dans l'offre).

Étapes (exemple push, configuré sur le PBS local)

  1. Configuration → Remotes → Add : Remote ID msp, Host pbs-msp.example.net, Auth ID client-a-sync@pbs!push (fourni par le MSP), Password = secret, Fingerprint = empreinte fournie.
  2. Bouton Scan ou liste déroulante : le datastore distant client-a doit apparaître.
  3. Datastore → pbs01 → Sync Jobs → Add → Sync Push Job (selon la version, Add puis direction Push).
  4. Renseigner : Remote msp, Remote Datastore client-a, Remote Namespace selon le MSP, Local Namespace Root, Max. Depth Full, Schedule 05:30, Remove vanished décoché, Rate limit sortant (par exemple 25 MiB le jour de la première sync).
  5. Onglet Group Filter si besoin : exclure les VMs de test (exclude:group:vm/9100, ou un regex).
  6. Options : Encrypted only si seules les sauvegardes chiffrées doivent quitter le site ; Verified only si un verify passe avant la sync.
  7. Run now et suivre le log.
proxmox-backup-manager remote create msp --host pbs-msp.example.net \
  --auth-id 'client-a-sync@pbs!push' --password 'SECRET' --fingerprint 'AB:CD:…:EF'
proxmox-backup-manager sync-job create push-msp --store pbs01 \
  --remote msp --remote-store client-a --sync-direction push \
  --schedule '05:30' --remove-vanished false --rate-out 25MiB
proxmox-backup-manager sync-job list

En pull (configuré par le MSP sur son PBS) : même commande avec --sync-direction pull (défaut) et --rate-in. Options utiles : --ns, --remote-ns, --max-depth, --group-filter, --transfer-last N (seulement les N derniers snapshots par groupe), --encrypted-only true, --verified-only true, --worker-threads.

Points de conception

  • Un remote par job push : deux jobs qui poussent vers la même cible avec remove-vanished peuvent supprimer le contenu l'un de l'autre.
  • Propriété : en push, les sauvegardes appartiennent côté MSP à l'utilisateur du remote, pas à l'utilisateur local.
  • Rétention : la cible applique ses propres prune jobs. Sans remove-vanished, un snapshot supprimé localement reste chez le MSP jusqu'à sa propre expiration.
  • Snapshots protégés : la protection n'est pas synchronisée ; elle se pose séparément sur chaque PBS.
  • Chiffrement à l'envoi : PBS 4.2 permet de chiffrer en push des snapshots non chiffrés. À valider avec le MSP avant usage (gestion de la clé).
  • Réparation : resync-corrupt recopie un snapshot dont le dernier verify a échoué (job pull vers le site sain).

Vérifications

proxmox-backup-manager sync-job list          # last-run-state: OK
proxmox-backup-manager task list --limit 5    # tâche syncjob terminée en OK

Log attendu en fin de tâche : nombre de groupes et snapshots synchronisés, volume transféré, aucune ligne error. Comparer avec le MSP le nombre de groupes des deux côtés (hebdomadaire, voir RB-15).

Rollback

Désactiver le job (Edit → Enable décoché) ou proxmox-backup-manager sync-job remove push-msp. Supprimer un job ou un remote ne supprime aucune sauvegarde, ni locale ni distante.

Pièges vus en support

  • remove-vanished activé « pour économiser de la place » : un prune local agressif ou un attaquant vide aussi la copie MSP.
  • Jeton push avec DatastorePowerUser ou DatastoreAdmin côté MSP : la copie n'est plus protégée contre une compromission du client.
  • Première sync de plusieurs To lancée sans limite de débit en journée : lien internet saturé.
  • Sync planifiée pendant la sauvegarde : snapshots en cours ignorés, copie MSP en retard d'un jour.
  • Clé de chiffrement non séquestrée : la copie MSP existe mais personne ne peut la lire.

Quand ouvrir un ticket iTop

Toute création ou modification de sync vers le MSP (jeton, remote, rétention distante) : demande P4. Sync en échec depuis plus de 48 h : P2. Restauration depuis la copie MSP : voir RB-15. Joindre proxmox-backup-manager sync-job list et le log de la dernière tâche.

Ouvrir un ticket iTop

Pour aller plus loin