Borg Sauvegardes PROBLEMES

Voilà la cause. La sauvegarde locale a été annulée, et c’est elle qui donne le code 2 :

Warning: The repository at location /home/yann/FreeUSB2To/sauvegardes/borgbackup/pc1
was previously located at ssh://u694796@u694796.your-storagebox.de:23/./pc1
Do you want to continue? [yN] Aborting.

Le script sort avec max(rc_local, rc_distant). Le local a échoué avec 2 et le distant a réussi avec 0, donc le service est marqué en échec alors que la sauvegarde distante est bonne.

Pourquoi

Chaque dépôt Borg a un identifiant unique, et Borg mémorise dans ~/.config/borg/security/ le dernier emplacement où il l’a vu. Ici, le dossier local …/borgbackup/pc1 contient le même dépôt que celui de la box u694796, avec le même identifiant. C’est ce que fait ton script de synchronisation Storage Box → Freebox (rsync --delete vers /mnt/FreeUSB2To/sauvegardes/borgbackup), qui a recopié le dépôt pc1 de la box exactement là où ton script de sauvegarde locale écrit.

En mode non interactif (service systemd), Borg ne peut pas répondre y à la question et abandonne. Le problème est plus grave qu’un simple avertissement :

Le dépôt local pc1 n’est plus un dépôt indépendant : c’est un miroir de celui de la box.
Si tu forces l’accès, le prochain rsync --delete écrasera ce que borg create y aura écrit, et tu risques de corrompre le dépôt.
Il y a donc probablement eu un écrasement de ton ancien dépôt local pc1, qui contenait peut-être un historique différent. Vérifie ce que contient aujourd’hui le dossier avec borg list /home/yann/FreeUSB2To/sauvegardes/borgbackup/pc1.

Correction (à choisir)

Recommandé : exclure pc1 de la synchronisation. Les sauvegardes de pc1 sont déjà faites localement et à distance par le script. Ajoute --exclude 'pc1' au rsync (ou saute l’hôte pc1 dans ta boucle), et garde le miroir pour les autres hôtes.
Ou séparer les dossiers : par exemple le dépôt local de pc1 dans …/FreeUSB2To/sauvegardes/pc1-local, et le miroir des box dans …/borgbackup/.

Après avoir séparé les deux, il faudra réinitialiser l’état du dépôt local, car son dossier actuel est un miroir et non ton ancien dépôt. Soit tu crées un nouveau dépôt local (borg init), soit tu restaures l’ancien s’il existe encore ailleurs. Supprime ensuite l’entrée de sécurité pour que Borg ne se plaigne plus du changement d’emplacement :

        
borg config /home/yann/FreeUSB2To/sauvegardes/borgbackup/pc1 id   # pour noter l'ID
ls ~/.config/borg/security/

rm -r ~/.config/borg/security/<ID> (le dossier portant cet ID) est sans danger : Borg la recrée au prochain accès. Ne mets BORG_RELOCATED_REPO_ACCESS_IS_OK=yes qu’en dépannage ponctuel : tant que les deux dépôts partagent le même identifiant, l’avertissement reviendra à chaque alternance entre local et distant.

Dis-moi ce que donne borg list sur le dossier local, et je t’aide à choisir entre recréer le dépôt et restaurer l’ancien.

Arrêt Borg cwwk sharenhs BX11

Latitude e6230 , arrêt timer qui lance la sauvegarde borg

sudo systemctl stop run-script-with-delay.timer
sudo systemctl disable run-script-with-delay.timer

Serveur cwwk

        
      
sudo systemctl stop borgbackup-cwwk.timer
sudo systemctl disable borgbackup-cwwk.timer

sudo systemctl stop borgbackup-sharenfs.timer
sudo systemctl disable borgbackup-sharenfs.timer

sudo systemctl stop borg-compact.timer
sudo systemctl disable borg-compact.timer

Initialisation dépôt

export BORG_PASSPHRASE="`cat /home/yann/.borg/yann-crypto.passphrase`"
export BORG_RSH='ssh -i /home/yann/.ssh/bx11-yann-02'
BORG_REPOSITORY='ssh://u694796@u694796.your-storagebox.de:23/./yann-crypto'
borg init --encryption=repokey-blake2 $BORG_REPOSITORY

Proxmox cli sauvegardes

