Wenn icewhale-files-backup auf ZimaOS 1.7.0 auf mehrere Gigabyte RAM anwächst und wiederholt den OOM-Killer auslöst, aktualisieren Sie zunächst auf ZimaOS 1.7.1 oder neuer. In den Versionshinweisen von IceWhale zu 1.7.1 werden ausdrücklich eine Behebung des abnormalen Speicherverbrauchs in bestimmten Szenarien mit Dateioperationen sowie Probleme mit fehlgeschlagenen oder unterbrochenen Backups genannt.
Der ursprüngliche Thread dokumentierte eine schwerwiegende Regression in 1.7.0: Der Speicherverbrauch stieg von etwa 3,5 GB auf über 10 GB, der Kernel beendete Backup, Restart=always startete den Dienst erneut, und dieser Kreislauf destabilsierte den Server. Das Maskieren des Dienstes beendete die Schleife, war jedoch nur eine Notlösung.
Die OOM-Schleife erkennen
journalctl -k | grep -i -E 'oom|out of memory|killed process'
ps aux --sort=-%mem | head
free -hWenn der Backup-Prozess wiederholt als größter Speicherverbraucher erscheint, kann die Neustartschleife Docker und andere Dienste ausbremsen.
Auf 1.7.1 oder neuer aktualisieren
Die offiziellen Versionshinweise zu ZimaOS 1.7.1 nennen Korrekturen für abnormalen Speicherverbrauch sowie für Backup-Aufgaben, die fehlschlagen oder unterbrochen werden konnten.
Notfallwiederherstellung unter 1.7.0
sudo systemctl stop icewhale-files-backup.service
sudo systemctl disable icewhale-files-backup.service
sudo systemctl mask icewhale-files-backup.serviceDas Maskieren war erforderlich, weil normales Stoppen oder Deaktivieren einen erneuten Start aufgrund der Neustartrichtlinie des Dienstes nicht immer verhinderte.
Verstehen, was das Maskieren deaktiviert
Durch das Maskieren wird die integrierte Backup-Funktion deaktiviert. Verwenden Sie dies nur, um einen nicht nutzbaren Host lange genug zu stabilisieren, damit Sie aktualisieren oder Daten wiederherstellen können.
Nach der Aktualisierung die Sperre aufheben
sudo systemctl unmask icewhale-files-backup.service
sudo systemctl enable icewhale-files-backup.service
sudo systemctl start icewhale-files-backup.serviceFühren Sie anschließend ein kleines, kontrolliertes Backup durch und überwachen Sie RAM und Swap.
USB-Backup-Workloads waren ein häufiger Auslöser
Mehrere Nutzer berichteten von einem ähnlichen Verhalten bei USB-Backup-Zielen. Dies erleichtert zwar die Reproduktion des Fehlers, beweist jedoch nicht, dass das Gehäuse selbst die Ursache war.
Die Vollständigkeit des Backups überprüfen
Vergleichen Sie die Dateianzahl von Quelle und Ziel und führen Sie einen Wiederherstellungstest durch. Der Leitfaden zur Backup-Überprüfung hilft, die Abhängigkeit von einem einzigen Auftrag zu verringern.
Prüfen, ob Docker durch Speichermangel beschädigt wurde
Im Thread führte der anhaltende Speicherdruck schließlich dazu, dass Docker-Anwendungen nicht mehr verfügbar waren. Prüfen Sie nach der Stabilisierung des Hosts docker ps, den Docker-Daemon und wichtige Container, bevor Sie einen großen Backup-Workload erneut starten.
Nach der Aktualisierung mit einem kleinen Backup beginnen
Starten Sie nicht sofort den Multi-Terabyte- oder USB-Auftrag erneut, der den Fehler ausgelöst hat. Erstellen Sie eine kleine Testaufgabe, überwachen Sie den Speicher 10–20 Minuten lang und erhöhen Sie anschließend schrittweise die Dateianzahl und die Gesamtgröße. So lässt sich leichter erkennen, ob der korrigierte Dienst einen begrenzten Speicherverbrauch beibehält.
Die Dateianzahl ist ebenso wichtig wie die Datenmenge
Hunderttausende kleine Dateien können deutlich mehr Metadatenverarbeitung verursachen als einige wenige große Mediendateien. Geben Sie bei einer Supportanfrage sowohl die Gesamtgröße in Bytes als auch die ungefähre Dateianzahl an.
Während des Tests einen unabhängigen Backup-Pfad beibehalten
Wenn das integrierte Backup zuvor unvollständig oder instabil war, bewahren Sie mit einem separaten Tool oder Ziel eine weitere, nachweislich funktionierende Kopie auf, bis ein Wiederherstellungstest bestätigt, dass der aktuelle ZimaOS-Auftrag zuverlässig ist.
Protokolle vor und nach der Korrektur aufbewahren
Speichern Sie vor der Aktualisierung die OOM-Meldungen, die Prozesse mit dem höchsten Speicherverbrauch, die ZimaOS-Version und den Typ des Backup-Ziels. Wiederholen Sie anschließend denselben kontrollierten Workload unter 1.7.1+ und vergleichen Sie das Speicherwachstum. So erhalten Sie Belege dafür, dass die Regression behoben ist, anstatt sich nur darauf zu verlassen, dass sich „der Server stabil anfühlt“.
Wenn der Speicherverbrauch auch in der korrigierten Version weiterhin unbegrenzt ansteigt, beenden Sie die Aufgabe und übermitteln Sie dem Support diese Messungen aus der Zeit vor und nach der Aktualisierung.
FAQ
Wurde das Speicherleck von mehreren Nutzern bestätigt?
Ja. Mehrere Nutzer berichteten dasselbe Verhalten unter 1.7.0.
Wurde diese Art von Problem in 1.7.1 behoben?
Ja. Das offizielle Änderungsprotokoll enthält Speicher- und Backup-Korrekturen, die dieses Problem direkt betreffen.
Soll ich auf 1.6.2 zurückgehen?
Das war eine vorübergehende Notlösung vor 1.7.1. Aktuelle Nutzer sollten vorzugsweise die korrigierte stabile Version verwenden.
Woran erkenne ich, dass die Korrektur funktioniert?
Führen Sie ein kontrolliertes Backup durch und überwachen Sie Speicher, Swap, Protokolle sowie die Vollständigkeit des Ziels.
