Dieser Thread vom April 2026 begann als allgemeiner Beitrag eines „neuen, von ZimaOS überforderten Benutzers“, der Backup und selbst gehostete E-Mail behandelte. Das E-Mail-Problem wurde schließlich nebensächlich: Der Benutzer brachte Mailcow für seine Anforderungen ausreichend gut zum Laufen. Die ungelöste technische Geschichte betraf ZimaOS Backup: Die angezeigten Größen waren inkonsistent, der erste Durchlauf wurde normalerweise abgeschlossen, und spätere Durchläufe konnten ohne weitere Festplattenaktivität einfrieren.
Die Quelle ist besonders nützlich, weil der Benutzer mehr als ein ZimaBoard 2, mehrere interne und externe Laufwerke, ein Synology-Netzwerkziel und später auch ZimaOS 1.6.1 getestet hat. Das Problem sollte daher nicht als einzelner fehlerhafter USB-Datenträger oder als ein einziger falscher Netzwerkpfad zusammengefasst werden.
Der Benutzer wollte ein einfaches Notfall-Backup, kein Archivformat
Der gewünschte Ablauf war unkompliziert: ein Backup im Stil einer 1:1-Kopie manuell starten, die vertraute Ordnerstruktur beibehalten, Verschlüsselung oder undurchsichtige Paketformate vermeiden und eine schnelle Wiederherstellung ermöglichen, falls ein ZimaBoard 2 vollständig ausfällt.
Diese Erwartung unterscheidet sich von versionsbasierten Backup-Programmen, die absichtlich historische Kopien aufbewahren. Wenn die Aufbewahrung mehrerer Versionen aktiviert ist, kann der Speicherbedarf des Ziels legitimerweise die Größe des aktuellen Quelldatensatzes überschreiten.
Das Problem auf der Mailserver-Seite wurde schließlich getrennt betrachtet
Im ursprünglichen Beitrag wurde außerdem beschrieben, dass der Ersatz von Synology Mail Plus schwierig war. Zima-Jerry schlug Stalwart vor, aber der Benutzer benötigte ausdrücklich den POP3-Abruf. Am 16. April berichtete der Benutzer, dass Mailcow funktionierte und die anderen Anwendungen zufriedenstellend liefen.
Dieses Ergebnis sollte festgehalten werden, damit die spätere Diskussion über Backup nicht fälschlich als Beleg dafür verstanden wird, dass Mailcow selbst das Speicherproblem verursacht hat.
Die Größen der Backup-Ziele stimmten nicht mit der Realität überein
Bei einem Board entsprachen etwa 800 GB an der Quelle ungefähr 2,7 TB im Zielverzeichnis. Bei einem anderen schienen von etwa 105 GB an der Quelle im Ziel ungefähr 2 GB zu fehlen.
Die Aufbewahrung von Versionen kann einen Teil des Wachstums erklären, aber keinen eingefrorenen zweiten Durchlauf
Zima-Jerry fragte, ob die Funktion „Version reservieren“ aktiviert sei. Das Aufbewahren vorheriger Versionen kann legitimerweise dazu führen, dass ein Sicherungsziel größer ist als die aktuelle Live-Quelle.
Der Nutzer setzte den Test später jedoch mit einer frisch formatierten externen USB-Festplatte zurück und dokumentierte einen anderen Fehler: Die erste Sicherung wurde abgeschlossen, die zweite kopierte einige Daten und machte dann keinen weiteren Fortschritt.
Der Test mit einem bereinigten USB-Laufwerk reproduzierte den Fehler beim zweiten Durchlauf
Der Nutzer löschte alte Aufträge, startete das ZimaBoard 2 neu, formatierte ein externes Laufwerk und erstellte eine neue manuelle Sicherung mit aktivierten Versionen. Der erste Durchlauf dauerte fast zwei Tage und kopierte erfolgreich etwa 1,25 TB.
Nachdem das Laufwerk über „Dateien“ getrennt und wieder verbunden worden war, kopierte der zweite Durchlauf einige Änderungen. Danach fror der Fortschrittsbalken ein, und die USB-Aktivitäts-LED erlosch. Dasselbe Verhalten war beim Synology-Ziel aufgetreten.
IceWhale eskalierte das Verhalten der Sicherung
Zima-Jerry dankte dem Nutzer für die kontrollierten Tests und sagte, dass das Problem zur Untersuchung an das Entwicklungsteam weitergeleitet werde.
Eine spätere Antwort im Zusammenhang mit IceWhale trennte zwei bekannte Problembereiche: die Sicherung aller /media/ZimaOS-HD hatte zuvor Docker-Pipe-/Socket-Inhalte eingeschlossen, und die Genauigkeit der Anzeige des Sicherungsfortschritts musste weiterhin verbessert werden.
Die Sicherung des gesamten Systemlaufwerks ist nicht dasselbe wie ein wiederherstellbares Systemabbild
Die Diskussion wandte sich später der Notfallwiederherstellung zu. Eine Antwort des Teams erklärte, dass eine blinde Sicherung der gesamten Systemfestplatte auch entbehrliche Docker-/Laufzeitdateien einschließt und nicht automatisch einen unterstützten Workflow nach dem Muster „Diesen Ordner wiederherstellen, und das gesamte ZimaOS-System ist exakt wie zuvor“ bietet.
Für die Notfallplanung sollten Benutzerdaten, Anwendungsdaten, Datenbanken, Konfigurationen und ersetzbare Container-Images unterschieden werden.
ZimaOS 1.6.0 hat die Metadaten der Speicherwiederherstellung geändert
Eine spätere offizielle Antwort besagte, dass ab ZimaOS 1.6.0 auch Informationen darüber, wie ein Speichergerät eingebunden werden sollte, auf dem Speicher selbst abgelegt wurden. Dadurch sollten RAID- oder Einzellaufwerkspeicher nach einem Problem mit dem Systemdatenträger leichter wiedererkannt werden können.
Dies verbessert die Wiederherstellung eines Arrays, macht RAID jedoch nicht zu einem Backup und behebt das Hängenbleiben des Backups beim zweiten Durchlauf durch den Benutzer nicht von selbst.
Der Benutzer konnte das Problem unter ZimaOS 1.6.1 weiterhin reproduzieren
Am 27. April berichtete der ursprüngliche Verfasser, dass das erste Backup weiterhin funktionierte, der zweite und die darauffolgenden Durchläufe jedoch länger als sechs Stunden ohne weitere Schreibaktivität hängen blieben. Nach dem Schließen und erneuten Öffnen von Backup konnte das Ziel mit 0 B angezeigt werden.
Sie sagten, das Muster sei mit vier internen Laufwerken, zwei externen USB-Laufwerken und drei ZimaBoard-2-Systemen getestet worden.
Der aktuelle Backup-Workflow hat sich weiterentwickelt
Die aktuelle ZimaOS-Dokumentation beschreibt nun geplante Backup-Aufgaben für lokale Ziele, USB, NAS und Cloud-Ziele als Teil einer 3-2-1-Strategie.
Verwenden Sie den aktuellen ZimaOS-Backup-Workflow und die Zieloptionen, statt davon auszugehen, dass sich die Benutzeroberfläche von 1.5.x/1.6.1 heute identisch verhält.
Der aktuelle Leitfaden beweist nicht allein, dass jeder historische Fehler beim zweiten Durchlauf in diesem Thread behoben wurde. Überprüfen Sie daher das tatsächliche Wiederherstellungsverhalten mit der von Ihnen verwendeten Version.
Backup außerhalb des Fortschrittsbalkens überprüfen
- Vergleichen Sie, sofern praktikabel, die Dateianzahl von Quelle und Ziel;
- Prüfen Sie die tatsächliche Kapazität des Ziels statt nur die Backup-Benutzeroberfläche;
- Testen Sie einen zweiten und dritten inkrementellen bzw. versionierten Durchlauf;
- Stellen Sie repräsentative Dateien an einem anderen Speicherort wieder her;
- Dokumentieren Sie, welche Anwendungsdatenbanken und Einstellungen separat gesichert werden müssen.
ZimaOS-Backup-FAQ
Trat das Problem mit der Quelle nur bei einem Synology-NAS auf?
Nein. Der Benutzer konnte ein ähnliches Einfrieren mit einem externen USB-Laufwerk reproduzieren.
Ist das erste Backup fehlgeschlagen?
Der kontrollierte erste Durchlauf wurde abgeschlossen; das wiederkehrende Problem trat bei späteren Durchläufen auf.
War das Problem in ZimaOS 1.6.1 behoben?
Nein. Der ursprüngliche Verfasser sagte ausdrücklich, dass das Problem dort weiterhin auftrat.
Kann ein Backup-Ziel berechtigterweise größer sein als die aktuelle Quelle?
Ja, wenn die Versionierung aktiviert ist, aber das erklärt nicht jedes Anzeige- oder Hängenbleiben-Symptom in diesem Thread.
