Ein durch den Hostingprovider hervorgerufener Speicherplatzmangel, nämlich ein automatischer Reboot der Maschine ließ das laufende Backup „überlaufen“ und schrieb den verfügbaren freien Festplattenspeicher voll. Normal war eine Speicherauslastung des NFS mit ca. 36 % ( bei 100 GB Kapazität) – folglich waren aber die gesamten 100 GB voll mit temporären Dumps des Plesk Backup Managers („pmm-ras“ Perl-Prozess).
Meist wird eine Fehlermeldung beim Login in den Plesk-Backend-Bereich ausgegeben:
„plesk sqlstate hy000 general error 1030 got error 28 from storage engine“
Vorgehensweise:
(Kommandozeilen-Eingaben in diesem Format)
- Backup abbrechen (über die Pleskoberfläche selbst oder per Kommandozeile)
- Freien Speicherplatz prüfen:
# df -h
Meist wird die / Partition mit 100 % Belegung ausgegeben – das rootfs bzw. /root hat mit 100 % Belegung nichts zu tun und bleibt unangetastet
- Nach großen Dateien auf dem gesamten Dateisystem suchen und nach Größe sortieren (größer als 500 Megabyte)
# find / -type f -size +500M | xargs ls -lahS
- Inhalte des Temporär-Verzeichnis /usr/local/psa/PMM/tmp/backup* mittels Kommando löschen:
# rm -rf /usr/local/psa/PMM/tmp/backup*
- Nochmals freien Speicherplatz prüfen
# df -h
- Nun kann vorkommen das Prozesse bereits gelöschte Dateien noch verwenden – diese kann man so ausgeben lassen:
# lsof | grep deleted
- Nun per „kill xxxxxxx“ die Perl-Prozesse des Plesk Backup Manager (ähnliche Ergebnisse siehe Bild oben, xxxxx durch Prozess ID [2. Wert in Zeile] ) killen.
# kill 1971
- Nun überprüfen, wie sich die „Disk Usage“ entwickelt hat im Verzeichnis /usr/local/psa/PMM/tmp :
# du /usr/local/psa/PMM/tmp -h
(Ausgabe in Gigabyte – die letzte Zahl unten ist die Gesamtgröße des Verzeichnisses)
- Falls nötig, Plesk neu starten:
# /etc/init.d/psa restart
- Et Voilà – Wieder Platz genug auf der Partition.
Grundsätzliche Anmerkungen:
Vor jeden Eingriff in das Live System – dieses per Snapshot oder Komplett-Backup sichern. Die oben aufgezeigten Kommandos sind auf eigene Gefahr durchzuführen.