Sur le nœud Proxmox, identifiez d’abord le nom logique du stockage NFS :

pvesm status
pvesm list <NOM_STOCKAGE>

Pour ne garder que les 5 dernières sauvegardes de chaque VM/CT sur ce stockage :

pvesm prune-backups <NOM_STOCKAGE> --keep-last 5

Exemple si le stockage s’appelle pve-sav :

pvesm prune-backups pve-sav --keep-last 5

Cette commande applique la rétention aux groupes de sauvegardes de ce stockage. Pour combiner des règles, par exemple garder 7 quotidiennes, 4 hebdomadaires et 6 mensuelles :

        
      
pvesm prune-backups pve-sav --keep-daily 7 --keep-weekly 4 --keep-monthly 6

Pour supprimer une sauvegarde précise, repérez son volume avec pvesm list, puis utilisez son identifiant complet :

pvesm free <VOLUME_ID>

Par exemple, le volume peut ressembler à pve-sav:backup/vzdump-qemu-101-....vma.zst. Vérifiez soigneusement l’identifiant avant pvesm free : la suppression est définitive. Évitez rm directement dans le répertoire monté NFS. La rétention supprime les anciennes archives ; elle ne réduit pas la taille des archives déjà créées.

Oui. Utilisez pvesm list avec le nom du stockage NFS et le VMID :

pvesm list <NOM_STOCKAGE> --vmid <VMID>

Par exemple, pour la VM 101 sur le stockage pve-sav :

pvesm list pve-sav --vmid 101

Chaque ligne de type backup correspond à une sauvegarde. Pour afficher seulement le nombre :

        
      
pvesm list pve-sav --vmid 101 | awk '$3 == "backup" {n++} END {print n+0}'

Remplacez pve-sav et 101 par le nom de votre stockage et l’ID de la VM. Vous pouvez retrouver le nom du stockage avec pvesm status.

Problèmes sauvegardes Storage Box Hetzner

Classer par taille les dossiers linux

Pour classer les éléments directement présents dans un répertoire, du plus volumineux au plus petit :

        
      
du -ah --max-depth=1 /chemin/du/repertoire 2>/dev/null | sort -hr | head -20

-a inclut les fichiers et les dossiers.
--max-depth=1 limite l’affichage au contenu immédiat du répertoire.
head -20 affiche les 20 premiers résultats.

Pour trouver les 20 plus gros fichiers, y compris dans les sous-dossiers :

        
      
find /chemin/du/repertoire -type f -printf '%s\t%p\n' 2>/dev/null |
  sort -nr | head -20 |
  numfmt --field=1 --to=iec

Remplacez /chemin/du/repertoire par le chemin voulu. du mesure l’espace disque occupé ; find classe les fichiers selon leur taille exacte.

Identifier le problème

Sauvegardes Borgbackup sur Box Hetzner 1To
Message reçu 96% used
Connexion limité par SFTP port 23, pas d’accès ssh, impossible d’évaluer la taille par dossier (du inconnu)

[yann@pc1 ~]$ sftp -P 23 -i ~/.ssh/bx11-yann-ed25519 u326239@u326239.your-storagebox.de
Connected to u326239.your-storagebox.de.
sftp> df -h
    Size     Used    Avail   (root)    %Capacity
   917GB    885GB   31.8GB   31.8GB          96%
sftp> ls -la backup/
drwxr-xr-x    ? u326239  u326239         3 Oct 19 07:35 backup/.
drwxr-xr-x    ? u326239  u326239         5 Sep 26  2025 backup/..
drwxrwxr-x    ? u326239  u326239        10 Sep 26 10:17 backup/borg
sftp> ls -la backup/borg
drwxrwxr-x    ? u326239  u326239        10 Sep 26 10:17 backup/borg/.
drwxr-xr-x    ? u326239  u326239         3 Oct 19 07:35 backup/borg/..
drwx------    ? u326239  u326239         9 Oct 28 18:27 backup/borg/cwwk
drwx------    ? u326239  u326239         9 Oct 28 20:10 backup/borg/e6230
drwx------    ? u326239  u326239         9 Oct 28 18:27 backup/borg/ouestline.xyz
drwx------    ? u326239  u326239         9 Oct 28 19:14 backup/borg/sharenfs
drwx------    ? u326239  u326239         9 Oct 28 18:27 backup/borg/vps-56d1c3c5
drwx------    ? u326239  u326239         9 Oct 28 18:27 backup/borg/xoyaz.xyz
drwx------    ? u326239  u326239         9 Oct 28 18:27 backup/borg/yannig.net
drwx------    ? u326239  u326239         9 Oct 28 18:27 backup/borg/yannir.xyz
sftp> du -hs backup/borg/sharenfs/
Invalid command.

