info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: Bandlaufwerk und grosse Dateien
3 views
Skip to first unread message
Sebastian Suchanek
Dec 8, 2021, 3:21:41 PM12/8/21
to
Am 08.12.2021 um 18:46 schrieb Volker Englisch:
> [Backup auf LTO2]
> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
> rund 24 (!) Stunden brauchen.
>
> Gibts für dieses Verhalten eine plausible Erklärung?
Hmm - mit dump habe ich keine Erfahrung. Was passiert, wenn Du
stattdessen tar benutzt? Was sagen top und iotop, während dump sich mit
den Videodateien quält?
Tschüs,
Sebastian
> [Backup auf LTO2]
> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
> rund 24 (!) Stunden brauchen.
>
> Gibts für dieses Verhalten eine plausible Erklärung?
Hmm - mit dump habe ich keine Erfahrung. Was passiert, wenn Du
stattdessen tar benutzt? Was sagen top und iotop, während dump sich mit
den Videodateien quält?
Tschüs,
Sebastian
Martin Klaiber
Dec 9, 2021, 4:08:10 AM12/9/21
to
Volker Englisch <vne_u...@rsli.de> wrote:
> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
> rund 24 (!) Stunden brauchen.
> Gibts für dieses Verhalten eine plausible Erklärung?
Könnte es "shoe-shining" sein?
> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
> rund 24 (!) Stunden brauchen.
> Gibts für dieses Verhalten eine plausible Erklärung?
https://searchdatabackup.techtarget.com/definition/shoeshining-or-backhitching
https://unix.stackexchange.com/questions/398179/my-lto-tape-drive-is-slow-and-shoe-shines-on-freebsd
Gruß
Martin
Marcel Mueller
Dec 9, 2021, 6:08:35 AM12/9/21
to
Am 08.12.21 um 18:46 schrieb Volker Englisch:
> Nochmal ich :) Mit einem "neuem" Laufwerk ist es mir doch gelungen, an
> meinem Server wieder eine Bandsicherung einzurichten (LTO-2 an SCSI auf
> NetBSD).
>
> Bei der Sicherung "üblicher" Dateien (was auf einem "Datenlaufwerk" so
> herumliegt) funktioniert es und das Bandlaufwerk läuft gleichmäßig.
Die Frage ist, warum.
Irgendetwas in deinem Setup ist *viel* zu langsam für den Streamer. LTO
kann ja normalerweise die Geschwindigkeit an den Pufferzustand anpassen.
Offenbar schafft der Rechner ab nicht einmal die Mindestdatenrate.
Normalerweise verwende ich bei LTO und DLT immer einen großzügigen FIFO
vor dem Tape device. Aus dem wird dann per fester Blockgröße - darauf
stehen die Tapes - an das Laufwerk übertragen.
Blockgröße mindestens 256kB aber auch bei LTO nicht mehr als 1 MB.
Und die Puffergröße sollte wenigstens für 30s Streaming reichen.
Damit kann der Streamer theoretisch schon nur noch alle 30s anhalten,
praktisch eher alle ein, zwei Minuten, weil der Quelldatenstrom ja
üblicherweise nicht vollständig versiegt.
Natürlich sollte man das primäre Ziel, dass die Quelle die Daten in
ausreichender Geschwindigkeit für den Streamer liefert, nicht aus den
Augen verlieren. Bei LTO gelingt mir das auch fast immer, also er hält
nur bei den Richtungswechseln an. Aber gegen in manchen Situationen mal
wackelige Datenraten hilft die Vorgehensweise alle mal.
Marcel
> Nochmal ich :) Mit einem "neuem" Laufwerk ist es mir doch gelungen, an
> meinem Server wieder eine Bandsicherung einzurichten (LTO-2 an SCSI auf
> NetBSD).
>
> Bei der Sicherung "üblicher" Dateien (was auf einem "Datenlaufwerk" so
> herumliegt) funktioniert es und das Bandlaufwerk läuft gleichmäßig.
>
> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
> rund 24 (!) Stunden brauchen.
>
> Gibts für dieses Verhalten eine plausible Erklärung?
Ja, die Puffer laufen leer. ;-)
> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
> rund 24 (!) Stunden brauchen.
>
> Gibts für dieses Verhalten eine plausible Erklärung?
Die Frage ist, warum.
Irgendetwas in deinem Setup ist *viel* zu langsam für den Streamer. LTO
kann ja normalerweise die Geschwindigkeit an den Pufferzustand anpassen.
Offenbar schafft der Rechner ab nicht einmal die Mindestdatenrate.
Normalerweise verwende ich bei LTO und DLT immer einen großzügigen FIFO
vor dem Tape device. Aus dem wird dann per fester Blockgröße - darauf
stehen die Tapes - an das Laufwerk übertragen.
Blockgröße mindestens 256kB aber auch bei LTO nicht mehr als 1 MB.
Und die Puffergröße sollte wenigstens für 30s Streaming reichen.
Damit kann der Streamer theoretisch schon nur noch alle 30s anhalten,
praktisch eher alle ein, zwei Minuten, weil der Quelldatenstrom ja
üblicherweise nicht vollständig versiegt.
Natürlich sollte man das primäre Ziel, dass die Quelle die Daten in
ausreichender Geschwindigkeit für den Streamer liefert, nicht aus den
Augen verlieren. Bei LTO gelingt mir das auch fast immer, also er hält
nur bei den Richtungswechseln an. Aber gegen in manchen Situationen mal
wackelige Datenraten hilft die Vorgehensweise alle mal.
Marcel
Volker Englisch
Dec 9, 2021, 1:08:07 PM12/9/21
to
dann berichten.
Volker Englisch
Dec 9, 2021, 1:08:07 PM12/9/21
to
Marcel Mueller schrieb am Do., 09 Dez. 2021 um 11:08 GMT:
> Am 08.12.21 um 18:46 schrieb Volker Englisch:
>> Nochmal ich :) Mit einem "neuem" Laufwerk ist es mir doch gelungen, an
>> meinem Server wieder eine Bandsicherung einzurichten (LTO-2 an SCSI auf
>> NetBSD).
>>
>> Bei der Sicherung "üblicher" Dateien (was auf einem "Datenlaufwerk" so
>> herumliegt) funktioniert es und das Bandlaufwerk läuft gleichmäßig.
>>
>> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
>> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
>> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
>> rund 24 (!) Stunden brauchen.
>>
>> Gibts für dieses Verhalten eine plausible Erklärung?
>
> Ja, die Puffer laufen leer. ;-)
> Die Frage ist, warum.
Vor allem eben, weil das *nur* bei sehr großen Dateien passiert.
> Am 08.12.21 um 18:46 schrieb Volker Englisch:
>> Nochmal ich :) Mit einem "neuem" Laufwerk ist es mir doch gelungen, an
>> meinem Server wieder eine Bandsicherung einzurichten (LTO-2 an SCSI auf
>> NetBSD).
>>
>> Bei der Sicherung "üblicher" Dateien (was auf einem "Datenlaufwerk" so
>> herumliegt) funktioniert es und das Bandlaufwerk läuft gleichmäßig.
>>
>> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
>> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
>> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
>> rund 24 (!) Stunden brauchen.
>>
>> Gibts für dieses Verhalten eine plausible Erklärung?
>
> Ja, die Puffer laufen leer. ;-)
> Die Frage ist, warum.
> Irgendetwas in deinem Setup ist *viel* zu langsam für den Streamer. LTO
> kann ja normalerweise die Geschwindigkeit an den Pufferzustand anpassen.
> Offenbar schafft der Rechner ab nicht einmal die Mindestdatenrate.
kontinuierlicher zu streamen sein als viele kleine.
> Normalerweise verwende ich bei LTO und DLT immer einen großzügigen FIFO
> vor dem Tape device. Aus dem wird dann per fester Blockgröße - darauf
> stehen die Tapes - an das Laufwerk übertragen.
einlesen.
> Blockgröße mindestens 256kB aber auch bei LTO nicht mehr als 1 MB.
hat allerdings nichts gebracht.
Wenn ich nur verstehen könnte, warum das *nur* bei den großen Dateien
passiert...
Volker Englisch
Dec 9, 2021, 1:08:07 PM12/9/21
to
Martin Klaiber schrieb am Do., 09 Dez. 2021 um 08:47 GMT:
> Volker Englisch <vne_u...@rsli.de> wrote:
>
>> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
>> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
>> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
>> rund 24 (!) Stunden brauchen.
>
>> Gibts für dieses Verhalten eine plausible Erklärung?
>
> Könnte es "shoe-shining" sein?
Natürlich. Die Frage ist halt nur, warum das nur bei großen Dateien
> Volker Englisch <vne_u...@rsli.de> wrote:
>
>> Auf dem Server liegen aber auch Videodateien mit einer Größe von über 1
>> GB. Und beim Sichern dieser geht es los: Das Bandlaufwerk zeigt das
>> berüchtigte Start-/Stop-Verhalten, und "dump" will für ca. 80 GB Daten
>> rund 24 (!) Stunden brauchen.
>
>> Gibts für dieses Verhalten eine plausible Erklärung?
>
> Könnte es "shoe-shining" sein?
passiert.
Volker Englisch
Dec 10, 2021, 5:08:07 AM12/10/21
to
Sebastian Suchanek schrieb:
Faszinierend. Mit tar läuft das Backup der großen Dateien problemlos und
schnell durch, und das Laufwerk schnurrt wie ein Kätzchen :)
Da die Videodateien eh nicht jedes Mal mitgesichert werden müssen, werde
ich das splitten: Bei Bedarf die großen Files mit tar, und das
regelmäßige Backup mit dump.
Danke für die Idee, es mit tar zu versuchen.
V.
schnell durch, und das Laufwerk schnurrt wie ein Kätzchen :)
Da die Videodateien eh nicht jedes Mal mitgesichert werden müssen, werde
ich das splitten: Bei Bedarf die großen Files mit tar, und das
regelmäßige Backup mit dump.
Danke für die Idee, es mit tar zu versuchen.
V.
Marcel Mueller
Dec 12, 2021, 4:40:06 AM12/12/21
to
Am 09.12.21 um 18:29 schrieb Volker Englisch:
unfragmentiert sind. Je nach Dateisystem und Aufzeichnungsprogramm kann
es z.B. passieren, dass wen zwei parallele Aufzeichnungen laufen, die
komplett zu Hackfleisch werden.
Eine andere Sache sind Platten-Caches. Manche Programme bzw. Caches
stellen sich etwas dumm an und versuchen große Dateien erst mal in den
Cache zu lesen. Wenn das dann nicht klappt, passieren lustige Dinge.
Entweder werden andere wichtige Daten verdrängt oder aber der Cache wird
dafür komplett deaktiviert. Beides könnte das beobachtete Verhalten
erklären.
Um näheres zu ergründen, müsste man erst mal wissen, wie dump intern
arbeitet - ich habe es nie benutzt.
>> Normalerweise verwende ich bei LTO und DLT immer einen großzügigen FIFO
>> vor dem Tape device. Aus dem wird dann per fester Blockgröße - darauf
>> stehen die Tapes - an das Laufwerk übertragen.
>
> Okay, das ist im Moment Neuland für mich, ich werde mich da mal
> einlesen.
Bei den Bandlaufwerken werden die Blockgrößen so wie die Schreibbefehle
über den Bus kommen aufs Band geschrieben. Falls aktiviert, werden sie
vorher noch komprimiert, aber eben immer nur ein Block auf einmal, sonst
könnte man ja nie mehr mitten drin anfangen zu lesen. Außerdem braucht
man das für Spul-Befehle zu einer bestimmten Blocknummer. (Benutzt das
noch jemand?)
Marcel
>> Die Frage ist, warum.
>
> Vor allem eben, weil das *nur* bei sehr großen Dateien passiert.
>
>> Irgendetwas in deinem Setup ist *viel* zu langsam für den Streamer. LTO
>> kann ja normalerweise die Geschwindigkeit an den Pufferzustand anpassen.
>> Offenbar schafft der Rechner ab nicht einmal die Mindestdatenrate.
>
> Aber eben nur bei großen Dateien. Dabei sollten die doch eigentlich
> kontinuierlicher zu streamen sein als viele kleine.
Falls die Quelle eine echte HDD ist, theoretisch ja, falls sie wirklich
>
> Vor allem eben, weil das *nur* bei sehr großen Dateien passiert.
>
>> Irgendetwas in deinem Setup ist *viel* zu langsam für den Streamer. LTO
>> kann ja normalerweise die Geschwindigkeit an den Pufferzustand anpassen.
>> Offenbar schafft der Rechner ab nicht einmal die Mindestdatenrate.
>
> Aber eben nur bei großen Dateien. Dabei sollten die doch eigentlich
> kontinuierlicher zu streamen sein als viele kleine.
unfragmentiert sind. Je nach Dateisystem und Aufzeichnungsprogramm kann
es z.B. passieren, dass wen zwei parallele Aufzeichnungen laufen, die
komplett zu Hackfleisch werden.
Eine andere Sache sind Platten-Caches. Manche Programme bzw. Caches
stellen sich etwas dumm an und versuchen große Dateien erst mal in den
Cache zu lesen. Wenn das dann nicht klappt, passieren lustige Dinge.
Entweder werden andere wichtige Daten verdrängt oder aber der Cache wird
dafür komplett deaktiviert. Beides könnte das beobachtete Verhalten
erklären.
Um näheres zu ergründen, müsste man erst mal wissen, wie dump intern
arbeitet - ich habe es nie benutzt.
>> Normalerweise verwende ich bei LTO und DLT immer einen großzügigen FIFO
>> vor dem Tape device. Aus dem wird dann per fester Blockgröße - darauf
>> stehen die Tapes - an das Laufwerk übertragen.
>
> Okay, das ist im Moment Neuland für mich, ich werde mich da mal
> einlesen.
über den Bus kommen aufs Band geschrieben. Falls aktiviert, werden sie
vorher noch komprimiert, aber eben immer nur ein Block auf einmal, sonst
könnte man ja nie mehr mitten drin anfangen zu lesen. Außerdem braucht
man das für Spul-Befehle zu einer bestimmten Blocknummer. (Benutzt das
noch jemand?)
Marcel
Marcel Mueller
Dec 12, 2021, 4:48:35 AM12/12/21
to
Am 10.12.21 um 10:47 schrieb Volker Englisch:
für LTO extrem schlecht geeignet. Viel zu klein.
Mehr ist theoretisch nicht tar Standard-konform. Faktisch können aber
schon lange nahezu alle verbreiteten tar-Versionen größere Blöcke. Gnu
tar sowieso.
Ich kann nur das Schily-tar (star) empfehlen, was jede Menge
Zusatzfeatures hat. Darunter ein eingebauter, geeigneter FIFO. Und es
schreibt die Bonus-Features in einer Weise, dass es Lesekompatibel zum
normalen tar bleibt, so dass ein Desaster-Recovery mit nahezu jedem
Linux Boot-Image auch ohne star gelingt.
Leider bekommt man das nicht aus den gängigen Repositories, sondern muss
es selber kompilieren, was ein paar Dependencies nach sich zieht. Und
der Urheber ist kürzlich verstorben. Ich weiß gar nicht, wer das jetzt
weiter führt. Aber eigentlich ist das ausgereift und braucht praktisch
keine Änderungen mehr.
Marcel
> Faszinierend. 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
> schnell durch, und das Laufwerk schnurrt wie ein Kätzchen :)
für LTO extrem schlecht geeignet. Viel zu klein.
Mehr ist theoretisch nicht tar Standard-konform. Faktisch können aber
schon lange nahezu alle verbreiteten tar-Versionen größere Blöcke. Gnu
tar sowieso.
Ich kann nur das Schily-tar (star) empfehlen, was jede Menge
Zusatzfeatures hat. Darunter ein eingebauter, geeigneter FIFO. Und es
schreibt die Bonus-Features in einer Weise, dass es Lesekompatibel zum
normalen tar bleibt, so dass ein Desaster-Recovery mit nahezu jedem
Linux Boot-Image auch ohne star gelingt.
Leider bekommt man das nicht aus den gängigen Repositories, sondern muss
es selber kompilieren, was ein paar Dependencies nach sich zieht. Und
der Urheber ist kürzlich verstorben. Ich weiß gar nicht, wer das jetzt
weiter führt. Aber eigentlich ist das ausgereift und braucht praktisch
keine Änderungen mehr.
Marcel
Volker Englisch
Dec 13, 2021, 1:08:08 PM12/13/21
to
Marcel Mueller <news.5...@spamgourmet.org> schrieb:
minimale Verbesserung zu sehen.
Wie 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 :)
> Ich kann nur das Schily-tar (star) empfehlen, was jede Menge
> Zusatzfeatures hat. Darunter ein eingebauter, geeigneter FIFO. Und es
> schreibt die Bonus-Features in einer Weise, dass es Lesekompatibel zum
> normalen tar bleibt, so dass ein Desaster-Recovery mit nahezu jedem
> Linux Boot-Image auch ohne star gelingt.
Ich habe mir star mal heruntergeladen und installiert, war ja kein
Hexenwerk. Ich werde es mal damit probieren.
Nachteil 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 :)
V.
> Am 10.12.21 um 10:47 schrieb Volker Englisch:
>> Faszinierend. 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
>> Faszinierend. 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.
minimale Verbesserung zu sehen.
Wie 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 :)
> Ich kann nur das Schily-tar (star) empfehlen, was jede Menge
> Zusatzfeatures hat. Darunter ein eingebauter, geeigneter FIFO. Und es
> schreibt die Bonus-Features in einer Weise, dass es Lesekompatibel zum
> normalen tar bleibt, so dass ein Desaster-Recovery mit nahezu jedem
> Linux Boot-Image auch ohne star gelingt.
Hexenwerk. Ich werde es mal damit probieren.
Nachteil 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 :)
V.
Marcel Mueller
Dec 14, 2021, 3:10:27 AM12/14/21
to
Am 13.12.21 um 18:51 schrieb Volker Englisch:
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.
> Wie 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.
> Nachteil 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
> Marcel Mueller <news.5...@spamgourmet.org> schrieb:
>> Am 10.12.21 um 10:47 schrieb Volker Englisch:
>>> Faszinierend. 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
>> Am 10.12.21 um 10:47 schrieb Volker Englisch:
>>> Faszinierend. 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.
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.
> Wie 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 :)
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.
> Nachteil 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 :)
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
Volker Englisch
Dec 15, 2021, 1:08:07 PM12/15/21
to
Marcel Mueller schrieb am Di., 14 Dez. 2021 um 08:10 GMT:
> Am 13.12.21 um 18:51 schrieb Volker Englisch:
>> Marcel Mueller <news.5...@spamgourmet.org> schrieb:
>>> Am 10.12.21 um 10:47 schrieb Volker Englisch:
>>>> Faszinierend. 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.
Welche Blockgröße verwendest du bei tar?
> Am 13.12.21 um 18:51 schrieb Volker Englisch:
>> Marcel Mueller <news.5...@spamgourmet.org> schrieb:
>>> Am 10.12.21 um 10:47 schrieb Volker Englisch:
>>>> Faszinierend. 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.
und die Sicherung läuft nachts, da sollte es eigentlich auch für -3
reichen. Oder nicht?
> 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.
verschiedene BSD-Varianten.
> 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.
Archiv ist. Mir persönlich dünkt dump/restore da schneller, dafür ist
tar wahrscheinlich kompatibler.
V.
Sebastian Suchanek
Dec 15, 2021, 3:31:42 PM12/15/21
to
Am 15.12.2021 um 18:41 schrieb Volker Englisch:
> Marcel Mueller schrieb am Di., 14 Dez. 2021 um 08:10 GMT:
>>
>> [...]
> Marcel Mueller schrieb am Di., 14 Dez. 2021 um 08:10 GMT:
>>
>> 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.
>
> Das Gefühl hatte ich mit LTO-3 auch schon. Mein Server hat zwei Kerne,
> und die Sicherung läuft nachts, da sollte es eigentlich auch für -3
> reichen. Oder nicht?
> [...]
>> 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.
>
> Das Gefühl hatte ich mit LTO-3 auch schon. Mein Server hat zwei Kerne,
> und die Sicherung läuft nachts, da sollte es eigentlich auch für -3
> reichen. Oder nicht?
Hier[tm] hängt u.a. ein LTO4-Streamer an einem Xeon E3-1225v5. Als
Software verwende ich Bacula, was meines Wissens nach hinter den
Kulissen tar verwendet. Der schafft bei einigermaßend passenden Dateien
(JPEGs mit ~10-15MB) über den dicken Daumen 100MB/s - allerdings glaube
ich, dass da (auch) die HDDs, von denen die Daten kommen, einen
Flaschenhals darstellen.
Software-Kompression verwende ich nicht (bei der Hardware-Kompression
weiß ich gerade selbst nicht, ob die eingeschaltet ist), allerdings
Software-Verschlüsselung.
In dieser Konstellation lastet ein Backup-Job einen der vier Kerne
komplett aus, die anderen Kerne haben aber quasi nichts zu tun.
Tschüs,
Sebastian
Marcel Mueller
Dec 15, 2021, 4:07:38 PM12/15/21
to
Am 15.12.21 um 18:41 schrieb Volker Englisch:
bei LTO.
>> 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.
>
> Das Gefühl hatte ich mit LTO-3 auch schon. Mein Server hat zwei Kerne,
> und die Sicherung läuft nachts, da sollte es eigentlich auch für -3
> reichen. Oder nicht?
War bei meinem Zweikerner seinerzeit nicht den Hauch einer Chance. LTO3
will einen Datenstrom von um die 40 MB/s sehen, damit es zügig durch
läuft. Heißt je nach Komprimierbarkeit bis zu 100 MB/s unkomprimiert.
Das wird ziemlich sportlich. Faktisch hat die Kiste eher höchstens
30MB/s komprimiert und das Band lief mit den resultierenden 10-20 MB/s
nicht einmal durch. Das habe ich ganz schnell wieder sein lassen.
>> 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.
>
> Ich hatte jetzt an VMS gedacht :) Nee, mir geht's dabei nur um
> verschiedene BSD-Varianten.
Uff, mit VMS habe ich schon fast 4 Jahrzehnte nichts mehr gemacht. Da
gab's dafür noch kein tar.
>> 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.
>
> Gute Idee. Trotzdem dauert es, wenn das gesuchte File ganz hinten im
> Archiv ist. Mir persönlich dünkt dump/restore da schneller, dafür ist
> tar wahrscheinlich kompatibler.
Warum sollte dump da schneller sein? Das Band ist so oder so kein Direct
Accessable Storage Device.
Marcel
>> 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.
>
> Welche Blockgröße verwendest du bei tar?
Habe ich irgendwo schon mal geschrieben. 256k bei DLT und 512k bzw. 1M
>> wir ja aus jedem Block _ein_ komprimierter Block dynamischer Länge. Es
>> geht also jedes mal die Lernfähigkeit der Huffman-Tabellen verloren.
>
> Welche Blockgröße verwendest du bei tar?
bei LTO.
>> 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.
>
> Das Gefühl hatte ich mit LTO-3 auch schon. Mein Server hat zwei Kerne,
> und die Sicherung läuft nachts, da sollte es eigentlich auch für -3
> reichen. Oder nicht?
will einen Datenstrom von um die 40 MB/s sehen, damit es zügig durch
läuft. Heißt je nach Komprimierbarkeit bis zu 100 MB/s unkomprimiert.
Das wird ziemlich sportlich. Faktisch hat die Kiste eher höchstens
30MB/s komprimiert und das Band lief mit den resultierenden 10-20 MB/s
nicht einmal durch. Das habe ich ganz schnell wieder sein lassen.
>> 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.
>
> Ich hatte jetzt an VMS gedacht :) Nee, mir geht's dabei nur um
> verschiedene BSD-Varianten.
gab's dafür noch kein tar.
>> 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.
>
> Gute Idee. Trotzdem dauert es, wenn das gesuchte File ganz hinten im
> Archiv ist. Mir persönlich dünkt dump/restore da schneller, dafür ist
> tar wahrscheinlich kompatibler.
Accessable Storage Device.
Marcel
Volker Englisch
Dec 16, 2021, 1:08:07 PM12/16/21
to
Marcel Mueller schrieb am Mi., 15 Dez. 2021 um 21:07 GMT:
> Am 15.12.21 um 18:41 schrieb Volker Englisch:
>>> 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.
>>
>> Welche Blockgröße verwendest du bei tar?
>
> Habe ich irgendwo schon mal geschrieben. 256k bei DLT und 512k bzw. 1M
> bei LTO.
Danke. Ich dachte zwar auch, aber ich habe es irgendwie nicht gefunden.
> Am 15.12.21 um 18:41 schrieb Volker Englisch:
>>> 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.
>>
>> Welche Blockgröße verwendest du bei tar?
>
> Habe ich irgendwo schon mal geschrieben. 256k bei DLT und 512k bzw. 1M
> bei LTO.
>>> Wenn man natürlich mit einer alten SGI mit Uralt-Irix (im wesentlichen
>>> System V) zurücksichern will, wird es eng.
>>
>> Ich hatte jetzt an VMS gedacht :) Nee, mir geht's dabei nur um
>> verschiedene BSD-Varianten.
>
> Uff, mit VMS habe ich schon fast 4 Jahrzehnte nichts mehr gemacht. Da
> gab's dafür noch kein tar.
laufen. Ich find' VMS nicht übel, nur a) hat der Rechner etwas viel
Strom verbraucht und b) kenne ich mich mit der Hardware eines Alpha so
gut wie gar nicht aus, kann also auch nichts reparieren, wenn der mal
streikt :)
>>> 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.
>>
>> Gute Idee. Trotzdem dauert es, wenn das gesuchte File ganz hinten im
>> Archiv ist. Mir persönlich dünkt dump/restore da schneller, dafür ist
>> tar wahrscheinlich kompatibler.
>
> Warum sollte dump da schneller sein? Das Band ist so oder so kein Direct
> Accessable Storage Device.
zuerst in dem tar-Archiv nach dem File gesucht hatte.
Volker
Volker Englisch
Dec 16, 2021, 1:08:08 PM12/16/21
to
annähernd schaffen.
Das heißt aber andererseits, dass auch nur ein Kern für das Backup
verwendet wird. Ist das ein Bug oder Feature? Ich bin in den Tiefen des
OS nicht so der Auskenner - könnten da nicht mehrere Kerne
zusammenarbeiten und die Ü-Rate erhöhen?
Volker
Sebastian Suchanek
Dec 16, 2021, 1:51:41 PM12/16/21
to
Ich würde sagen weder noch. Damit eine "Aufgabe" mehr als einen Kern
gleichzeitig nutzt, muss die Aufgabe ja überhaupt erst 'mal
parallelisierbar sein. Und das sehe ich bei einem Backup-Job nicht so
ohne weiteres. Und selbst, wenn die grundsätzliche Parallelisierbarkeit
gegeben sein sollte, muss die Software auch dafür geschrieben sein. Und
so alt, wie z.B. tar schon ist, dürfte das nicht der Fall sein.
Tschüs,
Sebastian
Volker Englisch
Dec 17, 2021, 1:08:07 PM12/17/21
to
Marcel Mueller schrieb am Mi., 15 Dez. 2021 um 21:07 GMT:
> Am 15.12.21 um 18:41 schrieb Volker Englisch:
> Am 15.12.21 um 18:41 schrieb Volker Englisch:
>> Welche Blockgröße verwendest du bei tar?
>
> Habe ich irgendwo schon mal geschrieben. 256k bei DLT und 512k bzw. 1M
> bei LTO.
Mein Versuch mit star war definitiv vielversprechend, ich lasse das
>
> Habe ich irgendwo schon mal geschrieben. 256k bei DLT und 512k bzw. 1M
> bei LTO.
heute Nacht mal über alles "sicherungswürdige" laufen.
Sehe ich das richtig, dass die mit star mit z.B. b=512k erstellten
Bänder dann nur noch mit star (rück-)lesbar sind?
Weder bsdtar noch gnu-tar wollte sich mit der Blockgröße anfreunden,
geschweige denn diese selbst herausfinden...
Volker
Volker Englisch
Dec 17, 2021, 1:08:07 PM12/17/21
to
Sebastian Suchanek schrieb am Do., 16 Dez. 2021 um 18:51 GMT:
>> Das heißt aber andererseits, dass auch nur ein Kern für das Backup
>> verwendet wird. Ist das ein Bug oder Feature?
> > [...]
>
> Ich würde sagen weder noch. Damit eine "Aufgabe" mehr als einen Kern
> gleichzeitig nutzt, muss die Aufgabe ja überhaupt erst 'mal
> parallelisierbar sein.
Ich hatte da in meiner unendlichen Blauäugigkeit an das Heranschaufeln
>> Das heißt aber andererseits, dass auch nur ein Kern für das Backup
>> verwendet wird. Ist das ein Bug oder Feature?
> > [...]
>
> Ich würde sagen weder noch. Damit eine "Aufgabe" mehr als einen Kern
> gleichzeitig nutzt, muss die Aufgabe ja überhaupt erst 'mal
> parallelisierbar sein.
der Daten von den Festplatten gedacht. Zu Ende gedacht hatte ich es
allerdings nicht, sodaß mir nach deinem Einwand durchaus Zweifel kommen
;)
Volker
Marcel Mueller
Dec 18, 2021, 5:42:26 AM12/18/21
to
Am 17.12.21 um 18:16 schrieb Volker Englisch:
beliebige Blockgröße.
Problematischer wird es, wenn du Erweiterungen verwendest, die tar nicht
kennt, z.B. erweiterte Attribute als exustar sichern. Aber angeblich ist
das immer noch so kompatibel, dass die nackten Daten trotzdem mit tar
extrahierbar sind. Das habe ich aber nie getestet.
> Weder bsdtar noch gnu-tar wollte sich mit der Blockgröße anfreunden,
-b 1024 ging nicht?
> geschweige denn diese selbst herausfinden...
Ja, da wird es dünn. Es gibt AFAIK auch gar keinen standardisierten
Befehl dafür. Jedenfalls nicht in der Filesystem-API über die tar auf
das Device zugreift.
Was aber immer geht, ist den Datenstrom mit irgendeinem anderen Programm
in der gewünschten Blockgröße lesen (z.B. dd mit bs=...) und dann an tar
pipen. Der Bytestream ist nämlich nicht davon abhängig. Es geht wirklich
nur um die abgesetzten I/O-Kommandos. Das ist so wie man von einer
native 4k-Platte nicht in 512 Bytes Blöcken lesen kann.
Marcel
> Marcel Mueller schrieb am Mi., 15 Dez. 2021 um 21:07 GMT:
>> Am 15.12.21 um 18:41 schrieb Volker Englisch:
>>> Welche Blockgröße verwendest du bei tar?
>>
>> Habe ich irgendwo schon mal geschrieben. 256k bei DLT und 512k bzw. 1M
>> bei LTO.
>
> Mein Versuch mit star war definitiv vielversprechend, ich lasse das
> heute Nacht mal über alles "sicherungswürdige" laufen.
>
> Sehe ich das richtig, dass die mit star mit z.B. b=512k erstellten
> Bänder dann nur noch mit star (rück-)lesbar sind?
Nein. tar kennt so eine Einstellung auch. Nur kann nicht jedes tar jede
>> Am 15.12.21 um 18:41 schrieb Volker Englisch:
>>> Welche Blockgröße verwendest du bei tar?
>>
>> Habe ich irgendwo schon mal geschrieben. 256k bei DLT und 512k bzw. 1M
>> bei LTO.
>
> Mein Versuch mit star war definitiv vielversprechend, ich lasse das
> heute Nacht mal über alles "sicherungswürdige" laufen.
>
> Sehe ich das richtig, dass die mit star mit z.B. b=512k erstellten
> Bänder dann nur noch mit star (rück-)lesbar sind?
beliebige Blockgröße.
Problematischer wird es, wenn du Erweiterungen verwendest, die tar nicht
kennt, z.B. erweiterte Attribute als exustar sichern. Aber angeblich ist
das immer noch so kompatibel, dass die nackten Daten trotzdem mit tar
extrahierbar sind. Das habe ich aber nie getestet.
> Weder bsdtar noch gnu-tar wollte sich mit der Blockgröße anfreunden,
> geschweige denn diese selbst herausfinden...
Befehl dafür. Jedenfalls nicht in der Filesystem-API über die tar auf
das Device zugreift.
Was aber immer geht, ist den Datenstrom mit irgendeinem anderen Programm
in der gewünschten Blockgröße lesen (z.B. dd mit bs=...) und dann an tar
pipen. Der Bytestream ist nämlich nicht davon abhängig. Es geht wirklich
nur um die abgesetzten I/O-Kommandos. Das ist so wie man von einer
native 4k-Platte nicht in 512 Bytes Blöcken lesen kann.
Marcel
Volker Englisch
Dec 18, 2021, 1:08:07 PM12/18/21
to
Marcel Mueller schrieb am Sa., 18 Dez. 2021 um 10:42 GMT:
> Am 17.12.21 um 18:16 schrieb Volker Englisch:
>> Marcel Mueller schrieb am Mi., 15 Dez. 2021 um 21:07 GMT:
>>> Am 15.12.21 um 18:41 schrieb Volker Englisch:
>>>> Welche Blockgröße verwendest du bei tar?
>>>
>>> Habe ich irgendwo schon mal geschrieben. 256k bei DLT und 512k bzw. 1M
>>> bei LTO.
>>
>> Mein Versuch mit star war definitiv vielversprechend, ich lasse das
>> heute Nacht mal über alles "sicherungswürdige" laufen.
>>
>> Sehe ich das richtig, dass die mit star mit z.B. b=512k erstellten
>> Bänder dann nur noch mit star (rück-)lesbar sind?
>
> Am 17.12.21 um 18:16 schrieb Volker Englisch:
>> Marcel Mueller schrieb am Mi., 15 Dez. 2021 um 21:07 GMT:
>>> Am 15.12.21 um 18:41 schrieb Volker Englisch:
>>>> Welche Blockgröße verwendest du bei tar?
>>>
>>> Habe ich irgendwo schon mal geschrieben. 256k bei DLT und 512k bzw. 1M
>>> bei LTO.
>>
>> Mein Versuch mit star war definitiv vielversprechend, ich lasse das
>> heute Nacht mal über alles "sicherungswürdige" laufen.
>>
>> Sehe ich das richtig, dass die mit star mit z.B. b=512k erstellten
>> Bänder dann nur noch mit star (rück-)lesbar sind?
>
>> Weder bsdtar noch gnu-tar wollte sich mit der Blockgröße anfreunden,
>
> -b 1024 ging nicht?
Wie sagt man in Schwaben? O Herr, lass Hirn vom Himmel 'ra. Doch, mit
>
> -b 1024 ging nicht?
1024 geht es, mit 1000 ging es nicht. Sorry.
Danke nochmal für die viele Hilfe!
Volker
0 new messages