Un reload du proxy PBS tue le ramasse-miettes chaque nuit

Le ramasse-miettes du gros dépôt d'un Proxmox Backup Server de client n'aboutissait plus. Les petits dépôts passaient, les blocs à supprimer s'accumulaient et le disque se remplissait. Le journal de chaque tâche donnait le même message : marking used chunks failed: Server shutdown requested - aborting task.

Le message dit que le serveur a demandé l'arrêt, pas qui l'a demandé. Le coupable était un reload. systemctl reload proxmox-backup-proxy relance le proxy, et le proxy emporte avec lui les tâches longues qu'il porte, le GC d'un dépôt compris. Le GC part à minuit, et le timer de logrotate tourne entre 00 h 00 et 01 h 00. Une règle logrotate dont le postrotate recharge le proxy tue donc chaque nuit tout GC plus long que le délai avant la rotation.

La règle, c'était nous. Notre rôle d'automatisation posait /etc/logrotate.d/proxmox-backup avec un postrotate qui lançait systemctl reload proxmox-backup-proxy.service après chaque rotation. PBS n'y était pour rien.

La preuve tient dans trois horodatages. logrotate.service part à 00:02:52, le proxy redémarre à 00:03:07, date de départ de son PID, et le GC du dépôt se termine à 00:03:07 en échec. Depuis juillet, 40 GC ont été coupés de cette façon, chaque nuit à partir du moment où le GC avait dépassé la fenêtre de logrotate.

Plus aucune règle logrotate ne doit recharger le proxy. Sur chaque serveur, grep -r proxmox-backup-proxy /etc/logrotate.d/ doit rendre vide.

Le serveur touché est corrigé. Son premier GC après correction a rattrapé tout le retard d'un coup : 17 Tio supprimés en près de sept heures. La vérification du dépôt était repartie à la même seconde, le serveur n'a plus répondu à temps aux hyperviseurs, et aucune sauvegarde vzdump n'est arrivée pendant une heure et demie. pvestatd a d'abord vu error fetching datastores - 500 read timeout, puis Can't connect.

Le retrait sur le reste du parc reste à faire. PBS tourne déjà son api/access.log lui-même, sans relancer le proxy : un access.log.1 antérieur à notre rôle le montre. Le mécanisme exact, je ne l'ai pas encore lu dans la doc.

Pour l'état du dernier GC, lance proxmox-backup-manager garbage-collection status <dépôt> et lis les champs last-run-state et pending-bytes. Pour l'historique, les journaux sont sous /var/log/proxmox-backup/tasks/archive, avec archive.1 et les archive.N.zst, à lire avec zstdcat. Ne compte pas sur proxmox-backup-manager task list pour tout voir : --limit plafonne à 1000.

Ne laisse pas repartir un GC en retard de plusieurs semaines sans prévenir ceux qui comptent sur ce dépôt. Et ne le lance pas à la même minute que la vérification du dépôt et qu'une passe de sauvegarde.

retour aux notes