Le du n’existe pas dans le sous-système SFTP, mais Hetzner autorise un petit jeu de commandes (dont du, df, ls, rm) via SSH sur le port 23. Comme Borg fonctionne déjà chez toi via ssh://...:23, le SSH est forcément actif sur ta box : il suffit de passer la commande directement.

1. Taille par dépôt, depuis pc1

        
      
echo "Storage Box u326239.your-storagebox.de"
echo -e "df -h" |sftp -P 23 -i ~/.ssh/bx11-yann-ed25519 u326239@u326239.your-storagebox.de
echo "Taille des dossiers (Mo)"
export BORG_PASSPHRASE=`cat /sharenfs/pc1/.borg/sharenfs.passphrase`
ssh -p 23 -i ~/.ssh/bx11-yann-ed25519 u326239@u326239.your-storagebox.de \
  "du -sm backup/borg/*" | sort -n

echo "Storage Box u694796.your-storagebox.de"
echo -e "df -h" |sftp -P 23 -i /sharenfs/pc1/.borg/bx11-yann-02.borgssh u694796@u694796.your-storagebox.de
echo "Taille des dossiers (Mo)"
export BORG_PASSPHRASE="$(cat /sharenfs/pc1/.borg/cwwk-sharenfs.passphrase)"
ssh -p 23 -i  /sharenfs/pc1/.borg/bx11-yann-02.borgssh u694796@u694796.your-storagebox.de \
   "du -sm *" | sort -n

du -sm donne des Mo, ce qui est plus simple à trier. Si le glob n’est pas interprété, liste les dossiers explicitement :

        
ssh -p 23 -i ~/.ssh/bx11-yann-ed25519 u326239@u326239.your-storagebox.de \
  "du -sm backup/borg/cwwk backup/borg/e6230 backup/borg/ouestline.xyz backup/borg/sharenfs backup/borg/vps-56d1c3c5 backup/borg/xoyaz.xyz backup/borg/yannig.net backup/borg/yannir.xyz"

Pense aussi à du -sm . à la racine : si le total dépasse la somme des dépôts, l’écart vient d’ailleurs (autres dossiers, snapshots).

2. Détail côté Borg (taille dédupliquée réelle)

Depuis chaque machine, borg info donne la taille réelle du dépôt et ce que pèse chaque archive :

        
borg info ssh://u326239@u326239.your-storagebox.de:23/./backup/borg/sharenfs
borg list --format '{archive} {size}{NL}' ...   # taille logique, pas dédupliquée

Le champ à regarder est « All archives / Deduplicated size » dans la section Original / Compressed / Deduplicated.

3. Pour récupérer de la place

borg compact est indispensable après chaque prune : sans lui, l’espace des segments supprimés n’est pas libéré. Tu l’as déjà en job indépendant, vérifie qu’il a bien tourné sur les 8 dépôts.
Les gros candidats sont probablement sharenfs (volumineux par nature) et e6230 : c’est ce que le du te dira. Revoir leurs exclusions ou leur rétention est le levier le plus efficace.
Si tu as activé des snapshots dans l’interface Hetzner, ils comptent dans le quota. Vérifie-les, c’est une cause classique d’écart entre du et df.

Avec 31,8 Go libres, ne laisse pas passer la prochaine sauvegarde sans libérer de l’espace : Borg échoue mal quand le disque est plein.

[yann@pc1 ~]$ ssh -p 23 -i ~/.ssh/bx11-yann-ed25519 u326239@u326239.your-storagebox.de  
"du -sm backup/borg/*" | sort -n  
1295 backup/borg/xoyaz.xyz  
1333 backup/borg/ouestline.xyz  
1717 backup/borg/vps-56d1c3c5  
1727 backup/borg/yannig.net  
3960 backup/borg/yannir.xyz  
13880 backup/borg/e6230  
34212 backup/borg/cwwk  
847891 backup/borg/sharenfs

