28.06.2025
4185
79
0LTFS und Restore
Ok, es ist nicht Freitag. Aber trotzdem hallo Digitalfreunde,
da ist ein LTO5 Bandstreamer (SAS) und ein oller PC mit Hostbusadapter (SAS) und es sollen einige Kisten voll mit LTO5 Bändern zurückgeschrieben werden auf Festplatten. Das klappt auch soweit.
So schlecht: Es scheint, dass bei meiner Weise zurück zu kopieren mit robocopy das Band oft kilometerweit her und hin gespult wird und dann erst die nächste Datei kopiert wird.
Gibt es da einen Weg, die Daten vom Band einfach in der Reihenfolge wie sie auf den Band sind auszulesen?
Kreuzberger
da ist ein LTO5 Bandstreamer (SAS) und ein oller PC mit Hostbusadapter (SAS) und es sollen einige Kisten voll mit LTO5 Bändern zurückgeschrieben werden auf Festplatten. Das klappt auch soweit.
So schlecht: Es scheint, dass bei meiner Weise zurück zu kopieren mit robocopy das Band oft kilometerweit her und hin gespult wird und dann erst die nächste Datei kopiert wird.
Gibt es da einen Weg, die Daten vom Band einfach in der Reihenfolge wie sie auf den Band sind auszulesen?
Kreuzberger
Kommentieren
Teilen
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: 673589
Url: https://administrator.de/forum/ltfs-lto5-bandstreamer-backup-673589.html
Ausgedruckt am: 18.07.2025 um 22:07 Uhr
79 Kommentare
Neuester Kommentar
Mal 'ne blöde Frage: Wie wurden die Daten auf die Bänder geschrieben?
Und das Verhalten von robocopy entspricht dem verhalten, daß keine Collocation für die Daten gemacht wurde.
Bei vernünftigen Datensicherungsprogrammen macht man das. Um genau diesen Vor- und Rückspuleffekt zu vermeiden. Und somit einen linearen Datenstrom auf Bänder zu schreiben.
Gruss Penny.
Und das Verhalten von robocopy entspricht dem verhalten, daß keine Collocation für die Daten gemacht wurde.
Bei vernünftigen Datensicherungsprogrammen macht man das. Um genau diesen Vor- und Rückspuleffekt zu vermeiden. Und somit einen linearen Datenstrom auf Bänder zu schreiben.
Gruss Penny.
Hallo @Penny.Cilin
Danke
Es ist leider nicht bekannt wie die Daten auf die Bänder geschrieben wurden. Man weiß nicht einmal was da drauf ist, was die komplette Rücksicherung auch erforderlich macht. Man hat an Ort und stelle auch kein LTO5 mehr. Darum sind die Kisten mit dem Bändern nun bei mir.
wie gesagt: Die Daten liegen per LTFS vor. Da war also in dem sinne kein wirkliches Datensicherungsprogramm am start, sondern nur ein banale draufkopieren wie auch ein Laufwerk.
Kreuzberger
Danke
Es ist leider nicht bekannt wie die Daten auf die Bänder geschrieben wurden. Man weiß nicht einmal was da drauf ist, was die komplette Rücksicherung auch erforderlich macht. Man hat an Ort und stelle auch kein LTO5 mehr. Darum sind die Kisten mit dem Bändern nun bei mir.
wie gesagt: Die Daten liegen per LTFS vor. Da war also in dem sinne kein wirkliches Datensicherungsprogramm am start, sondern nur ein banale draufkopieren wie auch ein Laufwerk.
Kreuzberger
Es gibt verschiedene Versionen von LTFS, siehe Wikiepediaartikel.
Mir ist keine Möglichkeit bekannt, diesen Vor- und Rückspuleffekt zu verhindern. Möglicherweise sind die Daten auf dem Band fragmentiert, wodurch auch das Vor- und Rückspulen kommt.
Gruss Penny.
Mir ist keine Möglichkeit bekannt, diesen Vor- und Rückspuleffekt zu verhindern. Möglicherweise sind die Daten auf dem Band fragmentiert, wodurch auch das Vor- und Rückspulen kommt.
Gruss Penny.
@Penny.Cilin
Ich dachte immer LTFS ist LTFS ist LTFS, also der eigentliche Sinn der Sache ist eben die allumfassende Kompatibilität. Immerhin weiss bei diesen Bändern kein Mensch mehr, wie die Daten auf die Bänder kamen.
Ich hatte befürchtet, dass die Bänder ggf. fragmentiert sind, weil Daten mitten drin gelöscht, und andere Daten dann nachträglich drauf kopiert wurden.
So dauert das Rückkopieren dann eben sehr viel länger. Schade.
Ich habe hier ein HP-LTO5 (HP StorageWorks Ultrium 3280 SAS) und die HP LTFS Software auf Windows Server 2022. Das Funktioniert so weit.
Leider kann man auch so gar nicht vorher sehen, wie viele Daten auf den Bändern sind, bzw. wie viel Platz noch drauf leer ist.
Leider kann man auch nicht einsehen, ob der LTO nun nur spult, oder auch Daten liesst, und wenn ja wie flott das geht. Ich kann es nur anhand von robocopy sehen, dass er gerade die eine oder andere Datei liesst.
Erfreulich bei der Sache: Man braucht keine völlig überteuerte Backupsoftware um Daten auf ein LTO zu schreiben. Es geht mit jedem Kopierprogramm.
Kreuzberger
Ich dachte immer LTFS ist LTFS ist LTFS, also der eigentliche Sinn der Sache ist eben die allumfassende Kompatibilität. Immerhin weiss bei diesen Bändern kein Mensch mehr, wie die Daten auf die Bänder kamen.
Ich hatte befürchtet, dass die Bänder ggf. fragmentiert sind, weil Daten mitten drin gelöscht, und andere Daten dann nachträglich drauf kopiert wurden.
So dauert das Rückkopieren dann eben sehr viel länger. Schade.
Ich habe hier ein HP-LTO5 (HP StorageWorks Ultrium 3280 SAS) und die HP LTFS Software auf Windows Server 2022. Das Funktioniert so weit.
Leider kann man auch so gar nicht vorher sehen, wie viele Daten auf den Bändern sind, bzw. wie viel Platz noch drauf leer ist.
Leider kann man auch nicht einsehen, ob der LTO nun nur spult, oder auch Daten liesst, und wenn ja wie flott das geht. Ich kann es nur anhand von robocopy sehen, dass er gerade die eine oder andere Datei liesst.
Erfreulich bei der Sache: Man braucht keine völlig überteuerte Backupsoftware um Daten auf ein LTO zu schreiben. Es geht mit jedem Kopierprogramm.
Kreuzberger
Ich dachte immer LTFS ist LTFS ist LTFS, also der eigentliche Sinn der Sache ist eben die allumfassende Kompatibilität. Immerhin weiss bei diesen Bändern kein Mensch mehr, wie die Daten auf die Bänder kamen.
Wie sich die Spezifikationen unterscheiden weiß ich jetzt nicht. Habe mich auch nie mit LTFS beschäftigt.Und das ist das Dilemma, Es Werden Bänder erstellt, aber nirgends dokumentiert wann, wie und mit was.
Mir reicht's wenn ich die alten Legato Networker Bänder migriert habe. Hier habe ich gottweidank noch die Software und die alte Quantum Library.
Ich restore von Legato auf extra SAN Storage. Von dort aus mache ich dann das Backup mit IBM Spectrum Protect (ehemals Tivoli Storage Manager). Es wird genau dokumentiert, was auf den Bändern gesichert wurde. Wie lange diese gesperrt sind. Und dann werden noch Kopien für die Lagerung in den Tresoren erstellt.
Die Bänder werden dann aus der Library entnommen und im Schrank im RZ aufbewahrt.
Ich hatte befürchtet, dass die Bänder ggf. fragmentiert sind, weil Daten mitten drin gelöscht, und andere Daten dann nachträglich drauf kopiert wurden.
Simpel gesagt, ist das nur eine lineare Form eines Datenträgers (HDD SSD). Wenn man dann mittendrin Dateien löscht, wird der Platz nicht sofort aufgefüllt.Gruss Penny.
@Penny.Cilin
Vom Prinzip her ist mir ja LTFS klar, und eine pfiffige Sache wenn man Kompatibilität hat und Laufwerke hat / einlagert, mit denen man das wieder auslesen kann. Das war hier eben nicht der fall, es war kein Laufwerk mehr da weil man längst auf neuere LTOx gewechselt war, die LTO5 Bänder mit Archiv und LTFS vergessen hatte.
Tja, das ist eben das Problem dabei immer wieder: Man archiviert etwas, vergisst aber die Technik bereit zu halten, wie man notfalls das Archiv zurück holen kann.
Wie ich das hier beobachte kommt dann noch dazu, dass da jede menge gepackte Archiv-Dateien dabei sind, wo ich / kein mensch weiss mit welcher Software die gepackten Archive entstanden.
TOLL!
Kreuzberger
Vom Prinzip her ist mir ja LTFS klar, und eine pfiffige Sache wenn man Kompatibilität hat und Laufwerke hat / einlagert, mit denen man das wieder auslesen kann. Das war hier eben nicht der fall, es war kein Laufwerk mehr da weil man längst auf neuere LTOx gewechselt war, die LTO5 Bänder mit Archiv und LTFS vergessen hatte.
Tja, das ist eben das Problem dabei immer wieder: Man archiviert etwas, vergisst aber die Technik bereit zu halten, wie man notfalls das Archiv zurück holen kann.
Wie ich das hier beobachte kommt dann noch dazu, dass da jede menge gepackte Archiv-Dateien dabei sind, wo ich / kein mensch weiss mit welcher Software die gepackten Archive entstanden.
TOLL!
Kreuzberger
Moin,
das sind eben die Nachteile einer LTFS "Sicherung", mal eben eine handvoll Dateien aus der Sicherung von gestern zurückspielen - kein Problem, aber eine komplette Rücksicherung von überwiegend relativ kleinen Dateien dauert ewig.
Für letzteren Zweck ist doch eher eine richtige Backup-Software geeignet oder man schaltet bspw. eine Imagesoftware vor und sichert das Image auf LTFS.
Dann könnte man auch jeweils die Installationsdatei der verwendeten Software auf das LTFS Medium mit draufpacken, falls dann mal so ein Fall, wie er jetzt auf Deinem Tisch liegt, eintritt.
Im übrigen mach is es inzwischen so, dass ich auf das Bandlabel verwendete Software inkl. Version draufschreibe. Aber das ist nur mein persönlicher Spleen
Habe aber auch viel Software (nur) getestet für Bandbackups, deswegen ist das auch für mich hilfreich...
Gruß
cykes
[EDIT]
das sind eben die Nachteile einer LTFS "Sicherung", mal eben eine handvoll Dateien aus der Sicherung von gestern zurückspielen - kein Problem, aber eine komplette Rücksicherung von überwiegend relativ kleinen Dateien dauert ewig.
Für letzteren Zweck ist doch eher eine richtige Backup-Software geeignet oder man schaltet bspw. eine Imagesoftware vor und sichert das Image auf LTFS.
Dann könnte man auch jeweils die Installationsdatei der verwendeten Software auf das LTFS Medium mit draufpacken, falls dann mal so ein Fall, wie er jetzt auf Deinem Tisch liegt, eintritt.
Im übrigen mach is es inzwischen so, dass ich auf das Bandlabel verwendete Software inkl. Version draufschreibe. Aber das ist nur mein persönlicher Spleen
Habe aber auch viel Software (nur) getestet für Bandbackups, deswegen ist das auch für mich hilfreich...Gruß
cykes
[EDIT]
Wie ich das hier beobachte kommt dann noch dazu, dass da jede menge gepackte Archiv-Dateien dabei sind, wo ich / kein mensch weiss mit welcher Software die gepackten Archive entstanden.
Wie lauten denn die Dateiendungen dieser Archivdateien? Darüber müsste sich doch herausfinden lassen, mit welcher Software die erstellt worden sind. Ansonsten mal auf eine Datei 7zip loslassen, das kann recht viele Formate entpacken.
@cykes
Danke
Aber was nützt mir "nur" die Installationsdatei für eine Software, wenn diese auf aktuellen Systemen nicht mehr installierbar ist?
Archive haben den Sinn, lange Daten einzulagern. Aber wie lange dauert es, dass die betreffende Sicherungssoftware noch Kompatibel verfügbar ist?
Muss man am ende doch einen alten 386er im Keller aufbewahren, damit man mit Windows 3 und irgendwas altem die Daten zurückholen kann?
Darum war mir ja die Idee mit LTFS durchaus Sympathisch. Aber man sollte ein darauf verzichten, zusätzliche Hürden einzubauen und die Daten wie auch immer zu verschlüsseln und zu Packen.
Kreuzberger
Danke
Aber was nützt mir "nur" die Installationsdatei für eine Software, wenn diese auf aktuellen Systemen nicht mehr installierbar ist?
Archive haben den Sinn, lange Daten einzulagern. Aber wie lange dauert es, dass die betreffende Sicherungssoftware noch Kompatibel verfügbar ist?
Muss man am ende doch einen alten 386er im Keller aufbewahren, damit man mit Windows 3 und irgendwas altem die Daten zurückholen kann?
Darum war mir ja die Idee mit LTFS durchaus Sympathisch. Aber man sollte ein darauf verzichten, zusätzliche Hürden einzubauen und die Daten wie auch immer zu verschlüsseln und zu Packen.
Kreuzberger
... hat sich jetzt etwas überschnitten, aber ich hatte zwischenzeitlich oben noch was ergänzt. [EDIT] ....
@cykes
derzeit schaufelt er tonnenweise "laufende_nummerierung.exr" Dateien.
Es waren aber auch noch andere Endungen zu sehen.
Kreuzberger
derzeit schaufelt er tonnenweise "laufende_nummerierung.exr" Dateien.
Es waren aber auch noch andere Endungen zu sehen.
Kreuzberger
Ist es evtl möglich unter Linux mit DD ein Image vom Band zu erstellen und dieses dann zu Mounten ?
@kaiand1
Danke
Es ist derzeit nicht das Problem die Daten vom Band zu kratzen. Das funktioniert ja, wenn auch langsam.
Ich weiß leider nicht, wie ich den SAS-HBA und das SAS LTO-Laufwerk in ein Linux einbinden könnte. Daher steht DD nicht zur Verfügung.
Kreuzberger
Danke
Es ist derzeit nicht das Problem die Daten vom Band zu kratzen. Das funktioniert ja, wenn auch langsam.
Ich weiß leider nicht, wie ich den SAS-HBA und das SAS LTO-Laufwerk in ein Linux einbinden könnte. Daher steht DD nicht zur Verfügung.
Kreuzberger
*.exr sind tatsächlich keine gepackten Archive in dem Sinne. Das sind HDR-Bilddateien, siehe u.a. de.wikipedia.org/wiki/OpenEXR
Dafür gibt es u.a. ein Photoshop-Plugin: www-exr--io-com.translate.goog/?_x_tr_sl=en&_x_tr_tl=de& ...
(Google(s KI) meinte es bei dem Link besonders gut und hat den Übersetzer angeworfen, hier noch der originale Link: exr-io.com/)
Wahrscheinlich ist der Rest etwas ähnliches, aber nenne doch einfach später nochmal die Dateiendungen ...
Dafür gibt es u.a. ein Photoshop-Plugin: www-exr--io-com.translate.goog/?_x_tr_sl=en&_x_tr_tl=de& ...
(Google(s KI) meinte es bei dem Link besonders gut und hat den Übersetzer angeworfen, hier noch der originale Link: exr-io.com/)
Wahrscheinlich ist der Rest etwas ähnliches, aber nenne doch einfach später nochmal die Dateiendungen ...
[...] Daher steht DD nicht zur Verfügung.
Notfalls unter Win* mal folgendes probieren: chrysocome.net/dd
@cykes
Ich hab jetzt erst einen Gedanken begriffen. Man macht ein Image vom Band und kann wenn es auf der Platte ist schneller auf die innenliegenden Daten des Images Zugreifen.
Bei LTFS wird das Band partitioniert. Ich weiss nicht, ob das dann so einfach funktioniert. In einem kleinen ersten Bandabschnitt scheint mir eine art Inhaltstabelle zu liegen, im dann folgenden größeren Abschnitt (Partition) eben die eigentlichen Daten.
Kreuzberger
Ich hab jetzt erst einen Gedanken begriffen. Man macht ein Image vom Band und kann wenn es auf der Platte ist schneller auf die innenliegenden Daten des Images Zugreifen.
Bei LTFS wird das Band partitioniert. Ich weiss nicht, ob das dann so einfach funktioniert. In einem kleinen ersten Bandabschnitt scheint mir eine art Inhaltstabelle zu liegen, im dann folgenden größeren Abschnitt (Partition) eben die eigentlichen Daten.
Kreuzberger
Zitat von @kreuzberger:
@cykes
Ich hab jetzt erst einen Gedanken begriffen. Man macht ein Image vom Band und kann wenn es auf der Platte ist schneller auf die innenliegenden Daten des Images Zugreifen.
Bei LTFS wird das Band partitioniert. Ich weiss nicht, ob das dann so einfach funktioniert. In einem kleinen ersten Bandabschnitt scheint mir eine art Inhaltstabelle zu liegen, im dann folgenden größeren Abschnitt (Partition) eben die eigentlichen Daten.
Kreuzberger
@cykes
Ich hab jetzt erst einen Gedanken begriffen. Man macht ein Image vom Band und kann wenn es auf der Platte ist schneller auf die innenliegenden Daten des Images Zugreifen.
Bei LTFS wird das Band partitioniert. Ich weiss nicht, ob das dann so einfach funktioniert. In einem kleinen ersten Bandabschnitt scheint mir eine art Inhaltstabelle zu liegen, im dann folgenden größeren Abschnitt (Partition) eben die eigentlichen Daten.
Kreuzberger
Ja des war der Gedanke dazu.
Denn würde des Band am Stück eingelesen und von der Platte denn Ausgelesen werden wo des "Rumspulen" entfällt und auch ggfs Schneller ist beim Auslesen...
@kaiand1
Ja, im Prinzip ne kuhle Idee, aber ich weiss nicht, wie ich den SAS Controller und das LTO5 Laufwerk (SAS) in ein Linux einbinde, samt dann welche LTFS-Software für Linux dann halt funktioniert.
Krezberger
Ja, im Prinzip ne kuhle Idee, aber ich weiss nicht, wie ich den SAS Controller und das LTO5 Laufwerk (SAS) in ein Linux einbinde, samt dann welche LTFS-Software für Linux dann halt funktioniert.
Krezberger
Moin,
das ist jetzt voll ins Blaue geraten.
Mit Winimage habe ich ganz früher images von Diskette und später Images von USB Sticks erstellt.
Vieleicht funktioniert das mit diesem Device auch?
chip.de/downloads/WinImage-64-Bit_40730445.html
Oder eine sonstige Images-Software für Windows probieren?
Stefan
das ist jetzt voll ins Blaue geraten.
Mit Winimage habe ich ganz früher images von Diskette und später Images von USB Sticks erstellt.
Vieleicht funktioniert das mit diesem Device auch?
chip.de/downloads/WinImage-64-Bit_40730445.html
Oder eine sonstige Images-Software für Windows probieren?
Stefan
Zitat von @kreuzberger:
@kaiand1
Ja, im Prinzip ne kuhle Idee, aber ich weiss nicht, wie ich den SAS Controller und das LTO5 Laufwerk (SAS) in ein Linux einbinde, samt dann welche LTFS-Software für Linux dann halt funktioniert.
Teste doch einfach mal, wie sich ein Knoppix verhält. Vom Stick starten und schauen ob das Drive und auch das gemountete Tape erkannt wird!?@kaiand1
Ja, im Prinzip ne kuhle Idee, aber ich weiss nicht, wie ich den SAS Controller und das LTO5 Laufwerk (SAS) in ein Linux einbinde, samt dann welche LTFS-Software für Linux dann halt funktioniert.
Hier mal etwas Lesestoff für Debian:
forum.vcfed.org/index.php?threads/tapes-a-few-pointers-when-usin ...
(Selbst aber nicht nachgestellt…)
Moin @kreuzberger,
wenn du die Daten schnell zurücksichern möchtest, dann kommst du an dieser Idee fürchte ich nicht wirklich vorbei.
LTFS Treiber installieren.
Dann Bandgerät identifizieren ...
... LTFS mounten ...
... und dann denn Inhalt des Bandes ...
... in ein TAR Archiv speichern. 😉
Ein RAW Image von dem Band, kannst du übrigens folgen ...
... erzeugen.
Gruss Alex
Ja, im Prinzip ne kuhle Idee,
wenn du die Daten schnell zurücksichern möchtest, dann kommst du an dieser Idee fürchte ich nicht wirklich vorbei.
aber ich weiss nicht, wie ich den SAS Controller und das LTO5 Laufwerk (SAS) in ein Linux einbinde, samt dann welche LTFS-Software für Linux dann halt funktioniert.
LTFS Treiber installieren.
Dann Bandgerät identifizieren ...
lsscsi... LTFS mounten ...
sudo mkdir /mnt/ltfs
sudo ltfs /mnt/ltfs -o devname=/dev/st0... und dann denn Inhalt des Bandes ...
sudo tar -cvf ltfs_band_backup.tar /mnt/ltfs... in ein TAR Archiv speichern. 😉
Ein RAW Image von dem Band, kannst du übrigens folgen ...
sudo dd if=/dev/st0 of=ltfs_band_raw.img bs=512... erzeugen.
Gruss Alex
@em-pie
Danke.
Aber ... aus dem nichts heraus nach dem booten von Knoppix kann so ein band doch nicht automatisch gemutet sein, oder?
danach bleibt die frage, wie konoppix das LTFS (FileSeystem) behandelt. Es ist eben ein eigenes FileSystem, was unterstützt werden müsste.
Derzeit liesst der per robocopy ein band aus. Das funktioniert audf Windows Server 2022, aber eben langsaaaaaaaaam, für jeden Mist muss der her und hin spulen. Das dauert bis Ostern 2076.
Ich hatte die Idee, dass man einfach copy oder xcopy benutzt, weil das ggf das zuerst kopiert, was es als erstes findet, und nicht wie robocopy auf den alphabetisch geordneten Verzeichnisbaum Rücksicht nimmt. Kann das hinkommen?
Was die Ideen mit Linux angeht hab ich da zu wenig Erfahrung / Ahnung. Ich hatte das Problem bereits bei meinem Bacula-Projekt, dass die Hardware-Einbindung von SAS und LTO mir nicht klar ist. Das ist dann auch hier so. Hier käme dann das FileSystem LTFS noch oben drauf.
Es gibt ja offensichtlich hier ein paar tolle ITler, die sich mit Linux super auskennen. Aber eben diese Stelle der Hardware-Implementierung wurde bisher nicht beschrieben.
Kreuzberger
Danke.
Aber ... aus dem nichts heraus nach dem booten von Knoppix kann so ein band doch nicht automatisch gemutet sein, oder?
danach bleibt die frage, wie konoppix das LTFS (FileSeystem) behandelt. Es ist eben ein eigenes FileSystem, was unterstützt werden müsste.
Derzeit liesst der per robocopy ein band aus. Das funktioniert audf Windows Server 2022, aber eben langsaaaaaaaaam, für jeden Mist muss der her und hin spulen. Das dauert bis Ostern 2076.
Ich hatte die Idee, dass man einfach copy oder xcopy benutzt, weil das ggf das zuerst kopiert, was es als erstes findet, und nicht wie robocopy auf den alphabetisch geordneten Verzeichnisbaum Rücksicht nimmt. Kann das hinkommen?
Was die Ideen mit Linux angeht hab ich da zu wenig Erfahrung / Ahnung. Ich hatte das Problem bereits bei meinem Bacula-Projekt, dass die Hardware-Einbindung von SAS und LTO mir nicht klar ist. Das ist dann auch hier so. Hier käme dann das FileSystem LTFS noch oben drauf.
Es gibt ja offensichtlich hier ein paar tolle ITler, die sich mit Linux super auskennen. Aber eben diese Stelle der Hardware-Implementierung wurde bisher nicht beschrieben.
Kreuzberger
Moin @kreuzberger,
also doch Windows.
Hast du dir auch schon mal die LTFS Tools von IBM, respektive " IBM Spectrum Archive Single Drive Edition (SDE)" angesehen.
ibm.com/docs/en/spectrum-archive-le?topic=tools-downloading-ltfs
Gruss Alex
Das funktioniert audf Windows Server 2022, aber eben langsaaaaaaaaam, für jeden Mist muss der her und hin spulen. Das dauert bis Ostern 2076.
also doch Windows.
Hast du dir auch schon mal die LTFS Tools von IBM, respektive " IBM Spectrum Archive Single Drive Edition (SDE)" angesehen.
ibm.com/docs/en/spectrum-archive-le?topic=tools-downloading-ltfs
Gruss Alex
@MysticFoxDE
Was bedeutet diese Bemerkung? Ich nehme eben das, was mir zur verfügung steht.
Ja, hab ich. Wie ich das mitbekomme unterstützt die software von IBM wohl auch nur Laufwerke von IBM. Deshalb hab ich die HP-Software genommen, mit der kann Ich halt auslesen.
Kreuzberger
also doch Windows.
Was bedeutet diese Bemerkung? Ich nehme eben das, was mir zur verfügung steht.
Hast du dir auch schon mal die LTFS Tools von IBM, respektive " IBM Spectrum Archive Single Drive Edition (SDE)" angesehen.
Ja, hab ich. Wie ich das mitbekomme unterstützt die software von IBM wohl auch nur Laufwerke von IBM. Deshalb hab ich die HP-Software genommen, mit der kann Ich halt auslesen.
Kreuzberger
Moin @kreuzberger,
Was bedeutet diese Bemerkung? Ich nehme eben das, was mir zur verfügung steht.
absolut nichts negatives!
Ich habe lediglich deine folgende Anwort ...
LTFS und Restore
... übersehen und erst bei der hier ...
LTFS und Restore
... gemerkt mit was du die Daten von den LTO Bändern herunterkratzen möchtest. 🙃
Ja, hab ich. Wie ich das mitbekomme unterstützt die software von IBM wohl auch nur Laufwerke von IBM. Deshalb hab ich die HP-Software genommen, mit der kann Ich halt auslesen.
HP (HPE) hat schon damals keine eigenen LTO-Drives gebaut, sondern nur die von IBM oder Quantum umgelabelt.
Wie schon geschrieben, versuch es mal mit den IBM Tools ...
Quelle:
ibm.com/docs/en/spectrum-archive-le?topic=tools-ltfs-copy-tool
... denn die scheinen schon eher das zu können was du benötigst.
Gruss Alex
also doch Windows.
Was bedeutet diese Bemerkung? Ich nehme eben das, was mir zur verfügung steht.
absolut nichts negatives!
Ich habe lediglich deine folgende Anwort ...
LTFS und Restore
... übersehen und erst bei der hier ...
LTFS und Restore
... gemerkt mit was du die Daten von den LTO Bändern herunterkratzen möchtest. 🙃
Hast du dir auch schon mal die LTFS Tools von IBM, respektive " IBM Spectrum Archive Single Drive Edition (SDE)" angesehen.
Ja, hab ich. Wie ich das mitbekomme unterstützt die software von IBM wohl auch nur Laufwerke von IBM. Deshalb hab ich die HP-Software genommen, mit der kann Ich halt auslesen.
HP (HPE) hat schon damals keine eigenen LTO-Drives gebaut, sondern nur die von IBM oder Quantum umgelabelt.
Wie schon geschrieben, versuch es mal mit den IBM Tools ...
Quelle:
ibm.com/docs/en/spectrum-archive-le?topic=tools-ltfs-copy-tool
... denn die scheinen schon eher das zu können was du benötigst.
Gruss Alex
@MysticFoxDE
Ah, danke, moin moin.
Ich hab auch die IBM Software da. Bisher war aber das Problem, dass die Hardware nicht kompatibel gewesen ist. Ich kann es aber noch mal probieren.
Letztlich bindet die Software nur ein Laufwerksmapping ins System ein, und das wars. Es kann die Reihenfolge, wie die Daten auf dem band bereits sind ja nicht beeinflussen. Es geht eher darum, wenn man so ein band komplett ausliesst, die Daten egal wie sie liegen einfach kopiert.
Kreuzberger
Ah, danke, moin moin.
Ich hab auch die IBM Software da. Bisher war aber das Problem, dass die Hardware nicht kompatibel gewesen ist. Ich kann es aber noch mal probieren.
Letztlich bindet die Software nur ein Laufwerksmapping ins System ein, und das wars. Es kann die Reihenfolge, wie die Daten auf dem band bereits sind ja nicht beeinflussen. Es geht eher darum, wenn man so ein band komplett ausliesst, die Daten egal wie sie liegen einfach kopiert.
Kreuzberger
Moin @kreuzberger,
Vielleicht ist da auch ein Quantum Laufwerk verbaut, so genau habe ich das jetzt selber nicht geprüft.
Nein, ganz egal ist das nicht ganz.
Denn die Dateistruktur von LTFS wird meistens in der Reihenfolge auf die Index Partition des entsprechenden Bandes geschrieben, in der auch die Daten auf der Daten-Partition landen, zumindest wenn nachträglich nicht gelöscht oder verändert wurde.
Sprich, du benötigst lediglich ein Tool, welches die Daten in genau der Reihenfolge von dem Band liest, wie auch die Index Einträge geschrieben wurden und schon kannst du es sequentiell auslesen.
Und genau das, sollte mit der bereits angesprochenen IBM Software, eigentlich auch möglich sein.
Gruss Alex
Ich hab auch die IBM Software da. Bisher war aber das Problem, dass die Hardware nicht kompatibel gewesen ist. Ich kann es aber noch mal probieren.
Vielleicht ist da auch ein Quantum Laufwerk verbaut, so genau habe ich das jetzt selber nicht geprüft.
Letztlich bindet die Software nur ein Laufwerksmapping ins System ein, und das wars. Es kann die Reihenfolge, wie die Daten auf dem band bereits sind ja nicht beeinflussen. Es geht eher darum, wenn man so ein band komplett ausliesst, die Daten egal wie sie liegen einfach kopiert.
Nein, ganz egal ist das nicht ganz.
Denn die Dateistruktur von LTFS wird meistens in der Reihenfolge auf die Index Partition des entsprechenden Bandes geschrieben, in der auch die Daten auf der Daten-Partition landen, zumindest wenn nachträglich nicht gelöscht oder verändert wurde.
Sprich, du benötigst lediglich ein Tool, welches die Daten in genau der Reihenfolge von dem Band liest, wie auch die Index Einträge geschrieben wurden und schon kannst du es sequentiell auslesen.
Und genau das, sollte mit der bereits angesprochenen IBM Software, eigentlich auch möglich sein.
Gruss Alex
Moin @kreuzberger,
das ist definitiv ein ...
ibm.com/support/pages/hp-oracle-quantum-and-tandberg-ultrium-gen ...
... IBM Laufwerk. 😉
Ähm ... Moment ... das was ich das sehe, bedeutet ja, dass auch Quantum schon mindestens seit LTO5 keine eigenen Laufwerke mehr baut. 😬
Und ich dachte bisher, dass die erst bei LTO 8 oder 9 ausgestiegen sind. 😔
Gruss Alex
Vielleicht ist da auch ein Quantum Laufwerk verbaut, so genau habe ich das jetzt selber nicht geprüft.
das ist definitiv ein ...
ibm.com/support/pages/hp-oracle-quantum-and-tandberg-ultrium-gen ...
... IBM Laufwerk. 😉
Ähm ... Moment ... das was ich das sehe, bedeutet ja, dass auch Quantum schon mindestens seit LTO5 keine eigenen Laufwerke mehr baut. 😬
Und ich dachte bisher, dass die erst bei LTO 8 oder 9 ausgestiegen sind. 😔
Gruss Alex
Ähm ... Moment ... das was ich das sehe, bedeutet ja, dass auch Quantum schon mindestens seit LTO5 keine eigenen Laufwerke mehr baut. 😬
Und ich dachte bisher, dass die erst bei LTO 8 oder 9 ausgestiegen sind. 😔
Nein, das ist schon richtig, daß Quantum seit LTO5 keine Laufwerke mehr herstellt. HP ist glaube ich auch irgendwann ausgestiegen. Finde es nur momentan nicht.Und ich dachte bisher, dass die erst bei LTO 8 oder 9 ausgestiegen sind. 😔
Gruss Penny.
Update:
Die rödelt noch immer seit gestern auf dem selben Band herum.
@MysticFoxDE
In der HP Software findet sich ein "HU1129HGCA (HP LTO5)".
Nun, ich benutze ja den Windows Explorer bzw. robocopy zum Auslesen der Tapes. Bei der HP Software findet sich nach Installation nicht nur die Configuration Software (Drive Mappings Anlegern) sondern auch dieser Cartrige Browser. Ich dachte der Browser ist so eine Art Offline-Suchhilfe, der eine Art Catalog aller beschriebener Bänder erstellt. Das kann aber für diese Bänder nicht da sein, da die Bänder ja nicht von Mir befüllt wurden.
Kreuzberger
Die rödelt noch immer seit gestern auf dem selben Band herum.
@MysticFoxDE
Vielleicht ist da auch ein Quantum Laufwerk verbaut, so genau habe ich das jetzt selber nicht geprüft.
In der HP Software findet sich ein "HU1129HGCA (HP LTO5)".
Nun, ich benutze ja den Windows Explorer bzw. robocopy zum Auslesen der Tapes. Bei der HP Software findet sich nach Installation nicht nur die Configuration Software (Drive Mappings Anlegern) sondern auch dieser Cartrige Browser. Ich dachte der Browser ist so eine Art Offline-Suchhilfe, der eine Art Catalog aller beschriebener Bänder erstellt. Das kann aber für diese Bänder nicht da sein, da die Bänder ja nicht von Mir befüllt wurden.
Kreuzberger
Update:
ich lese gerade Inder Region:
support.hpe.com/hpesc/public/docDisplay?docId=sd00001247en_us&am ...
Natürlich hab ich das Programm ausprobiert nach der Anleitung, da es ja auch mit der HP Software eh mit installiert wurde.
Mein Band Mapping ist H:
(Die Schrägstriche sind im Bildschirm korrekt.)
Schulterzuck, bzgl der Error-meldung.
Kreuzberger
ich lese gerade Inder Region:
support.hpe.com/hpesc/public/docDisplay?docId=sd00001247en_us&am ...
Natürlich hab ich das Programm ausprobiert nach der Anleitung, da es ja auch mit der HP Software eh mit installiert wurde.
Mein Band Mapping ist H:
"C:/Program Files/HPE/LTFS/ltfscopy.exe" -s H:/ -d D:/FS2_LTFS
Error: either the source or the destination (or both) must be on an LTFS Volume(Die Schrägstriche sind im Bildschirm korrekt.)
Schulterzuck, bzgl der Error-meldung.
Kreuzberger
Moin,
Nach meinem Verständnis deines Links muss das aber so lauten:
Nach meinem Verständnis deines Links muss das aber so lauten:
ltfscopy.exe –s H:\ -d D:\FS2_LTFS --recursiveZitat von @em-pie:
Moin,
Nach meinem Verständnis deines Links muss das aber so lauten:
Soweit ich weiß, kann W2K22 auch mit dem Slash ( / ) umgehen. Im Prinzip hast Du Recht. Windows wandelt den Slash in Backslash um.Moin,
Nach meinem Verständnis deines Links muss das aber so lauten:
ltfscopy.exe –s H:\ -d D:\FS2_LTFS --recursiveGruss Penny.
Ohh, das mit dem Slash 2 Backslash wusste ich noch gar nicht.
Ich hab auch eher an das Recursive gedacht
Ich hab auch eher an das Recursive gedacht
Hey, Leute, ich hab doch dazu geschrieben dass der slash/backslash korrekt im windows eingegeben war/ist. Ich hab das hier deshalb nur "falsch" eingegeben weil ich hier auf dem MAC in der Seite bin.
Mir ging es eher um die absurde Fehlermeldung.
Kreuzberger
Mir ging es eher um die absurde Fehlermeldung.
Kreuzberger
Mir ging es eher um die absurde Fehlermeldung.
Ruhig Blut, Börliner. Nitt nervös werden.Wenn ich mir Deinen Link durchlesen, scheint mir daß es mit den Pfaden sprich Quelle und Ziel zusammen hängt.
Im folgenden Beispiel sind Quellpfad und Zielpfad identisch.
ltfscopy.exe –s E:\photos\ -d C:\photos --recursiveBei Dir ist der Quellpfad H:\
Und Zielpfad D:\FS2_LTFS
Man müsste rausfinden ob der Quellpfad restorefähige Daten hat. Oder den Zielpfad anpassen.
Sprich
ltfscopy.exe –s H:\ -d D:\ --recursiveGruss Penny.
@Penny.Cilin
Mein LTO5 Laufwerk habe ich mit der HP Konfiguration Software auf H: gemalt. Immer, wenn da ein LTFS Formatiertes Band eingelegt wird, wird das untere H: automatisch "gemounted".
Bei diesem Band hatte ich per robocopy auch bereits Daten in die selbigen Ordner kopiert, also von H: nach D:/FS2_LTFS.
D: ist hier eine fast leere interne 8TB Platte im Windows Server.
Das band enthält also definitiv Daten im LTFS-Format. Ich hab auf anderem Weg von diesem Band ja schon kopiert.
Es ist mir unerklärlich, wie aber "ltfscopy.exe" die Fehlermeldung ausgibt, es sei kein LTFS-Band angegeben. Ist es aber bei mir mit H:.
Kreuzberger
Mein LTO5 Laufwerk habe ich mit der HP Konfiguration Software auf H: gemalt. Immer, wenn da ein LTFS Formatiertes Band eingelegt wird, wird das untere H: automatisch "gemounted".
Bei diesem Band hatte ich per robocopy auch bereits Daten in die selbigen Ordner kopiert, also von H: nach D:/FS2_LTFS.
D: ist hier eine fast leere interne 8TB Platte im Windows Server.
Das band enthält also definitiv Daten im LTFS-Format. Ich hab auf anderem Weg von diesem Band ja schon kopiert.
Es ist mir unerklärlich, wie aber "ltfscopy.exe" die Fehlermeldung ausgibt, es sei kein LTFS-Band angegeben. Ist es aber bei mir mit H:.
Kreuzberger
Die Fehlermeldung weißt doch im Prinzip auf den Fehler hin. Entweder das Qell- oder Ziel oder beide müssen ein LTFS Volume sein.
Error: either the source or the destination (or both) must be on an LTFS Volume
Ja, eben.
Und bei mir ist eben H: das gemappte, eingelegte LTFS Band, von dem ich per Windows Explorer durchaus Daten kopieren kann.
Kreuzberger
Und bei mir ist eben H: das gemappte, eingelegte LTFS Band, von dem ich per Windows Explorer durchaus Daten kopieren kann.
Kreuzberger
Die Fehlermeldung weißt doch im Prinzip auf den Fehler hin. Entweder das Qell- oder Ziel oder beide müssen ein LTFS Volume sein.
Ähm hast Du nicht den Parameter vergessen?
Weil vielleicht Subdirectories (Unterverzeichnisse) existieren?
Gruss Penny.
Error: either the source or the destination (or both) must be on an LTFS Volume
Ähm hast Du nicht den Parameter
--copy Weil vielleicht Subdirectories (Unterverzeichnisse) existieren?
Gruss Penny.
Da sind die Parameter beschrieben:
support.hpe.com/hpesc/public/docDisplay?docId=sd00001247en_us&am ...
Wie is das verstehe ist --copy optional nur dann nötig, wem na --verify nutzen will, aber sonst überflüssig.
Kreuzberger
support.hpe.com/hpesc/public/docDisplay?docId=sd00001247en_us&am ...
Wie is das verstehe ist --copy optional nur dann nötig, wem na --verify nutzen will, aber sonst überflüssig.
Kreuzberger
Wie is das verstehe ist --copy optional nur dann nötig, wem na --verify nutzen will, aber sonst überflüssig.
Nein, man kann --verify in Verbindung mit --copy nutzen.
Statt hier rum zu diskutieren einfach ausprobieren.
Mehr wie eine Fehlermeldung sollte nicht passieren.
Gruss Penny.
ausprobiert.
Es kommt die gleiche Fehlermeldung.
sorry
Kreuzberger
Es kommt die gleiche Fehlermeldung.
sorry
Kreuzberger
Moin @Penny.Cilin,
Nein, man kann --verify in Verbindung mit --copy nutzen.
Statt hier rum zu diskutieren einfach ausprobieren.
Mehr wie eine Fehlermeldung sollte nicht passieren.
@kreuzberger hat Recht, die Parameter "--copy" und "--verify" sind nicht wirklich notwendig.
Siehe auch ...
support.hpe.com/hpesc/public/docDisplay?docId=sd00001247en_us&am ...
Gruss Alex
Wie is das verstehe ist --copy optional nur dann nötig, wem na --verify nutzen will, aber sonst überflüssig.
Nein, man kann --verify in Verbindung mit --copy nutzen.
Statt hier rum zu diskutieren einfach ausprobieren.
Mehr wie eine Fehlermeldung sollte nicht passieren.
@kreuzberger hat Recht, die Parameter "--copy" und "--verify" sind nicht wirklich notwendig.
Siehe auch ...
support.hpe.com/hpesc/public/docDisplay?docId=sd00001247en_us&am ...
To copy files and all subfolders and files recursively:
ltfscopy.exe –s E:\photos\ -d C:\photos --recursiveGruss Alex
Okay, dann tippe ich Mal darauf, daß das Band kein LTFS Volume ist. Oder hast Du von diesem Band schon Daten kopieren können?
Gegebenenfalls Versuche es mit einem anderen Band.
Gruss Penny.
Gegebenenfalls Versuche es mit einem anderen Band.
Gruss Penny.
Okay, dann tippe ich Mal darauf, daß das Band kein LTFS Volume ist.
Den Verdacht habe ich auch so langsam, insbesondere, weil @kreuzberger in 2022 div. Bänder geplättet hat:LTO-5 Bänder Löschen geht nicht
Oder hast Du von diesem Band schon Daten kopieren können?
Ja, habe ich. siehe oben.
Update:
Ich habe das Kopieren von diesem Band abgebrochen.
Ich habe ein neues, leeres Band genommen und mit dem HP Tool als LTFS Formatiert.
Das Band wird erkannt als Laufwerk H:
Ich habe dieses ltfscopy.exe nun erneut beim Wickel:
Ich bin direkt per CMD/Eingabeaufforderung in das Verzeichnis gewechselt, wo ltfscopy.exe liegt. (Das ist bei mir: "C:/Program Files/HPE/LTFS/")
Dort habe ich das Programm erneut gestartet um von einem SYNOLOGY (SMB-Freigabe) einfach mal FLAC Dateien auf dieses frisch formatierte Band zu kopieren. Das sind in dem Ordner und Unterordner etwa 850GB. Das SYNO ist ein 920+ mit NVME-Cache-Modulen, also flott.
Und siehe da, er macht es, aber:
Etwa alle 2-3 sec schiebt er das Band her und hin, kopiert aber unerlässlich Daten. Laut Netzwerkkarte gehen da ca 42MB/s durch.
GEIL ist anders.
und: nach ca. 6,25GB brach er einfach mit Fehlermeldung ab, gab eine "Summery" aus, das wars.
Fehlermeldung: Kann eine bestimmte Datei nicht kopieren.
Kreuzberger
Update:
Ich kopiere gerade Ordnerweise Daten von diesem SYNO auf das Band per grafischem Windows Explorer und klicky-bunty-Mausschubsen.
Bisher funktioniert das am besten. Im schnitt kopiert der dabei so etwa 50MB/s aufs Band.
Kreuzberger
Ich kopiere gerade Ordnerweise Daten von diesem SYNO auf das Band per grafischem Windows Explorer und klicky-bunty-Mausschubsen.
Bisher funktioniert das am besten. Im schnitt kopiert der dabei so etwa 50MB/s aufs Band.
Kreuzberger
Ich kopiere gerade Ordnerweise Daten von diesem SYNO auf das Band
Heißt, es wird direkt auf H: keine einzelnen Dateien geben, sondern es liegt alles in Ordnerstrukturen?Dann musst du beim Test von Tape2Disk in jedem Fall den
-- recursive-Parameter mit benutzen.Edit: was mir gerade noch einfällt (für den Abbruch beim Disk2Tape):
Wenn der Puffer des SAS-Controllers vollläuft und die Daten nicht schnell genug aufs Band bringen kann, könnte es vielleicht solch eine. Fehler verursachen (ist aber eine reine Vermutung und kein Wissen!!!)
@em-pie
Missverständnis.
Ich kopiere gerade mit dem grafischen Windows Explorer, per Maus schubsen.
Das - sorry - funktioniert derzeit vergleichsweise am besten.
Kreuzberger
Missverständnis.
Ich kopiere gerade mit dem grafischen Windows Explorer, per Maus schubsen.
Das - sorry - funktioniert derzeit vergleichsweise am besten.
Kreuzberger
Das habe ich schon verstanden!
Aber dein Kernproblem ist doch, dass du nichts vom Band auf eine Platte (HDD/ SSD/ NAS) in passabler Geschwindigkeit kopieren kannst.
Deshalb das o.g. CLI-Tool, welches aber abbricht.
Um grundsätzlich zu prüfen, kopierst du gerade Daten auf ein frisch formatiertes (LTFS)-Tape um dann zu verifizieren, dass das o.g. Tool doch (nicht) funktioniert
Oder habe ich doch was übersehen?
Aber dein Kernproblem ist doch, dass du nichts vom Band auf eine Platte (HDD/ SSD/ NAS) in passabler Geschwindigkeit kopieren kannst.
und es sollen einige Kisten voll mit LTO5 Bändern zurückgeschrieben werden auf Festplatten.
Deshalb das o.g. CLI-Tool, welches aber abbricht.
Um grundsätzlich zu prüfen, kopierst du gerade Daten auf ein frisch formatiertes (LTFS)-Tape um dann zu verifizieren, dass das o.g. Tool doch (nicht) funktioniert
Oder habe ich doch was übersehen?
@em-pie
ja, genau so, oder in etwa so dachte ich mir das.
Da kein Mensch weiß wie die Bänder in den Kisten entstanden sind dachte ich mir jetzt mal selbst ein Band zu befüllen um vergleichsweise so mal die sinnvollste Handhabung damit zu finden.
Dieses ltfscopy.exe scheint mir zu instabil zu sein und ich habe nicht erkennen können, ob es wirklich so kopiert, wie die Daten auf den Band sind, oder nach einem anderen Chema, etwa wie robocopy das macht (alphanumerische Reihenfolge der Ordner und Daten).
Die Daten liegen auf den Bändern aber physisch nicht in der alphanumerischen Reihenfolge vor, sondern so wie sie der Reihenfolge nach eben darauf geschrieben wurden. Das führt beim Auslesen bei Programmen wie robocopy eben dazu, dass sehr viel her und hin gespult wird, was das ganze zum Auslesen unerträglich langsam macht.
Welches Programm die "Speichertabelle / Speicherreihenfolge" auf dem Band ausliesst und eine daraus eine optimale Rückkopierreihenfolge berücksichtigt ist derzeit die große Frage.
Kopiert man aber das gesamte Band zurück sollte die Reihenfolge ja Wurscht sein, dann soll es kopieren wie auf den Band eben ist.
Kreuzberger
ja, genau so, oder in etwa so dachte ich mir das.
Da kein Mensch weiß wie die Bänder in den Kisten entstanden sind dachte ich mir jetzt mal selbst ein Band zu befüllen um vergleichsweise so mal die sinnvollste Handhabung damit zu finden.
Dieses ltfscopy.exe scheint mir zu instabil zu sein und ich habe nicht erkennen können, ob es wirklich so kopiert, wie die Daten auf den Band sind, oder nach einem anderen Chema, etwa wie robocopy das macht (alphanumerische Reihenfolge der Ordner und Daten).
Die Daten liegen auf den Bändern aber physisch nicht in der alphanumerischen Reihenfolge vor, sondern so wie sie der Reihenfolge nach eben darauf geschrieben wurden. Das führt beim Auslesen bei Programmen wie robocopy eben dazu, dass sehr viel her und hin gespult wird, was das ganze zum Auslesen unerträglich langsam macht.
Welches Programm die "Speichertabelle / Speicherreihenfolge" auf dem Band ausliesst und eine daraus eine optimale Rückkopierreihenfolge berücksichtigt ist derzeit die große Frage.
Kopiert man aber das gesamte Band zurück sollte die Reihenfolge ja Wurscht sein, dann soll es kopieren wie auf den Band eben ist.
Kreuzberger
Moin @kreuzberger,
das merkst du recht schnell ob ltfscopy.exe die Daten genau so ausliest wie sie geschrieben wurden, denn in dem Fall wird das Band nicht ständig hin und her gespult.
Unter Windows hast du hier aber nicht wirklich viel Auswahl … OK, bei den Pinguinen ist es auch nicht viel mehr.
Und genau dafür, benötigst du eben eine Software, die die Daten gemäss der Reihenfolge der Indexeinträge ausliest und genau das sollte ltfscopy.exe auch machen.
Ist das eigentlich dasselbe Bandlaufwerk, mit dem die entsprechenden Bänder auch geschrieben wurden?
Vielleicht hat auch das Laufwerk und oder das Band einen Schaden.
Hast du es mal mit einem anderen versucht.
Gruss Alex
Dieses ltfscopy.exe scheint mir zu instabil zu sein und ich habe nicht erkennen können, ob es wirklich so kopiert, wie die Daten auf den Band sind, oder nach einem anderen Chema, etwa wie robocopy das macht (alphanumerische Reihenfolge der Ordner und Daten).
das merkst du recht schnell ob ltfscopy.exe die Daten genau so ausliest wie sie geschrieben wurden, denn in dem Fall wird das Band nicht ständig hin und her gespult.
Die Daten liegen auf den Bändern aber physisch nicht in der alphanumerischen Reihenfolge vor, sondern so wie sie der Reihenfolge nach eben darauf geschrieben wurden. Das führt beim Auslesen bei Programmen wie robocopy eben dazu, dass sehr viel her und hin gespult wird, was das ganze zum Auslesen unerträglich langsam macht.
Welches Programm die "Speichertabelle / Speicherreihenfolge" auf dem Band ausliesst und eine daraus eine optimale Rückkopierreihenfolge berücksichtigt ist derzeit die große Frage.
Welches Programm die "Speichertabelle / Speicherreihenfolge" auf dem Band ausliesst und eine daraus eine optimale Rückkopierreihenfolge berücksichtigt ist derzeit die große Frage.
Unter Windows hast du hier aber nicht wirklich viel Auswahl … OK, bei den Pinguinen ist es auch nicht viel mehr.
Kopiert man aber das gesamte Band zurück sollte die Reihenfolge ja Wurscht sein, dann soll es kopieren wie auf den Band eben ist.
Und genau dafür, benötigst du eben eine Software, die die Daten gemäss der Reihenfolge der Indexeinträge ausliest und genau das sollte ltfscopy.exe auch machen.
Ist das eigentlich dasselbe Bandlaufwerk, mit dem die entsprechenden Bänder auch geschrieben wurden?
Vielleicht hat auch das Laufwerk und oder das Band einen Schaden.
Hast du es mal mit einem anderen versucht.
Gruss Alex
@MysticFoxDE
Leider nein. Das verwendete Laufwerk existiert nicht mehr, man hatte da längst auf neuere LTO-Versionen umgestellt, aber die Archiv-Bänder vergessen.
Das HPE-Laufwerk (Typ siehe oben), was ich derzeit dafür benutze funktioniert soweit gut. Ich stelle auch mit anderer Software (Veeam) keine Probleme fest. (Mir fehlt nur derzeit ein weiterer SAS HBA, weil der nun aus einem anderen System geraubt ist.)
Ich befülle ja gerade selbst mal ein Band mit Daten um den Vergleich zu haben, ob dann das zurückholen der Daten gut läuft, oder auch so dramatisch langsam wird.
Tatsächlich scheint aber so bekloppt es auch klingt derzeit das Maus-Schubsen mit dem grafischen Windows-Explorer zum Datenkopieren noch am besten zu funktionieren.
dieses ltfscopy.exe hatte immer wieder mal einfach abgebrochen, wenn es etwas nicht lesen/schreiben konnte. Das ist natürlich blöd, wenn man ganze (fremde) Bänder auslesen will und nicht ununterbrochen auf den Bildschirm starren mag.
Kreuzberger
Ist das eigentlich dasselbe Bandlaufwerk, mit dem die entsprechenden Bänder auch geschrieben wurden?
Leider nein. Das verwendete Laufwerk existiert nicht mehr, man hatte da längst auf neuere LTO-Versionen umgestellt, aber die Archiv-Bänder vergessen.
Das HPE-Laufwerk (Typ siehe oben), was ich derzeit dafür benutze funktioniert soweit gut. Ich stelle auch mit anderer Software (Veeam) keine Probleme fest. (Mir fehlt nur derzeit ein weiterer SAS HBA, weil der nun aus einem anderen System geraubt ist.)
Ich befülle ja gerade selbst mal ein Band mit Daten um den Vergleich zu haben, ob dann das zurückholen der Daten gut läuft, oder auch so dramatisch langsam wird.
Tatsächlich scheint aber so bekloppt es auch klingt derzeit das Maus-Schubsen mit dem grafischen Windows-Explorer zum Datenkopieren noch am besten zu funktionieren.
dieses ltfscopy.exe hatte immer wieder mal einfach abgebrochen, wenn es etwas nicht lesen/schreiben konnte. Das ist natürlich blöd, wenn man ganze (fremde) Bänder auslesen will und nicht ununterbrochen auf den Bildschirm starren mag.
Kreuzberger
Moin @kreuzberger,
Leider nein. Das verwendete Laufwerk existiert nicht mehr, man hatte da längst auf neuere LTO-Versionen umgestellt, aber die Archiv-Bänder vergessen.
das ist nicht gut. 😬
Denn wen das Schreib-/Lesekopfsystem am ursprünglichen Laufwerk dejustiert war, dann kann man die Bänder die damit geschrieben wurden, auch nur an diesem Laufwerk auslesen.
Vielleicht ist auch das Schreib-/Lesekopfsystem von deinem jetzigen Laufwerk dejustiert.
Ich würde es mal mit einem anderen LTO5 Laufwerk versuchen und die SAS HBA's bekommt man gebraucht fast schon hinterhergeschmissen, zumindest im Vergleich zu deren Neupreis. 🙃
Dadurch findest du aber nicht heraus, ob die Ausrichtung von deinem jetzigen Schreib-/Lesekopfsystem, genau dieselbe ist, wie auch bei dem ursprünglichen Laufwerk.
Das nährt eher meine Vermuttung, dass entweder das Laufwerk (Dejustierung) oder auch die Bänder (falsche Lagerung) ein Problem haben. 😔
Gruss Alex
Ist das eigentlich dasselbe Bandlaufwerk, mit dem die entsprechenden Bänder auch geschrieben wurden?
Leider nein. Das verwendete Laufwerk existiert nicht mehr, man hatte da längst auf neuere LTO-Versionen umgestellt, aber die Archiv-Bänder vergessen.
das ist nicht gut. 😬
Denn wen das Schreib-/Lesekopfsystem am ursprünglichen Laufwerk dejustiert war, dann kann man die Bänder die damit geschrieben wurden, auch nur an diesem Laufwerk auslesen.
Vielleicht ist auch das Schreib-/Lesekopfsystem von deinem jetzigen Laufwerk dejustiert.
Das HPE-Laufwerk (Typ siehe oben), was ich derzeit dafür benutze funktioniert soweit gut. Ich stelle auch mit anderer Software (Veeam) keine Probleme fest. (Mir fehlt nur derzeit ein weiterer SAS HBA, weil der nun aus einem anderen System geraubt ist.)
Ich würde es mal mit einem anderen LTO5 Laufwerk versuchen und die SAS HBA's bekommt man gebraucht fast schon hinterhergeschmissen, zumindest im Vergleich zu deren Neupreis. 🙃
Ich befülle ja gerade selbst mal ein Band mit Daten um den Vergleich zu haben, ob dann das zurückholen der Daten gut läuft, oder auch so dramatisch langsam wird.
Dadurch findest du aber nicht heraus, ob die Ausrichtung von deinem jetzigen Schreib-/Lesekopfsystem, genau dieselbe ist, wie auch bei dem ursprünglichen Laufwerk.
dieses ltfscopy.exe hatte immer wieder mal einfach abgebrochen, wenn es etwas nicht lesen/schreiben konnte. Das ist natürlich blöd, wenn man ganze (fremde) Bänder auslesen will und nicht ununterbrochen auf den Bildschirm starren mag.
Das nährt eher meine Vermuttung, dass entweder das Laufwerk (Dejustierung) oder auch die Bänder (falsche Lagerung) ein Problem haben. 😔
Gruss Alex
@MysticFoxDE
Danke, dass du hier so intensiv einsteigst.
Grundsätzlich finde ich ja die LTFS-Idee toll, weil man so um völlig überteuerte Backup-Programme teils herum kommt. Leider scheint das aber was die Softwareseite angeht von den Herstellern nur Stiefmütterlich behandelt worden zu sein. Es gibt ja nur recht spartanische Software, die eigentlich nur die Treiberfunktionalität bereit stellen, mehr nicht. Die Datenübertragung von/nach dem Band ist deutlich schlechter als bei vollwertigen Backup-Programmen. Cache scheint da wohl kein Thema gewesen zu sein, als man die LTFS-Software entwickelte.
Zu meinem Anlass:
Ich hab derzeit nicht den Eindruck, dass hier ein Hardwareproblem (Dejustierung) vorliegt mit der verwendeten Technik. Das Laufwerk als solches tut ordentlich seinen Dienst. Trotz seines Alters ist es kaum Benutzt mehr oder weniger neuwertig. Kaum Betriebsstunden.
Ich schreibe gerade FLAC-Dateien (850GB) auf das Band per Windows Explorer. Da kommt er auf stark schwankend bis zu 70MB/s. Der Rechner hat 16GB ECC RAM, 4core XEON, 3,xGHz, , der RAM wird laut kleinem Monitoring-Tool kaum benutzt. Ich höre wie neben mir das Laufwerk jault und ständig auch mal kurz anhält. Mit besserer Cache-Nutzung wäre vermutlich ein wesentlich durchgängigerer Datenfluss und mehr Bums möglich. Das Laufwerk kann denke ich 130MB/s max.
Kreuzberger
Danke, dass du hier so intensiv einsteigst.
Grundsätzlich finde ich ja die LTFS-Idee toll, weil man so um völlig überteuerte Backup-Programme teils herum kommt. Leider scheint das aber was die Softwareseite angeht von den Herstellern nur Stiefmütterlich behandelt worden zu sein. Es gibt ja nur recht spartanische Software, die eigentlich nur die Treiberfunktionalität bereit stellen, mehr nicht. Die Datenübertragung von/nach dem Band ist deutlich schlechter als bei vollwertigen Backup-Programmen. Cache scheint da wohl kein Thema gewesen zu sein, als man die LTFS-Software entwickelte.
Zu meinem Anlass:
Ich hab derzeit nicht den Eindruck, dass hier ein Hardwareproblem (Dejustierung) vorliegt mit der verwendeten Technik. Das Laufwerk als solches tut ordentlich seinen Dienst. Trotz seines Alters ist es kaum Benutzt mehr oder weniger neuwertig. Kaum Betriebsstunden.
Ich schreibe gerade FLAC-Dateien (850GB) auf das Band per Windows Explorer. Da kommt er auf stark schwankend bis zu 70MB/s. Der Rechner hat 16GB ECC RAM, 4core XEON, 3,xGHz, , der RAM wird laut kleinem Monitoring-Tool kaum benutzt. Ich höre wie neben mir das Laufwerk jault und ständig auch mal kurz anhält. Mit besserer Cache-Nutzung wäre vermutlich ein wesentlich durchgängigerer Datenfluss und mehr Bums möglich. Das Laufwerk kann denke ich 130MB/s max.
Kreuzberger
Moin @kreuzberger.
gerne, ausserdem kann ich so mein altes Tape Wissen auch mal wieder entstauben. 🙃
LTFS wurde primär auch nicht wirklich dafür entwickelt, die Daten so schnell es geht vollständig wieder auslesen zu können, sondern eher dafür, um die Daten so einfach und so kostengünstig wie möglich archivieren zu können und genau das macht es ja auch. Sprich, du installierts den Treiber und schon kannst du auf das Band wie auf eine Festplatte zugreifen nur eben um Welten langsamer, dafür aber auch um einiges günstiger.
Du kannst "ltfscopy.exe" mit dem Zusatzparameter "--verbose" starten, dann müsstest du eigentlich genau sehen, wo, sprich, bei welcher Datei der Fehler beim Kopieren geschieht. Wenn du dieselbe Datei mit dem Explorer auch nicht kopieren kannst, dann hat entweder das Band einen Schuss oder die Daten wurden bereits fehlerhaft auf das Band geschrieben.
Insbesondere die Intel Systeme, müssen für volle Leistung BIOS-Seitig zum Teil sehr umfangreich optimiert werden. 😔
Hast du denn das entsprechende BIOS, zumindest mal oberflächlich und auch im Windows den Energiesparplan auf Hochleistung eingestellt?
Mehr wie 140 MB/s, bekommst du bei LTO5 auch nicht raus, zumindest wenn keine Komprimierung verwendet wurde.
Gruss Alex
Danke, dass du hier so intensiv einsteigst.
gerne, ausserdem kann ich so mein altes Tape Wissen auch mal wieder entstauben. 🙃
Grundsätzlich finde ich ja die LTFS-Idee toll, weil man so um völlig überteuerte Backup-Programme teils herum kommt. Leider scheint das aber was die Softwareseite angeht von den Herstellern nur Stiefmütterlich behandelt worden zu sein. Es gibt ja nur recht spartanische Software, die eigentlich nur die Treiberfunktionalität bereit stellen, mehr nicht. Die Datenübertragung von/nach dem Band ist deutlich schlechter als bei vollwertigen Backup-Programmen. Cache scheint da wohl kein Thema gewesen zu sein, als man die LTFS-Software entwickelte.
LTFS wurde primär auch nicht wirklich dafür entwickelt, die Daten so schnell es geht vollständig wieder auslesen zu können, sondern eher dafür, um die Daten so einfach und so kostengünstig wie möglich archivieren zu können und genau das macht es ja auch. Sprich, du installierts den Treiber und schon kannst du auf das Band wie auf eine Festplatte zugreifen nur eben um Welten langsamer, dafür aber auch um einiges günstiger.
Ich hab derzeit nicht den Eindruck, dass hier ein Hardwareproblem (Dejustierung) vorliegt mit der verwendeten Technik. Das Laufwerk als solches tut ordentlich seinen Dienst. Trotz seines Alters ist es kaum Benutzt mehr oder weniger neuwertig. Kaum Betriebsstunden.
Du kannst "ltfscopy.exe" mit dem Zusatzparameter "--verbose" starten, dann müsstest du eigentlich genau sehen, wo, sprich, bei welcher Datei der Fehler beim Kopieren geschieht. Wenn du dieselbe Datei mit dem Explorer auch nicht kopieren kannst, dann hat entweder das Band einen Schuss oder die Daten wurden bereits fehlerhaft auf das Band geschrieben.
Ich schreibe gerade FLAC-Dateien (850GB) auf das Band per Windows Explorer. Da kommt er auf stark schwankend bis zu 70MB/s. Der Rechner hat 16GB ECC RAM, 4core XEON, 3,xGHz, , der RAM wird laut kleinem Monitoring-Tool kaum benutzt. Ich höre wie neben mir das Laufwerk jault und ständig auch mal kurz anhält. Mit besserer Cache-Nutzung wäre vermutlich ein wesentlich durchgängigerer Datenfluss und mehr Bums möglich. Das Laufwerk kann denke ich 130MB/s max.
Insbesondere die Intel Systeme, müssen für volle Leistung BIOS-Seitig zum Teil sehr umfangreich optimiert werden. 😔
Hast du denn das entsprechende BIOS, zumindest mal oberflächlich und auch im Windows den Energiesparplan auf Hochleistung eingestellt?
Mehr wie 140 MB/s, bekommst du bei LTO5 auch nicht raus, zumindest wenn keine Komprimierung verwendet wurde.
Gruss Alex
@MysticFoxDE
Sprich --copy --verify einsetzen.
Gruss Penny.
Du kannst "ltfscopy.exe" mit dem Zusatzparameter "--verbose" starten, dann müsstest du eigentlich genau sehen, wo, sprich, bei welcher Datei der Fehler beim Kopieren geschieht. Wenn du dieselbe Datei mit dem Explorer auch nicht kopieren kannst, dann hat entweder das Band einen Schuss oder die Daten wurden bereits fehlerhaft auf das Band geschrieben.
Dafür gibt es doch auch den Parameter "--verify". Um mittels Hash von Source und Destination zu prüfen.Sprich --copy --verify einsetzen.
Gruss Penny.
@MysticFoxDE
also: Ich versuche gerade die Rücksicherung.
Die 850GB hatte ich vollständig auf ein Band geschrieben.
Das Band habe ich dem Laufwerk entnommen.
Das Band dann wieder eingelegt.
Das Band Eingelsen mit der HP Configuration-Software, es wurde als gefülltes Laufwerk H: angezeigt.
Dann habe ich eine Rückkopie eines Unterordners der 850GB mit ltfscopy.exe angestossen. (Parameter: --recursive --force --verbose)
Seit nicht ganz einer Stunde rödelt der auf dem Band her und hin ohne dass im angegebenen Zielordner eine einzige Datei angekommen ist.
Ich breche das als sinnentleert ab.
Neuer Versuch:
Ich starte ltfscopy.exe erneut mit den selben Parametern, jedoch zusätzlich --copy.
siehe:
support.hpe.com/hpesc/public/docDisplay?docId=sd00001247en_us&am ...
Auch das hat kein anderes Ergebnis wie zuvor.
Ich breche das als sinnentleert ab.
Neuer versuch:
Ich kopiere einfach per Maus-Schubs den Unterordner im Windows Explorer in meinen Zielordner.
Er legt sofort der den Unterordner an und beginnt die enthaltenen 129GB zu kopieren.
Derzeit spult er dabei aber massiv das Band her und hin um jeweils nur kleine Stücke zu kopieren.
Das könnte bis etwa Ostern 2067 dauern.
Kreuzberger
also: Ich versuche gerade die Rücksicherung.
Die 850GB hatte ich vollständig auf ein Band geschrieben.
Das Band habe ich dem Laufwerk entnommen.
Das Band dann wieder eingelegt.
Das Band Eingelsen mit der HP Configuration-Software, es wurde als gefülltes Laufwerk H: angezeigt.
Dann habe ich eine Rückkopie eines Unterordners der 850GB mit ltfscopy.exe angestossen. (Parameter: --recursive --force --verbose)
Seit nicht ganz einer Stunde rödelt der auf dem Band her und hin ohne dass im angegebenen Zielordner eine einzige Datei angekommen ist.
Ich breche das als sinnentleert ab.
Neuer Versuch:
Ich starte ltfscopy.exe erneut mit den selben Parametern, jedoch zusätzlich --copy.
siehe:
support.hpe.com/hpesc/public/docDisplay?docId=sd00001247en_us&am ...
Auch das hat kein anderes Ergebnis wie zuvor.
Ich breche das als sinnentleert ab.
Neuer versuch:
Ich kopiere einfach per Maus-Schubs den Unterordner im Windows Explorer in meinen Zielordner.
Er legt sofort der den Unterordner an und beginnt die enthaltenen 129GB zu kopieren.
Derzeit spult er dabei aber massiv das Band her und hin um jeweils nur kleine Stücke zu kopieren.
Das könnte bis etwa Ostern 2067 dauern.
Kreuzberger
Moin @kreuzberger,
ähm, schau mal worüber ich gerade eben gestolpert bin ...
Quelle:
quantumhub-my.sharepoint.com/personal/everett_gidlund_quantum_co ...
... 😬
Und auch seitens IBM ...
Quelle:
ibm.com/docs/en/spectrum-archive-sde/2.4.5?topic=planning-system ...
... gibt es für Windows seit April 2023 keinen LTFS Support. 😔
HPE hat davon bisher anscheinend jedoch noch nichts mitbekommen, denn die bewerben das weiter ...
buy.hpe.com/de/de/storage/storage-software/storage-device-manage ...
... und zwar auch für Windows, als ob nichts wäre. 🙊🙈😭
Siehe auch ...
Quelle:
reddit.com/r/DataHoarder/comments/11xpf54/ibm_ltfs_does_not_work ...
... 😬
Sprich, versuche es mal mit Server 2016 oder 2019.
Gruss Alex
ähm, schau mal worüber ich gerade eben gestolpert bin ...
quantumhub-my.sharepoint.com/personal/everett_gidlund_quantum_co ...
... 😬
Und auch seitens IBM ...
ibm.com/docs/en/spectrum-archive-sde/2.4.5?topic=planning-system ...
... gibt es für Windows seit April 2023 keinen LTFS Support. 😔
HPE hat davon bisher anscheinend jedoch noch nichts mitbekommen, denn die bewerben das weiter ...
buy.hpe.com/de/de/storage/storage-software/storage-device-manage ...
... und zwar auch für Windows, als ob nichts wäre. 🙊🙈😭
Siehe auch ...
reddit.com/r/DataHoarder/comments/11xpf54/ibm_ltfs_does_not_work ...
... 😬
Sprich, versuche es mal mit Server 2016 oder 2019.
Gruss Alex
@MysticFoxDE
ich habe gerade mit jemandem Kontakt aufgenommen, der einen neuen HBA verkaufen will in Berlin. Ich hoffe der meldet sich und man wird sich einig.
Dann kann ich das ganze auf einem separaten Rechner komplett neu ausprobieren wie du es vorschlägst.
Auf Server 2022 wie jetzt hier bei mir ist mit dem Windows Explorer das Kopieren noch am gängigsten zu machen. Alles andere ist Quark.
250GB/s werde ich mit LTO5 wohl nicht erreichen können, aber dass es überhaupt halbwegs flüssig läuft ja schon gerne.
Schade ist aber in der tat, dass M$ das ganze Thema LTFS begraben hat. Es ist daher die große Frage, wie man mit vorhandener Technik weiter LTFS betreibt.
Ein Server 2016 oder Win10 20H2 dürfte dann kein Gateway bekommen und keine Updates. Zweifelsohne könnte man es aber so dauerhaft ohne Aktivierung betreiben. Denn zum Archivieren will man ja eh u.U. nichts am System ändern.
Kreuzberger
ich habe gerade mit jemandem Kontakt aufgenommen, der einen neuen HBA verkaufen will in Berlin. Ich hoffe der meldet sich und man wird sich einig.
Dann kann ich das ganze auf einem separaten Rechner komplett neu ausprobieren wie du es vorschlägst.
Auf Server 2022 wie jetzt hier bei mir ist mit dem Windows Explorer das Kopieren noch am gängigsten zu machen. Alles andere ist Quark.
250GB/s werde ich mit LTO5 wohl nicht erreichen können, aber dass es überhaupt halbwegs flüssig läuft ja schon gerne.
Schade ist aber in der tat, dass M$ das ganze Thema LTFS begraben hat. Es ist daher die große Frage, wie man mit vorhandener Technik weiter LTFS betreibt.
Ein Server 2016 oder Win10 20H2 dürfte dann kein Gateway bekommen und keine Updates. Zweifelsohne könnte man es aber so dauerhaft ohne Aktivierung betreiben. Denn zum Archivieren will man ja eh u.U. nichts am System ändern.
Kreuzberger
Nachtrag:
Ich habe die IBM Software für LTFS ausprobiert. Diese erkennt aber gar nicht das HP LTO5 Laufwerk.
Kreuzberger
Ich habe die IBM Software für LTFS ausprobiert. Diese erkennt aber gar nicht das HP LTO5 Laufwerk.
Kreuzberger
Moin @kreuzberger,
ich drücke dir die Daumen.
Am besten mit Server 2016, denn der ist ohne komplizierte Optimierung noch halbwegs performant gelaufen und hat auch noch nicht so viele Sicherheitsfeatures, die zum Teil auch massiv ausbremsen können.
Na ja, für genau diesen Zweck, wurde LTFS ja auch geboren, sprich, damit man auf ein Band wie auf eine Festplatte zugreifen kann, aber eben nicht mit derselben Performance, weil das die Band-Technik schlichtweg nicht hergibt.
Nein, die 250GB/s wirst du mit einem LTO5 nicht wirklich packen. 🙃
Selbst die max. 140 MB/s, wirst du nur schaffen, wenn du die Daten vollständig als "Stream" lesen oder schreiben kannst, was bei LTFS, prinzipbedingt jedoch eher die Ausnahme ist.
Und die höheren Geschwindigkeiten die mit einer Komprimierung theoretisch beim Lesen (und auch beim Schreiben) möglich sind, kannst du übrigens nur dann erreichen, wenn die entsprechenden Daten bereits schon beim Schreiben komprimiert wurden, was jedoch oft nicht der Fall ist.
Das ist bei LTFS jedoch prinzipbedingt nicht wirklich möglich, ausser dem oben bereits erwähnten Trick, sprich, die Daten gemäss der Indexreihenfolge auszulesen und selbst dann, ist eine dauerhafte Übertragung mit hoher Bandbreite dennoch nicht garantiert.
Na ja, ich kann es durchaus verstehen. Denn es gibt immer mehr Daten und auf diese möchten die Meisten auch so schnell es geht zugreifen können, selbst auf Archivdaten und auch Backups.
Gar nicht, da für die meisten Einsatzbereiche wo Daten dauerhaft bereitgestellt werden müssen, ein Fileserver oder eine NAS, selbst mit HDD Bestückung um Welten die bessere Wahl sind.
Nimm wenn es geht Server 2016, da ist weniger Mühl drauf als beim einem normalen Windows.
Auch ein Archivierungssystem sollte von Zeit zu Zeit auf Stand der Technik angehoben werden, denn ein totes Archiv bringt einem ja auch nichts mehr.
Gruss Alex
ich habe gerade mit jemandem Kontakt aufgenommen, der einen neuen HBA verkaufen will in Berlin. Ich hoffe der meldet sich und man wird sich einig.
ich drücke dir die Daumen.
Dann kann ich das ganze auf einem separaten Rechner komplett neu ausprobieren wie du es vorschlägst.
Am besten mit Server 2016, denn der ist ohne komplizierte Optimierung noch halbwegs performant gelaufen und hat auch noch nicht so viele Sicherheitsfeatures, die zum Teil auch massiv ausbremsen können.
Auf Server 2022 wie jetzt hier bei mir ist mit dem Windows Explorer das Kopieren noch am gängigsten zu machen. Alles andere ist Quark.
Na ja, für genau diesen Zweck, wurde LTFS ja auch geboren, sprich, damit man auf ein Band wie auf eine Festplatte zugreifen kann, aber eben nicht mit derselben Performance, weil das die Band-Technik schlichtweg nicht hergibt.
250GB/s werde ich mit LTO5 wohl nicht erreichen können
Nein, die 250GB/s wirst du mit einem LTO5 nicht wirklich packen. 🙃
Selbst die max. 140 MB/s, wirst du nur schaffen, wenn du die Daten vollständig als "Stream" lesen oder schreiben kannst, was bei LTFS, prinzipbedingt jedoch eher die Ausnahme ist.
Und die höheren Geschwindigkeiten die mit einer Komprimierung theoretisch beim Lesen (und auch beim Schreiben) möglich sind, kannst du übrigens nur dann erreichen, wenn die entsprechenden Daten bereits schon beim Schreiben komprimiert wurden, was jedoch oft nicht der Fall ist.
aber dass es überhaupt halbwegs flüssig läuft ja schon gerne.
Das ist bei LTFS jedoch prinzipbedingt nicht wirklich möglich, ausser dem oben bereits erwähnten Trick, sprich, die Daten gemäss der Indexreihenfolge auszulesen und selbst dann, ist eine dauerhafte Übertragung mit hoher Bandbreite dennoch nicht garantiert.
Schade ist aber in der tat, dass M$ das ganze Thema LTFS begraben hat.
Na ja, ich kann es durchaus verstehen. Denn es gibt immer mehr Daten und auf diese möchten die Meisten auch so schnell es geht zugreifen können, selbst auf Archivdaten und auch Backups.
Es ist daher die große Frage, wie man mit vorhandener Technik weiter LTFS betreibt.
Gar nicht, da für die meisten Einsatzbereiche wo Daten dauerhaft bereitgestellt werden müssen, ein Fileserver oder eine NAS, selbst mit HDD Bestückung um Welten die bessere Wahl sind.
Ein Server 2016 oder Win10 20H2 dürfte dann kein Gateway bekommen und keine Updates. Zweifelsohne könnte man es aber so dauerhaft ohne Aktivierung betreiben.
Nimm wenn es geht Server 2016, da ist weniger Mühl drauf als beim einem normalen Windows.
Denn zum Archivieren will man ja eh u.U. nichts am System ändern.
Auch ein Archivierungssystem sollte von Zeit zu Zeit auf Stand der Technik angehoben werden, denn ein totes Archiv bringt einem ja auch nichts mehr.
Gruss Alex
@MysticFoxDE
Migrationen von alten Backup- / Archivierungssystemen. Weil immer ein diletantsch dämlicher Entscheider meint: Wir haben ein neues System - das alte kann weg.
Sei es nur die Ablösung von alten LTO-Bändern, oder von ganzen Librarys voll mit Bändern.
Was ich da schon für Dramen erlebt habe, das kann man sich nicht vorstellen.
Gruss Penny.
Auch ein Archivierungssystem sollte von Zeit zu Zeit auf Stand der Technik angehoben werden, denn ein totes Archiv bringt einem ja auch nichts mehr.
Genau dass, was ich seit Jahren mache.Migrationen von alten Backup- / Archivierungssystemen. Weil immer ein diletantsch dämlicher Entscheider meint: Wir haben ein neues System - das alte kann weg.
Sei es nur die Ablösung von alten LTO-Bändern, oder von ganzen Librarys voll mit Bändern.
Was ich da schon für Dramen erlebt habe, das kann man sich nicht vorstellen.
Gruss Penny.
1
Moin @Penny.Cilin,
na ja, wenn die Daten von dem alten Archiv, vollständig in das neue übertragen wurden,
dann kann und sollte man das alte schon irgendwann mal auch abschalten.
Aber, dass das nicht immer ganz einfach ist, belegt mitunter dieser ganze Beitrag und auch dein ...
... eigener Kommentar, geht ja auch in diese Richtung.
Auf der anderen Seite ... es gibt glaube ich keine andere Branche, wo man an so gut wie jeder Ecke, sowohl eine gute als auch eine böse Überraschung erleben kann. 🙃
Gruss Alex
Weil immer ein diletantsch dämlicher Entscheider meint: Wir haben ein neues System - das alte kann weg.
na ja, wenn die Daten von dem alten Archiv, vollständig in das neue übertragen wurden,
dann kann und sollte man das alte schon irgendwann mal auch abschalten.
Aber, dass das nicht immer ganz einfach ist, belegt mitunter dieser ganze Beitrag und auch dein ...
Was ich da schon für Dramen erlebt habe, das kann man sich nicht vorstellen.
... eigener Kommentar, geht ja auch in diese Richtung.
Auf der anderen Seite ... es gibt glaube ich keine andere Branche, wo man an so gut wie jeder Ecke, sowohl eine gute als auch eine böse Überraschung erleben kann. 🙃
Gruss Alex
@MysticFoxDE
Ich werde oft von anderen Unternehmen gebucht, um solche Arbeiten durchzuführen. Kann mir ja nur recht sein. Ich habe was zu tun. Einen fest definierten Arbeitsbereich und gebe gerne mein Wissen an diese Kollegen weiter.
Und wie man beim aktuellen Beitrag von @kreuzberger sieht, besteht bei vielen Unternehmen Handlungsbedarf.
Ich sehe das ganz entspannt und positiv. Habe schon den Termin beim Rentenberater gehabt. Mal schauen, wie das Ergebnis ausfällt. Vielleicht gehe ich dann mit 99,99% in Rente und arbeite nebenbei weiter. Um weitere Rentenpunkte zu sammeln und weiterhin Lohnfortzahlung bei Krankheit zu bekommen.
Gruss Penny.
Moin @Penny.Cilin,
Weil immer ein diletantsch dämlicher Entscheider meint: Wir haben ein neues System - das alte kann weg.
na ja, wenn die Daten von dem alten Archiv, vollständig in das neue übertragen wurden,
dann kann und sollte man das alte schon irgendwann mal auch abschalten.
Deswegen achte ich auf solche Dinge. Und habe mir eine Checkliste erstellt, welche ich alle 6 Monate bei uns abarbeite.Weil immer ein diletantsch dämlicher Entscheider meint: Wir haben ein neues System - das alte kann weg.
na ja, wenn die Daten von dem alten Archiv, vollständig in das neue übertragen wurden,
dann kann und sollte man das alte schon irgendwann mal auch abschalten.
Ich werde oft von anderen Unternehmen gebucht, um solche Arbeiten durchzuführen. Kann mir ja nur recht sein. Ich habe was zu tun. Einen fest definierten Arbeitsbereich und gebe gerne mein Wissen an diese Kollegen weiter.
Und wie man beim aktuellen Beitrag von @kreuzberger sieht, besteht bei vielen Unternehmen Handlungsbedarf.
Ich sehe das ganz entspannt und positiv. Habe schon den Termin beim Rentenberater gehabt. Mal schauen, wie das Ergebnis ausfällt. Vielleicht gehe ich dann mit 99,99% in Rente und arbeite nebenbei weiter. Um weitere Rentenpunkte zu sammeln und weiterhin Lohnfortzahlung bei Krankheit zu bekommen.
Gruss Penny.
1
Ok, was das Band angeht ist mein ursprünglicher Beweggrund eben ein anderer: Die Kosten.
Datensicherungsprogramme wie Veeam sind extrem teuer geworden. Denkt man dann an kleine Einzelunternehmer/innen oder Kleinbetriebe wo große Datenmengen anfallen (Cutter, Videoschnitt, Colouergrading, Musikbearbeitung, Musikstudio, Fotostudio, etc.) bracht man auch da ein Archiv und Backup großer Datenmengen. Ok, groß ist relativ.
Do als Fotograf sich für mehrere tausend euro / Jahr ein Veeam mieten? nee!
Es muss da auch andere Lösungen geben.
Kreuzberger
Datensicherungsprogramme wie Veeam sind extrem teuer geworden. Denkt man dann an kleine Einzelunternehmer/innen oder Kleinbetriebe wo große Datenmengen anfallen (Cutter, Videoschnitt, Colouergrading, Musikbearbeitung, Musikstudio, Fotostudio, etc.) bracht man auch da ein Archiv und Backup großer Datenmengen. Ok, groß ist relativ.
Do als Fotograf sich für mehrere tausend euro / Jahr ein Veeam mieten? nee!
Es muss da auch andere Lösungen geben.
Kreuzberger
Update:
Ich hab nun den HP HBA (NEU) in ein MINI-ITX PC (16GB RAM, AMD A-5000 APU, 4x1,5GHz) geworfen und auf einer SSD (NEU) ein Server 2016 Std installiert. Während der Installation war (weil ich so pfiffig bin) der LTO5 von HP bereits extern angeschlossen und eingeschaltet. Das ergab, dass gleich die korrekten Treiber dazu installiert sind.
Dann hab ich Netzanpassung und Servername korrigiert.
Dann hab ich diese HP LTFS Software drauf gewuppt.
Bis hier alles Perfekt.
Jetzt teste ich gerade eines der fremden Bänder so auszulesen. Das geht auch mit dem Windows Explorer soweit gut (40 ... 50MB/s) auf eine externe USB3-Platte (5TB).
Aber auch hier noch wirres her und hin spulen.
Ich beobachte das mal ......
Kreuzberger
Ich hab nun den HP HBA (NEU) in ein MINI-ITX PC (16GB RAM, AMD A-5000 APU, 4x1,5GHz) geworfen und auf einer SSD (NEU) ein Server 2016 Std installiert. Während der Installation war (weil ich so pfiffig bin) der LTO5 von HP bereits extern angeschlossen und eingeschaltet. Das ergab, dass gleich die korrekten Treiber dazu installiert sind.
Dann hab ich Netzanpassung und Servername korrigiert.
Dann hab ich diese HP LTFS Software drauf gewuppt.
Bis hier alles Perfekt.
Jetzt teste ich gerade eines der fremden Bänder so auszulesen. Das geht auch mit dem Windows Explorer soweit gut (40 ... 50MB/s) auf eine externe USB3-Platte (5TB).
Aber auch hier noch wirres her und hin spulen.
Ich beobachte das mal ......
Kreuzberger
Update: Für das Restore eines LTO5-Bandes muss man etwa einen ganzen Tag (20-24Std.) rechnen.
Kreuzberger
Kreuzberger
Update: Ich habe nun nachdem ich ein weiteres Band komplett per Windows Explorer ausgelesen hatte (ca. 20 Std) das ganze nochmal gestartet mit dism.
Ich erzeuge also vom kompletten Band (1,37TB) ein WIM-Image.
Ich beziehe mich da auf die Idee von @kaiand1, der das mit DD machen wollte. Das steht mir aber in Windows Server 2026 nicht zur verfügung. Aber DISM.
Kreuzberger
Ich erzeuge also vom kompletten Band (1,37TB) ein WIM-Image.
Ich beziehe mich da auf die Idee von @kaiand1, der das mit DD machen wollte. Das steht mir aber in Windows Server 2026 nicht zur verfügung. Aber DISM.
Kreuzberger
Moin @kreuzberger,
wenn du über den Explorer mit 20-24 Std. den Inhalt auch kopieren kannst, dann macht der Umweg über DISM nur bedingt Sinn, da du die Daten aus dem Image ja auch noch herausziehen musst.
Gruss Alex
Update: Ich habe nun nachdem ich ein weiteres Band komplett per Windows Explorer ausgelesen hatte (ca. 20 Std) das ganze nochmal gestartet mit dism.
Ich erzeuge also vom kompletten Band (1,37TB) ein WIM-Image.
Ich erzeuge also vom kompletten Band (1,37TB) ein WIM-Image.
wenn du über den Explorer mit 20-24 Std. den Inhalt auch kopieren kannst, dann macht der Umweg über DISM nur bedingt Sinn, da du die Daten aus dem Image ja auch noch herausziehen musst.
Gruss Alex
@MysticFoxDE
Die Idee war ja, ob ein Image-Programm anders mit dem Quelldatenträger umgeht als z. B. der Windows Explorer oder robocopy oder etc. Also einfach die Daten vom Datenträger kratzt wie sie liegen.
Würde das gehen wäre der Zeitaufwand deutlich geringer (ggf. nur 4 Std.) und man könnte dann aus dem Image flott auslesen, was man haben will.
Kreuzberger
Die Idee war ja, ob ein Image-Programm anders mit dem Quelldatenträger umgeht als z. B. der Windows Explorer oder robocopy oder etc. Also einfach die Daten vom Datenträger kratzt wie sie liegen.
Würde das gehen wäre der Zeitaufwand deutlich geringer (ggf. nur 4 Std.) und man könnte dann aus dem Image flott auslesen, was man haben will.
Kreuzberger
@MysticFoxDE
@kreuzberger
Im Prinzip ist die Idee nicht verkehrt. Weil wenn die zusichernden Daten zuerst in ein Image (TAR, ZIP, RAR, usw.) gespeichert werden, dann ist der Datenstrom für die Sicherung und Wiederherstellung konstant.
Ein Zeitgewinn kann dabei rauskommen, muss aber nicht.
Weil, erstmal müssen die Daten in ein Archiv gepackt werden. Ja nach Menge und Größe der Daten kann das eine Stunde oder mehr sein. Dann sollte das Archiv verifiziert (geprüft) werden. Dann kommt das Schreiben auf Band.
Bei der Wiederherstellung vom Band dann genau anders rum. Sprich vom Band herstellen. Archiv prüfen und danach entpacken.
@kreuzberger
Es ist ein Versuch wert.
Bei den Datenmengen, mit welchen ich arbeite, wird die blockbasierte Sicherung verwendet. Weil das die schnellste Möglichkeit ist die Daten zu sichern. Wir machen Backup-to-Disk-to-Tape. Wobei es mehrere Bandsätze gibt. Zwei Bandsicherungen kommen in unterschiedliche Tresore. Ein Bandsatz ist im Tresor im Haus. Und ein Bandsatz im Rechenzentrum in einem abgeschlossenen Raum, wo nur ein sehr beschränkter Personenkreis einen Schlüssel hat.
Gruss Penny.
@kreuzberger
Im Prinzip ist die Idee nicht verkehrt. Weil wenn die zusichernden Daten zuerst in ein Image (TAR, ZIP, RAR, usw.) gespeichert werden, dann ist der Datenstrom für die Sicherung und Wiederherstellung konstant.
Ein Zeitgewinn kann dabei rauskommen, muss aber nicht.
Weil, erstmal müssen die Daten in ein Archiv gepackt werden. Ja nach Menge und Größe der Daten kann das eine Stunde oder mehr sein. Dann sollte das Archiv verifiziert (geprüft) werden. Dann kommt das Schreiben auf Band.
Bei der Wiederherstellung vom Band dann genau anders rum. Sprich vom Band herstellen. Archiv prüfen und danach entpacken.
@kreuzberger
Es ist ein Versuch wert.
Bei den Datenmengen, mit welchen ich arbeite, wird die blockbasierte Sicherung verwendet. Weil das die schnellste Möglichkeit ist die Daten zu sichern. Wir machen Backup-to-Disk-to-Tape. Wobei es mehrere Bandsätze gibt. Zwei Bandsicherungen kommen in unterschiedliche Tresore. Ein Bandsatz ist im Tresor im Haus. Und ein Bandsatz im Rechenzentrum in einem abgeschlossenen Raum, wo nur ein sehr beschränkter Personenkreis einen Schlüssel hat.
Gruss Penny.
@Penny.Cilin
In dem Fall geht es ja hier um vorliegende LTFS-Formatierte Bänder. Und die sollen eben nur einmal ausgelesen werden. Danach kann ich die Kiste mit den Bändern behalten. Ich kann da wohl noch weitere Kisten voll erwarten . . . 😳
Für mich selbst ist dann die Frage offen, ob LTFS eine gangbare Möglichkeit ist, Daten zu archivieren bzw Backups zu machen. LTFS kann aber immer nur ein Band beschreiben am Stück, nicht wie richtige Backupsoftware wie Veeam, Veritas, wo eben mehrere Bänder aneinander folgend ein deutlich größeres Volume beinhalten können.
Das beschreiben per LTFS ist ja schon noch hinnehmbar schnell. Das auslesen aber scheint mir doch extrem langsam zu sein.
TAR (für Windows)
Tar ist ja nun auch Bestandteil von windows geworden. Wie aber es gehen soll, dass man mit Tar auf ein Band schreibt, und zwar nicht LTFS, ist mir unklar.
Und: Kann diese sTar für Windows mehrere Bänder zueinander koppeln?
Kreuzberger
In dem Fall geht es ja hier um vorliegende LTFS-Formatierte Bänder. Und die sollen eben nur einmal ausgelesen werden. Danach kann ich die Kiste mit den Bändern behalten. Ich kann da wohl noch weitere Kisten voll erwarten . . . 😳
Für mich selbst ist dann die Frage offen, ob LTFS eine gangbare Möglichkeit ist, Daten zu archivieren bzw Backups zu machen. LTFS kann aber immer nur ein Band beschreiben am Stück, nicht wie richtige Backupsoftware wie Veeam, Veritas, wo eben mehrere Bänder aneinander folgend ein deutlich größeres Volume beinhalten können.
Das beschreiben per LTFS ist ja schon noch hinnehmbar schnell. Das auslesen aber scheint mir doch extrem langsam zu sein.
TAR (für Windows)
Tar ist ja nun auch Bestandteil von windows geworden. Wie aber es gehen soll, dass man mit Tar auf ein Band schreibt, und zwar nicht LTFS, ist mir unklar.
Und: Kann diese sTar für Windows mehrere Bänder zueinander koppeln?
Kreuzberger
Mit LTFS habe ich mich noch nie beschäftigt. Bei vernünftiger Backupsoftware wird ein Folgeband angefordert, sobald das Band voll ist. Und beim Restore werden dann die Bänder aauch eingelesen.
Gruss Penny.
Gruss Penny.
@Penny.Cilin
Ja genau. So kenne ich das von vernünftigen Backup-Programmen wie Retrospect, Veeam, Veritas etc. seit je her.
Es gibt aber auch Backup-Prgramme, die sich professionell nennen, genau das aber nicht können. Da erlebt man schon mal Überraschungen. (Iperius Backup)
LTFS kann das vom Prinzip her nicht, es ist ja als Einzellaufwerk - wie eine USB-Platte - anzusehen.
Kreuzberger
Ja genau. So kenne ich das von vernünftigen Backup-Programmen wie Retrospect, Veeam, Veritas etc. seit je her.
Es gibt aber auch Backup-Prgramme, die sich professionell nennen, genau das aber nicht können. Da erlebt man schon mal Überraschungen. (Iperius Backup)
LTFS kann das vom Prinzip her nicht, es ist ja als Einzellaufwerk - wie eine USB-Platte - anzusehen.
Kreuzberger
Update / Zwischenmeldung
Seit heute 10.00 Uhr versuche ich per dism ein Wim-Image vom LTFS-Band zu machen. Auch hier wird massiv her und hin gespult. Es ist relativ sinnentleert.
Leider sieht man bei dism gar nichts, wie weit der denn schon ist.
Da ich nun aber zum Bier trinken verpflichtet wurde lasse ich das jetzt erst einmal so weiter laufen.
🍻
Krezberger
Seit heute 10.00 Uhr versuche ich per dism ein Wim-Image vom LTFS-Band zu machen. Auch hier wird massiv her und hin gespult. Es ist relativ sinnentleert.
Leider sieht man bei dism gar nichts, wie weit der denn schon ist.
Da ich nun aber zum Bier trinken verpflichtet wurde lasse ich das jetzt erst einmal so weiter laufen.
🍻
Krezberger
Moin @kreuzberger,
hast du auf dem 2016 es auch mal mit ltfscopy.exe versucht, vielleicht läuft es auf diesem nun viel besser.
Gruss Alex
hast du auf dem 2016 es auch mal mit ltfscopy.exe versucht, vielleicht läuft es auf diesem nun viel besser.
Gruss Alex
Update
Das dism Kopieren läuft noch. Derzeit 27 Stunden.
ltfscopy.exe probiere ich danach noch mal aus.
Kreuzberger
Das dism Kopieren läuft noch. Derzeit 27 Stunden.
ltfscopy.exe probiere ich danach noch mal aus.
Kreuzberger
1
Update:
Ich habe das kopieren des ltfs-Bandes per dism nach 50 Stunden abgebrochen, da er nicht einmal 2% geschafft hatte. Das ist also sinnlos.
Ich habe jetzt auf Server 2016 noch einmal das ltfscopy.exe gestartet. Es scheint aber nicht besser zu gehen.
Interessant fand ich diese Hinweise:
youtube.com/watch?v=THdp-gWxSL8
Hier ist von einer Linux-Installation die rede, mit entsprechender LTFS-Software für Linux. Wenn ich wüsste,
- welches System genau er nimmt,
- welche software er genau nimmt
- wie ich die SAS Treiber für Streamer und Controller einbinde
wäre ich mal interessiert, wie das ginge.
Kreuzberger
Ich habe das kopieren des ltfs-Bandes per dism nach 50 Stunden abgebrochen, da er nicht einmal 2% geschafft hatte. Das ist also sinnlos.
Ich habe jetzt auf Server 2016 noch einmal das ltfscopy.exe gestartet. Es scheint aber nicht besser zu gehen.
Interessant fand ich diese Hinweise:
youtube.com/watch?v=THdp-gWxSL8
Hier ist von einer Linux-Installation die rede, mit entsprechender LTFS-Software für Linux. Wenn ich wüsste,
- welches System genau er nimmt,
- welche software er genau nimmt
- wie ich die SAS Treiber für Streamer und Controller einbinde
wäre ich mal interessiert, wie das ginge.
Kreuzberger
