Filesystemsicherung - Alternative zum tar-Befehl?

Ich muss ein grosses Unix-SunOS 5.8 Filesystem sichern, auf welches ständig zugegriffen wird während der Sicherung. Die Datenmenge ist gross, ca. 1GB, und zur Zeit dauert das Sichern mit dem tar-Befehl ca. 45 Minuten und verlangsamt die Applikation, mit welcher auf das Filesystem zugegriffen wird. Zudem kann ich mit dem tar-Befehl nicht inkrementell sichern (oder?). Gibt es einen anderen Befehl oder ein Tool, welches mir ermöglicht, Verzeichnisbäume und Daten effizienter zus sichern? Bin dankbar um jede Anregung oder Hilfe. Grüsse Tobi!

Hallo,

Ich muss ein grosses Unix-SunOS 5.8 Filesystem sichern, auf
welches ständig zugegriffen wird während der Sicherung.

Schlecht. Backups und gleichzeitiges Schreiben fuehrt fast zwangslaeufig zu inkonsistenten Staenden.

Die Datenmenge ist gross, ca. 1GB,

Das ist nicht gross.

und zur Zeit dauert das Sichern
mit dem tar-Befehl ca. 45 Minuten und verlangsamt die
Applikation, mit welcher auf das Filesystem zugegriffen wird.
Zudem kann ich mit dem tar-Befehl nicht inkrementell sichern
(oder?).

Doch:

$ tar --newer=$date $taropt 

sichert alle Dateien, die neuer als $date,

$ tar --newer=./lastbackup $taropt

alle, die neuer als die Datei ./lastbackup sind. Wenn es gar keine einzelnen Dateien sind, sondern eine grosse koennte rsync Dein Freund sein: das findet selbst innerhalb von binaries geaenderte Stellen und schiebt wirklich nur die Aenderungen ins Backup.

Bin dankbar um jede Anregung oder Hilfe. Grüsse Tobi!

Kommen bestimmt noch mehr,
Gruss vom Frank.

Doch:

$ tar --newer=$date $taropt

sichert alle
Dateien, die neuer als $date,

$ tar --newer=./lastbackup
$taropt

alle, die neuer als die Datei ./lastbackup sind.
Wenn es gar keine einzelnen Dateien sind, sondern eine grosse
koennte rsync Dein Freund sein: das findet selbst innerhalb
von binaries geaenderte Stellen und schiebt wirklich nur die
Aenderungen ins Backup.

falls die grosse datei aber zufaellig das datenfile einer datenbank ist, dann sollte man aus konsistenzgruenden dringend davon absehen. wenn rsync da in richtung dateiende kommt, hat der datawriter schon wieder vorne was veraendert.

man sollte uebrigens dringend bei der etablierung eines backupverfahrens mal einen disaster recovery drill durchfuehren und schauen, ob der restore innerhalb der avisierten downtime zu schaffen ist (auch extrapolieren, wie das bei gewachsenem datenbestand naechstes jahr aussieht) und ob die applikation danach noch tut oder wegen irgendwelchen inkonsistenzen nicht mehr hochkommt.

joachim