Je ne comprends pas `847891 backup/borg/sharenfs`  
Le dossier /sharenfs que j'ai sauvegardé et compacté ne fait qur 223Go

Ton problème est donc bien localisé : sharenfs occupe 848 Go sur les 885 Go utilisés. Un dépôt Borg qui pèse près de 4 fois la taille de la source n’est pas normal. Il y a deux explications possibles, et une commande suffit à les départager.

Diagnosticls

        
      
export BORG_PASSPHRASE=`cat /sharenfs/pc1/.borg/sharenfs.passphrase`
export BORG_RSH='ssh -i /root/.ssh/id_borg_ed25519'
export BORG_REPO='ssh://u326239@u326239.your-storagebox.de:23/./backup/borg/sharenfs'
borg info          # taille dédupliquée réelle, nombre d'archives
borg list --short  # combien d'archives existent vraiment

Compare la ligne « All archives → Deduplicated size » avec les 848 Go du du :

Dedup size ≈ 848 Go : le dépôt contient vraiment ces données. Le compact fonctionne, c’est le contenu qui est trop gros.
Dedup size ≪ 848 Go (par exemple ~250 Go) : de l’espace est occupé par des segments morts que le compact n’a pas libérés.

Cas 1 : le contenu est réellement gros

Causes fréquentes :

Trop d’archives conservées : le prune ne passe peut-être pas sur ce dépôt (ou sur ce dépôt-là avec d’autres paramètres que ceux du script de cwwk). borg list --short | wc -l doit donner ~14 avec 7d/1w/1m.
Mauvaise déduplication : fichiers volumineux modifiés à chaque passage (images de VM, bases de données, coffres Cryptomator, archives déjà compressées ou chiffrées). Chaque version est stockée presque entière. Pour trouver les coupables : borg diff ::archive_ancienne archive_recente ou borg info ::archive, qui affiche la taille dédupliquée propre à chaque archive.
Des archives d’une ancienne source (autre chemin, autre exclusion) qui ne correspondent plus au prune actuel (--glob-archives/-a ne les voit pas).

Cas 2 : espace mort non récupéré

borg compact -v --progress

Vérifie que ton job compact cible bien ce dépôt avec ce chemin exact. Vérifie aussi si une clé authorized_keys/option --append-only est activée côté box : en mode append-only, prune et compact ne libèrent rien tant qu’on ne les lance pas depuis une session non restreinte. Si un borg check --repair ou une sauvegarde interrompue a laissé des verrous ou des checkpoints, borg break-lock puis un nouveau compact peut aider.

Pour regarder dans le dépôt sans Borg

        
ssh -p 23 -i ~/.ssh/bx11-yann-ed25519 u326239@u326239.your-storagebox.de \
  "du -sm backup/borg/sharenfs/data/* | sort -n | tail"

Si le dossier data ne représente que quelques centaines de Go alors que le dépôt en pèse 848, regarde aussi les fichiers hors data/ (index, cache de checkpoint).

Poste-moi la sortie de borg info et de borg list --short | wc -l, et on saura laquelle des deux situations est la bonne.

