News Tape Embedded Drive: Western Digital erwägt Bandspeicher im HDD-Format

[bL4ckfish]

Ich frage mich für was solche Technologien Anno 2023 noch entwickelt werden.

Wofür werden solche Techniken überhaupt noch gebraucht ?

Für welchen Bereich sind sie überhaupt sinnvoll ?

Für den normalen Heimnutzer doch sicherlich weniger interessant oder ?

Die Zeit der Magnetbänder im normalen Heimanwenderbreich ist einfach vorbei in meinen Augen.

Hier geht es auch nicht im Heimanwenderbereich sondern Enterprise. Als Datensicherung sind Bänder z.B. am langlebigsten

 

[darkcrawler]

Es liest sich so als wäre im Zugriff mit der herkömlichen Technik noch der Teil mit dem Roboterarm mit dabei mit den 100ms. Wenn man sich natürlich den mechanischen Teil des "Einlegens" komplett spart, ist klar dass der Zugriff 10mal schneller geht ^^

Man legt mehrere ein, z.b. in 2 magazinen a 12 slots,
mache ich auf arbeit, daher frage ich mich wozu das hier gut sein soll, da beschreiben wir 10 pro woche

Das ding hier ist weder fisch (hdd) noch fleisch (lto tape)

Ergänzung (24. Januar 2023)

Für den Normalen Heimanwender waren Tapes noch nie interessant.

Dann bist du vllt. noch nicht lang genug dabei

 

[Bigeagle]

Das Problem an den kleinkram ist das der Streamer schneller ist, als dass das HDD Raid die Daten liefern kann. Ein HDD Raid 5 liefert bei großen Daten ohne Probleme 4-500 MB/sek allerdings bei Kleinkram bricht es auf 30-50 MB/sek ein und ein LTO der neueren Genneratron wollen durchgängig min. 150 und mehr MB/sek. Wenn das nicht gehalten werden kann schreibt der Streamer leerdaten oder er schaltet eine Stufe runter.
Leider hab ich in keiner Backupsoftware eine Funktion gefunden wo man einstellen kann wieviel RAM das Ding als Cache nutzten soll.

Ich dachte dafür hat man tar erfunden. ^^
Ich hätte sowieso gedacht dass man da zur Sicherheit bei gemischten oder kleinen Dateien einen Zwischenspeicher nutzt.

Oh doch, sehr wohl und dass das passiert war seiner Zeit überhaupt der Grund, warum anno dazumal der erste große Ars Technica Artikel zu ZFS so einschlug.

as in besagtem Artikel damals unter den Tisch fiel, war, dass HDD-Sektoren ECC haben - aber wenn zwei Bits im Sektor flippen, nutzt das halt nichts mehr. Niemand weiß genau, wie schnell das geht, dass die Bits verbleichen und es flippen auch meist nur vereinzelte und nie plötzlich die ganze HDD in einem Monat. Vielleicht liegt letzteres daran, dass die Leute, die annehmen, dass die HDD-Firmware Sektoren wirklich neuschreibt, wenn sie ein Bit ECC wieder herstellen musst, mit ihrer Vermutung doch gar nicht so bösefalsch liegen und chkdsk /r gar nicht soo dumm ist, wie es geredet wird.

Ich stelle mich vielleicht auch gerade mit der Suche blöd an, aber ich finde nichts passendes dazu.
Bitflips gibts schon, aber afaik eher durch Strahlung oder übersprechen bei Sektoren. Dass die Signale zu schwach werden und erneuert werden müssen bei in für hdds relvanten Zeiträumen und Lagerbedingungen wäre mir aber neu.
Nicht zuletzt weil dann ja entweder Datenverlust bei uraltdaten oder hdds die seit jahren offline waren sichtbar sein sollte und bei einer automatischen korrektur diese zu hören sein sollte. Das einzige was ich von HDDs aber höre sind nachvollziehbare Zugriffe und das stetige kopf parken, entparken wenn sie geweckt werden. Wenn da etwas losrattert ohne dass ich die Quelle zuordnen kann neige ich dazu nachzugucken was auf meinem PC los ist. Daher bin ich mir relativ sicher dass ich eine automatische auffrischung der Sektoren im laufe der Jahre mal mitbekommen hätte. Ich wäre panisch im Dreieck gesprungen und hätte ein rootkit vermutet wenn die HDD ackert und das OS nichts davon weiß.
Außer natürlich die machen das alles ganz ganz leise, was sie bei normalen Zugriffen nicht schaffen. Die alten WD Red ausgenommen, da höre ich nix.

