En 2026, le datastore de Proxmox Backup Server 4.2 est plein : faut-il nettoyer ou étendre ?

Le datastore PBS affiche une occupation élevée, alors que vous venez de supprimer des sauvegardes.

Cette semaine, vérifiez d’abord les tâches prune et GC, puis comparez l’état du datastore à celui du système de fichiers ; ne supprimez jamais manuellement les fichiers .chunks. Si la capacité est réellement épuisée ou si le GC ne peut plus progresser, choisissez une intervention adaptée au backend et à une procédure de récupération vérifiée.

Les administrateurs d’une instance PBS autonome peuvent suivre cet ordre pour séparer une tâche défaillante d’un problème de capacité.
Les MSP doivent aussi vérifier que la politique de conservation et les journaux permettent d’identifier le client et la modification concernés.
Les responsables d’une petite infrastructure de sauvegarde multi-locataire peuvent s’en servir pour réévaluer leur capacité et leurs limites de stockage.

Dernière vérification : 28 octobre 2026, à partir de la publication officielle de PBS 4.2 et de la documentation officielle sur le stockage et la maintenance.

Commencez par établir si le problème concerne les tâches ou le stockage

Le mot « plein » peut décrire plusieurs états différents : le système de fichiers hébergeant le datastore n’a plus d’espace, une tâche échoue faute de ressources disponibles, ou les sauvegardes continuent à croître alors que la conservation attendue ne s’applique pas. Ces situations n’appellent pas la même réponse. Ajouter de la capacité ne corrige pas une politique de conservation incorrecte ; supprimer des sauvegardes ne résout pas un montage ou un espace de stockage mal identifié.

La version 4.2 de Proxmox Backup Server a été publiée le 29 avril 2026, selon la publication officielle de Proxmox. La documentation de cette version décrit les datastores, les politiques de conservation et les fonctions de maintenance. Elle ne permet pas, à elle seule, de conclure qu’un datastore qui se remplit révèle un défaut général du logiciel.

Pour cadrer le diagnostic, notez ce que vous observez et à quelle couche appartient le signal :

• Tâche prune absente ou en échec : la politique de conservation peut ne pas avoir été appliquée, ou son exécution peut être interrompue.
• GC non planifié, en échec ou non terminé : des blocs inutilisés peuvent rester à traiter ; cela ne prouve pas que tout l’espace associé aux sauvegardes supprimées est récupérable.
• Datastore signalé comme saturé : ce constat doit être comparé à l’occupation du volume ou du système de stockage qui héberge les données.
• Système de fichiers réellement plein : l’espace disponible pour les opérations et les nouvelles sauvegardes est limité, mais la marche à suivre dépend du backend et de son état.
• Politique inadaptée à l’usage : une conservation plus longue que prévu, ou une organisation des tâches qui ne correspond pas aux attentes, peut expliquer une croissance régulière sans qu’il y ait de panne logicielle.

Dans PBS, prune et GC ont des rôles distincts. Prune applique une politique de conservation aux instantanés. Le garbage collection examine les blocs du datastore et peut traiter ceux qui ne sont plus référencés. La déduplication signifie qu’un bloc peut contribuer à plusieurs sauvegardes : la disparition d’un instantané ne prouve donc pas que ses données occupent désormais de l’espace supprimable. La documentation officielle de maintenance est la référence pour comprendre les opérations de maintenance et leur séquencement.

Pour l’administrateur : contrôlez l’exécution avant de modifier la rétention

Sur une instance autonome, commencez par l’interface de gestion et les journaux des tâches. Relevez la dernière exécution de prune pour le datastore concerné, son résultat et tout message d’erreur. Faites de même pour le GC : un travail planifié mais en échec n’équivaut pas à une opération terminée. Conservez ces éléments avant toute correction, afin de pouvoir comparer l’état initial et l’état après intervention.