## root@alder:/home/yick# export BORG_PASSPHRASE=`cat /sharenfs/pc1/.borg/sharenfs.passphrase`  
export BORG_RSH='ssh -i /root/.ssh/id_borg_ed25519'  
root@alder:/home/yick# export BORG_REPO='ssh://u326239@u326239.your-storagebox.de:23/./backup/borg/sharenfs'  
root@alder:/home/yick# borg info  
Repository ID: a1e7ad03eb0c8e50c888e73861d99dda5e6b40a580012686b1c2759efebc0e7e  
Location: ssh://u326239@u326239.your-storagebox.de:23/./backup/borg/sharenfs  
Encrypted: Yes (repokey)  
Cache: /root/.cache/borg/a1e7ad03eb0c8e50c888e73861d99dda5e6b40a580012686b1c2759efebc0e7e  
Security dir: /root/.config/borg/security/a1e7ad03eb0c8e50c888e73861d99dda5e6b40a580012686b1c2759efebc0e7e

               Original size      Compressed size    Deduplicated size   ```

All archives: 3.82 TB 3.75 TB 886.09 GB

                   Unique chunks         Total chunks  

Chunk index: 465737 3202716

CMD_PRUNE=”borg prune -v –stats –keep-daily=7 –keep-weekly=1 –keep-monthly=1 “${BORG_REPOSITORY}””
borg prune -v –stats –keep-daily=7 –keep-weekly=1 –keep-monthly=1 “$BORG_REPOSITORY”

Le résultat de `borg info` règle la question : **886 Go dédupliqués ≈ 848 Gio mesurés par `du`**. Ce n'est donc pas un problème de compact, qui fonctionne. Le dépôt contient réellement 886 Go de chunks uniques, alors que la source n'en fait que 223.

Autres indices dans ta sortie :

- **3,82 To d'archives originales ÷ 223 Go ≈ 17 archives** : cela correspond à ta rétention (7j + 1s + 1m), donc le prune semble bien passer.
- **Compressé ≈ original** (3,82 → 3,75 To) : tes données sont déjà incompressibles (médias, archives, coffres chiffrés, etc.).
- Il y a donc environ **660 Go de données « en plus » de la source**. Ce sont des fichiers qui changent beaucoup entre deux sauvegardes, et dont chaque version reste stockée tant qu'une archive la référence.

Le travail consiste maintenant à trouver quels fichiers changent.

**1. Voir ce qui est ajouté chaque jour**

```bash
borg list --format '{archive} {time}{NL}'
borg info ::NOM_DERNIERE_ARCHIVE     # ligne "This archive : Deduplicated size"

Ta notification ntfy ou les logs de borg create --stats contiennent aussi cette valeur. Si un jour normal ajoute 20 à 50 Go, le coupable est un gros fichier modifié en continu.

2. Trouver les fichiers qui changent

        
      
borg diff ::ARCHIVE_J-1 ARCHIVE_J | grep -E '[0-9.]+ [MG]B' | head -50

Cette commande liste les fichiers modifiés avec la taille ajoutée/retirée. Les suspects habituels dans un dossier partagé NFS sont les bases de données ou leurs dumps non compressés, les images de VM ou disques, les coffres Cryptomator, les caches ou miniatures, les dossiers de téléchargement ou de torrents, et les copies de sauvegardes d’autres outils. Si tu retrouves .borg, .cache ou une copie de dépôts Borg dans /sharenfs, c’est un cas classique : Borg ne déduplique pas des données déjà chiffrées par un autre outil.

3. Libérer de la place rapidement

Teste d’abord un prune plus court en simulation :

        
      
  borg prune -v --list --dry-run --keep-daily=3 --keep-weekly=1 --keep-monthly=1 "$BORG_REPO"

Supprime les plus anciennes archives si besoin (borg delete ::NOM), puis borg compact : sans lui, rien n’est libéré.
Exclus dans le script les chemins qui changent trop (--exclude), sauvegarde-les différemment (dump compressé avec --rsyncable, ou rétention spécifique), ou déplace-les dans un dépôt dédié avec une rétention plus courte.

Poste-moi la sortie du borg diff (les 20-30 plus grosses lignes) et on saura exactement où partent les 660 Go.

Le borg diff donne la réponse : ce sont les dumps vzdump de Proxmox qui remplissent le dépôt.

Ce qui est ajouté chaque jour

Fichier	Taille
`proxmox/sav/dump/vzdump-qemu-105-…vma.zst`	8,98 Go
`proxmox/sav/dump/vzdump-qemu-101-…vma.zst`	7,80 Go
`proxmox/sav/dump/vzdump-qemu-103-…vma.zst`	4,87 Go
`proxtin/sav/dump/vzdump-qemu-200-…vma.zst`	1,70 Go
`proxtin/sav/dump/vzdump-lxc-210-…tar.zst`	0,24 Go
Total	≈ 23,6 Go par jour

Chaque nuit, Proxmox écrit de nouveaux fichiers .zst avec un nom daté. Borg les voit comme des fichiers neufs, et comme ils sont déjà compressés par zstd, leur contenu change entièrement d’un jour à l’autre. Il n’y a donc aucune déduplication possible, et chaque jour ajoute ~23 Go au dépôt. Sur les ~37 jours couverts par tes archives (7 quotidiennes, 1 hebdomadaire, 1 mensuelle, plus les dumps que Proxmox garde), cela explique à peu près les 660 Go en trop. Le reste du diff (pages Jekyll, sqlite, logs, snapshots Immich) pèse quelques Mo et est négligeable.

