Am Montag, 6. September 2010, 14:57:10 schrieb Björn Abheiden:
Hallo,
@Ronny und Bernhard: Vielen Dank
Das Problem ist, dass sich die ganze Situation doch etwas schwieriger gestaltet. Derzeit gibt es zig-Millionen kleine (proprietäre, binäre) Dateien, die gesichert werden müssen. Jeden Tag kommen einige Tausende hinzu. Aufgrund von Performance-Schwierigkeiten werden tägliche Backups so erstellt, dass eine MySQL-Datenbank nach neu angelegten Datensätzen befragt wird. Dort wird auch ersichtlich, welche Dateien hinzugekommen sind. Anschließend wird aus diesen Informationen eine Liste von Dateinamen generiert. Die Liste wird an tar übergeben (siehe vorherige E-Mail).
Ich werde bei den "vielen kleinen Dateien" hellwach. (Im Zusammenhang mit der geringen Backup-Leistung)
Wenn zwischen dd if=/dev/xyz of=/dev/null cat (xyz)/dir_abc/* find (xyz)/dir_abc -type f -print0 | xargs -0 rm -f
krasse Unterschiede bestehen (z.B. weil das Filsystem für Zugriff auf Refcounts zuviel Zeit braucht) dann muß man halt ein anderes FS wählen. Unter Linux gibt es ja genug Auswahl. (Das oben nur zur Verdeutlichung der Idee der Trennung Zugriff auf Dateiinhalt von OS/FS-Problemen.)
Lacher: Meine (30?)-zig Millionen Files (s. vorige Mail) zu löschen hat auf einem dicken RAID mit XFS an SCSI sage und schreibe 16 Stunden gedauert. (richtig geraten "nur" rm -rf dir_abc/)
Andere Richtung: Auch RAID ist bei regelmäßigen Backups nicht unbedingt ein muß.
Wenn nun eine Vollsicherung gemacht werden soll, braucht die Datenbank nicht befragt werden, aber alle Verzeichnisse und Unterverzeichnisse (mehrstufige Struktur) werden nach Dateien durchsucht. Auch leere Verzeichnisse müssen gesichert werden. rsnapshot läuft bei uns bereits und würde in einer Nacht nicht fertig werden, vom entfernten System die Daten zu beziehen. Daher werden die beschriebenen Sicherungsvorgänge alle auf dem entfernten System durchgeführt und nächtlich holt sich das externe Sicherungssystem die Daten, die bereits vorliegen. Das System ist eigentlich sehr schnell, darf aber durch Sicherungsvorgänge nicht ausgebremst werden. (16 GB RAM, 450 GB SAS-HDD 15krpm, Quad Core)
Mit Änderungen während eines Backupvorgangs muß man leben können (ggf. eben auch 2>/dev/null :-) ).
Leider lassen die Fehlermeldungen den gesamten Vorgang abbrechen, also ist danach die Sicherung nutzlos.
Klar, aber seltsam.
rsync meldet zwar, mit 2>/dev/null arbeitet es aber bei mir weiter.
Der Standpunkt "ignoriere Fehler" mag zwar nicht ganz politisch korrekt sein, aber praktisch durchaus brauchbar. (NB: bacula ist auch äußerst fehlertolerant. Es läuft also so lange wie irgend möglich annehmbar weiter. das auch mit manchmal verblüffenden Lösungen.)
Vielleicht fällt euch da noch etwas ein.
Dazu müßte ich das System mal in die Finger bekommen.
Gruß
Björn
Bernhard