Installer Proxmox Backup Server sur un VPS

Ce que Proxmox Backup Server sur un VPS vous apporte réellement

Proxmox Backup Server (PBS) sur un VPS est une cible distante qui utilise le même protocole que votre cluster Proxmox VE (virtual environment). Ainsi, après la première sauvegarde, toutes les suivantes sont incrémentielles, dédupliquées entre les guests, chiffrées avant de quitter vos locaux et vérifiables ensuite. Vous louez un VPS avec un volume bloc, installez PBS sur Debian 13, créez un datastore sur ce volume et l’ajoutez dans Proxmox VE comme stockage de type pbs. L’installation prend dix minutes. Tout le reste — namespaces, garbage collection, conservation des clés et restauration réellement testée — détermine si la sauvegarde aura encore une valeur dans un an.

La raison d’utiliser PBS plutôt que de copier des fichiers vzdump sur un disque loué tient au chunk store. Le client découpe le disque de chaque guest en chunks d’environ 4 MiB, calcule leur hash et envoie uniquement ceux que le datastore ne contient pas déjà. Pour une machine virtuelle en fonctionnement, QEMU suit les blocs modifiés dans une dirty bitmap après la première sauvegarde. L’exécution suivante ne lit donc que ces blocs sur le disque local. Un guest de 200 GB qui modifie 3 GB par jour envoie environ 3 GB par jour. C’est ce qui permet de faire fonctionner ensemble une connexion montante domestique et un volume loué. C’est aussi pourquoi un VPS comme cible de sauvegarde distante est préférable à un disque de rechange chez un ami. Si vous réfléchissez encore à l’emplacement de l’hyperviseur lui-même, Proxmox chez soi ou sur un VPS loué traite cette question séparément.

Dimensionnez le volume avant de le louer

Le dimensionnement consiste à effectuer des calculs à partir de vos propres données. Prenez l’espace réellement utilisé par chaque guest, et non la taille de son disque virtuel, puis ajoutez le volume de données modifiées chaque jour multiplié par le nombre de jours de conservation. La compression et la déduplication réduisent toutes deux ce volume. Considérez donc le résultat comme un plafond, et non comme un objectif.

[
  {
    "label": "web VM",
    "used_gb": 40,
    "daily_change_gb": 0.8,
    "store_gb": 64
  },
  {
    "label": "mail VM",
    "used_gb": 120,
    "daily_change_gb": 3.0,
    "store_gb": 210
  },
  {
    "label": "file server container",
    "used_gb": 300,
    "daily_change_gb": 1.5,
    "store_gb": 345
  }
]

Ces lignes constituent un exemple de calcul, et non une mesure. Relevez l’espace utilisé avec df -h dans chaque guest. Relevez ensuite la variation quotidienne en comparant la taille des deuxième et troisième sauvegardes dans le journal de tâches PBS, une fois qu’elles existent.

Dans l’exemple, le guest de messagerie utilise 120 Go et change d’environ 3.0 Go par jour. Trente snapshots quotidiens nécessitent donc environ 210 Go : une copie complète plus trente jours de modifications. Additionnez la dernière colonne pour les 3 guests. Le total est d’environ 619 Go. Ajoutez un cinquième pour les index, les métadonnées et l’espace nécessaire au garbage collection. Un volume de 1 To est alors approprié.

Le reste de la configuration est simple. PBS fonctionne avec 2 Go de RAM et est à l’aise avec 4 Go, car les opérations coûteuses ont lieu côté cluster : le nœud Proxmox VE lit les disques des guests et effectue le découpage en chunks ainsi que le hashing. Le VPS écrit les chunks et exécute les deux tâches lourdes : le garbage collection et la vérification. Louez le datastore sous la forme d’un volume bloc distinct plutôt que d’utiliser un disque root unique de grande taille. Vous pourrez ainsi agrandir le volume ultérieurement sans reconstruire le serveur.

