Backups bringen vServer ans Limit - üblich? Anderes Konzept?

D

dev

Registered User
Hallo Leute,

ich betreibe meine eigene vServer Infrastruktur auf Basis von OpenVZ unter Centos 5.7.

Die letzten Tage ist mir aufgefallen, dass in einem VE der Backupvorgang mit einer Fehlermeldung abbricht. Auf der Kiste laufen:

• httpd-worker
• php via fcgid angestöpselt
• mysld

Um den LAMP Betrieb geht es mir jedoch gar nicht, das habe ich gut im Griff. Das VE rennt mit 2 GB zugesichertem RAM (+1 GB Burst RAM zusätzlich) seit längerem, ohne dass Limits/Barrieren berührt werden.

Es sind insgesamt 56 vHosts, die 5.25 GB Daten haben, inkl. der Logs.
Dazu kommen noch einmal 7 GB anderer Kram, der mitgesichert wird.

Es sind also (aktuell) ca. 12 GB zu sichern.

Wenn der crond Duplicity* anstupst (2x täglich), werden im Verlauf des Backups bis zu 3.8 GB RAM (!!!) vom Python Interpreter alloziert. Naja, und dann greift natürlich der OpenVZ Kernel ein und macht im VE Duplicity dicht.

Ich bin also am Ressourcenlimit, wofür nicht der eigentliche LAMP Betrieb ursächlich ist, sondern meine Backupvorgänge.

Ist das üblich, dass man _deswegen_ leistungstechnisch upgraden muss? Ich bin aus diesem Grund schon vor längerer Zeit von einem vServer auf einen Root-Server für den Remote-Backupsserver umgestiegen. Nun muss ich die Ressourcenlimits erhöhen - schon wieder wegen Backups. Oder ist ein anderes Konzept sinnvoll, z. B. dass sich der Backupserver die zu sichernden Daten selbst von den Clients holt und die eigentliche Arbeit macht (Vergleichen & Verpacken)?

Wie machen denn die Hoster Backups, die 100erte/1000e Kunden von einer Maschine sichern müssen??

* Duplicity ist ein Python-Skript, dass bei mir GPG verschlüsselte Backups via sftp auf eine dedizierte Remote-Backupmaschine (Rootserver) erstellt.
 
Ich setze bei einem Kunden auch Duplicity ein, allerdings unter FreeBSD. Dort habe ich keine Probleme. Zwar habe ich mehr RAM, der wird aber bei weitem nicht so belastet wie von dir geschildert.

Versuchst du ggf Daten zu sichern die sich nicht sichern lassen oder einen Loop verursachen?
 
Da sind halt die Logfiles für den Apache mit dabei, also schon einige offene Dateihandles. Ob die Probleme machen? Dann wäre die einzige Alternative, httpd während des Backups zu stoppen - das wäre aber nicht so schön.

Was für Dateien könnten denn noch Probleme machen?

EDIT: Habe nochmal schnell durchgezählt: Es sind 154.847 Dateien, die sich über die erwähnten 11.2 GB erstrecken. Sind es bei Dir auch so viel, mehr oder weniger?

Aktuell lief das Backup durch, hatte den Zeitpunkt etwas nach hinten verschoben und damit aus dem Zeitfenster des Backups der anderen VEs genommen - so bleibt mehr vom Nodekuchen für die Problemkiste.
 
Last edited by a moderator:
dev said:
Oder ist ein anderes Konzept sinnvoll, z. B. dass sich der Backupserver die zu sichernden Daten selbst von den Clients holt und die eigentliche Arbeit macht (Vergleichen & Verpacken)?
Click to expand...
Das halte ich so oder so für sinnvoll - zum einen wegen der "Arbeit", aber auch wegen der "Sicherheit" die man davonträgt, dass ein kompromittierter Server keine Logindaten zum Backupserver irgendwo liegen hat und der Angreifer somit keine Backups infizieren kann.

dev said:
Wie machen denn die Hoster Backups, die 100erte/1000e Kunden von einer Maschine sichern müssen??
Click to expand...
Nicht jeder Hoster macht Backups. :(
Ich könnte mir in dem Fall aber vorstellen, dass der ganze Host (also der Teil mit den VEs) gesichert wird und nicht einzeln pro vServer.

dev said:
Duplicity ist ein Python-Skript, dass bei mir GPG verschlüsselte Backups via sftp auf eine dedizierte Remote-Backupmaschine (Rootserver) erstellt.
Click to expand...
Warum nicht rsync? :)
 
s24! said:
Das halte ich so oder so für sinnvoll - zum einen wegen der "Arbeit", aber auch wegen der "Sicherheit" die man davonträgt, dass ein kompromittierter Server keine Logindaten zum Backupserver irgendwo liegen hat und der Angreifer somit keine Backups infizieren kann.
Click to expand...

