Re: Datensicherung mittels linux dd

Moin,

Eines sicherheitshalber vorweg: Bei Backup-Verfahren ist
es ein bisschen wie mit Programmiersprachen, Editoren,
Shells usw.: Jeder hat seine eigenen Vorlieben, und in
vielen Fällen kann man nicht sagen, dass eines "besser"
ist als das andere. Es ist auch zu einem Teil Gewohnheits-
sache.

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.

Marc Santhoff wrote:
> Oliver Fromme wrote:
> > Es schadet sicherlich auch nicht, solche Daten, die von
> > kritischer Wichtigkeit sind, ab und zu mal auf CD zu
> > brennen und an verschiedenen Orten aufzubewahren (ggf.
> > verschlüsselt).
>
> Und insbesondere bei CD oder DVD sollte man natürlich mindestens zwei
> Kopien erstellen. Und prüfen. Und mal ein anderes Laufwerk als das
> eigene zum Einlesen testen.
>
> Mit Fehlbränden und kaputten Laufwerken, deren Produkte kein anderes
> Gerät mehr lesen konnte, hatte ich es selbst schon zu tun.

100% Zustimmung. Unbedingt die CD/DVD mit einem anderen
Laufwerk prüfen als das, mit dem man sie gebrannt hat.
Am besten von einem anderen Hersteller, und noch besser
ein Laufwerk, das nur lesen kann (kein Brenner).

> > Ich persönlich verwende weder dd noch tar o.ä., sondern
> > lege auf den Sicherungs-Festplatten ein ganz normales
> > Dateisystem an (UFS2) und kopiere bzw. synchronisiere
> > die Dateien hinüber. Ich verwende hierfür das Tool
> > cpdup aus der Ports-Collection. Für Linux könntest Du
> > z.B. rsync nehmen; es gibt sicher noch weitere Tools,
> > die in Frage kämen.
>
> 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"?

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.

Eine andere Möglichkeit sind Snapshots: Man stoppt alle
Programme, die Schreibzugriffe machen, legt einen Snapshot
an, und startet sie dann wieder. Den (konsistenten) Snap-
shot kann man dann in Ruhe sichern. Wobei UFS2-Snapshots
auch ihre Tücken haben; ZFS-Snapshots scheinen besser zu
funktionieren.

Für den Desktop-Rechner eines Privatanwenders ist das in
der Regel alles ziemlich egal. Da kann man einfach "blind"
ein Backup ziehen und fertig. Mehr Aufwand muss man dann
investieren, wenn es um das Sichern von Servern geht (z.B.
die erwähnten Datenbanken), aber ich glaube, darum ging es
hier nicht. (Zum Thema Datenbank-Backup wurden auch schon
ganze Bücher gefüllt.)

> Wie stehen im Vergleich dazu (und auf modernen Dateisystemen) cpdup und
> rsync da?

Meiner Meinung nach sind unter diesem Aspekt alle Lösungen
gleich gut geeignet, mit der Ausnahme von dd(1), welches
man zwingend nur auf einem Dateisystem machen sollte, das
nicht schreibbar gemountet ist.

> > Übrigens: Du solltest auch regelmäßig die Sicherungen
> > testen. Absolutes Minimum ist, die Lesbarkeit der
> > Festplatten zu prüfen:
> >
> > # find /mountpoint -type f | xargs cat | wc
> >
> > Wenn man der Hardware nicht vertraut, dass sie Lese-
> > fehler verlässlich erkennt und meldet, kann man auch
> > Checksummen aller Dateien ermitteln und vergleichen.
> > Dazu kann man z.B. das Tool mtree(1) verwenden.
>
> 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.

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).

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"I invented Ctrl-Alt-Delete, but Bill Gates made it famous."
        -- David Bradley, original IBM PC design team
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message