Le lancement d'une sauvegarde incrémentielle manuellement sur nagios-hetzner et nagios a fonctionné. Il s'agit peut etre d'un effet de bord du probleme lié a la corruption due a mail.april.org qui a été corrigé aujourd'hui.

Pas de backup incrémental
Sur beaucoup de machines sauvegardées, il n'existe quasiment aucun backup incrémental, la totalité des sauvegardes sont des sauvegardes intégrales. Exemple controller.vm.april-int.
Je soupçonne un conflit de configuration avec les périodes d'interdiction (lun-ven, 7h-19h), les heures de polling (2h-7h) et les durées de rétention (6.97 pour les full, 0.97 pour les incr)
En 5h, aucune machine n'a le temps de se backuper et encore moins l'intégralité des machines. Passé 7h, plus aucun backup n'est lancé, jusqu'à 2h le lendemain.
Du coup, le reliquat ne sera fait que le jour suivant.
Un tour complet des machines n'arrive que tous les X jours (X>7 à ce que j'ai vu), délai qui dépasse la rétention incrémentale et donc déclenche une sauvegarde intégrale à chaque fois.
Ça explique aussi l'aléatoire observé dans les sauvegardes, avec des backups qui sont faites au petit bonheur la chance et en tout cas pas quotidiennement.
Il reste à confirmer tout ça, c'est pas vraiment clair et difficilement traçable.
Prévoir une nuit de veille pour voir de visu ce qui se passe.
Quelque chose qui me confirme quand même ce diagnostique est que seule 4 machines ont des incrémentales, ce qui correspond exactement au nombre de backups exécutables en parallèle.
Chaque jour, seules 4 machines seraient backupées avant 7h du matin, et donc toujours les mêmes (avec incrémentaux), au détriment des autres machines qui se contentent des miettes.
h1. Durée de backup
Il y a des problèmes de durée de backup. On dépasse la 10aine d'heure, voire 24h pour des machines de moins de 10Go (hertzner).
Les IO ne semblent pas en cause (<30%), ni la charge de la machine (<1), ni le réseau (<100kbs), en tout cas chez hertzner.
Il est difficile de debugger le problème, backuppc lançant les rsync en mode serveur et communiquant ensuite par la socket ouverte.
On ne peut donc pas simuler ce que backuppc fait ni ce qui se passe.
h1. Plantage de backup
Des backups échouent avec comme erreur

fileListReceive() failed
Done: 0 files, 0 bytes
Got fatal error during xfer (fileListReceive failed)

Idem, difficile à débugger car on ne connait pas les commandes envoyées à « rsync --server » par la socket.
Le cas le plus bizarre est le backup de la machine hertzner, où l'erreur n'est apparu qu'au bout de 24h aujourd'hui…
Il reste aussi le cas de spip.libre-en-fete.org, qui ne semble même pas avoir d'accès ssh ouvert, mais que backuppc tente quand même de sauvegarder.
h1. Surcharge des machines.
Les machines en charge des backups écroulent l'infrastructure régulièrement.
On a un double problème, interne à chaque machine de backup et entre les machines de backup.
En interne, backuppc possède une limite qui interdit plus de X backup à la fois (4 dans notre cas).
Mais il peut lancer 4 backups simultanés vers 4 machines virtuelles hébergées par le même host, ce qui va écrouler les têtes de lecture des disques du host ainsi que la bande passante.
En externe, on backup depuis plusieurs sources et personne ne se synchronise pour interdire de déclencher des backups sur une machine déjà en cours de travail.
L'exemple le plus frappant est pavot, qui peut se retrouver avec 5 ou 6 processus de copies en parallèle (4 en tant que machine de backup + 1 ou 2 en tant que machine en cours de sauvegarde par hertzner ou ovh).
Tous ces accès simultanés explosent le load des machines (>70 pendant 4h sur pavot), les io (100+%) et le réseau.
Les têtes de disque doivent aussi être fortement sollicitées par 5 processus concurrents d'accès aux données.
Ce problème peut expliquer en partie les durées de sauvegarde.

il n'y a plus de problèmes, tous les hosts sont sauvegardés