Document généré automatiquement depuis /home/jerome/pub/docs/01-audit-k3-avant-effacement.md sur kimsufi3, le 11 September 2026 à 14:03. Toute modification faite ici sera écrasée à la prochaine régénération : éditer le fichier source.
Contrôle préalable à la réinstallation. Question posée : k3 contient-il des données qui n’existent nulle part ailleurs ?
Réponse : non. L’effacement peut être fait sans perte.
Ce qui occupe les 1015 Go
| Emplacement | Taille |
|---|---|
/var/lib/docker/volumes |
1004 Go |
/var/lib/docker/overlay2 (images) |
2,7 Go |
/var/www |
4,9 Go |
/var/log |
2,4 Go |
Les images ne pèsent que 2,7 Go : ce sont bien les volumes qui remplissent le disque, pas les images.
Le mécanisme du remplissage, mesuré
rsync sans --delete, toutes les 10 minutes, sur des volumes vivants. Rien n’est jamais supprimé côté k3, donc tout s’accumule indéfiniment.
| Volume | k4 (réel) | k3 (accumulé) | Déchet |
|---|---|---|---|
ttrss-docker_db |
84 Mo | 223 Go | ~223 Go |
nextcloud_NCData |
724,7 Go | 744 Go | ~19 Go |
llama_ollama_data |
9,6 Go | 15 Go | ~5,4 Go |
mailcowdockerized_rspamd-vol-1 |
192 Mo | 2,8 Go | ~2,6 Go |
mailcowdockerized_vmail-vol-1 |
8,0 Go | 9,5 Go | ~1,5 Go |
mailcowdockerized_clamd-db-vol-1 |
338 Mo | 1,6 Go | ~1,3 Go |
mailcowdockerized_solr-vol-1 |
(supprimé) | 918 Mo | 918 Mo |
Le cas ttrss-docker_db est exemplaire : 223 Go de déchets pour une base de 84 Mo. PostgreSQL réécrit ses fichiers en permanence ; chaque segment WAL et chaque relation supprimée reste sur k3 à jamais. C’est aussi la preuve que ces copies de bases, prises à chaud, sont inexploitables.
Total : ~254 Go de déchets purs sur les 1004 Go.
Volumes présents sur k3 et absents de k4
| Volume | Verdict |
|---|---|
subversion_svn-server-repository |
sans valeur unique. Les 14 dépôts sont archivés sur k4 dans ~/claude/backups/subversion-2026-09-04/, avec dumps rechargés et révisions comparées — 14 sur 14 vérifiés — et tous ont leur équivalent dans Gitea. |
mailcowdockerized_solr-vol-1 |
résidu de Solr, désactivé sur k4. |
ttrss-dockerbak_{app,backups,db} |
résidus de la migration tt-rss vers PostgreSQL 17 du 09/09. |
Le courrier — le point qui comptait vraiment
La structure vmail est identique des deux côtés :
| Domaine | k4 | k3 |
|---|---|---|
bunzenthal.lu |
2 | 2 |
chabod.eu |
5 | 5 |
chabod.lu |
4 | 4 |
kopains.fr |
1 | 1 |
sieve |
9 | 9 |
mailcow.local |
0 | 1 |
La seule différence, mailcow.local, est un répertoire vide de 12 Ko contenant 0 message — résidu d’une boîte technique supprimée sur k4 le 28/08.
Fraîcheur de la réplication : fichier le plus récent à 2026-09-09 14:55:55 sur k3 et 2026-09-09 16:55:55 sur k4 — le même instant, à l’écart de fuseau près (k3 en UTC, k4 en CEST). La réplication du courrier est à jour à la minute, et aucun message n’existe uniquement sur k3.
Cet écart de 2 h entre les deux machines est exactement le piège de corrélation de logs signalé dans
HERITAGE.md. Il disparaît à la réinstallation :Europe/Luxembourgdes deux côtés.
Conséquence pour le dimensionnement
Après réinstallation avec /var porté à ~1,67 To, les 725 Go réels de NCData laissent environ 900 Go de marge. La question « Nextcloud tient-il sur k3 ? » est tranchée : oui, largement.
Verdict
Feu vert pour l’effacement. La sauvegarde de ce qui était propre à k3 (sonde, crontab) est dans ~/claude/dockersync/sauvegarde-k3-avant-reinstall/.
Leave a Reply