memory-service
Projekte
/
Interne IT
/
backup-sicherheit
Bearbeiten
Unterthema
Titel
Inhalt (Markdown)
**Status:** Konzept sauber dokumentiert, Umsetzung teils produktiv — aber laufender, mehrwöchiger technischer Defekt weiterhin ungelöst (Stand 09.08.2026, jüngste Alert-Mail). ## Konzept (aus TrueNAS-Dataset-Plan, 15.05.2026) - ZFS-Snapshot-Policy: `apps` stündlich/24h, `bulk/docs` täglich 02:00/30 Tage, `bulk/media` 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-rekursiv. - Ersetzt die alte Synology-„Hyper Backup"-Lösung (907 GB) bewusst — die wurde NICHT migriert. - 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 (Restic/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 kopieren — in mehreren Dokumenten wiederholt als Kernregel verankert und in der DB-Wartung 07.06.2026 auch so durchgeführt. ## Laufender realer Defekt — bislang deutlich unterschätzt (NEU im Detail) Es existiert tatsächlich bereits ein **dritter ZFS-Pool namens `backup`** (Replikationsziel, vermutlich das im Konzept vorgesehene Off-Site/Replication-Target) — das war in den bisherigen Konzeptdokumenten nicht namentlich erwähnt, taucht aber ab Anfang August 2026 in den TrueNAS-Alert-Mails auf. - **Rsync-„PUSH"-Tasks für `/mnt/apps` und `/mnt/bulk` schlagen durchgehend fehl**, erstmals 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 über 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 einen zyklischen Replikations-/Löschprozess hindeutet, der den Pool nicht stabil unter Kontrolle 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 konkreten Fehlermeldungen: - „No incremental base on dataset 'bulk/paperless' and replication from scratch is not allowed" (09.08.2026 07:26). - „cannot receive resume stream: out of space Broken pipe" für mehrere Datasets: `apps/nextcloud-geb/data@auto-2026-07-29_10-48` (02.08.2026 05:49 und erneut 02.08.2026 04:57) und `apps/kasm@auto-2026-07-30_00-00` bzw. `@auto-2026-08-02_00-00` (02.08.2026 10:17, erneut 08.08.2026 22:52). - Kernursache klar erkennbar: der `backup`-Pool läuft chronisch voll, wodurch Replikationen mit Resume-Token abbrechen und der abgebrochene State ein sauberes Neu-Anlaufen verhindert (kein Platz für vollständigen Neu-Sync „from scratch"). - **Parallel/historisch (vor der TrueNAS-Migration):** Die alte Synology „Hyper Backup"-Aufgabe „Synology Remote Daily" (Ziel: `backup-familie-bayram.synology.me` / `Remote_Backup` / `DiskStation.hbk`) schlug ebenfalls wiederholt fehl — dokumentiert für 20.–31.05.2026 sowie 01.–04.06.2026 (mehrere Läufe mit 1–14 Stunden Laufzeit, alle „fehlgeschlagen"). Diese 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 Backup-Ausfall auf drei Ebenen** (Rsync-Push, Pool-Space, ZFS-Replication). Ohne Auflösung ist aktuell unklar, ob überhaupt ein funktionierendes Off-Site-Backup existiert. Naheliegendste Ursache: der `backup`-Pool ist zu klein für die replizierten Datenmengen bzw. alte Snapshots werden nicht rotiert/gelöscht. ## Nicht gefunden - Keine Information zur Kapazität/Hardware des `backup`-Pools (USB-HDD wie im Konzept vorgesehen, oder etwas anderes?). - Keine Fehlerursachen-Analyse oder Reparaturversuch dokumentiert — nur die Alert-Mails selbst. - Keine Bestätigung, dass die Cloud-Off-Site-Option (Restic/B2/Wasabi/Hetzner) je umgesetzt wurde. **Quellen:** Nextcloud privat `truenas-dataset-plan-final.md` (Snapshot-Policy-Konzept); Mail-MCP Volltextsuche „TrueNAS", „Backup" (Alert-Mails 04.06.–09.08.2026, Synology-Hyper-Backup-Mails Mai/Juni 2026).
Tags (kommagetrennt)
Status
—
offen
wartet
Speichern
Abbrechen