Ja, das stimmt, das wäre ein Nebeneffekt. Allerdings sind auf dem Backupserver die einzelnen Backupuser separiert, d. h. backup-ve-1 kommt nicht an die Daten von backup-ve-n heran. Ausserdem sind es nur "normale" Shell-User. Und die Backupdaten sind verschlüsselt, der Angreifer müsste auf dem Opfersystem schon Root-Rechte erlangen, um überhaupt auf das Backupsystem zu kommen.

Bzgl. Deines Vorschlages: Wenn ich vom Backupserver auf den zu sichernden Klienten via ssh wechsele - wie kann ich dann Daten sichern, die root.root/700 oder 600 haben? Via sudo? Weil vorher alle Daten zusammenpacken und in einem extra Verzeichnis sichern wäre ja hirnrissig - genau das will ich ja dann nicht mehr.

s24! said:
Ich könnte mir in dem Fall aber vorstellen, dass der ganze Host (also der Teil mit den VEs) gesichert wird und nicht einzeln pro vServer.
Click to expand...

Ich weiss nicht, ob das die Problematik nicht noch weiter verschlimmert, also per vzdump iterierend komplette VE sichern. Das dauert richtig und ist für 2x täglich bzgl. der Leistung zu teuer, da vzdump in jedem Fall auf dem Wirtssystem ausgeführt werden muss.

Müsste ich evtl. mal probieren, im Moment sichere ich die VEs von "aussen" gar nicht. Ich habe Bashskripte, die mir die nackten VEs nach dem Starten mit allen benötigten Anwendungen der Distribution (Nutzdienste, Backup, Monitoring, Sicherheit) und individuellen Einstellungen innerhalb von 15 Minuten automatisch installieren.

s24! said:
Warum nicht rsync? :)
Click to expand...

Rsync nehme ich nur für einfach 1:1 Klonvorgänge. Meine Backups werden ja verschlüsselt und gepackt. Da macht Duplycity einen guten Job, auch was das Überprüfen, Wiederherstellen usw. angeht.

Da müsste ich wohl bei rsync selber einiges dazucoden? Ehrlich gesagt habe ich da nicht so viel Interesse dran...
 
Frisst duplicity bei jedem Backup-Vorgang bei dir soviel RAM oder nur bei Full Backups?
 
Die Full-Backups laufen nur 2x im Monat, es sind also die "normalen". Die Fulls habe ich noch gar nicht überprüft...
 
Das Problem hat duplicity bei mir momentan auch, vor paar Tagen wurde laut munin 700MB commited, entsprechend wurde geswappt und der Server reagierte kaum noch (Rootserver bei OVH).
 
Ist beir mir "nur" eine virtuelle Maschine, die dann gut vom Node gemaßregelt wird. Trotzdem ziemlich ärgerlich das Ganze. Zum Glück habe ich von Anfang an ein 2. Backupkonzept etabliert und muss jetzt nicht hektisch werden...

Weiss leider noch nicht, was ich damit mache, muss mir mal die letzten Updates ansehen, ob da was neues eingespielt wurde in Verbindung mit Python oder Duplicity. Vorher lief es ja.
 
So, nochmal Zeit gehabt, ein bisschen zu stöbern:

Also es ist wohl ein Memory Leak, dass auftritt. Je grösser die Anzahl der Files, desto eher wird der RAM gegessen. Anscheinend war das schon behoben und ist wieder eingebaut wurden (Regressionsbug).

Auf jeden Fall ist die Urasche klar und die Entwickler sind wohl dran. Mal sehen, wann eine aktualisierte Version in meinem Repository auftaucht:

https://bugs.launchpad.net/duplicity/+bug/908228
http://lists.gnu.org/archive/html/duplicity-talk/2012-01/msg00037.html

Der Fehler ist wohl ab 0.6.16 drin, 0.6.15 ist ok.
 
Last edited by a moderator:
Mittlerweile ist der Fehler behoben (Duplicity 0.6.18) und seit heute ist diese Version auch im EPEL stable verfügbar (für die Red Hat Ableger).

Allerdings hat sich eine Menge geändert, u. a. der Code für das SSH Backend. Ich musste, damit es wieder läuft, eine Datei aus dem Duplicity Paket patchen.

Nach 4 Jahren robuster Nutzung von Duplicity war das ein ziemlich düsteres Kapitel :(

Auf jeden Fall laufen die Backups nun wieder problemlos durch und knallen nicht auf dem Host den Swap voll.
 
You must log in or register to reply here.
Back
Top