Mailinglist Archive: opensuse-de (4938 mails)

< Previous Next >
Re: Ideale Backp-Loesung
  • From: weissel@xxxxxxxxxxxxx (Wolfgang Weisselberg)
  • Date: Fri May 12 21:12:36 2000
  • Message-id: <20000512231236.C1509@xxxxxxxxxxxxxxxxxxxxx>



Jan Stifter schrieb in 1,0K (39 Zeilen):

Hallo ListenLeserInnen,
Ich suche die ideale Backup-Loesung fuer:
* Server fuer Mail/Web/Dns/Ftp/Cvs

Wieviel MB an zu sichernden Daten?

* IDE-Tape HP Colorado 5GB
* Regelmaessige Backups woechentlich, Server kann fuer ca. 1h "down"
sein

Zu selten. Mindestens taegliche inkrementelle oder
differenzielle Sicherungen zusaetzlich.

Zudem ist eine Stunde IMHO zu kurz, um das Tape zu beschreiben
und testweise zurueckzulesen, vor allem, wenn du ein komplettes
System sicherst. Laut HP kann das Colorado 5GB '70 MB/min' ==
45 reale MB/Minute Maximum, also kannst du in der Stunde weniger
1.1 GB (reale Daten) sichern und zuruecklesen (Spoolzeiten
nicht vergessen! Zumal du am Anfang eine Retension machen
willst, die ca. 8-10 Minuten dauern duerfte).

Du kannst den Durchsatz durch Anwendung von Komprimierung
pushen. Dennoch wuerde ich hier Software-Komprimierung
vorziehen, dann kann jedes Laufwerk, dass die Baender lesen
kann, die Daten lesen. (HW-Komprimierung ist u.U. nicht
besonders kompatibel.)

(http://www.hp.com/cposupport/information_storage/support_doc/lpg10885.html)

* Die Backups sollten ALLES draufhaben, so dass bei einem crash
lediglich der backup aufgespult werden muss

Was den Zeitfaktor erheblich unterstreicht. (Hinweis: 10k+
Dateien in einem Verzeichnis *ist* ein langsamer Dateizugriff.)

Anhand Studium des Archivs sehe ich mehrere Moeglichkeiten:

- tar / mt
nachteile:
* file-zugriff nicht moeglich (wenn ich /ein/file/hier zurueckspulen
moechte)

Doch, einfach so lange durch das Archiv roedeln, bis du das
File hast.

* bei nur einem falschen byte auf dem tape ist das ganze archiv
unbrauchbar

Nur bei Komprimierung. Dabei ist die Groesse des Tapes eine
Frage. (5 GB == 2.48 GB realer Platz vor Komprimierung?)

- afio
kenn ich nicht. erfahrungen?

Ja. Wie cpio, nur besser. Kann u.a. per-File-Komprimierung,
Start im Archiv an beliebiger Stelle (-vB gibt dir die
Startpositionen der Files aus), ...

- cpio
ist momentan meine wahl. hat jemand skripte, mit denen er den

- dump/restore
vorteil:
* inkrementelle backups moeglich

Integrierte Shell zur Auswahl der zurueckzuschreibenden
Files/Dirs.

Sichert Directory-Info am Anfang der Daten.

Nachteile: Kann nicht (unbedingt) sauber ueber (Archiv ==
Tape)-Grenzen hinweg sichern, dies ist moeglicherweise
mitlerweile behoben (dump wird wieder aktiv entwickelt,
neueste Version IIRC 0.4b16 (http://dump.sourceforge.net))

Meine persoenliche Vorstellung:

1. Testen, ob LVM auf diesem Server stabil genug ist (vor
allem snapshot -- bei mir mag es reiserfs nicht und auch
nicht kleine Bloecke (64k ist der Default fuer snapshots,
der scheint in Ordnung)).

2. Server bis auf kleines / (IMHO) und /boot auf LVM umstellen.

3. Zum Backup: Snapshots generieren, / und /boot sollten
sich kaum aendern. Die Snapshots halten, bis der Platz
durch Aenderungen im realen FS verbraucht ist (never,
wenn snapshot-Groesse == FS-Groesse) oder bis zum reboot).

4. Backups werden (geg.) nicht direkt auf Band geschrieben,
sondern erst auf Platte erstellt (3 GB hast du sicher noch
extra Platz, oder?) und dann auf Band migriert. Damit ist
selbst ohne snapshots der Zeitrahmen bei (maximal maessiger)
Komprimierung machbar, denn die Migration ist im laufenden
Betrieb machbar. Zudem hast du das Backup auch nochmal
auf Platte -- bis zur naechsten Backup-Generierung.

5. Haeufig differentielle oder inkrementelle Backups:
find ... \( -newer $stampfile -or -cnewer $stampfile \) \
-and -print0 | ...
Diese werden in eine (eigene, kleine, nach dem Datum und
dem Level benannte LVM-)Partition geschrieben. Und auf ein
'immer im Laufwerk' Band migriert. Geht schnell, kostet
wenig, ist zwar nicht sicher gegen Wasser/Feuer/Diebstahl,
aber gegen User Error und tote Platten.

(man beachte das -print0 !)

-Wolfgang

---------------------------------------------------------------------
To unsubscribe, e-mail: suse-linux-unsubscribe@xxxxxxxx
For additional commands, e-mail: suse-linux-help@xxxxxxxx

< Previous Next >
References