Am Montag, 6. September 2010, 12:07:55 schrieb Björn Abheiden:
Hallo Liste,
derzeit versuche ich die Backup-Funktionen auf einem unserer Server zu optimieren. Bei einem Voll-Backup wird zunächst mittels »find« eine Dateiliste erstellt, welche anschließen über »tar --files-from <DATEILISTE>« eingelesen wird.
... Ronny hat schon das wichtigste gesagt.
Zuerst mußt Du rausbekommen, woher die "grottige" Schreibleistung kommt.
Für eine Vollsicherung von knapp 250 GB Daten haben wir mit dieser Methode 56 Stunden berechnet.
Toll. Das sind 4,5 GB/h oder 1.2 MB/s. Das ist eine Stelle wo ich ernsthafte Fragen habe. 10-30 MB/s Schreibleistung kann man schon erwarten.
Thema "richtige" Software: Ich verwende wie Ronny bacula ebenfalls, kann aber von der "mal eben so" Verwendung nur abraten. (s.u.) Letztlich ist bacula eine Datenbank, die im Umfeld von (auch netzwerkmäßig verteilbaren) Kopiervorgängen festhält, was, wann, wo und wie passiert. Bei Einsatz sollte man sich mit den entsprechenden Sprachregelungen schon sehr gut vertraut machen und die eigenen Absichten klar benennen können.
Beispiel zur geringen Schreibleistung: Bei Einsatz von bacula könntest Du mit so was Schwierigkeiten bekommen. Dort werden die Jobs "gestapelt". Ich hatte mal den Fall, daß ein full-backup zu langsam war, das für den nächsten Tag geplante differential-backup das (fertige) full als Bezug nicht fand und daraufhin wiederum seinerseits ein full-backup anschob etc.etc. Dort die Notbremse zu ziehen, war schwer, weil die verwendete Datenbank (sqlite) bei der Gelegenheit auch überlief. (Jemand hatte für Tests einfach ein paar -zig Millionen kleine Dateien erzeugt.)
Zitat Ronny:
Alternatv, wenns schnell gehen soll biete sich rsync an, wozu es mit rsnapshot ne ressourcensparende fast fertige Lösung gibt - vllt. ist das genau der richtige Einstieg für Dich sofern Dein Ziel irgendwie unixoid ist.
+=1 (Zusammen mit Hardlinks kann man da eine Menge anfangen.)
Ziat Ronny:
Das kann man Pauschal nicht beantworten. Mnache arbeiten mit Snapshots von den zu sichernden Volumes, sie frieren also die Partition quasi ein, sichern den "Eiswürfel" während das OS in einen "Zwischenspeicher" arbeitet. Das muss aber das OS bzw. Storage unterstützen.
Echte Snapshots von Dateisystemen sind unter Linux IMHO die Ausnahme. (XFS kann's?) Mit Änderungen während eines Backupvorgangs muß man leben können (ggf. eben auch 2>/dev/null :-) ).
Thema *.zip Das ist ein tradeoff, den ich in letzter Zeit immer mehr gegen zip entscheide. Die meisten "Platzkiller" sind schon recht gut gepackt (*.avi, *jpg, *.mp3). Für andere Dateien (Text, html etc. verstellt man sich sich mit zip die rsync- Möglichkeit.)
Bisher unerwähnt: Datenintegrität. DAS ist m.E. ein viel zu leicht genommenes Thema, sei es das die Daten auf dem origininalen Datenträger oder dem Backup-Medium korrumpiert sind/werden. (Ich hatte mal einen bacula-restore Fall, der letztlich ein HD-Problem aufzeigte.)
Bernhard