Post by Volker EnglischPost by Marcel MuellerPost by Volker EnglischFaszinierend. Mit tar läuft das Backup der großen Dateien problemlos und
schnell durch, und das Laufwerk schnurrt wie ein Kätzchen :)
Bei tar bitte auch auf die Blockgröße achten. Der Standard von 10kB ist
für LTO extrem schlecht geeignet. Viel zu klein.
Welche Blockgröße würdest du denn empfehlen? Bei 128kB war nur eine
minimale Verbesserung zu sehen.
Der Unterschied wäre eklatant, wenn die Kompression aktiviert wäre. Da
wir ja aus jedem Block _ein_ komprimierter Block dynamischer Länge. Es
geht also jedes mal die Lernfähigkeit der Huffman-Tabellen verloren.
Das ergibt bei Videos natürlich wenig Sinn. Aber für ein Systembackup
ist selbst die alte, und mäßig gute Hardwarekompression immer noch gut
verglichen mit dem, was man mit der CPU macht. Es ist ganz schön schwer,
die Datenrate für ein LTO-Band mit nur einem CPU-Kern aufrecht zu
erhalten. Bei LTO-2 mag das noch gehen. Bei 3 und 4 wird es echt eng.
Für bessere Komprimierer wie xz reicht es keinesfalls.
Post by Volker EnglischWie sieht das eigentlich aus, wenn man keine Default-Blockgröße
verwendet? Angenommen, das Band soll mal auf einem anderen OS oder mit
einem anderen Laufwerk zurückgespielt werden - klappt das ohne
Verrenkungen? Die verwendete Blockgröße hat man bis dahin bestimmt
vergessen, oder sie ist nicht mehr zu entziffern - Murphy's Law :)
Man kann mit größeren Blockgrößen lesen, aber nicht mit kleineren.
Das ist wie wenn du von einer Festplatte weniger als 512 Bytes haben
willst - geht nicht. Aber mehr ist kein Problem.
Dem OS ist die Blockgröße egal. Nicht einmal das Backupprogramm muss es
unbedingt können. Es ist das _Leseprogramm_ was es können muss.
Und tar hat halt in der Computersteinzeit irgendwann mal mit (damals
großzügigen) maximal 10k gearbeitet. Den Standard hat nie einer
geändert. Aber alle mir bekannten Implementierungen können auch mehr.
Wenn man natürlich mit einer alten SGI mit Uralt-Irix (im wesentlichen
System V) zurücksichern will, wird es eng.
Aber selbst dann würde es genügen, ein Pufferprogramm dazwischen zu
schalten, um die Daten doch noch lesen zu können. Tar selbst schreibt ja
keine Blöcke, sondern einen Byte-Stream. Nur der wird halt in Blöcken an
das OS übergeben. Und das kann es nicht einfach in größeren Blöcken an
das Band liefern. Und das Band wiederum hat keine Emulation, die
kleinere Blöcke per Read-Modify-Write schreiben könnte. Wohin also mit
den zu kurzen Daten? Es bleibt ihm nichts anderes als einen kleinen
physikalischen Block zu schreiben.
Post by Volker EnglischNachteil von tar gegenüber dump ist für mich das Rücksichern einzelner
Dateien. Von wegen "Ich habe gerade versehentlich eine Datei gelöscht,
die hieß irgendwas mit Quartal oder so". Bei dump rufe ich restore -i
auf, und kann dann mit cd und ls etc. durch die Sicherung blättern und
das passende File finden. Bei tar muss ich eigentlich ein tar -t und ein
grep mit einem möglichst passenden Muster anhängen. Das dauert dann aber
ein wenig :)
Ja, das ist so.
Lösung:
Beim Sichern tar -v in eine Datei umleiten, die Datum und dem Barcode
des Bandes im Namen trägt. Das schreibt alle gesicherten Dateinamen
nebst Pfad hinein. In der kann man dann nach dem genauen Namen gucken -
das erhöht die Trefferchance auf nahe 100% -, oder mit grep über alle
Dateien auch das passedne Band herausfinden.
Und falls die Dateien wirklich mal futsch sind, kann man sie aus dem
Bändern notfalls auch regenerieren. Faktisch sichere ich (die alten)
Dateien immer einfach mit. Für Desaster Recovery brauche ich also nur
das letzte Band von der Systemsicherung.
Marcel