28.07.2025
488
21
3Bänder sind (noch) nicht tot, LTO Band lebt
Bandsicherungen sind (noch) nicht tot, im folgenden Link ein Artikel auf Heise Online.
Grade für Langzeitarchivierung und große Datenmengen sind heutzutage immer Bandsicherungen eine gute Wahl
Auch wenn die Bänder selbst teuer sind. Und LTO9 Kompatibilitätsprobleme hat.
Gruss Penny.
Grade für Langzeitarchivierung und große Datenmengen sind heutzutage immer Bandsicherungen eine gute Wahl
Auch wenn die Bänder selbst teuer sind. Und LTO9 Kompatibilitätsprobleme hat.
Gruss Penny.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 674037
Url: https://administrator.de/info/bandsicherung-lto-band-langzeitarchivierung-674037.html
Ausgedruckt am: 28.07.2025 um 14:07 Uhr
21 Kommentare
Neuester Kommentar
Moin,
den Artikel hab ich am WE auch vernommen.
Für die Langzeitarchivierung von offline-Daten auch aus meiner Sicht immer noch das Medium schlecht hin.
Wobei der Artikel natürlich folgerichtig erwähnt, dass das erst mit steigender Zahl an Tapes preislich ggü. HDDs lohnenswert wird, da die Drives selbst in der Anschaffung auch nicht gerade günstig sind.
Mit LTO10 ist es natürlich in sofern ungünstig, das man für das Migrieren der Daten erst einmal noch ein Drive benötigt, welches LTO9/ 8 lesen kann.
Insgesamt wurde LTO10 ja in deinem, @Penny.Cilin, Beitrag hier schon etwas weiter "diskutiert":
Neue LTO10 Tapes im Juni verfügbar
den Artikel hab ich am WE auch vernommen.
Für die Langzeitarchivierung von offline-Daten auch aus meiner Sicht immer noch das Medium schlecht hin.
Wobei der Artikel natürlich folgerichtig erwähnt, dass das erst mit steigender Zahl an Tapes preislich ggü. HDDs lohnenswert wird, da die Drives selbst in der Anschaffung auch nicht gerade günstig sind.
LTO wird von vielen Unternehmen trotz der hohen Kosten für die Bandlaufwerke eingesetzt, weil die Bänder relativ günstig sind und die Speicherkosten bei steigender Kapazität immer weiter sinken.
Mit LTO10 ist es natürlich in sofern ungünstig, das man für das Migrieren der Daten erst einmal noch ein Drive benötigt, welches LTO9/ 8 lesen kann.
Insgesamt wurde LTO10 ja in deinem, @Penny.Cilin, Beitrag hier schon etwas weiter "diskutiert":
Neue LTO10 Tapes im Juni verfügbar
Mit LTO10 ist es natürlich in sofern ungünstig, das man für das Migrieren der Daten erst einmal noch ein Drive benötigt, welches LTO9/ 8 lesen kann.
Was ja vorhanden ist. Mit irgendetwas hat man seine LTO8/9-Bänder ja beschrieben. Der Zusätzliche Platz, 2 Bandlaufwerke auf einmal zu betreiben kann aber in so manchem Betrieb schon zu Problemen führen
Hinzu kommt leider auch die Tatsache, daß die Abwärtskompatibilität immer mehr eingeschränkt wird.
Ab LTO3 bis einschließlich LTO7 konnte man immer Bänder von zwei Generationen davor lesen.
Seit LTO7 bis LTO9 sind es nur die aktuelle Generation und eine Generation davor. - Schon mal ganz schlecht.
Beim Schreiben war es so, daß die aktuelle Generation und eine Generation davor unterstützt wurde.
Somit konnte man die Laufwerke noch eine gute Weile beenutzen.
Ich bin seit Jahren damit beschäftigt, Archive zu migrieren. Auch in externen Projekten. Deshalb werden auch nicht gleich alle Laufwerke getauscht. Und es muss auch noch gestestet werden.
Gruss Penny.
Ab LTO3 bis einschließlich LTO7 konnte man immer Bänder von zwei Generationen davor lesen.
Seit LTO7 bis LTO9 sind es nur die aktuelle Generation und eine Generation davor. - Schon mal ganz schlecht.
Beim Schreiben war es so, daß die aktuelle Generation und eine Generation davor unterstützt wurde.
Somit konnte man die Laufwerke noch eine gute Weile beenutzen.
Ich bin seit Jahren damit beschäftigt, Archive zu migrieren. Auch in externen Projekten. Deshalb werden auch nicht gleich alle Laufwerke getauscht. Und es muss auch noch gestestet werden.
Gruss Penny.
@snowman29
Gruss Penny.
Der Zusätzliche Platz, 2 Bandlaufwerke auf einmal zu betreiben kann aber in so manchem Betrieb schon zu Problemen führen.
Kommt auf die Library an. Je nach Library sind ein / Zwei / oder mehrere Laufwerke vorhanden. Oder können mehrere Laufwerke benutzt werden. Ist auch eine Frage des Budgets und der Masse der Daten.Gruss Penny.
Moin @Penny.Cilin,
na ja, genaugenommen ist die Bandsicherung schon seit Jahrzehnten eigentlich die einzige für die breite Masse verfügbare Langzeitarchivierungsmethode, zumindest ab einer bestimmten Datenmenge. 🙃
Es wurde zwar in den letzten Jahrzehnten viel über Alternativen wie DNA-Datenspeicherung, 5D-Speicher auf Quarzglas, Phasenwechselspeicher, Saphir- oder Platin-Scheiben oder gar Atomare oder molekulare Speicher gesprochen, umgesetzt wurde davon jedoch bisher so gut wie nichts. 😔
Siehe auch:
iit-berlin.de/publikation/technologische-ansaetze-zur-langzeitar ...
Gruss Alex
Bandsicherungen sind (noch) nicht tot
Grade für Langzeitarchivierung und große Datenmengen sind heutzutage immer Bandsicherungen eine gute Wahl
Grade für Langzeitarchivierung und große Datenmengen sind heutzutage immer Bandsicherungen eine gute Wahl
na ja, genaugenommen ist die Bandsicherung schon seit Jahrzehnten eigentlich die einzige für die breite Masse verfügbare Langzeitarchivierungsmethode, zumindest ab einer bestimmten Datenmenge. 🙃
Es wurde zwar in den letzten Jahrzehnten viel über Alternativen wie DNA-Datenspeicherung, 5D-Speicher auf Quarzglas, Phasenwechselspeicher, Saphir- oder Platin-Scheiben oder gar Atomare oder molekulare Speicher gesprochen, umgesetzt wurde davon jedoch bisher so gut wie nichts. 😔
Siehe auch:
iit-berlin.de/publikation/technologische-ansaetze-zur-langzeitar ...
Gruss Alex
@MysticFoxDE
Nicht zu vergessen Entwicklung / Tests auf tesafilmahnlichem Material im letzten Jahrtausen von der IBM.
Gruss Penny.
Nicht zu vergessen Entwicklung / Tests auf tesafilmahnlichem Material im letzten Jahrtausen von der IBM.
Gruss Penny.
@Penny.Cilin
Ich hab den Artikel auch heute früh gelesen.
Es gibt eben zwei wesentliche Nutzungsbereiche für LTO: Die Datensicherung und die Archivierung.
Kürzlich hatte ich hier einen Threat auf gemacht, wo es darum geht, LTFS-Formatiertze LTO5 Bänder auszulesen, die man im Keller als Archiv vergessen hatte.
Das Auslesen der Bänder gestaltet sich schwierig, da es extrem langsam vonstatten geht. Übertrage ich das mal auf nachfolge-Generationen nach LTO5 für das vermutlich noch wesentlich länger dauern, die Bänder auszulesen.
Und, nunja, nur wenn man die Daten auch wieder auslesen kann ist die Archivierung so sinnvoll. Die Idee von LTFS ist daher im Ansatz gut, in der Durchführung eher nicht.
Verlässt man sich also zur Archivierung g auf ein bestimmten Softwarehersteller ist man da durchaus schneller auf dem Band unterwegs. Aber: Man begibt sich mit Petabytes von Datenmassen in die Abhängigkeit dieses Softwareherstellers. Das stellt dann eine Bedingung dar, die ein sehr großes Archiv ebenfalls in Frage stellt.
Es braucht mehr Auswahl, und es bracht mehr Replikationssicherheit.
Kreuzberger
Ich hab den Artikel auch heute früh gelesen.
Es gibt eben zwei wesentliche Nutzungsbereiche für LTO: Die Datensicherung und die Archivierung.
Kürzlich hatte ich hier einen Threat auf gemacht, wo es darum geht, LTFS-Formatiertze LTO5 Bänder auszulesen, die man im Keller als Archiv vergessen hatte.
Das Auslesen der Bänder gestaltet sich schwierig, da es extrem langsam vonstatten geht. Übertrage ich das mal auf nachfolge-Generationen nach LTO5 für das vermutlich noch wesentlich länger dauern, die Bänder auszulesen.
Und, nunja, nur wenn man die Daten auch wieder auslesen kann ist die Archivierung so sinnvoll. Die Idee von LTFS ist daher im Ansatz gut, in der Durchführung eher nicht.
Verlässt man sich also zur Archivierung g auf ein bestimmten Softwarehersteller ist man da durchaus schneller auf dem Band unterwegs. Aber: Man begibt sich mit Petabytes von Datenmassen in die Abhängigkeit dieses Softwareherstellers. Das stellt dann eine Bedingung dar, die ein sehr großes Archiv ebenfalls in Frage stellt.
Es braucht mehr Auswahl, und es bracht mehr Replikationssicherheit.
Kreuzberger
Kürzlich hatte ich hier einen Threat auf gemacht, wo es darum geht, LTFS-Formatiertze LTO5 Bänder auszulesen, die man im Keller als Archiv vergessen hatte.
undVerlässt man sich also zur Archivierung g auf ein bestimmten Softwarehersteller ist man da durchaus schneller auf dem Band unterwegs. Aber: Man begibt sich mit Petabytes von Datenmassen in die Abhängigkeit dieses Softwareherstellers. Das stellt dann eine Bedingung dar, die ein sehr großes Archiv ebenfalls in Frage stellt.
Ist der Grund, weshalb wir unseren IBM TSM (ja, der heisst so nicht mehr 
) noch mit am Laufen haben, obwohl wir vor rund 5 Jahren auf VEEAM gewechselt sind. Wir müssen nämlich sicherstellen, dass wir auch nach 10/ 15 Jahren an div. Dokumente kommen. und weil der TSM mit an einer Library hängt, läuft monatlich ein Job, der die Datenbestände auf andere Bänder LTO6-Tapes schiebt. Und einmal im Jahr lassen wir die offline-Tapes "umschreiben", damit wir sicherstellen können, dass die Tapes im Safe auch noch funktionsfähig bleiben.Sicherlich hätte man einmal einen Restore der TSM-gesicherten Systeme machen können und die wiederum dann mit VEEAM sichern, AABER....
Zitat von @Snowman25:
Was ja vorhanden ist. Mit irgendetwas hat man seine LTO8/9-Bänder ja beschrieben. Der Zusätzliche Platz, 2 Bandlaufwerke auf einmal zu betreiben kann aber in so manchem Betrieb schon zu Problemen führen
Mit LTO10 ist es natürlich in sofern ungünstig, das man für das Migrieren der Daten erst einmal noch ein Drive benötigt, welches LTO9/ 8 lesen kann.
Was ja vorhanden ist. Mit irgendetwas hat man seine LTO8/9-Bänder ja beschrieben. Der Zusätzliche Platz, 2 Bandlaufwerke auf einmal zu betreiben kann aber in so manchem Betrieb schon zu Problemen führen
Stimme ich bedingt zu: Ist das Drive direkt im Server verbaut wird man i.d.R. keinen Platz für ein zweites Laufwerk haben (hast du ja schon erkannt).
Und was machst du mit den archivierten Jahresbändern, die im Safer noch auf LTO8/ 9/ xxx geschrieben sind und ggf. mal brauchst? Dann musst du ja ein passendes Drive mit in den Safe legen - oder die Daten mit rüber kopieren.
Frage an die Mathematiker:
Ab wann ist es logistisch schlicht unmöglich, ggf. 100.000 LTO9 Bänder umzukopieren auf LTO10, um der Veralterung der LTO9-gespeicherten Daten zuvorzukommen?
Oder anders gefragt: Wie lange braucht man eigentlich, um derartige Datenmengen in die Zukunft zu sichern?
Kreuzberger
Ab wann ist es logistisch schlicht unmöglich, ggf. 100.000 LTO9 Bänder umzukopieren auf LTO10, um der Veralterung der LTO9-gespeicherten Daten zuvorzukommen?
Oder anders gefragt: Wie lange braucht man eigentlich, um derartige Datenmengen in die Zukunft zu sichern?
Kreuzberger
Ich kam auf diese Fragen weil ich mal beteiligt war am Digitalisieren (Scannan) von großen Buchbeständen. Das ist zur Erklärung Speicher aus Papier. Ja, sowas gab es mal!
Da die Papierspeicher so voll waren stellte sich die Frage, wie viele Scannsysteme (Zeutschel.de) man betreiben müsste um vor dem Säure- und Bakterienzerfall der Bücher diese digital schafft.
Kreuzberger
Da die Papierspeicher so voll waren stellte sich die Frage, wie viele Scannsysteme (Zeutschel.de) man betreiben müsste um vor dem Säure- und Bakterienzerfall der Bücher diese digital schafft.
Kreuzberger
@kreuzberger
Sondern in die Ecke stellen. Man kann es auch ausschalten.> Ist der Grund, weshalb wir unseren IBM TSM (ja, der heisst so nicht mehr ) noch mit am Laufen haben
@em-pie
Wir hatten damals im Rechenzentrum im Bankenumfeld zwei große Grau-Roboter mit jeweils 6 Türmen und 12 Bandlaufwerken auf beiden Seiten der Bandsilos. Alles in allem hatten wir damals ca. 500 000 Bänder.
Die Bandlaufwerke waren damals von Comparex. Aufgrund der intensiven Nutzung / Belastung, hatten wir einen Techniker vor Ort. Welche öfter die Laufwerke nachjustiert und auch gereinigt hat. Auch die Festplatten waren damals von Comparex.
Die Steuerung der Grau Roboter lief damals noch unter OS/2. ( ).
[Edit]Anzahl der korrigiert. Es wurden 3 Nuller verschluckt.
Das Auslesen der Bänder gestaltet sich schwierig, da es extrem langsam vonstatten geht. Übertrage ich das mal auf nachfolge-Generationen nach LTO5 für das vermutlich noch wesentlich länger dauern, die Bänder auszulesen.
Deshalb sollte man das alte Softwareprodukt NICHT einstampfen!Sondern in die Ecke stellen. Man kann es auch ausschalten.> Ist der Grund, weshalb wir unseren IBM TSM (ja, der heisst so nicht mehr ) noch mit am Laufen haben
@em-pie
Ist der Grund, weshalb wir unseren IBM TSM (ja, der heisst so nicht mehr ) noch mit am Laufen haben,
Das nennt sich nun IBM Spectrum Protect.Zitat von @em-pie:
Bei 100.000 Tapes (LTO9) wirst du sicherlich keine Lib mit nur 2 oder 4 Laufwerken haben.
Da hat man eher sowas im Einsatz (TechSpecs).
Richtig, dann nutzt man keine Libraries in dem Sinne, sondern ganze Bandroboter.Bei 100.000 Tapes (LTO9) wirst du sicherlich keine Lib mit nur 2 oder 4 Laufwerken haben.
Da hat man eher sowas im Einsatz (TechSpecs).
Wir hatten damals im Rechenzentrum im Bankenumfeld zwei große Grau-Roboter mit jeweils 6 Türmen und 12 Bandlaufwerken auf beiden Seiten der Bandsilos. Alles in allem hatten wir damals ca. 500 000 Bänder.
Die Bandlaufwerke waren damals von Comparex. Aufgrund der intensiven Nutzung / Belastung, hatten wir einen Techniker vor Ort. Welche öfter die Laufwerke nachjustiert und auch gereinigt hat. Auch die Festplatten waren damals von Comparex.
Die Steuerung der Grau Roboter lief damals noch unter OS/2. (
).[Edit]Anzahl der korrigiert. Es wurden 3 Nuller verschluckt.
1
@Penny.Cilin
Genau deshalb habe ich ja das LTFS-Thema angezettelt. Hier wanderten plötzlich erst ein paar LTO5 Bänder mit LTFS Format durch meine Tür mit der bitte, diese auszulesen. Man hatte beim Erneuern der LTO-Technologie in einem Unternehmen (Videoschnitt, Postproduction) das Archiv im Keller vergessen. Das Auslesen der LTO5-Bänder wird bei mir nun wohl zu einer Lebensaufgabe, es sind Kistenweise Bänder. Und niemand weiß mehr, was da drauf eigentlich ist. Ich weise also auf den Zeitfaktor hin, der zum Rückkopierten erforderlich ist bei solchen Archiven.
Da keine LTO5-Laufwerke mehr hergestellt werden stellt sich zudem die Frage, wie viele Laufwerke welcher Generation auch immer erforderlich eingelagert werden sollten, damit Rücklesen in zeitrelevanter Dauer möglich ist.
. . . . es ist kompliziert.
Also: ein LTO5 mit LTFS voll schreiben dauert 4 - 6 Std. Es wieder auslesen 20 - 24 Std.
Ein LTO9 beschreiben dauert? Und das Rücklesen zwei Wochen?
Kreuzberger
Deshalb sollte man das alte Softwareprodukt NICHT einstampfen!
Sondern in die Ecke stellen. Man kann es auch ausschalten.> Ist der Grund, weshalb wir unseren IBM TSM (ja, der heisst so nicht mehr ) noch mit am Laufen haben
Sondern in die Ecke stellen. Man kann es auch ausschalten.> Ist der Grund, weshalb wir unseren IBM TSM (ja, der heisst so nicht mehr ) noch mit am Laufen haben
Genau deshalb habe ich ja das LTFS-Thema angezettelt. Hier wanderten plötzlich erst ein paar LTO5 Bänder mit LTFS Format durch meine Tür mit der bitte, diese auszulesen. Man hatte beim Erneuern der LTO-Technologie in einem Unternehmen (Videoschnitt, Postproduction) das Archiv im Keller vergessen. Das Auslesen der LTO5-Bänder wird bei mir nun wohl zu einer Lebensaufgabe, es sind Kistenweise Bänder. Und niemand weiß mehr, was da drauf eigentlich ist. Ich weise also auf den Zeitfaktor hin, der zum Rückkopierten erforderlich ist bei solchen Archiven.
Da keine LTO5-Laufwerke mehr hergestellt werden stellt sich zudem die Frage, wie viele Laufwerke welcher Generation auch immer erforderlich eingelagert werden sollten, damit Rücklesen in zeitrelevanter Dauer möglich ist.
. . . . es ist kompliziert.
Also: ein LTO5 mit LTFS voll schreiben dauert 4 - 6 Std. Es wieder auslesen 20 - 24 Std.
Ein LTO9 beschreiben dauert? Und das Rücklesen zwei Wochen?
Kreuzberger
@kreuzberger
Somit hast Du schlechte Karten!
Wenn die Daten wichtig sind, ab zum Datenretter, ansonsten NULL Chance.
Ich weiß das klingt hart! - Ich musste diese Lektion auch lernen! Aus diesem Grund dokumentiere ich alles, was ich mache. Gut mittlerweile habe ich meine Notizen in digitaler Form und nicht mehr im Notizblock (ja alles archiviert!).
Gruss Penny.
Genau deshalb habe ich ja das LTFS-Thema angezettelt. Hier wanderten plötzlich erst ein paar LTO5 Bänder mit LTFS Format durch meine Tür mit der bitte, diese auszulesen. Man hatte beim Erneuern der LTO-Technologie in einem Unternehmen (Videoschnitt, Postproduction) das Archiv im Keller vergessen.
Ich verstehe Deine Intention! - Allerdings LTO5 kam im Frühjahr 2010 auf den Markt. Das war vor 15 Jahren. Ich sehe somit nur die Möglichkeit mittels einem professionellem Datenretter wie Kroll OnTrack, oder evtl. Personen welche damals mit der Sicherung der Bänder beschäftigt waren, zu fragen. Außerdem weißt Du nicht, wie die Bänder damals erstellt wurden, geschweige denn mit welcher Software. Auch die Hardware von damals ist Dir unbekannt. Ich und auch andere Kollegen aus dem Forum hatten Dich informiert, daß auch die Justage des Schreib- / Lesekopfes eine Rolle spielt.Somit hast Du schlechte Karten!
Wenn die Daten wichtig sind, ab zum Datenretter, ansonsten NULL Chance.
Ich weiß das klingt hart! - Ich musste diese Lektion auch lernen! Aus diesem Grund dokumentiere ich alles, was ich mache. Gut mittlerweile habe ich meine Notizen in digitaler Form und nicht mehr im Notizblock (ja alles archiviert!).
Gruss Penny.
@Penny.Cilin
Missverständnis: Die Daten sind ja auslesebar, es dauert nur mit der LTFS-Formatierung der Bänder recht lange. Das liegt eher nur an der unzureichenden Software, die die Daten alphanumerisch geordnet auslesen will/mag, anstatt nach Ort und stelle wie sie auf den band sind.
Kreuzberger
Missverständnis: Die Daten sind ja auslesebar, es dauert nur mit der LTFS-Formatierung der Bänder recht lange. Das liegt eher nur an der unzureichenden Software, die die Daten alphanumerisch geordnet auslesen will/mag, anstatt nach Ort und stelle wie sie auf den band sind.
Kreuzberger
@kreuzberger
Schau doch mal unter Archive.org, vielleicht findest Du dort Information / Dokumentationen, wie man mittels Parameter das Auslesen steuern kann.
Hier habe ich schon manches gefunden, was mir weiter geholfen hat.
Gruss Penny.
Schau doch mal unter Archive.org, vielleicht findest Du dort Information / Dokumentationen, wie man mittels Parameter das Auslesen steuern kann.
Hier habe ich schon manches gefunden, was mir weiter geholfen hat.
Gruss Penny.
@Penny.Cilin
Danke, von da hab ich ja bereits ein umfangreiches Softwarepaket. Für LTFS gibt es aber nichts neueres/neues, auch auch Microsoft LTFS abgekündigt hatte. Wie mein Wissensstand ist ist die Linux-Software defakto die selbe wie für windows, was einen auch nicht nach vorne bringt.
Kreuzberger
Danke, von da hab ich ja bereits ein umfangreiches Softwarepaket. Für LTFS gibt es aber nichts neueres/neues, auch auch Microsoft LTFS abgekündigt hatte. Wie mein Wissensstand ist ist die Linux-Software defakto die selbe wie für windows, was einen auch nicht nach vorne bringt.
Kreuzberger
Okay, hast Du evtl. einen LTFS Manager oder so ähnliches? Dann könntest Du die Bänder importieren.
Gruss Penny.
Gruss Penny.
Neee, aber es wäre kuhl wenn man die XML-Tabellen wenigstens auslesen könnte. Damit könnte dann wohl die HP Software (Windows) umgehen. Da ich ja die Bänder nicht beschrieben hatte, sind die XML Dateien nur auf den Bändern, und nicht bei mir im System.
Krezberger
Krezberger
Leute, macht Euch keinen Kopp!
In dem Augenblick, wo Siemens seinen alten Plan umsetzt, mit Atomreaktoren betriebene Taschenfeuerzeuge auf den Markt zu bringen, werden auch die USB Sticks mit Infinity Space freigeben werden. Vertraut mir!
In dem Augenblick, wo Siemens seinen alten Plan umsetzt, mit Atomreaktoren betriebene Taschenfeuerzeuge auf den Markt zu bringen, werden auch die USB Sticks mit Infinity Space freigeben werden. Vertraut mir!