Installer Proxmox Backup Server sur Debian 13

En août 2026, la combinaison actuelle est Proxmox Backup Server 4 sur Debian 13, nom de code trixie. Les anciens guides associent PBS 2 à Debian 11. Le nom de code fait partie de la définition du dépôt. La copie d’un ancien nom de suite provoque donc une erreur apt concernant l’absence du fichier Release. Commencez avec une image Debian 13 minimale. Exécutez toutes les commandes ci-dessous en tant que root ou avec sudo comme indiqué.

sudo apt update && sudo apt install -y wget
sudo wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
sha256sum /usr/share/keyrings/proxmox-archive-keyring.gpg

La somme doit être 136673be77aba35dcce385b28737689ad64fd785a797e57897589aed08db6e45. Si ce n’est pas le cas, arrêtez-vous. Un mauvais keyring signifie que vous êtes sur le point d’installer des paquets signés par une source que vous n’avez pas vérifiée.

Écrivez /etc/apt/sources.list.d/pbs.sources avec le dépôt no-subscription. C’est le dépôt adapté à un serveur sans contrat de support :

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update
sudo apt install -y proxmox-backup-server

L’interface web répond sur le port HTTPS 8007. Connectez-vous en tant que root@pam avec le mot de passe root du système, car PBS authentifie cet utilisateur via PAM (pluggable authentication modules), c’est-à-dire les mêmes comptes que ceux utilisés par le système d’exploitation. Le certificat est auto-signé et votre navigateur vous l’indiquera. L’empreinte de ce certificat est la valeur que Proxmox VE épingle ensuite. L’avertissement est donc attendu et ne constitue pas un problème à corriger.

Le port 8007 expose un formulaire de connexion sur Internet. Ne le laissez donc pas ouvert à tout le monde. Un seul fichier nftables suffit pour le gérer. L’écriture de /etc/nftables.conf flushes le ruleset actuel. Ignorez donc cette étape si un autre composant gère déjà le firewall sur ce serveur.

#!/usr/sbin/nft -f
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport 22 accept
    ip saddr 203.0.113.7 tcp dport 8007 accept
  }
}

Appliquez la configuration avec sudo systemctl enable --now nftables et gardez une deuxième session SSH ouverte pendant l’opération : policy drop, associé à une simple faute de frappe dans la règle SSH, peut vous verrouiller l’accès à votre propre serveur. Remplacez 203.0.113.7 par l’adresse depuis laquelle votre cluster se connecte. Si cette adresse est dynamique, élargissez la règle à la plage de votre fournisseur ou terminez la connexion dans un tunnel. N’oubliez pas que la plupart des panneaux VPS disposent d’un firewall réseau distinct devant la machine. Celui-ci doit autoriser le même port.

Placez le datastore sur son propre volume

Le datastore ne doit pas se trouver sur le système de fichiers racine. Lorsqu’un datastore remplit un système de fichiers racine partagé, la sauvegarde échoue, comme tout le reste sur le serveur, y compris la journalisation dont vous avez besoin pour déterminer la cause. Attachez le volume bloc, formatez-le, montez-le, puis créez seulement le datastore dans le point de montage.

lsblk
sudo mkfs.ext4 -L pbsstore /dev/vdb
sudo mkdir -p /mnt/datastore/store1

Relevez le nom du périphérique dans lsblk. Il s’agit de /dev/vdb sur la plupart des images KVM et de /dev/sdb sur les autres. Il ne faut jamais le supposer. Ajoutez le montage à /etc/fstab en utilisant le label, afin qu’un changement de nom du périphérique après un redémarrage ne puisse pas diriger le datastore vers le mauvais disque :

LABEL=pbsstore  /mnt/datastore/store1  ext4  defaults,relatime  0  2

sudo systemctl daemon-reload
sudo mount -a
findmnt -no SOURCE,TARGET,OPTIONS /mnt/datastore/store1

