Capacity and Lifecycle - KalliLab CORE

Status: Initiale Capacity-Baseline 2026-05-26; H:/-Nearline-Bewertung 2026-05-26; externe Cold-Storage-Groessen offen.

Zweck

Dieses Dokument haelt Wachstum, Schwellenwerte und Upgrade-Trigger fest. Es verhindert, dass Storage-, RAM- oder Backup-Entscheidungen erst dann getroffen werden, wenn der Host bereits unter Druck steht.

Aktuelle Kapazitaet

Bereich	Groesse	Belegt	Frei	Schwellwert	Bewertung
Cache	1.9T	97G	1.8T	70 % Planung / 85 % Aktion	gruen, 6 % belegt
Disk1 / Array	5.5T	1.8T	3.7T	80 % Planung / 90 % Aktion	gruen, 33 % belegt
User Shares gesamt	5.5T	1.8T	3.7T	80 % Planung / 90 % Aktion	gruen, entspricht aktuell Disk1
Backups lokal	5.5T geteilter Array-Space	2.2G unter `/mnt/user/backups`	3.7T Share-frei	Review bei Borg-/Dump-Wachstum	lokal nicht unabhaengig vom Array
Hetzner Borg	TBD	TBD	TBD	TBD	TBD
Externe Cold-Platte	TBD	TBD	TBD	TBD	TBD

Pruefkommando:

