Re: Datensicherung mittels linux dd

From: Marc Santhoff <M.Santhoff(at)t-online.de>
Date: Tue, 23 Dec 2008 22:34:06 +0100

Am Dienstag, den 23.12.2008, 17:34 +0100 schrieb Oliver Fromme:
> Moin,

> Entscheidend ist natürlich, dass ein Backup "sicher" sein
> muss (sonst ist es kein Backup), und dass es möglichst
> bequem sein sollte, denn wenn es unbequem ist, macht man
> es zu selten.

Allerdings, das ist der Aspekt, an dem ich gerade feile.

> Marc Santhoff wrote:

> > Ich benutze aus alter Gewohnheit immer dump/restore. Irgendwann las ich
> > mal in einem Artikel, daß dies Pärchen bei einem Vergleich üblicher
> > Problemdateien wie z.B. geöffnet und gesperrt und ähnlich die höchste
> > Erfolgsquote haben soll.
>
> Was ist eine "gesperrte Datei"?

Eine, die mit flock(2) von einem Prozeß exclusiv gesperrt ist. Ist aber
nur ein Beispiel aus meiner Erinnerung, für konkretere Informationen
müßte ich den Artikel wiederfinden.

> Das einzige Problem sind Dateien, in die geschrieben wird,
> während das Backup läuft. Wenn nur am Ende angehängt wird
> (Logdateien, Mailfolder), fehlt im schlimmsten Fall am Ende
> der Datei etwas. Bei Random-Access (z.B. Datenbanken) kann
> man davon ausgehen, dass die Datei im Backup inkonsistent
> ist. Ob das schlimm ist oder nicht, hängt von der Anwen-
> dung ab, z.B. ist PostgreSQL erfahrungsgemäß härter im
> Nehmen als MySQL. Aber grundsätzlich gilt, dass Datenban-
> ken ohnehin mit spezialisierten Mitteln (im einfachsten
> Fall ein SQL-dump) gemacht werden sollten, nicht auf Datei-
> system-Ebene.

Keine Datenbanken im Spiel. Aber gut daran erinnert worden zu sein. :)

> > Auch da hilft dump & restore, mit "restore -rNf <backupdatei>" oder
> > vielleicht noch "gzip -cd <file> |" vorweg kann man die Lesbarkeit
> > testen.
> >
> > Auch hier frage ich mich: wie verläßlich ist das?
>
> Es ist ebenso verlässlich, insbesondere wenn die dump-
> Datei mit gzip komprimiert ist, weil gzip immer eine
> Prüfsumme einbaut. Nachteil ist natürlich, dass immer
> die gesamte dump-Datei dekomprimiert werden muss, auch
> wenn Du nur eine einzelne Datei aus dem Backup zurück-
> holen willst.

Kommt halt drauf an, wo die gesuchte Datei im Backup liegt. Folgendes
funktioniert:

zcat <datei.dump.gz> | restore -if -

ganz gut, ohne vorher extra "auszupacken". Wenn die gesuchten Dateien
ganz am Ende der komprimierten Eingabedatei sind braucht man natürlich
'ne Menge /tmp.

> Ganz früher habe ich auch regelmäßig dump und restore
> verwendet (ohne gzip; mein DAT- bzw. DDS-Streamer hat
> eh komprimiert), aber es ging mir schon ziemlich auf die
> Nerven, insbesondere wenn man nur eine einzelne Datei
> (oder ein Verzeichnis) zurückholen wollte und man sich
> durch die Bänder hangeln musste. Und wenn man Pech hatte
> und der Index beschädigt war, wurde es erst richtig lustig.
>
> Als ich dann mein Backup von Bändern auf Festplatten um-
> stellte (schneller, billiger, und nicht weniger sicher),
> schmiss ich auch dump+restore über Bord. Wenn ich jetzt
> eine Datei zurückspielen muss, dann stöpsel ich die Platte
> ein und tippe »cp -p /backup/foo /bar«, fertig. Und
> wenn's ein ganzes Verzeichnis ist, tippe ich cpdup statt
> cp. Das Anfertigen von Backups geht ähnlich einfach
> (bzw. durch kleine Skripte automatisiert, die auf der
> Backup-Platte ein Unterverzeichnis mit Datum anlegen).

Bei cpdup muß man ein bischen aufpassen, welchen Modus man wählt. Für
einen anderen Zweck benutze ich es auch mit -o für "nicht löschen, nur
überschreiben/hinzufügen".

Allerdings werden glücklicherweise Ordner nicht mit gleichnamigen
Dateien überschrieben. Und es kann sogar md5 Prüfsummen, sehe ich
gerade. :)

Marc

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 23 Dec 2008 - 23:08:38 CET

search this site