findmnt doit afficher le périphérique, le chemin et les options, notamment rw,relatime. Deux problèmes peuvent se cacher dans cette seule ligne. Si le montage n’est pas présent et que vous créez quand même le datastore, PBS écrit dans le système de fichiers racine sous le point de montage. Le montage suivant masque ces données sans les supprimer : le datastore semble alors vide, tandis que le système de fichiers racine reste plein. Si les options indiquent noatime, PBS refuse de fonctionner, car il effectue un contrôle de sécurité de l’accès aux fichiers lors de la création du datastore, puis à chaque garbage collection.

sudo proxmox-backup-manager datastore create store1 /mnt/datastore/store1
sudo proxmox-backup-manager datastore list

Cette commande crée un répertoire .chunks contenant 65536 sous-répertoires nommés de 0000 à ffff. Un datastore contient des centaines de milliers de petits fichiers, et non quelques gros fichiers. Deux conséquences en découlent. Copier un datastore avec un outil classique opérant au niveau des fichiers est suffisamment lent pour être inutilisable. De plus, un snapshot du volume fourni par le provider, pris pendant l’exécution des sauvegardes, ne constitue pas une copie cohérente du datastore. C’est la même raison pour laquelle les snapshots ne remplacent pas les sauvegardes ailleurs.

Les namespaces empêchent deux hôtes d’entrer en conflit

Un datastore est plat par défaut. Les sauvegardes sont nommées vm/100, ct/101 et host/<name>. Deux clusters qui possèdent chacun un guest avec l’ID 100 écrivent dans le même groupe. Leurs snapshots s’entremêlent, et une règle de rétention prévue pour l’un compte aussi les snapshots de l’autre. Les namespaces donnent à chaque source sa propre arborescence dans un datastore unique.

Créez-les sur l’hôte PBS. L’argument --repository prend la forme [[auth-id@]server[:port]:]datastore. Pour un namespace local, utilisez donc root@pam@localhost:store1. La commande demande le mot de passe root.

sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-home
sudo proxmox-backup-client namespace create --repository 'root@pam@localhost:store1' pve-office
sudo proxmox-backup-client namespace list --repository 'root@pam@localhost:store1'

La déduplication n’est pas affectée par cette séparation. Les chunks sont partagés dans tout le datastore. Ainsi, dix guests Debian répartis entre trois namespaces ne stockent qu’une seule copie du système de base. C’est l’intérêt d’un datastore avec des namespaces plutôt que d’un datastore par hôte : des datastores distincts signifient des pools de chunks distincts, et ces pools distincts obligent à stocker plusieurs fois la même installation Debian.

Attribuez à chaque source son propre compte, limité à son namespace. Un token d’API (application programming interface) est un identifiant d’authentification rattaché à un utilisateur et doté de ses propres permissions. C’est ce qu’il faut utiliser sur une machine susceptible d’être volée.

sudo proxmox-backup-manager user create backup@pbs --email you@example.com
sudo proxmox-backup-manager user generate-token backup@pbs pve-home
sudo proxmox-backup-manager acl update /datastore/store1/pve-home DatastoreBackup --auth-id 'backup@pbs!pve-home'

La commande du token affiche le secret une seule fois :

Result: {
  "tokenid": "backup@pbs!pve-home",
  "value": "d63e505a-e3ec-449a-9bc7-1da610d4ccde"
}

Copiez-le maintenant, car PBS ne conserve aucune forme du secret qu’il pourrait vous afficher à nouveau. Vérifiez deux fois la commande de contrôle d’accès. Elle nomme le token, backup@pbs!pve-home, et non l’utilisateur, car les permissions du token sont calculées uniquement à partir des entrées qui nomment le token lui-même. Une entrée contenant seulement backup@pbs laisse le token sans aucun accès. La première sauvegarde échoue alors à cause des permissions, et non à cause d’un problème visible sur le réseau. Le chemin est tout aussi important : un token limité à /datastore/store1/pve-home ne peut rien lire ni supprimer dans le namespace office. Ainsi, un cluster compromis ne peut pas détruire l’historique d’un autre site.