Vérifiez ensuite si la politique de conservation correspond bien au besoin opérationnel. Confirmez qu’elle s’applique au bon groupe de sauvegardes et que ses règles ne conservent pas davantage d’instantanés que prévu. Ne réduisez pas la rétention uniquement parce qu’un indicateur d’occupation est élevé : cela peut supprimer des points de restauration requis, sans résoudre l’origine du problème.

Comparez enfin la vue de PBS et l’occupation de la cible de stockage. Pour une cible montée comme système de fichiers, des commandes de lecture comme findmnt -T /chemin/du/datastore et df -hT /chemin/du/datastore permettent d’identifier le montage et son occupation. La commande du peut aider à examiner les répertoires, mais son résultat ne doit pas être interprété comme une mesure exacte de l’espace récupérable par prune ou GC, notamment avec des données partagées et dédupliquées. Pour les commandes PBS, vérifiez les options et la syntaxe dans le référentiel officiel des commandes, plutôt que de reprendre une commande trouvée dans un message de forum.

Un écart entre les indicateurs mérite d’être expliqué, pas « corrigé » en supprimant des fichiers. Vérifiez que vous mesurez le bon chemin, que le datastore est bien sur le volume attendu et qu’aucun autre usage ne consomme l’espace. Si les tâches ont échoué, traitez d’abord leur cause à partir des journaux. Si elles se sont terminées, mais que la capacité reste proche de sa limite, préparez la décision de capacité sans supposer qu’une nouvelle exécution libérera une quantité déterminée.

Pour un MSP : distinguez le problème client du changement de politique

Lorsque vous administrez plusieurs environnements, évitez de traiter l’ensemble des sauvegardes comme un seul incident. Associez chaque alerte à son datastore, aux tâches correspondantes et à la politique de rétention du client. Cette séparation réduit le risque d’appliquer à un groupe les règles destinées à un autre ou de supprimer des points de restauration sans validation.

Conservez une chronologie minimale de l’incident : heure de l’alerte, résultat des dernières tâches prune et GC, changement récent de configuration, messages d’erreur et état du stockage. Il ne s’agit pas seulement de faciliter le dépannage. Cette trace permet aussi de distinguer une opération planifiée qui n’a pas été lancée, une tâche qui a échoué et un volume arrivé à saturation malgré un traitement correct.

Avant de modifier la rétention d’un client, confirmez avec la personne responsable quelles sauvegardes doivent rester disponibles et si une copie indépendante existe. Une politique plus courte peut diminuer la durée de conservation, mais elle ne constitue pas une méthode générale de réparation. De même, déclencher une opération de maintenance sur un stockage déjà saturé n’est pas automatiquement sans risque : vérifiez d’abord son état et les instructions PBS correspondant à votre configuration.

Un fil de discussion de la communauté daté du 22 septembre 2026 rapporte un cas de manque d’espace ; il constitue un exemple de dépannage individuel, pas une preuve d’une cause commune à PBS 4.2. Consultez-le comme un retour communautaire contextualisé, et non comme une procédure officielle. Les suggestions publiées par des utilisateurs ne remplacent ni la documentation ni l’analyse de vos propres journaux.

Pour une petite infrastructure multi-locataire : identifiez le backend avant l’action

Le bon indicateur et les précautions à prendre dépendent de l’emplacement réel des données. La documentation officielle présente les options de stockage et les conditions d’utilisation : consultez la documentation PBS sur les datastores, puis confrontez-la à votre configuration, plutôt que de transposer un cas vu sur un autre système.

Pour un datastore sur ext4 ou XFS, confirmez quel système de fichiers est monté au chemin utilisé, son espace disponible et l’état de ce montage. Les outils du système d’exploitation donnent une vue du système de fichiers ; ils ne vous disent pas directement combien d’espace prune ou GC pourront récupérer.

Pour un datastore hébergé sur ZFS, distinguez la place disponible dans le système de fichiers ou le jeu de données de celle du pool. Vérifiez également la topologie et l’état du pool avant d’envisager une modification. Une valeur d’occupation isolée ne suffit pas à autoriser une opération sur le pool.