Suppression des ISO

Les ISO de sharenfs/iso que tu as supprimées (≈ 20 Go) disparaîtront du dépôt une fois que les archives qui les contiennent auront été prunées, puis après borg compact.

Correction en 3 étapes

Exclure les dumps de la sauvegarde Borg (ils sont déjà des sauvegardes, Proxmox gère leur rétention) en ajoutant à ton fichier d’exclusions :
1 2 sharenfs/proxmox/sav/dump sharenfs/proxtin/sav/dump
Adapte le préfixe à ton fichier d’exclusions : le chemin absolu côté disque est /sharenfs/proxmox/sav/dump.
Retirer les dumps des archives existantes avec borg recreate. Fais d’abord un essai à blanc :
1 2 3 4 borg recreate -v --list --dry-run \ --exclude 'sharenfs/proxmox/sav/dump' \ --exclude 'sharenfs/proxtin/sav/dump' \ "$BORG_REPO"
Si la liste te convient, relance sans --dry-run. Aucune sauvegarde ne doit tourner en même temps (verrou du dépôt). Il vaut mieux tester d’abord sur une seule archive : "$BORG_REPO"::2026-10-27-02h50.
Libérer l’espace : borg compact -v --progress. Les quelque 650 Go se libéreront à ce moment-là. recreate ne demande presque pas d’espace temporaire puisque les chunks existent déjà, donc tes 31 Go libres suffisent.

Pour garder les VM sauvegardées hors site

Ajoute un dépôt Borg dédié, dont tu fais tourner les dumps non compressés (compress: 0 dans /etc/vzdump.conf), avec une rétention courte.
Ou, mieux, passe à Proxmox Backup Server, qui déduplique nativement les VM.

Veux-tu que je te prépare le script recreate complet (avec boucle de contrôle, ntfy et compact) ?

Pas nécessairement. Tu as deux voies, selon que tu veux garder l’historique.

Option A : borg recreate (recommandée)

Tu gardes toutes tes archives (donc ton historique de 7 jours, 1 semaine, 1 mois), mais sans les dumps vzdump. Rien n’est perdu, seulement les fichiers exclus. C’est la commande de l’étape 2, suivie de borg compact.

Option B : borg delete (plus simple, mais irréversible)

Si tu n’as pas besoin de l’historique, supprime les anciennes archives et garde les plus récentes. Dans ce cas, ajoute d’abord l’exclusion des dumps au script de sauvegarde. Sinon la prochaine sauvegarde réajoute 23 Go et tu retombes dans la même situation, avec 31 Go libres seulement.

        
      
# 1. Arrête le timer de sauvegarde (verrou du dépôt)
systemctl stop <ton-timer>.timer

# 2. Liste et choisis ce que tu supprimes
borg list --short "$BORG_REPO"

# 3. Simulation
borg delete --dry-run --list "$BORG_REPO"::2026-10-20-02h50

# 4. Suppression réelle, une ou plusieurs archives
borg delete --list "$BORG_REPO"::2026-10-20-02h50

# 5. Libère l'espace sur la box
borg compact -v --progress "$BORG_REPO"

À savoir :

Garde au moins l’archive la plus récente et, si possible, quelques-unes de plus : si le dépôt est vide, la prochaine sauvegarde repart de zéro (800 Go à retransférer).
borg delete seul ne libère pas l’espace : tant que compact n’a pas tourné, df sur la box ne bouge pas.
Une fois supprimé, une archive est perdue définitivement. Vérifie avec borg list avant de lancer.

Mon conseil : exclus les dumps dans le script, teste recreate --dry-run sur une archive, puis lance-le sur toutes. Tu gagnes ~650 Go sans rien perdre d’utile. N’utilise delete qu’en secours si tu manques de temps.

Les 885 Go sont bien libérés, mais un détail ne colle pas : la taille totale est passée de 917 Go à 79,1 Go. Je ne vois pas ce qui l’explique, et c’est à vérifier avant de te rassurer.

Ce qui est normal : 43,2 Go utilisés après suppression d’une grosse partie de sharenfs, c’est cohérent.

Ce qui ne l’est pas :