Ajouter le VPS comme stockage de sauvegarde dans Proxmox VE

Lisez d’abord l’empreinte du certificat sur l’hôte PBS.

sudo proxmox-backup-manager cert info | grep Fingerprint

Ensuite, sur n’importe quel nœud du cluster :

sudo pvesm add pbs pbs-offsite --server pbs.example.com --datastore store1
sudo pvesm set pbs-offsite --username 'backup@pbs!pve-home' --password
sudo pvesm set pbs-offsite --fingerprint 'FINGERPRINT_FROM_CERT_INFO'
sudo pvesm set pbs-offsite --namespace pve-home
sudo pvesm set pbs-offsite --prune-backups keep-all=1

Collez la valeur cert info affichée à la place de l’espace réservé de la troisième ligne. Passer --password sans valeur demande à pvesm de la saisir, afin que le secret du token ne soit pas enregistré dans l’historique du shell. Il est stocké dans /etc/pve/priv/storage/pbs-offsite.pw, tandis que la définition du stockage est enregistrée dans /etc/pve/storage.cfg. Cette définition est répliquée sur chaque nœud du cluster. Vous ne configurez donc le stockage qu’une seule fois pour l’ensemble du cluster.

--prune-backups keep-all=1 indique à Proxmox VE de ne rien supprimer. La rétention se configure côté PBS, comme expliqué plus bas. La raison est simple : le token n’a alors pas besoin de permission de suppression. Ainsi, un cluster chiffré par un ransomware ne peut pas atteindre l’historique distant qui doit permettre sa restauration et le purger.

sudo pvesm status --storage pbs-offsite
sudo vzdump 100 --storage pbs-offsite --mode snapshot

pvesm status affiche active dans la colonne d’état, avec l’espace total et l’espace utilisé du datastore à côté. inactive signifie que le nœud n’a pas pu établir une session TLS (transport layer security) vers le port 8007. Il s’agit d’un problème de firewall ou d’empreinte, pas d’un problème d’identifiants.

La première sauvegarde téléverse toutes les données. Faites donc le calcul avant de la lancer. 200 GB correspondent à 1600 gigabits. Une liaison montante à 100 Mbit transporte 0.1 gigabit par seconde. La durée minimale est donc d’environ quatre heures et demie, et la durée réelle sera plus longue. Lancez-la lorsque la bande passante ne vous est pas nécessaire. Les exécutions suivantes n’envoient que les nouveaux chunks.

Chiffrement côté client et emplacement de la clé

Le VPS est un ordinateur qui ne vous appartient pas. Chiffrez côté client : le datastore ne contient alors que des blocs que le fournisseur ne peut pas lire.

sudo pvesm set pbs-offsite --encryption-key autogen

Cette commande écrit une nouvelle clé dans /etc/pve/priv/storage/pbs-offsite.enc. Seul root peut la lire, et elle est répliquée avec le reste de /etc/pve. À partir de la sauvegarde suivante, le client chiffre chaque bloc avant son envoi. Le serveur peut toujours lister vos snapshots et leur taille, mais il ne peut pas lire leur contenu.

Voici le point qui transforme une sauvegarde en protection plutôt qu’en risque. Une clé générée n’a pas de passphrase et existe uniquement sur le cluster qu’elle protège. Si ce cluster est volé ou chiffré par un tiers, le VPS contient des données que personne ne peut ouvrir. Copiez la clé hors du cluster le jour où vous la créez.

sudo cp /etc/pve/priv/storage/pbs-offsite.enc /root/pbs-offsite.enc
sudo proxmox-backup-client key paperkey /root/pbs-offsite.enc

