Files
homelab-infra/docs/archive/2026-05/DISK1_PHASE2_PLAN_2026-05-23.md
T
2026-05-31 22:53:10 +02:00

4.9 KiB

Disk1 Phase 2 - NTFS to XFS Migration

Stand: 2026-05-25 06:15 CEST. Ziel erreicht: /mnt/disk1 wurde von ntfs3 auf XFS migriert, ohne produktive Compose-Pfade zu aendern. Container nutzen weiter /mnt/user/....

Preflight

Check Ergebnis
Disk1 Mount /dev/md1p1 auf /mnt/disk1, ntfs3, 5.5T, 1.7T genutzt, 3.8T frei
Cache Mount /dev/nvme0n1p1 auf /mnt/cache, xfs, 1.9T, 100G genutzt
H: Backup-Ziel H:\, Label Externe HDD, NTFS, 8T, 5.96T frei, healthy
Compose-Binds Keine Treffer fuer direkte /mnt/disk1, /mnt/cache, /mnt/disks, /mnt/remotes Binds
SMB-Zugriff \\Kallilabcore\services, documents, photos, media erreichbar

Zu sichernde Shares

Share Groesse laut Preflight
services 451M
documents 196M
photos 23G
backups 2.2G
media 1.7T
finance 0
projekte 92K

Zusaetzliche Disk1-Top-Level-Pfade: scripts 3.3M, isos 0, System Volume Information 0.

Backup-Strategie

  • Zielroot: H:\kallilab-recovery\disk1-phase2-2026-05-23.
  • Kritischer Linux-/GitOps-Pfad services wird zusaetzlich als Tar-Archiv ueber SSH gesichert, damit Linux-Metadaten erhalten bleiben.
  • User-Shares werden per SMB/Robocopy kopiert, mit Logs und anschliessender Zaehler-/Groessenverifikation.
  • Keine produktiven Datenpfade werden geloescht.

Gates

  1. Backup komplett und verifiziert.
  2. Dienste-Freeze vorbereitet und letzte Dumps frisch.
  3. Direkt vor Format/Array-Prozedur: Operator-Bestaetigung im konkreten Moment.

Backup-Ergebnis

Stand: 2026-05-24 13:07 CEST.

Bereich Sicherungsart Ergebnis
media Robocopy/SMB nach H:\kallilab-recovery\disk1-phase2-2026-05-23\shares\media 2722 Dateien, 1677.11 GiB, Manifestvergleich: 0 missing, 0 size mismatch, 0 extra
services Host-Tar auf Unraid Cache, danach binaer per scp nach H: services.tar, 0.441 GiB, tar -tf gueltig
documents Host-Tar auf Unraid Cache, danach binaer per scp nach H: documents.tar, 0.192 GiB, tar -tf gueltig
photos Host-Tar auf Unraid Cache, danach binaer per scp nach H: photos.tar, 22.876 GiB, tar -tf gueltig
backups Host-Tar auf Unraid Cache, danach binaer per scp nach H: backups.tar, 2.099 GiB, tar -tf gueltig
finance Host-Tar auf Unraid Cache, danach binaer per scp nach H: finance.tar, leerer Share, tar -tf gueltig
projekte Host-Tar auf Unraid Cache, danach binaer per scp nach H: projekte.tar, klein, tar -tf gueltig
Disk1-Extras scripts, isos Host-Tar auf Unraid Cache, danach binaer per scp nach H: disk1-extra.tar, 0.003 GiB, tar -tf gueltig

Hinweis: Erste Tar-Versuche per PowerShell-Redirect wurden verworfen, weil PowerShell den binaeren SSH-Stream als UTF-16 geschrieben hatte. Die ungueltige media.tar und unvollstaendige SMB-Teilkopien fuer services/documents wurden vom Backup-Ziel entfernt, damit nur verwertbare Sicherungen uebrig bleiben.

Abschluss

Stand: 2026-05-25 06:15 CEST.

Check Ergebnis
Freeze-Dumps pre-backup-dumps.sh vor Format ausgefuehrt; nach Wiederanlauf erneut erfolgreich, 15 kanonische Dump-Artefakte juenger als 24 h
Disk1 Filesystem /dev/md1p1 auf /mnt/disk1, xfs, 5.5T, 1.8T genutzt, 3.7T frei
Restore media 2722 Dateien, 1,800,782,188,226 Bytes; finaler Manifestvergleich: 0 missing, 0 size mismatch, 0 extra
Restore Tar-Shares services, documents, photos, backups, finance, projekte und Disk1-Extras aus H:-Freeze-Archiven nach /mnt/disk1 extrahiert
Docker/Services 49 Container laufend, 0 stopped, 0 unhealthy, 0 starting
Smoke-Tests git.kaleschke.info 200, komodo.kaleschke.info 200, borg.kaleschke.info 302, jellyfin.kaleschke.info 302, monitoring.kaleschke.info 302
Service-Mounts Gitea SSH :222 offen; Jellyfin und Plex sehen /media; Prometheus readiness ok
Backup-Lauf Borg-UI Repository appdata-critical, letzter Job completed, Archiv Taegliche-Sicherung-2026-05-25T05:52:44.157, nfiles=100221
Temp-Cleanup /mnt/cache/disk1-phase2-tmp/*.tar nach H:-Verifikation geloescht; Cache weiter XFS mit ca. 1.7T frei

Hinweis zum Docker-Wiederanlauf: Nach dem manuellen Docker-Start liefen die Container, aber Healthcheck-Execs scheiterten wegen dockerd mit XDG_RUNTIME_DIR=/run/user/0. Ein gezielter Docker-Neustart mit unsetztem XDG_RUNTIME_DIR behob den Runtime-Fehler; danach wurden alle Healthchecks gruen. monitoring-prometheus war durch den geplanten Docker-Stop sauber beendet und wurde als bestehender Container wieder gestartet.

Offener Nachlauf: Die Array-Parity-Anzeige zeigte nach Abschluss weiter mdNumDisabled=1, mdNumInvalid=1 und mdResyncAction=check P, waehrend beide beteiligten Devices rdevStatus=DISK_OK und rdevNumErrors=0 melden. Parity-Zustand separat in Unraid pruefen und keinen Parity-/Disk-Slot ohne Operator-Entscheid aendern.