Files

T

Effi c246427cf5 Phase 4 : kit G9 (scripts + compose) + Gitea T4.4 backend Postgres

- compose/gitea : SQLite -> Postgres (source = paquet App Center DSM, gitea_db 13 repos/3 users), image épinglée 1.27.3, push-to-create
- scripts/07a-migrate-gitea.sh : export pg_dump (MVCC, .25 lecture seule) + tar/ssh (sshd DSM refuse rsync/scp) + manifestes sha256
- scripts/03b-secrets.sh : secrets gitea ajoutés
- journal.md : entrées Phase 4

2026-10-11 07:45:00 +02:00

8.8 KiB

Raw Permalink Blame History

État de l'art — Infrastructure Folzo Home (suivi 06/10/2026)

Dernière mise à jour : 06/10/2026 Réseau : 192.168.1.0/24 Base : ETAT-DE-LART-2026-09-30.md (scan live 30/09/2026 — specs hardware, disques, conteneurs, réseau).

Modèle de document : snapshot daté — référence matérielle à la date indiquée (06/10/2026). Il complète le snapshot 30/09 avec les faits mesurés entre le 30/09 et le 06/10 (diagnostic USB, incident Nextcloud, état HyperBackup, accès SSH). Chaque évolution majeure produit un nouveau fichier daté ; le plus récent est la référence courante. Pour les décisions, corrections et le plan de (re)création, voir DOSSIER-RECREATION.md (v2) et DOSSIER-SOFTWARE.md (Partie 5).

Sommaire

Accès SSH au xpenology
Disque USB 3 — BACKUP HORS SERVICE
Incident Nextcloud — mise à jour non supervisée par Watchtower
État du backup — HyperBackup en échec

1. Accès SSH au xpenology

Documenté : 06/10/2026 (scan live)

Champ	Valeur
Connexion	`ssh -p 222 Effi@192.168.1.25` (mot de passe)
Utilisateur	`Effi` (uid 1043) — groupe `administrators` → `sudo` disponible (mot de passe)
Docker	Pas dans le PATH : binaire à `/var/packages/ContainerManager/target/usr/bin/docker` (symlink ContainerManager). À invoquer via `sudo` (socket `/var/run/docker.sock` = root).
Gestion des conteneurs	Majorité gérée via la GUI (ContainerManager) — seulement 12 fichiers `compose` dans `/volume1/docker/` (Freshrss, immish-app, Docmost, openwebui, watchtower, mini-qr, postgres16, Gitea, beszel, beszel-agent, Leantime). Les conteneurs stateful (Nextcloud, MariaDB, Redis, Vaultwarden, n8n, InfluxDB, OnlyOffice, Affine, Joplin…) sont créés via GUI (pas de `compose` versionné).

Conséquence ops : l'absence de compose versionné sur la majorité des briques stateful est exactement ce qui a permis l'incident Nextcloud (§3) — pas de déclaration, pas de pinning, pas de migration supervisée. → Action : re-déclarer les briques stateful en docker-compose.yml (pinning + labels Watchtower + backup) dans le cadre de la migration (voir DOSSIER-SOFTWARE.md S11.4/S11.5 + DOSSIER-RECREATION.md R5).

2. Disque USB 3 — BACKUP HORS SERVICE

Diagnostiqué : 01/10/2026 (scan live effi-server)

Le 3e disque USB est branché mais non reconnu par le xpenology. Or c'est lui qui assure le backup du Synology. Le backup est donc inopérant actuellement.

Identification :

Champ	Valeur
Périphérique	`/dev/sda` (partition `sda2`)
Marque / modèle	Seagate Expansion Portable (réf. USB `0bc2:231a`)
Serial	NAAXB11T
Taille	3.6 To
Système de fichiers	NTFS (version 3.1), label "Folzo Save"
Occupation	3.2 To utilisés / 519 Go libres (87%)
Contenu	Sauvegarde Hyper Backup (`Save FolzoCorp..hbk`, 2.0 To) + `save NAS/` (copies USB quotidiennes) + snapshots DSM (`.dss`)

Diagnostic technique :

Système de fichiers NTFS : COHÉRENT (ntfsfix -n OK — MFT, MFTMirr, boot sector validés).
SMART : inaccessible via le pont USB Seagate (limitation connue de ces disques — pas de conclusion S.M.A.R.T. possible).
2 zones de secteurs défectueux (erreurs I/O physiques) détectées sur 1 058 485 entrées scannées :
1. Save FolzoCorp..hbk/Config/@Share/docker-REC/ → 12.db-shm + 12.db-wal (fichiers SQLite temporaires — impact faible).
2. save NAS/USB Copy_2026-08-18_040106/2008/Anni stephe blonde/ → répertoire illisible (photos famille 2008 — impact élevé).
Conclusion : la corruption est physique (bad blocks), pas une fragmentation logicielle. Le non-détection par Synology est très probablement causé par ces secteurs HS (DSM refuse de monter un volume avec secteurs illisibles) + le format NTFS (lecture seule sans paquet ntfs-3g).