key paperkey affiche la clé sous la forme d’un document destiné à être imprimé sur papier et conservé ailleurs. Traitez le fichier comme un secret, car toute personne qui le détient peut déchiffrer chaque sauvegarde créée avec cette clé. Pour une installation plus importante, PBS prend également en charge une master key : une paire de clés RSA (Rivest Shamir Adleman) créée avec proxmox-backup-client key create-master-key. Chaque sauvegarde stocke alors sa propre clé de chiffrement, chiffrée avec la partie publique, tandis que la partie privée reste hors ligne pour la récupération.

Il faut connaître une conséquence de cette conception avant de commencer, et non après. Pour les sauvegardes chiffrées, le digest du bloc est calculé à partir du contenu en clair combiné à la clé de chiffrement. Deux blocs identiques chiffrés avec des clés différentes produisent donc des digests différents et ne sont jamais dédupliqués ensemble. Si vous changez de clé, la sauvegarde suivante transfère de nouveau toutes les données. Les anciens blocs restent présents jusqu’à la purge et la collecte de leurs snapshots. Décidez du chiffrement avant le premier upload.

Élagage des snapshots et récupération par le garbage collector

C’est la tâche qui est souvent oubliée, alors que c’est elle qui finit par remplir le volume. L’élagage d’un snapshot supprime ses métadonnées : le manifest, les indexes, le log et les notes. Il ne supprime aucun chunk. Les chunks sont partagés entre les snapshots. Il est donc impossible de savoir qu’un chunk n’est plus utilisé avant d’avoir lu tous les indexes restants. C’est le rôle du garbage collector. Un datastore avec un planning d’élagage, mais sans planning de garbage collection, ne fait que grossir.

Configurez les deux. Commencez par la rétention, avec un job par namespace :

sudo proxmox-backup-manager prune-job create home-daily --store store1 --ns pve-home --schedule '02:30' --keep-daily 14 --keep-weekly 8 --keep-monthly 6
sudo proxmox-backup-manager prune-job list

Configurez ensuite le planning de collection sur le datastore, quelques heures après le job d’élagage et en dehors de la fenêtre de sauvegarde :

sudo proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27'
sudo proxmox-backup-manager datastore show store1

Vérifiez une fois la séparation des rôles sur l’hôte PBS :

df -h /mnt/datastore/store1
sudo proxmox-backup-manager garbage-collection start store1
df -h /mnt/datastore/store1

Exécutez le job d’élagage, puis df. La valeur utilisée ne change pas. Exécutez ensuite le garbage collector, puis df. La valeur change.

Le garbage collection s’exécute en deux phases. La première parcourt tous les indexes du datastore et met à jour l’heure d’accès de chaque chunk référencé par ces indexes. La seconde supprime les chunks dont l’heure d’accès est antérieure à la limite. Cette limite correspond à 24 hours et 5 minutes avant le début de l’exécution, ou au début de la plus ancienne sauvegarde encore en cours d’écriture, selon l’heure la plus ancienne. Cette marge existe parce que Linux monte par défaut les systèmes de fichiers avec relatime. L’heure d’accès est ainsi mise à jour environ une fois par jour, et non à chaque lecture. Un chunk écrit il y a une heure n’est donc jamais supprimé, même si aucun index ne le référence encore. L’espace libéré par un élagage apparaît lors de la première collection exécutée plus d’un jour après le dernier accès au chunk. Lorsqu’un datastore semble n’avoir rien récupéré, il se trouve souvent encore dans cette fenêtre.

Sur un petit VPS, c’est la tâche la plus lourde exécutée sur la machine, car elle effectue un stat sur chaque fichier de chunk du volume. Le log de la tâche se termine par un récapitulatif des éléments supprimés et de ceux qui restent en attente à cause de la période de grâce. S’il reste beaucoup d’éléments en attente, relancez la tâche le lendemain. PBS expose gc-atime-safety-check et gc-atime-cutoff comme options de réglage du datastore. Laissez ces options inchangées. Elles sont prévues pour les stockages qui ne peuvent pas enregistrer les heures d’accès. Désactiver le contrôle de sécurité sur un système de fichiers monté avec noatime peut supprimer des chunks encore référencés par des snapshots actifs.

