Multi-Volume-Backup mit dump

juergen

Spielkind
Hallo,

eine Frage an die Backup-Experten:
Ich experimentiere gerade mit meinem neuen DLT-Laufwerk und möchte gerne eine dump-Sicherung auf Band speichern. Problem: Irgendwie klemmts mit der multi-volume-Unterstützung, da die Partition recht groß ist.
Der Rechner ist recht langsam, daher benutze ich mbuffer zum Puffern des Datenstroms (hängt per Pipe zwischen dump und Laufwerk).
Eines der beiden Tools verhaspelt sich beim Bandende, anstatt in Ruhe auf ein neu eingelegtes Band zu warten, spult das erste nur noch ständig hin und her (autsch).

Hat jemand schon prinzipiell mit multi-volume-Backups und dump erfolgreiche Sicherungen hinbekommen? Oder geht das mit tar und Konsorten leichter?

Sichern möchte ich meinen Fileserver, der hauptsächlich diverse home-Verzeichnisse enthält, keine Datenbanken (bis jetzt).

juergen
 
ich kenn dump/restore leider ueberhaupt nicht.

bei gnu tar gibt es aber die option -M die eigentlich genau fuer diese situation gedacht ist ;)

also, probier einfach mal ein
Code:
% gtar -M  cvf /dev/DEVICEBANDLAUFWERK /*
aus. wuerd mich auch interessieren.
 
also ein z.b.

dump -0au -L /einhängpunkt

läuft bei mir auf /dev/sa0 und will nen weiteres tape wenn das bereits benutze voll ist.
 
dump(8) funktioniert hier auch einwandfrei, wenn es selbst auf /dev/sa0 schreibt. Mit einer Pipe kann das jedoch nicht klappen, schliesslich kommt keinerlei Information zurueck, dass wir ein End-of-Tape haben.

Ich bezweifle ausserdem, dass ein zusaetzliches Programm hier die Geschwindigkeit erhoehen kann. Schau dir doch mal den Parameter -b fuer dump(8) an.
 
Ich bezweifle ausserdem, dass ein zusaetzliches Programm hier die Geschwindigkeit erhoehen kann. Schau dir doch mal den Parameter -b fuer dump(8) an.

Es geht mir nicht um die Geschwindigkeit, sondern darum, dass das DLT mit einem konstanten Datenstrom versorgt werden will. Häufige Stream-Abbrüche führen zum ständigen Starten und Stoppen des Laufwerks, was abgesehen von der längeren Backup-Dauer vor allem der Haltbarkeit des Laufwerks abträglich ist.

Das gute Stück will im optimalen Fall mit 5-10MB/s versorgt werden (je nach Kompression). Meine IDE-Platte liefert das nunmal nicht konstant, daher will ich einen möglichst großen Ringpuffer (150MB) verwenden, um ständige Stream-Abbrüche weitgehend zu vermeiden.

Das Caching von dump ist im übrigen leider ineffizient:
man dump(8) schrieb:
Beware that dump forks, and the actual memory use may be larger than the specified cache size.
 
mh also ich benutz jetzt dump schon ne weil mit DLT und nun sei einiger Zeit mit LTO-1/LTO-2 ... es läuft und läuft ...

selbst mit "Pseudo-Proffessionellen-Tools" like Backupexec hat man Einbrüche im Datenschaufeln.

Generell hatte ich bis jetzt eigentlich bis auf 2 Autoloader keine Verecker unter den Laufwerken. Und bei den Autoloadern denke ich das nach 3 Jahren intensiver benutzung schon mal etwas futsch gehen darf. Leider immer genau nach Ablauf der Garantie ... wird wohl kein Bug sondern ein Feature im Vertrieb sein.

Wenn du es hübsch automatisieren willst plus jede menge "Optionen" schau dir mal Bacula an.

*edit*

ähm Professionel ... aber ich habs gern mit jeder menge Buchstabensuppe! .. *duck*
 
Hallo ShekconTrebb,

an Bacula habe ich anfangs auch gedacht, aber für die Privatnutzung ist mir das zu mächtig.
Das DLT kommt im SOHO-Bereich zum Einsatz, ich mag schon eher umsichtig mit dem Teil umgehen.

Nach einigem Schmökern im Netz bin ich zum Schluss gekommen, es aufgrund der Probleme (gerade beim Puffern mittels zusätzlicher Software) lieber erstmal bei Single-Tape-Backups zu belassen. 35GB nativ sind ja auch nicht zu verachten.

Aber danke für alle Ratschläge!

jürgen
 
star kann mit einem Puffer arbeiten, konnte ich aufgrund der default-limits aber leider nur bis 512MB testen. Und selbst dann kommt tar nicht dem LTO-3 hinterher (ist ja auch klar, so ein Band laesst sich sehr schnell beschreiben).

Wenn du also mit den Unzulaenglichkeiten eines tar-Backup leben magst, schau dir mal star an.
 
Zurück
Oben