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@suse.com For additional commands, e-mail: suse-linux-help@suse.com