La vérification confirme que les chunks sont toujours lisibles

Une sauvegarde téléversée sans erreur peut devenir illisible un an plus tard. La vérification relit les chunks et les compare aux checksums stockés dans l’index. Les dommages sont ainsi détectés selon une planification, au lieu de l’être pendant une restauration.

sudo proxmox-backup-manager verify store1 --read-threads 1 --verify-threads 4

Limitez le nombre de threads sur un petit VPS. La vérification dépend du disque et du CPU. Elle entrerait sinon en concurrence avec les autres tâches du serveur. Pour planifier la vérification, utilisez l’onglet Verify Jobs du datastore dans l’interface web. Une tâche hebdomadaire qui ignore les snapshots déjà vérifiés et revérifie ceux datant de plus de 30 jours couvre progressivement l’ensemble du datastore sans répéter le travail.

Un snapshot qui échoue à la vérification est marqué comme ayant échoué dans la vue du datastore. N’ignorez pas cet échec. Les chunks sont partagés. Un seul chunk endommagé provenant d’une image de base peut donc faire échouer tous les snapshots qui le référencent. Pour corriger le problème, oubliez les snapshots en échec, puis lancez une nouvelle sauvegarde. Les chunks manquants seront alors téléversés de nouveau. Si les échecs continuent, suspectez le stockage sous-jacent au datastore et mettez en place une surveillance de l’état du disque sur le VPS afin que le disque vous avertisse avant la tâche de vérification.

Tester une restauration, puis la tester sans le cluster

Vous ne savez pas si une sauvegarde fonctionne tant que vous n’en avez pas restauré une. Ces deux tests vérifient des éléments différents.

Invité complet, sur le cluster :

sudo pvesm list pbs-offsite
sudo qmrestore 'pbs-offsite:backup/vm/100/2026-08-14T22:00:00Z' 999 --storage local-lvm

La première colonne de pvesm list contient l’ID du volume, et l’horodatage en fait partie. Copiez donc le vôtre au lieu de saisir l’exemple. Restaurez-le avec un ID d’invité inutilisé et sur un autre stockage, puis démarrez-le avec son interface réseau déconnectée. Ne restaurez jamais par-dessus un invité en cours d’exécution pour vérifier le fonctionnement des sauvegardes. Si la restauration échoue en cours de route, vous risquez également de perdre la copie opérationnelle.

Le deuxième test est celui que personne n’exécute. Supposez que le bâtiment qui héberge le cluster a disparu, puis restaurez la sauvegarde depuis une machine qui n’en a jamais fait partie. Sur n’importe quelle machine Debian 13, ajoutez le dépôt réservé au client avec /etc/apt/sources.list.d/pbs-client.sources :

Types: deb
URIs: http://download.proxmox.com/debian/pbs-client
Suites: trixie
Components: main
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

sudo apt update && sudo apt install -y proxmox-backup-client
export PBS_REPOSITORY='backup@pbs!pve-home@pbs.example.com:store1'
export PBS_PASSWORD='<the token secret>'
export PBS_FINGERPRINT='<the value cert info printed>'
proxmox-backup-client snapshot list --ns pve-home
proxmox-backup-client snapshot files vm/100/2026-08-14T22:00:00Z --ns pve-home
proxmox-backup-client restore vm/100/2026-08-14T22:00:00Z 'ARCHIVE_NAME_FROM_THAT_LIST' ./restore-test --keyfile ./pbs-offsite.enc --ns pve-home