Bei meinem zfs pool hatte ich auch erwartet irgendwann wenigstens mal einen Fehler beim scrubbing zu sehen, doch seit 7 Jahren mit teils ebenso alten Daten, die praktisch read only sind, nix.
Ich hab hier auch noch ein paar alte Platten rumliegen die erstaunlicherweise nach 6-10 Jahren Schrank/Umzugskiste noch immer lesbar zu sein schienen. Genauere Untersuchung scheiterte an Motivation und defektem Kabel oder Board an einem ähnlich alten PC. Wäre unter dem Aspekt ja mal einen Blick wert. Ich hab vom aufräumen letztens noch 2 alte externe hier stehen, die eine noch IDE aber ohne Netzteil, die vermutlich noch länger rumlagen. Da wollte ich ohnehin mal gucken ob und was noch drauf ist.
Meine Erwartung wäre allerdings dass die Sicherheitsspanne bei der magnetisierung im normalfall groß genug ist dass man nach 10 Jahren keine größeren Verluste zu erwarten hat, selbst wenn keinerlei auffrischung erfolgte. Die Mechanik macht mir da viel mehr Sorgen.
Konkrete Daten zum Verlust an Feldstärke bei HDDs und wie viel zum Lesen noch nötig ist wären da praktisch, aber vermutlich auch wieder zwischen Baureihen unterschiedlich.

Dass ein Sektor mit reparierbarem defekt gleich neu geschrieben wird fände ich logisch. Aber nur wenn man denn auch Sicherheit hätte. Doch die hdd kann nicht wissen wo der Fehler aufgetreten ist (Platter, Kopf, bitflip in der prüfsummenberechnung, etc) und wenn man schon bei bitflips ist könnte auch das vermeintlich korrigierte ergebnis falsch sein und beim rückschreiben korrekte daten falsch überschrieben werden. Da die firmware das transparent für den Rest des Systems macht wäre das auch ein risiko für schleichende datenkorruption. Außerdem kostet es Zeit und ggf. ist das lesen ohnehin nicht so stabil und korrigierbare fehler sind normal, erst bei erkannten aber nicht korrigierbaren fehlern wird mehrfach gelesen und schließlich dem OS ein Fehler gemeldet (und der sektor ersetzt). Direkt neu schreiben würde dann spürbar im normalen Betrieb auf die Geschwindigkeit schlagen und das noch potentiell ungleichmäßig. Daher denke ich mal ist das nicht üblich. Fehlerkorrektur von Daten auf der Platte ist Sache der höheren Ebenen, die kann das besser verwalten und hat ggf. Zugriff auf redundanz die erheblich mehr sicherheit gibt als es die einzelne hdd könnte.
P.S.: Eine Super User Frage dazu

 

[wern001]

Ich dachte dafür hat man tar erfunden. ^^
Ich hätte sowieso gedacht dass man da zur Sicherheit bei gemischten oder kleinen Dateien einen Zwischenspeicher nutzt.

ja nennt sich Backup2disk2tape wäre halt schön wenn das ohne einen zwischen Schritt gehen würde

 

[mkossmann]

Sehr interessant. Ein Bandlaufwerk mit Band und SATA oder SAS Schnittstelle, welches sich für das System wie eine Festplatte verhält.

Eher wie eine beschreibbare Audio-CD. Als Schnittstelle wird SATA wohl nicht mehr benutzt werden . Sondern SAS oder PCIe/NVME.