Pour une cible S3, ne supposez pas que les outils de mesure d’un système de fichiers local décrivent le stockage distant. Vérifiez les limites, les compteurs et les règles de votre service S3, ainsi que la manière dont votre déploiement PBS l’utilise. Confirmez les responsabilités de chaque couche avant de modifier une configuration. Les capacités et modalités d’un stockage distant varient selon l’implémentation ; la seule présence du terme S3 ne garantit pas que deux installations se comportent de la même façon.

Dans tous les cas, n’appliquez pas à un datastore des conseils de déplacement ou de suppression de .chunks tirés d’un forum, sauf si une documentation officielle les confirme explicitement pour votre configuration. Gardez également à l’esprit qu’une opération sur un stockage partagé entre clients peut affecter plusieurs politiques de conservation à la fois.

Décidez à partir de l’état constaté, puis validez la réparation

Utilisez la liste suivante comme point de contrôle. Cochez un élément uniquement après avoir relevé l’information correspondante ; si un état n’est pas confirmé, restez au diagnostic plutôt que de passer directement à une suppression.

• [ ] J’ai identifié le datastore, son chemin et le backend qui héberge réellement les données.
• [ ] J’ai relevé l’état et les journaux des tâches prune et GC, sans confondre tâche planifiée et tâche réussie.
• [ ] J’ai vérifié que la politique de conservation correspond aux exigences de restauration des utilisateurs ou des clients concernés.
• [ ] J’ai comparé l’occupation du datastore à celle du système de fichiers, du pool ou du stockage distant approprié.
• [ ] J’ai conservé les journaux, l’état initial et les changements prévus dans le suivi d’incident.
• [ ] Avant toute opération risquée, j’ai défini une fenêtre de maintenance, vérifié la sauvegarde des données concernées et documenté un chemin de récupération.
• [ ] Après intervention, j’ai contrôlé les résultats des tâches, l’espace du backend et la réussite des sauvegardes suivantes.

Si vous devez arbitrer entre nettoyage et extension, utilisez cette grille de lecture :

Ne vous appuyez pas sur un seuil universel ou sur le volume libéré dans un cas publié par un tiers : la consommation dépend des données, du niveau de déduplication, de la rétention, des tâches et du backend. Après toute correction, vérifiez séparément le résultat de prune, celui du GC, l’état du stockage sous-jacent et l’achèvement des sauvegardes prévues. Si un de ces contrôles échoue, ne considérez pas l’incident comme clos.

Pour réévaluer la capacité, partez de votre propre historique : espace effectivement utilisé, rythme constaté, durée de conservation et marge nécessaire pour les opérations et les nouvelles sauvegardes. Ajoutez à cette analyse le mode de redondance, les possibilités de récupération et une copie hors de la cible principale. Une extension du datastore n’est pas, à elle seule, une stratégie de sauvegarde indépendante.

Questions fréquentes sur un datastore PBS saturé

Pourquoi la suppression d’instantanés ne fait-elle pas immédiatement baisser l’occupation ?

La disparition d’instantanés et la récupération de blocs sont deux étapes différentes. Des blocs peuvent rester référencés par d’autres sauvegardes en raison de la déduplication, puis le GC doit traiter ceux qui ne sont plus utilisés. Comparez les résultats des tâches et l’état du backend ; ne transformez pas la taille apparente des sauvegardes supprimées en estimation de l’espace récupérable.

Quel est le rôle respectif de prune et du GC ?

Prune applique la règle qui détermine quels instantanés doivent être conservés. Le GC s’occupe des blocs devenus inutilisés dans le datastore. Une politique prune correcte ne garantit donc pas que l’occupation du volume baisse immédiatement, et un GC achevé ne corrige pas une politique qui conserve trop de points de restauration.

Comment choisir entre nettoyage et extension du datastore ?