Remplacez les trois valeurs entre guillemets par vos propres valeurs, et utilisez comme nom d’archive sur la dernière ligne celui affiché par snapshot files. Ce test vérifie ce que le premier ne peut pas vérifier : la copie de votre fichier de clé permet bien de déchiffrer des données réelles, et vous pouvez piloter le client depuis une machine qui n’a jamais contenu la configuration de votre cluster. Notez les quatre valeurs nécessaires : la chaîne du dépôt, le secret du token, l’empreinte et le fichier de clé. Conservez-les ensemble à l’emplacement indiqué par votre plan de reprise après sinistre.

Ce que la déduplication change ou non sur votre facture de stockage

La déduplication est bien réelle et fonctionne sur l’ensemble du datastore. Dix guests Debian partagent une copie du système de base. Le stockage du deuxième guest identique ne coûte donc presque rien. Elle réduit aussi la bande passante nécessaire à l’upload, car le client envoie une somme de contrôle au lieu des données pour chaque chunk que le serveur possède déjà.

Il est important de préciser ce qu’elle ne fait pas.

• Elle ne réduit pas les données qui changent. Une base de données qui réécrit une grande partie de ses fichiers chaque nuit produit de nouveaux chunks chaque nuit, et la rétention les multiplie.
• Elle ne franchit pas une limite de clé de chiffrement, comme indiqué plus haut.
• Elle ne franchit pas une limite de datastore, ce qui constitue tout l’intérêt des namespaces.
• Elle n’empêche pas un volume de se remplir. Lorsque le datastore est plein, les sauvegardes échouent. Les seules solutions sont d’utiliser un volume plus grand ou de réduire la rétention.

N’ajoutez pas une autre couche de déduplication en dessous. Les chunks arrivent déjà dédupliqués et compressés par le client. La déduplication ZFS sous un datastore consomme donc de la RAM pour rechercher des correspondances qui ont été supprimées avant l’écriture. Utilisez ici ext4 ou xfs sans déduplication sur le volume.

L’interface web affiche un facteur de déduplication pour le datastore. Ce nombre décrit vos guests. C’est le seul facteur utile pour vos prévisions, car les ratios publiés correspondent aux données d’autres utilisateurs. Si vous avez également besoin de sauvegardes au niveau des fichiers pour des machines qui ne sont pas des guests Proxmox, exécutez-les en parallèle sur le même VPS : PBS est une cible consciente de l’hyperviseur pour les guests complets, tandis que restic et BorgBackup ciblent des répertoires, et que les sauvegardes restic vers un VPS conviennent aux laptops et aux serveurs autonomes que PBS n’a jamais été conçu pour couvrir.

Modes de défaillance et symptômes observables

Le stockage apparaît comme inactif. pvesm status --storage pbs-offsite affiche inactive lorsque le nœud ne peut pas terminer une session TLS vers le port 8007. Vérifiez le pare-feu du VPS, puis le pare-feu réseau distinct du fournisseur, puis l’empreinte. Une empreinte qui ne correspond plus au certificat produit le même symptôme visible qu’un port bloqué. Elle change chaque fois que le certificat est remplacé.

La première sauvegarde échoue à cause des permissions. L’entrée de contrôle d’accès doit désigner le token, et non l’utilisateur. Elle doit aussi couvrir l’espace de noms vers lequel pointe le stockage. Vérifiez ces deux éléments dans l’onglet des permissions du datastore, dans l’interface web, avant de chercher ailleurs.

Le garbage collection refuse de démarrer. Le contrôle de sécurité de la date de dernier accès a échoué. Cela signifie presque toujours que le système de fichiers du datastore est monté avec noatime. Exécutez findmnt -no OPTIONS /mnt/datastore/store1 pour le confirmer, corrigez l’option dans /etc/fstab, puis remontez le système de fichiers. Ne désactivez pas ce contrôle pour contourner le problème.

Le datastore ne fait qu’augmenter. Les tâches de purge s’exécutent, mais rien n’est récupéré. Soit aucune planification de garbage collection n’est définie, soit chaque collecte a lieu dans la fenêtre de grâce de 24 heures, car elle s’exécute juste après les sauvegardes. Vérifiez la planification avec proxmox-backup-manager datastore show store1.