Die Idee dabei dürfte sein, das man die "teure" Mechanik einsparen will, die das Band aus der Kassette über Leseköpfe des Laufwerks zieht und das Bandlaufwerk teuer macht Mit fest in der Kassette montierten Leseköpfen hat man nur noch "billige" Kontakte an der Kassette nach aussen, das Band liegt immer "geschützt" innerhalb der Kassette und kann wohl auch näher am Lesekopf vorbeigeführt werden. Was eine höhere Datendichte ermöglicht. Das Laufwerk enthält dann nur noch die Antriebsmotoren.

 

[M@tze]

Wir haben auch ewig lange auf Tape gesichert, bin aber froh dass das mittlerweile vorbei ist. War immer quälend langsam und wir hatten, bevor alle Server virtualisiert wurden, immer öfter Probleme das Backup rechtzeitig fertig zu bekommen, da die Datenbanken und unsere Software für das Konfigurationsmanagement in der Zeit gesperrt werden mussten (niemand konnte derweil arbeiten) und damit nur wenig Zeit war.

allein schon weil irgendwann keiner mehr ein Gerät hat, das die uralten Medien lesen kann.

Auch ein unterschätztes Problem! Ganz alte Bänder bei uns basierten noch auf DDS, da konnte man nicht mal sicher sein, das ein Band von Server A mit dem Laufwerk von Server B gelesen werden konnte und irgendwann hat man nicht mal mehr Laufwerke für das alte System bekommen.

Ich bin echt kein Verfechter der deutschen Sprache aber man bekomnt das Gefühl der Redakteur hat vergessrn wie Deutsch geht. 😅

Das war jetzt irgendwie ein Eigentor, oder?! 😉

 

[ebird]

Interessant bei den Bändern finde ich immer die Phantasiewerte für die Komprimierung.
Ich bin noch nie auf den wert von 2:1 gekommen eher etwas in die Richtung 1,2:1

Bei Backups von Unternehmensdaten? Ich erreiche teilweise Komprimierungsfaktoren von mehr als 3:1. Bei Mails sind es 2:1, da da viele komprimierte oder verschlüsselte Dateien dabei sind.
Solche Bandlaufwerke nutzt man nicht um seine Filmsammlung zu sichern.

 

[Rickmer]

War immer quälend langsam und wir hatten, bevor alle Server virtualisiert wurden, immer öfter Probleme das Backup rechtzeitig fertig zu bekommen, da die Datenbanken und unsere Software für das Konfigurationsmanagement in der Zeit gesperrt werden mussten (niemand konnte derweil arbeiten) und damit nur wenig Zeit war.

Hmm... wir implementieren immer ein Backup auf Disk in der ersten Instanz und Copy to Tape in einer zweiten. In den allermeisten Fällen wird für ein Restore nur das Disk Backup benötigt, was erheblich bequemer ist.
Außerdem entsprechend bessere Performance, je nachdem was für einen Disk Pool man hat.

'Vor der Virtualisierung' ist sicherlich auch schon ein Weilchen her, oder?

Bei Backups von Unternehmensdaten? Ich erreiche teilweise Komprimierungsfaktoren von mehr als 3:1. Bei Mails sind es 2:1, da da viele komprimierte oder verschlüsselte Dateien dabei sind.

Bei Copy to Tape eines bestehenden Backup wie oben beschrieben ist kaum bis keine Komprimierung mehr drin, da das Backup an sich schon dedupliziert und komprimiert ist. Wir deaktivieren daher meistens Hardware-Komprimierung - bringt eh kaum was und ist dann nur ein Schritt mehr, der im Wurst-Käse-Szenario potentiell Probleme machen kann.

 

[latiose88]

Solche Bandlaufwerke nutzt man nicht um seine Filmsammlung zu sichern.

Schade dann ist auch diese Technik hier nicht dafür geeignet. Ich spielte schon mit dem Gedank, die Filme Sammlung günstig auf das zu sichern. Damit weniger Festplatten benötigt werden. Habe nicht nur Filme sondern Serien, Bilder, textdokumente, Spiele und ISO Dateien.

