RootForum Community

Hallo,

ich würde gern von euren Erfahrungen hören, so dass ich meine jetzigen Ã?berlegungen und Umsetzungen einmal schildere:
Auf dem Rootserver laufen ca. 20-25 Webseiten, deren Größen von wenigen KBs zu 1-3 GB reichen. Diese Webseiten werden durch ein Backup-Skript wie Reoback oder ESR Backup in der Nacht bzw. am frühen morgen inkrementell gesichert. Diese Sicherungen landen kann auf einem über 300GB großen FTP-Backup-Space. Aus Performance-Gründen verzichte ich auf eine Komprimierung der Archive (gz oder bzip2) und erzeuge nur unkomprimierte Archive. Soweit klappt das sehr gut und zuverlässig.

Es existiert jedoch noch eine Webseite, die eine Größe von über 30GB aufweist. Auch hier wird nichts komprimiert, da die meisten Daten sowieso JPG-Bilder sind. Nichtdestotrotz erzeugt der Backup-Job hier eine so hohe Systemlast, dass insbesondere der Webserver in der Zeit des Backups praktisch unbenutzbar träge wird.
Ich denke nicht, dass es dafür direkt eine Lösung gibt, sondern Suche nach einer alternativen Strategie zur Sicherung dieser Webseite per FTP.

Welche funktionierenden Ideen habt ihr dazu? Aufteilen der Sicherung auf verschiedene Teilbereiche der Seite zu verschiedenen Zeiten? Gibt es eine Möglichkeit, die Seite direkt per FTP zu spiegeln (Stichwort: sitecopy)?

Gibt es möglicherweise noch sinnvolle Alternativen zu reoback oder ESR Backup, welche ohne lokal vorgehaltene Sicherung auf dem Server (backup2l) funktionieren?

Schon einmal Danke für die Infos und die Hilfe. Gruß, Vevelt.

Wieso stellst du nicht einfach die Prozess Priorität mit nice oder so runter.
Dann würde das BackUp zwar länger dauern aber im "hintergrund" laufen.

Ich finde es auch nit grade sinnvoll solche Datenmengen unkomprimiert zu verschicken.

aubergine wrote:Wieso stellst du nicht einfach die Prozess Priorität mit nice oder so runter.
Dann würde das BackUp zwar länger dauern aber im "hintergrund" laufen.

Habe ich auch schon überlegt, aber dann ist doch die Wahrscheinlichkeit größer, dass die Daten zwischenzeitlich verändert werden und somit Dateien in der Sicherung auftauchen, die zusammen nicht mehr funktionieren... ich werd es aber bestimmt mal ausprobieren und mir die Laufzeiten ansehen.

aubergine wrote: Ich finde es auch nit grade sinnvoll solche Datenmengen unkomprimiert zu verschicken.

Wie schon gesagt: 30GB JPG-Bilder komprimieren gerade mal 0,xx Prozent, dafür steigt die Laufzeit um ein Vielfaches... ich glaube, ich weiss schon, warum ich diese Datenmengen nicht mehr komprimiere... :-)

hiho,

produzieren die etwa 30 GB _neue_ Daten jeden Tag?

ich wuerde an Deiner Stelle ueber rsync nachdenken, dabei werden 2 Strukturen miteinander verglichen und immer nur die Veraenderten Daten abgeglichen. Allerdings hast Du da das Problem, dass Du da ueber die Server Integritaet nachdenken musst ;)

greetZ
Cat

Cat wrote: produzieren die etwa 30 GB _neue_ Daten jeden Tag?

Nein, zum Glück nicht. Da kommen wohl so ca. 20GB im Jahr dazu... es sind aber die Fullbackups, die den Server lahmlegen können... :-(

Cat wrote: ich wuerde an Deiner Stelle ueber rsync nachdenken, dabei werden 2 Strukturen miteinander verglichen und immer nur die Veraenderten Daten abgeglichen. Allerdings hast Du da das Problem, dass Du da ueber die Server Integritaet nachdenken musst ;)

Ok, rsync funktioniert aber nicht mit FTP, oder? Da sollte ich mir dann wohl wirklich auch mal sitecopy genauer ansehen...

aubergine wrote:Wieso stellst du nicht einfach die Prozess Priorität mit nice oder so runter.
Dann würde das BackUp zwar länger dauern aber im "hintergrund" laufen.

Soweit ich das bis jetzt probiert habe, könnte das tatsächlich eine probate Lösung sein. So könnte der Backup-Prozess komplett im Hintergrund laufen. Das dauert dann wohl ein paar Stunden, aber solange das beinahe unsichtbar läuft, ist das ja kein Problem... bin gespannt, wie lange es wirklich läuft.

Wenn es nur um die Bilder geht:

Alle einmal per FTP inkl. Verzeichnisstruktur auf den Backupspace kopieren (ohne Tar, jede Datei einzelnt inkl. Verzeichnis) und dabei einen index der Dateien erstellen. Bei jedem Lauf nachschauen, welche Bilder sich verändert haben und nur diese einzelnt auf dem Backupplatz schieben (oder von dort löschen).