Une sauvegarde qui était rapide prend désormais des heures. Un guest qui a été arrêté, migré ou restauré perd son dirty bitmap. L’exécution suivante relit donc l’intégralité du disque côté cluster, même si elle téléverse très peu de données. Le journal de la tâche indique une longue durée et un faible volume téléversé. L’exécution suivante redevient rapide. Si toutes les tâches du VPS sont lentes, la cause se situe généralement en dehors du datastore. Le temps de steal CPU causé par un voisin bruyant est le premier élément à mesurer.

FAQ

Pourquoi le datastore de Proxmox Backup Server continue-t-il de grossir lorsque le job de prune s’exécute ?

Parce que le prune supprime uniquement les métadonnées des snapshots : le manifeste, les index, le journal et les notes. Les chunks restent sur le disque jusqu’à ce que le garbage collection supprime ceux qui ne sont plus référencés par aucun index. Planifiez le datastore avec proxmox-backup-manager datastore update store1 --gc-schedule 'Sun 04:27', puis vérifiez-le en exécutant df -h sur le chemin du datastore avant et après proxmox-backup-manager garbage-collection start store1. Prévoyez un délai d’au moins un jour, car la deuxième phase supprime uniquement les chunks dont la date d’accès remonte à plus de 24 heures et 5 minutes.

De quel espace disque un VPS exécutant Proxmox Backup Server a-t-il besoin ?

Additionnez l’espace réellement utilisé par chaque guest, puis ajoutez la quantité de données modifiées quotidiennement par chaque guest, multipliée par le nombre de jours de conservation. Ce total constitue une limite supérieure, car la compression et la déduplication réduisent toutes deux l’espace nécessaire. Ajoutez environ un cinquième pour les index et la marge de fonctionnement, puis arrondissez à la taille de volume que vous pouvez acheter. Vérifiez de nouveau après deux semaines dans la vue du datastore, en comparant avec l’utilisation réelle, car une estimation faite avant le premier backup est toujours erronée dans un sens ou dans l’autre.

Où faut-il stocker la clé de chiffrement des backups ?

N’importe où, à condition de ne pas la conserver uniquement sur le cluster qu’elle protège. Proxmox VE la conserve à /etc/pve/priv/storage/<storage>.enc. Ce fichier est répliqué sur chaque nœud et est donc perdu avec le cluster. Copiez-le dès le premier jour, imprimez-le avec proxmox-backup-client key paperkey et conservez cette copie dans un autre bâtiment. Notez également que la clé intervient dans le digest des chunks. La remplacer ultérieurement signifie donc que le backup suivant réenverra tout.

Faut-il un datastore par hôte Proxmox, ou utiliser des namespaces ?

Utilisez un datastore et un namespace par hôte source ou par cluster. La déduplication fonctionne à l’échelle d’un datastore, et non entre plusieurs datastores. Séparer les hôtes stocke donc plusieurs fois les mêmes images de base. Les namespaces séparent les groupes de backups. Deux hôtes qui possèdent chacun un guest avec l’ID 100 ne peuvent ainsi pas entrer en collision. Un chemin de contrôle d’accès de la forme /datastore/store1/pve-home limite le token API de chaque hôte à son propre namespace.

Un petit VPS peut-il suivre la charge en tant que serveur de backup Proxmox ?

En général, oui, dans un homelab, car le découpage en chunks et le hashing s’effectuent sur le nœud Proxmox VE, et non sur le serveur de backup. Le VPS écrit les chunks et exécute les deux jobs lourds : le garbage collection et la vérification. Attribuez-lui 4 GB de RAM et limitez le nombre de threads de vérification. Planifiez ces deux jobs en dehors de la fenêtre de backup. S’ils prennent encore beaucoup plus de temps que ne devrait le nécessiter le disque, mesurez le steal time avant d’acheter une offre plus grande.