Repères · Tous niveaux · Relecture documentaire : 2 octobre 2026. Les exemples sont génériques ; adapter les noms, versions et chemins avant toute modification.
Le RPO indique la quantité de travail que l’on accepte de perdre, exprimée en durée depuis la dernière sauvegarde. Le RTO est le délai visé pour rétablir le service. Une sauvegarde hebdomadaire peut donc perdre presque une semaine de modifications ; elle n’est pas adaptée à tous les usages.
Un snapshot sur le même pool accélère certains retours arrière mais ne constitue pas une copie indépendante. PBS apporte une gestion dédiée des sauvegardes ; sa présence ne dispense pas d’une autre copie ou d’une protection hors du domaine de panne principal selon le risque.
Inventorier les VM/CT et leurs volumes. Vérifier ce que la tâche inclut réellement, notamment les points de montage de CT et les données accessibles par réseau. Pour une base de données, prévoir une méthode cohérente avec le moteur et l’application ; copier des fichiers ouverts sans coordination peut être insuffisant.
Choisir horaires, rétention et stockage selon la croissance mesurée. Protéger les accès PBS, les clés de chiffrement et les notifications. Une clé perdue peut rendre une sauvegarde chiffrée inutilisable ; conserver sa récupération hors du serveur concerné.
Contrôler le résultat de chaque tâche et programmer les vérifications PBS adaptées. La vérification des blocs et une restauration applicative répondent à deux questions différentes. La suppression logique de sauvegardes et la récupération physique des blocs par garbage collection ont des rôles distincts : ne pas attendre une libération instantanée dans tous les cas.
Si le serveur de sauvegarde s’allume à la demande, attendre qu’il soit réellement prêt avant de lancer les tâches. Son arrêt ne doit intervenir qu’après confirmation de leur fin et absence d’autres activités nécessaires. Un échec doit produire une alerte, pas être assimilé à une sauvegarde réussie.
Restaurer régulièrement un invité dans un réseau isolé et sous un identifiant distinct. Empêcher les doublons d’IP et les envois de courriels ou traitements automatiques. Vérifier connexion, données récentes, pièces jointes et dépendances. Mesurer la durée et consigner les difficultés. Nettoyer le test selon une décision contrôlée après validation.
Preuve utile : date du point restauré, périmètre, durée, tests fonctionnels et personne ayant confirmé le résultat.
Dans Datacenter → Storage → Add → Proxmox Backup Server, préparer les champs suivants. Le serveur PBS et son datastore doivent déjà exister et avoir les droits appropriés.
| Champ | Comment le remplir | Pourquoi |
|---|---|---|
| ID | Nom de stockage lisible | Référence utilisée par les jobs |
| Server / port | Nom ou adresse privée, port PBS prévu | Joignabilité et certificat cohérents |
| Username | Compte ou identifiant de jeton dédié selon format PBS | Éviter un compte administrateur global |
| Password / secret | Secret du compte ou du jeton | Stockage protégé, jamais dans le wiki |
| Datastore | Nom exact du datastore | Ne pas confondre avec un chemin local arbitraire |
| Namespace | Espace logique si utilisé | Séparer usages et permissions |
| Fingerprint | Empreinte vérifiée par un autre canal si nécessaire | Ne pas accepter l’identité d’un serveur inconnu |
| Encryption | Politique et clé de chiffrement choisies | Garder une copie de récupération hors du serveur |
Tester l’inventaire puis un premier backup. Un stockage affiché actif ne prouve pas encore les droits d’écriture ou de restauration.
| Paramètre | Décision | Contrôle |
|---|---|---|
| Node / sélection | Tous les invités nécessaires ou liste explicite | Un nouveau CT sera-t-il inclus automatiquement ? |
| Storage | PBS indépendant prévu | Capacité, fenêtre et disponibilité |
| Schedule | Horaire hors maintenance concurrente | Fuseau et sauvegarde manquée |
| Mode | Snapshot si adapté ; arrêt/suspension selon contraintes | Cohérence de l’application et interruption acceptée |
| Compression | Option supportée pertinente au backend | CPU et durée mesurés |
| Retention | Nombre de points horaires/journaliers/hebdomadaires/mensuels | Historique suffisant et capacité réelle |
| Notifications | Cible et filtre de résultat | Envoyer un essai et vérifier sa réception |
| Limites de débit / concurrence | Éviter de saturer réseau et disques | Durée complète dans la fenêtre disponible |
Les règles de rétention ne s’additionnent pas naïvement : un même point peut satisfaire plusieurs catégories. Vérifier la liste de points conservés avant purge. Un snapshot à chaud d’un OS ne garantit pas une sauvegarde métier cohérente d’une base ; utiliser les mécanismes applicatifs adaptés.
Pour chaque point de montage, noter origine, chemin, option backup et méthode de restauration. Les bind mounts et device mounts ne sont pas inclus comme un volume géré ordinaire par vzdump. Si les données sont sur un NAS ou dans une autre VM, le backup du système CT peut ne contenir aucun de ces fichiers. Restaurer un CT vide de ses données peut pourtant se terminer techniquement avec succès.
Prune retire des points selon la politique. Garbage collection récupère les chunks devenus non référencés avec ses contraintes de sécurité et de temps ; supprimer un snapshot ne rend donc pas forcément immédiatement les Go. Verify contrôle l’intégrité des données sauvegardées. Sync copie vers ou depuis un autre PBS selon configuration ; examiner propagation des suppressions et droits.
Planifier ces tâches pour qu’elles terminent réellement. Si PBS est hébergé sur un serveur réveillé pour les backups, l’arrêt doit attendre jobs VE, écritures, vérification, synchronisation et collecte prévues. Une simple minuterie « éteindre après deux heures » ne sait pas qu’une tâche a pris du retard. En cas d’échec, conserver le serveur allumé et alerter selon la politique.
Choisir un point connu, restaurer sous un autre ID sur un réseau isolé et empêcher doublon IP, envoi de mails et tâches externes. Vérifier démarrage, montages, fichiers, base, comptes et fonction métier. Mesurer temps de reprise et perte de données maximale par rapport à l’heure de sauvegarde. Enregistrer cette preuve.
Un test de téléchargement d’un fichier ne remplace pas toujours une restauration d’application complète. Inversement, une VM restaurée qui démarre ne prouve pas que tous les documents sont présents. Garder clés de chiffrement, comptes de secours et procédure PBS accessibles en cas de perte de l’hôte principal.