Actions recommandées (ordre strict) :

🔴 SAUVEGARDER IMMÉDIATEMENT les données saines (3.2 To) vers un autre support (218play / G9) — le disque se dégrade, chaque jour augmente le risque de perte totale.
Ne PAS défragmenter : la défrag ne traite pas la cause (bad blocks) et est risquée sur un disque défaillant (réécrit des données sur des secteurs potentiellement HS).
Rebrancher sur le xpenology + installer ntfs-3g (écriture) — mais sans l'étape 1, le backup restera inopérant tant que les secteurs HS bloquent le montage.
À terme : remplacer le disque (Seagate Expansion = disque portable, pas conçu pour du 24/7 de backup).

3. Incident Nextcloud — mise à jour non supervisée par Watchtower

Date : 06/10/2026 (détecté et corrigé)

Symptôme : Nextcloud inaccessible — 503, mode maintenance actif, needsDbUpgrade: true (migration de schéma incomplète).

Cause racine : Watchtower (config non sélective — CLEANUP=true, 0 exclusion, 0 notification, image :latest ; détail DOSSIER-SOFTWARE.md S11.4) a mis à jour l'application nextcloud_app (image nextcloud:latest, non pinnée) le 25/09/2026, puis la base nextcloud_db (MariaDB) le 03/10/2026, sans laisser la migration de schéma se terminer. Le swap d'image a relancé l'app sur un schéma non migré → needsDbUpgrade: true → maintenance mode.

Actions correctives (06/10/2026) :

#	Action	Détail
1	Dump SQL de la base MariaDB	~31 Mo (snapshot de schéma + données).
2	Suppression de l'index résiduel `tta_throom_attendee`	Index orphelin laissé par la migration incomplète (bloquait la re-migration).
3	`occ upgrade`	Migration de schéma relancée manuellement → OK.
4	Maintenance mode OFF	`occ maintenance:mode --off` → service restauré.

Version finale : Nextcloud 35.0.1.1 (confirmé via occ --version le 06/10/2026).

Leçon : une MAJ stateful non supervisée (app + DB mises à jour la nuit, sans migration, sans backup récent) = service HS. C'est la preuve concrète du risque « Watchtower non sélectif ». → Règle corrective : Watchtower sélectif (stateless auto / stateful exclu) + procédure de MAJ manuelle stateful + backup en place — voir DOSSIER-SOFTWARE.md S11.4 / S11.5 et DOSSIER-RECREATION.md R7.

4. État du backup — HyperBackup en échec

Confirmé : 06/10/2026 (scan live)

Le backup de données du xpenology est inopérant. Confirmation live de l'état §2 :

Tâche HyperBackup	Contenu	Dernier état	Date
task_8 (backup données — `.hbk` ~2 To)	Volumes + apps (le vrai backup)	`failed_checking` — `error: status_dest_file_not_exist` (code 2008) → destination absente (USB3 3,6 To débranché)	échec depuis 01/10/2024 (tâche créée 29/09/2024)
task_9 (backup apps/config DSM — ~1 Go)	Configs DSM + quelques apps	`done` (succès)	06/10/2026 (quotidien)

Faits mesurés (06/10/2026) :

Aucun /dev/sd* : le disque USB3 (3,6 To, NTFS) est débranché / absent → c'est la destination du backup données (task_8) → aucun backup de données depuis 01/10/2024.
synobackup.log : 108 erreurs pour la tâche « Synology NVR 1 » (task_8), dernière entrée 03/11/2024 (Failed to access the backup destination / Failed to run backup task). Première erreur : 01/10/2024 03:00:05 — la destination /volume1/Save/Save_Folzo-NAS2.hbk/Guard/config.json n'existe plus.
Le fichier last_result/backup.last de task_8 porte un end_time de 25/04/2026 (stale) — ce n'est pas la date de début de l'échec, mais le dernier timestamp écrit avant que la tâche ne cesse d'être planifiée.
Pas de restic / borg installés sur le NAS (le 3-2-1 cible, DOSSIER-SOFTWARE.md S10, n'existe pas encore).
USB1 (15 To) + USB2 (5,5 To) montés (média, 92%), pas des destinations de backup.
Seul le backup apps/config (task_9, ~1 Go) réussit quotidiennement — insuffisant (ne couvre ni les données ni les bases).

Risque #1 renforcé : AUCUN backup de données fonctionnel sur le xpenology depuis 01/10/2024. C'est le prérequis absolu de toute migration (voir DOSSIER-RECREATION.md R7 risque #1 + DOSSIER-SOFTWARE.md S13 A.0). Aucune migration ni MAJ stateful sans un backup 3-2-1 fonctionnel + restauration testée.

8.8 KiB Raw Permalink Blame History