| n | **Status:** teils produktiv, teils offen (bekannte laufende Probleme). | n | **Status:** Konzept sauber dokumentiert, Umsetzung teils produktiv — aber laufender, mehrw |
| | | öchiger technischer Defekt weiterhin ungelöst (Stand 09.08.2026, jüngste Alert-Mail). |
| | | |
| n | ZFS-Snapshot-Policy: `apps` stündlich/24h, `bulk/docs` täglich/30 Tage, `bulk/media` wöche | n | ## Konzept (aus TrueNAS-Dataset-Plan, 15.05.2026) |
| ntlich/8 Wochen, `bulk/homes` täglich/14 Tage — ersetzt die alte Synology-„Hyper Backup"-L | | |
| ösung (907 GB, bewusst nicht migriert). Off-Site-Konzept: Stufenplan USB-HDD-Rotation (emp | | |
| fohlener Start) → optional Cloud (Restic/B2/Wasabi/Hetzner Storage Box) → optional Replika | | |
| tion auf zweiten ZFS-Host. | | |
| | | - ZFS-Snapshot-Policy: `apps` stündlich/24h, `bulk/docs` täglich 02:00/30 Tage, `bulk/medi |
| | | a` wöchentlich So/8 Wochen, `bulk/homes` täglich 02:30/14 Tage, `bulk/timemachine` bewusst |
| | | OHNE Snapshot (TM versioniert selbst), `apps/docker/system` wöchentlich/4 Wochen nicht-re |
| | | kursiv. |
| | | - Ersetzt die alte Synology-„Hyper Backup"-Lösung (907 GB) bewusst — die wurde NICHT migri |
| | | ert. |
| | | - Off-Site-Stufenplan: Option 1 (empfohlener Start) externe USB-HDD mit eigenem ZFS-Pool ` |
| | | usb-backup`, wöchentliche/tägliche Replication-Tasks, Platte rotiert. Option 2 Cloud (Rest |
| | | ic/B2/Wasabi/Hetzner Storage Box) für kritische Datasets. Option 3 zweiter ZFS-Host — als |
| | | Overkill eingestuft. |
| | | - Postgres-Major-Upgrade-Disziplin: strikt `pg_dump`/`pg_restore`, niemals Datadir kopiere |
| | | n — in mehreren Dokumenten wiederholt als Kernregel verankert und in der DB-Wartung 07.06. |
| | | 2026 auch so durchgeführt. |
| | | |
| n | **Laufende reale Probleme (ungelöst):** Rsync-„PUSH"-Tasks für `/mnt/apps` und `/mnt/bulk` | n | ## Laufender realer Defekt — bislang deutlich unterschätzt (NEU im Detail) |
| schlagen seit mind. 04.06.2026 bis mind. 02.08.2026 wiederholt fehl (mehrere Alert-Mails) | | |
| ; außerdem Pool-Space-Warnungen für Pool „backup" (93 %, dann 96 % voll, beide am 02.08.20 | | |
| 26 wieder abgeklungen). | | |
| | | Es existiert tatsächlich bereits ein **dritter ZFS-Pool namens `backup`** (Replikationszie |
| | | l, vermutlich das im Konzept vorgesehene Off-Site/Replication-Target) — das war in den bis |
| | | herigen Konzeptdokumenten nicht namentlich erwähnt, taucht aber ab Anfang August 2026 in d |
| | | en TrueNAS-Alert-Mails auf. |
| | | |
| t | Postgres-Major-Upgrade-Disziplin: feste Regel „immer pg_dump/pg_restore, nie Datadir kopie | t | - **Rsync-„PUSH"-Tasks für `/mnt/apps` und `/mnt/bulk` schlagen durchgehend fehl**, erstma |
| ren" durchgängig verankert. | | ls dokumentiert 04.06.2026 (`/mnt/apps`), erweitert 15.07.2026 um `/mnt/bulk` — und laufen |
| | | laut jüngster Alert-Mail vom **09.08.2026 immer noch als „Current alerts"**, also seit üb |
| | | er zwei Monaten ununterbrochen fehlgeschlagen. |
| | | - **Pool `backup` wiederholt fast voll:** Alert-Serie am 02.08.2026 zeigt Auslastung 90% → |
| | | 95% → 96%, dann kurz „cleared" auf 93%, dann wieder 96% — ein Sägezahn-Muster, das auf ei |
| | | nen zyklischen Replikations-/Löschprozess hindeutet, der den Pool nicht stabil unter Kontr |
| | | olle hält. Wiederholt sich am 08.–09.08.2026 identisch (91% → 93% → 96%). |
| | | - **ZFS-Replication-Task „apps,bulk/paperless → backup" schlägt mehrfach fehl** mit konkre |
| | | ten Fehlermeldungen: |
| | | - „No incremental base on dataset 'bulk/paperless' and replication from scratch is not a |
| | | llowed" (09.08.2026 07:26). |
| | | - „cannot receive resume stream: out of space Broken pipe" für mehrere Datasets: `apps/n |
| | | extcloud-geb/data@auto-2026-07-29_10-48` (02.08.2026 05:49 und erneut 02.08.2026 04:57) un |
| | | d `apps/kasm@auto-2026-07-30_00-00` bzw. `@auto-2026-08-02_00-00` (02.08.2026 10:17, erneu |
| | | t 08.08.2026 22:52). |
| | | - Kernursache klar erkennbar: der `backup`-Pool läuft chronisch voll, wodurch Replikatio |
| | | nen mit Resume-Token abbrechen und der abgebrochene State ein sauberes Neu-Anlaufen verhin |
| | | dert (kein Platz für vollständigen Neu-Sync „from scratch"). |
| | | - **Parallel/historisch (vor der TrueNAS-Migration):** Die alte Synology „Hyper Backup"-Au |
| | | fgabe „Synology Remote Daily" (Ziel: `backup-familie-bayram.synology.me` / `Remote_Backup` |
| | | / `DiskStation.hbk`) schlug ebenfalls wiederholt fehl — dokumentiert für 20.–31.05.2026 s |
| | | owie 01.–04.06.2026 (mehrere Läufe mit 1–14 Stunden Laufzeit, alle „fehlgeschlagen"). Dies |
| | | e Aufgabe betrifft die inzwischen abgelöste Synology und dürfte mit dem Wegfall von Hyper |
| | | Backup (siehe TrueNAS/Docker-Eintrag) hinfällig sein, war aber zum damaligen Zeitpunkt ein |
| | | weiteres Backup-Problem. |
| | | |
| | | ## Bewertung / Handlungsbedarf |
| | | Das ist kein Rand-Problem mehr, sondern ein **seit >2 Monaten ununterbrochen aktiver Backu |
| | | p-Ausfall auf drei Ebenen** (Rsync-Push, Pool-Space, ZFS-Replication). Ohne Auflösung ist |
| | | aktuell unklar, ob überhaupt ein funktionierendes Off-Site-Backup existiert. Naheliegendst |
| | | e Ursache: der `backup`-Pool ist zu klein für die replizierten Datenmengen bzw. alte Snaps |
| | | hots werden nicht rotiert/gelöscht. |
| | | |
| | | ## Nicht gefunden |
| | | - Keine Information zur Kapazität/Hardware des `backup`-Pools (USB-HDD wie im Konzept vorg |
| | | esehen, oder etwas anderes?). |
| | | - Keine Fehlerursachen-Analyse oder Reparaturversuch dokumentiert — nur die Alert-Mails se |
| | | lbst. |
| | | - Keine Bestätigung, dass die Cloud-Off-Site-Option (Restic/B2/Wasabi/Hetzner) je umgesetz |
| | | t wurde. |
| | | |
| | | **Quellen:** Nextcloud privat `truenas-dataset-plan-final.md` (Snapshot-Policy-Konzept); M |
| | | ail-MCP Volltextsuche „TrueNAS", „Backup" (Alert-Mails 04.06.–09.08.2026, Synology-Hyper-B |
| | | ackup-Mails Mai/Juni 2026). |