Und das geht mit dem Band also nicht. Dann gibt es wohl auch für mich in Zukunft keine Option als weiterhin auf hdd zu setzen. Ich habe zudem ein chaos also muss es immer wieder mal sotiert werden das ich irgendwann mal richtig Ordnung habe. Aber wenn die Band so langsam sind mache ich mir da kein Gefallen wenn ich diese jeden Tag verwenden will. Naja villeicht gibt es auch für mich ne Lösung. Oder es wachsen immer größere Platten, so das ich auch kein Platz Problem mehr habe. Zahle halt dann immer mehr.
Habe gehofft also auf ne günstige Alternative mit möglichst viel Speicher zu kriegen bzw zu entdecken. Dann bleibt das wohl auch in Zukunft ein Traum.

Und weil mein Nas eh schon 10 von 10 Festplatten hat und mir das nicht reichen wird, muss ich wohl auf einen weiteren Nas umsatteln. Damit ich da auch wieder nicht zu teure Festplatten verstauen kann. Mir bleibt also ne Aufteilung die einzige Option. Besser als nix kann man dazu sagen.

 

[ebird]

Bei Copy to Tape eines bestehenden Backup wie oben beschrieben ist kaum bis keine Komprimierung mehr drin, da das Backup an sich schon dedupliziert und komprimiert ist. Wir deaktivieren daher meistens Hardware-Komprimierung - bringt eh kaum was und ist dann nur ein Schritt mehr, der im Wurst-Käse-Szenario potentiell Probleme machen kann.

Was ist das für eine Logik? Hier geht es um einen Komprimierungsfaktor von normalen Unternehmensdaten und da ist 2:1 absolut realistisch. Natürlich kann man komprimierte Daten nicht noch mal komprimieren, sonst könnte man diesen Schritt ja immer wieder anwenden. In diesem Zusammenhang macht Deine 1.2:1 dann überhaupt keinen Sinn mehr.

 

[Banned]

Habe nicht nur Filme sondern Serien, Bilder, textdokumente, Spiele und ISO Dateien.

Und das geht mit dem Band also nicht.

Klar, ist dem Band doch egal, was da für Daten drauf kommen.

Band ist gut zur Langzeitarchivierung, egal von welchen Daten. Ob es bei einer Filmesammlung (welche ja idR schon ein sehr großes Datenvolumen hat) Sinn macht, wird man sehen, wenn die Preise bekannt sind.

 

[wern001]

Bei Copy to Tape eines bestehenden Backup wie oben beschrieben ist kaum bis keine Komprimierung mehr drin, da das Backup an sich schon dedupliziert und komprimiert ist. Wir deaktivieren daher meistens Hardware-Komprimierung - bringt eh kaum was und ist dann nur ein Schritt mehr, der im Wurst-Käse-Szenario potentiell Probleme machen kann.

mach ich auch so. Komprimierung und Duplizierung mit Acronis auf eine eingens Raid0 nur für Backup und sobald das fertig ist copy auf Tape

 

[M@tze]

Hmm... wir implementieren immer ein Backup auf Disk in der ersten Instanz und Copy to Tape in einer zweiten. In den allermeisten Fällen wird für ein Restore nur das Disk Backup benötigt, was erheblich bequemer ist.

Ja, so haben wir das später dann auch gemacht. Nachdem bei den Systemen keine inkrementellen Backups funktionierten und immer Fullbackup gefahren werden musste und wir weltweit entwickeln, es also nie den klassischen "in der Nacht wird das Backup gemacht" Fall gab, war die Zeitspanne immer sehr gering.

'Vor der Virtualisierung' ist sicherlich auch schon ein Weilchen her, oder?

Ja, heute ist das ja alles mit Snapshots ein Kinderspiel, da kann das Backup danach schon eine Weile laufen.

 

[Wechsler]

Bei meinem zfs pool hatte ich auch erwartet irgendwann wenigstens mal einen Fehler beim scrubbing zu sehen, doch seit 7 Jahren mit teils ebenso alten Daten, die praktisch read only sind, nix.