Un quota qui change tout seul n’a pas de raison évidente. Il peut s’agir d’un affichage particulier de df côté Hetzner, d’un changement de forfait, ou d’un problème sur ta box.
43,2 Go au total est inférieur à ce que tes autres dépôts occupaient (cwwk 34 Go + e6230 14 Go + les petits ≈ 58 Go). Soit tu as supprimé des archives ailleurs aussi, soit certains dépôts ont été touchés.

Vérifications à faire

        
      
export BORG_PASSPHRASE=`cat /sharenfs/pc1/.borg/sharenfs.passphrase`
export BORG_RSH='ssh -i /root/.ssh/id_borg_ed25519'
export BORG_REPO='ssh://u326239@u326239.your-storagebox.de:23/./backup/borg/sharenfs'
borg info          # taille dédupliquée réelle, nombre d'archives
borg list --short  # combien d'archives existent vraiment

        
      
export BORG_PASSPHRASE=`cat /sharenfs/pc1/.borg/sharenfs.passphrase`
export BORG_RSH='ssh -i /root/.ssh/id_borg_ed25519'
export BORG_REPO='ssh://u326239@u326239.your-storagebox.de:23/./backup/borg/sharenfs'
# 1. Taille réelle de chaque dépôt
ssh -p 23 -i ~/.ssh/bx11-yann-ed25519 u326239@u326239.your-storagebox.de \
  "du -sm backup/borg/* | sort -n"

# 2. Le dépôt sharenfs est-il intact et que reste-t-il ?
borg list --short "$BORG_REPO"
borg info "$BORG_REPO"
borg check --repository-only "$BORG_REPO"   # rapide, ne lit pas les données

Ensuite :

Regarde dans l’interface Hetzner (Robot ou Console) le forfait et le quota de la Storage Box (BX11 = 1 To), ainsi que les éventuels messages ou tickets.
Compare avec df -h dans quelques heures : si le chiffre revient à ~917 Go, c’était un affichage temporaire.
Si le quota est réellement tombé à ~79 Go, contacte le support Hetzner avant la prochaine sauvegarde, sinon elle échouera dès que la limite sera atteinte.

À faire de toute façon

Ajoute l’exclusion des dumps vzdump dans ton script, sinon tu rajoutes ~23 Go par jour.
Lance borg compact si ce n’est pas fait, puis une sauvegarde complète pour confirmer que tout fonctionne.

Poste-moi le du par dépôt et le résultat de borg list / borg info, on y verra plus clair.

Voilà le message, rédigé en anglais, ce qui facilite le traitement côté Hetzner. Les deux df avant et après y figurent, avec la demande de vérifier le quota ou le forfait.

Avant de l’envoyer, deux choses à vérifier :

Le forfait dans Robot/Console : si le forfait affiché est toujours BX11, tu peux le mentionner. S’il est différent, ajuste la phrase « I did not change it ».
Les snapshots : le message propose d’en fournir la liste, mais regarde aussi dans Robot s’il y en a. Si des snapshots existent, ils peuvent expliquer des écarts de taille et mieux vaut le savoir avant la réponse du support.

Si tu préfères l’envoyer en français ou en allemand, dis-le-moi et je l’adapte.

C’est un bon choix : tant que le quota de la box est incertain, tu as ta copie locale, et les autres dépôts continuent normalement vers la bx11.

Quelques points pour que la suspension soit propre :

Désactive le timer proprement (systemctl disable --now <timer-sharenfs>.timer), sans quoi il tentera de recréer le dépôt ou échouera chaque nuit avec une notification ntfy.
Vérifie que ta sauvegarde locale est saine : un borg list et un borg check --repository-only sur ce dépôt, et un test d’extraction d’un fichier. C’est maintenant ta seule copie de l’historique de sharenfs, et tu dois savoir qu’elle est restaurable.
Vérifie que les dumps vzdump y sont bien exclus, ou qu’ils ont une rétention adaptée, pour ne pas voir le dépôt local gonfler de la même façon.
Note ce qui manque : pour les tests de restauration de ta méthode, cette copie locale ne te protège pas contre un sinistre sur place (vol, incendie, panne électrique). Quand le quota de la box sera clarifié, tu pourras ré-initialiser le dépôt sharenfs avec les exclusions et refaire une sauvegarde distante, au moins des dossiers essentiels.

Pense à relancer le point avec Hetzner si le quota reste à 80 Go dans quelques jours.