# É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

1. [Accès SSH au xpenology](#1-accès-ssh-au-xpenology)
2. [Disque USB 3 — BACKUP HORS SERVICE](#2-disque-usb-3--backup-hors-service)
3. [Incident Nextcloud — mise à jour non supervisée par Watchtower](#3-incident-nextcloud--mise-à-jour-non-supervisée-par-watchtower)
4. [État du backup — HyperBackup en échec](#4-é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)** :

1. **🔴 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.
2. **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).
3. **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.
4. À 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.**