Une sauvegarde posée sur le même disque que les machines virtuelles disparaît avec lui. Réinstallation du VPS, disque remplacé, incident matériel : le fichier vzdump n’est plus là au moment où il servirait. La copie utile est celle qui vit ailleurs.
Où écrire la copie
Proxmox VE sait lancer vzdump vers un stockage local. Ce n’est qu’une première étape. Proxmox Backup Server reçoit ensuite ces sauvegardes, les déduplique et garde plusieurs dates. Le disque de PBS, ou le dépôt vers lequel il synchronise, ne doit pas être le disque système du VPS qui héberge les VM.
Un NAS, un second serveur, ou un stockage objet font l’affaire. Le critère est unique : détruire le disque des VM ne détruit pas les sauvegardes.
Ce qu’on planifie
- Une sauvegarde quotidienne des VM qui portent le site et la base.
- Une rétention de plusieurs jours, pas une seule copie écrasée chaque nuit.
- Une notification si la tâche échoue. Une sauvegarde silencieuse et ratée ne se voit qu’à la restauration.
- Les conteneurs et la configuration de l’hôte, pas seulement le disque de la VM applicative.
Restaurer une fois, avant d’en avoir besoin
On choisit une sauvegarde datée, on la restaure sur une VM de test, on démarre l’application et on ouvre une page. Si la base refuse de monter ou si le disque est trop petit, on le découvre ce jour-là, pas le jour où le VPS est vide.
La base PostgreSQL mérite en plus une sauvegarde logique, décrite dans l’article sur l’envoi chiffré vers un stockage objet. L’image de la VM et le pg_dump ne répondent pas au même incident : l’un reconstruit la machine, l’autre reconstruit les données dans une machine neuve.