Ich habe noch nie einen unkorrigierbaren Fehler bei einer modernen Festplatte gesehen, die ansonsten voll funktionstüchtig war. Geschweige denn Fehler, die der festplatteninterne ECC nicht erkannt und nach außen durchgereicht hat, damit sie ZFS per Checksumming finden kann. Statt dessen haben sich jede Menge Leute ihre Daten gegrillt, weil ZFS DRAM Corruption für Storage Corruption gehalten hat.

Die ganzen ZFS zugrundliegenden Annahmen über Hardware entsprechen nicht der realen Welt.

 

[ReactivateMe347]

Was bedeutet eigentlich "mit Komrpession" ? Ohne Kenntnis der Daten kann man doch für gewöhnlich die Datenreduktion gar nicht abschätzen, sind das MIttelwerte oder gar einfach fiktive Werte?

 

[Ranayna]

Das wird ein "Durchschnitt" ueber eine grosse Menge an vielfaeltigen Daten sein. Plus ein gewisser Marketingfaktor um eine runde Nummer zu bekommen.
Aber Komprimierungsalgorithmen entwickeln sich ja auch weiter (siehe das WinRAR Update vor ein paar Tagen), und die sind auf den Laufwerken in Hardware gegossen, also schnell.

Ist eine ganze Weile her, aber damals, zu LTO-4 Zeiten, wo ich noch mit Bandsicherungen beschaeftigt war, passte das eigendlich fuer normale Firmenuserdaten ganz gut. Teile unserer Daten sind schlecht komprimierbar, da war es dann vielleicht nur 1,1zu1 oder 1,2zu1, aber die schraddelige "Textfile-Datenbank" hatte ich ja schon erwaehnt, die auf um die 10zu1 kam

 

[foofoobar]

Die ganzen ZFS zugrundliegenden Annahmen über Hardware entsprechen nicht der realen Welt.

Nein, das Arschloch ist Intel weil die ECC nur in den teuren CPUs freischalten und zusätzlich viele Ahnungslose behaupten das ECC komplett überflüssig wäre. Und Schrottcomputer sollte man nicht zum Maßstab machen.

Ergänzung (25. Januar 2023)

Was bedeutet eigentlich "mit Komrpession" ? Ohne Kenntnis der Daten kann man doch für gewöhnlich die Datenreduktion gar nicht abschätzen, sind das MIttelwerte oder gar einfach fiktive Werte?

In der realen Welt werden Produktionsdaten gesichert die meistens gut komprimierbar sind und nicht Unmengen an Zeug was man in der Glotze schaut.

 

[AlphaKaninchen]

@foofoobar Und in Kompakten Notebooks sucht man es vergebens...

 

[ebird]

Schade dann ist auch diese Technik hier nicht dafür geeignet. Ich spielte schon mit dem Gedank, die Filme Sammlung günstig auf das zu sichern. Damit weniger Festplatten benötigt werden. Habe nicht nur Filme sondern Serien, Bilder, textdokumente, Spiele und ISO Dateien.

Ich meinte die Komprimierung. Dieses Laufwerk wird schon eher geeignet sein, als ein echtes Banklaufwerk, da dieses Konstrukt hermetisch abgesichert sein wird. Ein Bank musst Du entsprechend lagern.
Wahrscheinlich wird diese System sogar eine wesentlich bessere Fehlerresistenz aufweisen, als die aktuellen Helium Monster - das habe ich jedoch nicht geprüft.

 

[Banned]

Nein, das Arschloch ist Intel weil die ECC nur in den teuren CPUs freischalten

War vor gar nicht so langer Zeit ja noch anders, da konnten es Celeron, Pentium und i3, dafür i5 und i7 nicht. Hat wahrscheinlich damit zu tun, dass der i3 mittlerweile vier Kerne hat und das für einen privaten Homeserver für die meisten wohl die optimale Anzahl an Kernen sein dürfte. Da musste Intel natürlich handeln.

Mein Negativ-Favorit bisher waren aber die RAID-Keys im HEDT.