df -h /mnt/cache /mnt/disk1 /mnt/user
du -sh /mnt/user/appdata/* | sort -hr | head -30
du -sh /mnt/user/documents /mnt/user/photos /mnt/user/media /mnt/user/backups 2>/dev/null

Wachstumsbereiche

Bereich	Erwartetes Wachstum	Risiko	Naechste Aktion
Medien	aktuell ca. 1.7T	groesster Speicherblock	Array-Erweiterung vor 80 % planen
Immich Fotos/Videos	aktuell ca. 23G	hoechster privater Datentopf	Restore-Test priorisieren
Paperless/Dokumente	aktuell ca. 199M im Documents-Share	wichtig, moderates Wachstum	Restore-Test existiert, Share-Wachstum beobachten
Nextcloud	TBD	Familiennutzung kann stark wachsen	Quota/Backup pruefen
Monitoring/Loki	begrenzt durch Retention	Retention kann Disk fuellen	Retention und Volume-Groesse bei Reviews pruefen
Borg Dumps	aktuell ca. 2.2G lokale Backups	Retention und Excludes pruefen	Borg-Stale + Groessenprofil

Upgrade-Trigger

Trigger	Massnahme
Cache dauerhaft >70 %	Zweite NVMe oder Appdata-Verteilung planen
Cache >85 %	Sofortmassnahme, keine grossen Deployments
Disk1 >80 %	Array-Erweiterung planen
Disk1 >90 %	Keine neuen grossen Datenimporte, Erweiterung priorisieren
RAM >90 % ueber 10 Minuten regelmaessig	RAM-Ausbau oder Service-Limits pruefen
Borg-Laufzeit deutlich steigend	Scope, Netzwerk und Ziel pruefen
SMART-Warnung	Ersatz planen, Restore-/Backup-Frische pruefen
Keine USV-Abschaltung	Risiko ist per Operator-Entscheidung 2026-05-26 bewusst akzeptiert; bei Stromausfaellen/Datenkorruption neu bewerten

H:/ als zusaetzliches lokales Backup-Ziel

Operator-Befund 2026-05-26: das Windows-Laufwerk H:/ laeuft dauerhaft am Arbeits-PC und wurde bereits als H:-Freeze-Backup waehrend der Disk1 NTFS->XFS Phase 2 erfolgreich genutzt (siehe docs/MIGRATION_LOG.md).

Eigenschaften von H:/

Eigenschaft	Wert	Konsequenz
Anbindung	Windows-PC, dauerhaft verbunden	kein Air-Gap, kein Hardware-Trenn-Schutz
Standort	gleicher physischer Standort wie Unraid-Host	kein Off-site, kein Schutz gegen Brand/Diebstahl/Wasser
Schreibzugriff	dauerhaft moeglich	Ransomware oder Operator-Fehler koennen Original und Kopie gleichzeitig treffen
Filesystem (Windows)	typischerweise NTFS	fuer Borg-Ziel ueber CIFS/SMB ungeeignet als Hard-Mount auf Unraid (STORAGE_LAYOUT §12.6)
Reproduzierbar nutzbar	ja, bewaehrt durch Disk1-Phase-2-Freeze-Backup	Pull-Modell vom Windows-PC ist der getestete Weg

Bewertung

H:/ ist keine echte Offsite-/Airgap-Kopie und kein Ersatz fuer Hetzner. Es ist aber sinnvoll als:

Zweite lokale Nearline-Kopie fuer kritische Restore-Quellen (Borg-Dumps, Repo-Bundles, Flash-Backup). Schnellster Restore-Pfad bei Hetzner-Stoerung, weil kein Off-site-Download noetig ist.
Cold-Storage-Vorstufe: wenn H:/ kuenftig periodisch (z. B. monatlich) physisch getrennt und durch eine zweite Platte ersetzt wird, wuerde sich daraus ein echtes Air-Gap-Rotationsschema ableiten lassen.
Freeze-Sicherung vor strukturellen Eingriffen (Disk-Tausch, Pool-Umzug, Format), wie bereits 2026-05-25 praktiziert.

Empfohlene Nutzung

Nutzung	Umsetzung	Hinweis
Pull von `/mnt/user/backups/borg/dumps/latest` auf H:/	Windows-seitiger Scheduled Task per `robocopy` oder `rclone` von einem SMB-Read-Share	keine CIFS-Hard-Mounts auf Unraid; STORAGE_LAYOUT-Konstitution bleibt erhalten
Pull der Gitea-Bundles aus `/mnt/user/backups/git-bundles/gitea`	identisch	Bundles sind klein und schnell synchronisiert
Pull des Unraid-Flash-Artefakts `unraid-flash-config.tar.gz`	identisch	wie Secret behandeln, Windows-seitig nicht in geteilten Ordnern ablegen

Der konkrete Pull-Pfad ist in docs/H_DRIVE_NEARLINE_PULL.md und ops/h-drive-nearline/pull-critical-backups.ps1 vorbereitet. Der Windows Scheduled Task wird erst nach Operator-Sichtpruefung aktiviert. | Nicht als Ersatz fuer Hetzner-Off-site | — | 3-2-1 bleibt mit Hetzner als einzigem Off-site weiterhin unerfuellt; siehe docs/AUDIT_2026-05-25.md F-03 | | Nicht als zweites Borg-Repo am Unraid | — | dauerhafte CIFS-Verbindung im Borg-Lauf verletzt Hard Rule §12.6 |

Kapazitaets-Eintrag

Bereich	Groesse	Belegt	Schwellwert	Bewertung
H:/ (Windows-Arbeitsplatz, `Externe HDD`)	8.0T	3.91T belegt / 4.10T frei	Review wenn > 70 %	NTFS, `Healthy`; Pull-Ziel fuer Borg-Dumps, Gitea-Bundles und Flash-Backup

Naechste Schritte

Pull-Script (Operator-Aufgabe, kein Repo-Pflichtteil) etablieren; alternativ ueber Filebrowser/Nextcloud-Sync abdecken.
Review-Intervall: quartalsweise. Bei jeder grossen Strukturaenderung (Disk-Tausch, Pool-Umzug) Freeze-Pull manuell ausloesen.

Restore-Zeitziele

Tier	Beispiel	Zielzeit	Status
Tier 0	Repo, Secrets, Traefik, DNS	TBD	offen
Tier 1	Gitea, Vaultwarden, Paperless, Immich	TBD	offen
Tier 2	Nextcloud, Mealie, Monitoring	TBD	offen
Tier 3	Komfort-/Ops-Tools	TBD	offen

Review-Log

Datum	Befund	Entscheidung
2026-05-26	Cache 6 %, Array/User-Shares 33 %, lokale Backups 2.2G; keine validierte USV-Abschaltung	Capacity gruen; USV wird aktuell nicht angeschafft, Power-Loss-Risiko bewusst akzeptiert; externe Backup-/Cold-Storage-Groessen bleiben offen
2026-05-26	H:/ als dauerhaft verbundenes Windows-Laufwerk evaluiert	als zweite lokale Nearline-Kopie und Freeze-Sicherung sinnvoll; nicht als Offsite-Ersatz und nicht als Borg-CIFS-Hard-Mount am Unraid; Pull-Modell vom Windows-PC bleibt der getestete Weg
2026-05-26	H:/ Kapazitaet erfasst: 8.0T NTFS, 3.91T belegt, 4.10T frei, `Healthy`	genug Reserve fuer Nearline-Pull der kritischen Restore-Artefakte; Pull-Schedule bleibt offen
2026-05-27	H:/ Pull-Workflow vorbereitet	SMB-Quelle `\\192.168.178.58\backups` erreichbar; PowerShell-Skript und Runbook erstellt; empfohlener Schedule taeglich 05:30, aber Task noch nicht aktiviert

7.0 KiB Raw Blame History