Commencez par établir si prune a été exécuté et si le GC peut travailler. Si l’incident vient d’une tâche ou d’une configuration, corrigez-la après validation de la politique. Si le stockage est véritablement saturé ou si la capacité prévisionnelle ne suffit plus, examinez une extension selon le backend et la procédure de récupération. N’appuyez pas cette décision sur un exemple communautaire isolé.

Que faire si le disque saturé empêche le GC ?

Évitez toute suppression manuelle dans le datastore. Relevez les journaux et l’état du backend, puis vérifiez les consignes officielles adaptées à ce stockage. Si une intervention est indispensable pour rétablir une marge de fonctionnement, préparez une fenêtre de maintenance, confirmez la possibilité de récupération et documentez chaque changement. Recontrôlez ensuite les tâches et les sauvegardes suivantes.

Faites correspondre la capacité à votre cible de sauvegarde

Si le diagnostic confirme un manque durable, dimensionnez une cible indépendante à partir des besoins observés, et non d’une capacité théorique détachée de votre rétention. Vérifiez le nombre de disques, la capacité réellement utilisable, la redondance choisie, le débit réseau nécessaire et la présence d’une copie externe. Une machine dédiée peut convenir à une cible que vous administrez vous-même, mais elle ne constitue pas automatiquement un service de sauvegarde géré ni une copie hors site.

Pour comparer une configuration de serveur dédié, vérifiez les caractéristiques réellement proposées au moment de votre choix et leur compatibilité avec le backend envisagé. Les options de paiement et leur calcul sont présentés dans les modalités de paiement mensuel ; utilisez les informations courantes de ces pages plutôt qu’une estimation non vérifiée. Si vos besoins se limitent à une intervention ponctuelle ou à une charge légère et temporaire, une extension dédiée peut ne pas être proportionnée.

Lorsque le partage de ressources, la capacité de stockage ou la configuration du système de fichiers d’une solution mutualisée empêchent de maîtriser vos opérations, un serveur physique AMD dédié loué auprès d’OVN Cloud peut être plus adapté à une cible que vous administrez intégralement. Il vous revient toutefois de valider la configuration disponible, la redondance, le réseau et la copie hors machine avant d’y déplacer des sauvegardes ; comparez ces éléments au besoin calculé à partir de votre propre historique, plutôt que de traiter l’achat d’un serveur comme une réparation automatique de PBS.

Questions fréquentes

1. Pourquoi le disque reste-t-il plein après la suppression de sauvegardes dans PBS ? La suppression d’instantanés par prune ne signifie pas que toutes les données associées sont immédiatement récupérées. Des blocs peuvent encore être référencés par d’autres sauvegardes dédupliquées, et le garbage collection doit ensuite traiter les blocs qui ne sont plus référencés. Vérifiez donc les tâches, leur résultat et l’espace du système de fichiers avant de conclure à une anomalie.
2. Quelle différence faut-il retenir entre prune et garbage collection dans PBS ? Prune applique une politique de conservation aux instantanés : il retire de la vue les sauvegardes qui ne doivent plus être conservées selon cette politique. Le garbage collection, ou GC, travaille ensuite sur les blocs de données devenus inutilisés dans le datastore. Ces opérations sont liées, mais ne mesurent ni ne libèrent l’espace de la même façon.
3. Quand vaut-il mieux étendre un datastore PBS plutôt que le nettoyer ? Corrigez d’abord une tâche prune absente ou en échec si la politique de conservation est incorrecte, et vérifiez si le GC peut s’exécuter. Si le système de fichiers est réellement saturé, qu’aucune opération sûre ne peut progresser ou que la croissance attendue dépasse la capacité disponible, préparez une extension adaptée au backend et à votre procédure de récupération.
4. Comment réagir si le disque est plein et que le GC ne démarre plus ? N’effacez pas manuellement les fichiers du datastore, en particulier les répertoires de blocs. Conservez les journaux, identifiez le backend et consultez les instructions officielles correspondant à cette configuration. Si une intervention est nécessaire pour rendre de l’espace, définissez une fenêtre de maintenance et un chemin de restauration avant toute modification, puis vérifiez les tâches et les sauvegardes.