Tape-Storage sollte tot sein, dann kam jemand mit 50PB und einem Realitätscheck vorbei

Alle paar Jahre erklärt jemand Tape-Storage für tot, mit der Selbstsicherheit einer Person, die noch nie zig Petabyte innerhalb eines abgeschotteten Standorts bewahren musste. Es ist leicht, vom Komfort eines Laptops mit SSD, einem Cloud-Bucket und einer monatlichen Rechnung aus, die noch harmlos aussieht, über Tape zu lachen. Tape klingt uralt, nach Bandrollen, die in einem beigen Maschinenraum surren, nach der Art Technologie, die irgendwann zwischen Diskette und Faxgerät hätte ausgemustert werden sollen. Dann taucht eine echte Storage-Umgebung auf und ruiniert den Witz.

Zwei IBM-TS4500-Bibliotheken, jeweils rund 25PB, Tape als Second-Tier-Storage genutzt. Daten wandern von Tier-1-NL-SAS hinunter in kalte Medien, und Cloud-Upload fällt weg, weil der Standort geschlossen ist. Die Tape-Hardware ist bereits vorhanden, bereits teuer, bereits Teil des Betriebsmodells. Deshalb stellt sich eine schärfere Frage als „nutzt überhaupt noch jemand Tape?": Wenn man bereits über einen 50PB-Tape-Bestand verfügt, was genau soll ihn ersetzen, ohne Kosten, Sicherheit, Performance oder Verstand in die Luft zu jagen?

Genau dort wurde die Diskussion interessant. Manche antworteten mit einem einfachen Ja: Tape ist immer noch der beste und günstigste Weg, um Hunderte Terabyte und mehr zu sichern. Andere drängten in Richtung moderner Disk-Systeme, Ceph, TrueNAS, IBM ESS oder VAST Data. Ein paar wiesen auf etwas hin, das Cloud-Marketing selten laut ausspricht: Ein großer Teil des „Cloud"-Archivs hat wahrscheinlich irgendwo hinter den Kulissen Tape. Das alte Medium hat nur aufgehört, sich darum zu kümmern, ob coole Leute es gutheißen.

Tape gewinnt weiter, weil kalte Daten andere Regeln haben

Der Fehler, den Menschen machen, ist, Tape mit aktivem Storage zu vergleichen. Tape ist furchtbar, wenn man alles sofort braucht. Es ist sequenziell, es ist mechanisch, und es hängt von Robotik, Kassetten, Laufwerken, Katalogen und Geduld ab. Wenn der Anwendungsfall latenzarmer wahlfreier Zugriff auf heiße Daten ist, ist Tape offensichtlich die falsche Antwort. Niemand Ernsthaftes tut so, als sollte sich eine Tape-Bibliothek wie ein NVMe-Cluster verhalten. Kalte Daten spielen aber nach anderen Regeln.

Im Petabyte-Maßstab wirkt günstiger passiver Storage weniger wie Nostalgie und mehr wie Überleben. Tape muss nicht den ganzen Tag rotieren und braucht keinen Strom pro Kassette, sobald sie eingelagert ist. Es kann off-site verlagert werden, es kann air-gapped sein, und es kann außerhalb der teuersten Bereiche des Rechenzentrums leben, wenn die Umgebung ordentlich kontrolliert wird. Das zählt, wenn die Alternative darin besteht, für riesige Disk-Farmen zu zahlen, die Strom, Kühlung, Rackplatz, Support und Aufmerksamkeit verbrauchen, nur um Daten verfügbar zu halten, die so gut wie niemand anfasst.

Ein Kommentator brachte es schlicht auf den Punkt: Tape ist immer noch der beste und günstigste Weg, um große Datenmengen zu sichern, sobald man von Hunderten Terabyte spricht. Diese Person nutzte ein LTO-8-Laufwerk mit Dutzenden Bändern. Die ursprüngliche Umgebung war weit größer, aber dasselbe Prinzip skaliert: Je kälter die Daten werden, desto mehr ergibt Tape wieder Sinn.

Deshalb hat die Frage „nutzt überhaupt noch jemand Tape?" eine seltsame Antwort. Zu Hause vielleicht nicht oft. In ernsthaften Archiven, Backup-Umgebungen, Forschungsstandorten, Medienbetrieben, Regierungseinrichtungen und geschlossenen Netzwerken absolut. Die Menschen, die es nutzen, brauchen nicht, dass es angesagt ist. Sie brauchen, dass es günstig, langlebig, entfernbar und langweilig ist, und im Langweiligsein ist Tape sehr gut.

Geschlossene Standorte verändern das gesamte Cloud-Gespräch

Cloud-Storage ist in vielen modernen Infrastrukturdiskussionen die Standardantwort, oft mit einem Schulterzucken vorgetragen. Einfach hochladen, einfach Object Storage nutzen, einfach Archiv-Tiers verwenden, einfach jemand anderen die Hardware verwalten lassen. Dieser Rat bricht in einer geschlossenen Standortumgebung schnell zusammen. Wenn Daten den Standort nicht verlassen dürfen, ist die Cloud ein Compliance-Verstoß in Produktseiten-Verkleidung und eben kein Storage-Tier.

Diese Einschränkung verändert alles. Der ursprüngliche Poster machte klar, dass ein Upload in die Cloud keine Option war. Das bedeutet: kein einfacher Ausweg zu Glacier-artiger Ökonomie, kein Vorspiegeln, Hyperscaler würden das Archivmanagement magisch lösen, und kein Abwälzen des Datengravitationsproblems auf die Bilanz eines anderen. Der Storage muss innerhalb des Standorts leben, das Betriebsmodell muss lokal im eigenen Besitz sein, und der Migrationspfad muss die vorhandene physische Infrastruktur respektieren.

Für geschlossene Umgebungen hat Tape zusätzlichen Reiz. Es ist lokal, es ist physisch kontrollierbar, und es kann gemäß internen Verfahren eingelagert werden. Es erfordert kein Vertrauen in das Zugriffsmodell, Abrechnungsmodell, die regionale Haltbarkeitsgeschichte oder die künftige Preisstimmung eines externen Anbieters. Es schafft außerdem eine saubere Trennung zwischen Online-Storage und Offline-Archiv, was zählt, wenn Sicherheitsleute über Ransomware, Insider-Risiken und Blast Radius sprechen.

Eine anonyme Stimme wies darauf hin, dass Menschen überrascht sein könnten, wie viel von der Cloud immer noch Tape-Storage beinhaltet. Ob nun jedes Cloud-Archiv-Tier in jeder Implementierung wirklich so funktioniert oder nicht, der Punkt trifft: Selbst die Cloud-Welt versteht die Ökonomie kalter Daten. Deep Archive ist keine Magie, irgendwo muss Hardware die Bits noch immer halten. Die Cloud ließ Storage abstrakt wirken, und Tape erinnert alle daran, dass Physik immer noch Rechnungen verschickt.

Das Problem steckt im alternden Tier 1

Die ursprüngliche Frage drehte sich weniger darum, Tape zu ersetzen, als darum, altes Tier-1-Storage zu ersetzen, und diese Unterscheidung zählt. Die Tape-Bibliotheken sind bereits vorhanden, dienen bereits als Second-Tier-Storage und sind bereits teuer zu ersetzen. Der alternde Teil ist der NL-SAS-Tier, der das Archiv speist. Der Standort braucht jetzt Performance, und dort beginnt die Debatte sich zu spalten.

Manche schlugen TrueNAS- oder ZFS-artige Ansätze vor. Der ursprüngliche Poster widersprach und sagte, er glaube nicht, dass TrueNAS auf 50 bis 60PB skalieren könne und gleichzeitig hohe Performance liefere, weshalb IBM ESS und VAST Data in Betracht gezogen wurden. Eine Antwort sagte, TrueNAS könne so hoch skalieren, aber man würde primäre Backup-Daten als erste Kopie nicht iX anvertrauen. Eine andere Person sagte, VAST sei hervorragend: kerngesund, hochperformant und eine starke Grundlage für Datenmanagement.

Hier wird Storage-Architektur ernst. Der heiße Tier und der Archiv-Tier haben unterschiedliche Aufgaben. Tape wegen eines alten Tier 1 durch Disk zu ersetzen, wäre, als würde man ein Lagerhaus ersetzen, weil die Laderampe kaputt ist. Vielleicht funktioniert das Lagerhaus noch, und vielleicht muss nur die Laderampe modernisiert werden. Die bessere Frage ist: Welche Daten brauchen Performance, für wie lange, und wann sollten sie altern?

Wenn nur eine Teilmenge der Daten hohe Geschwindigkeit braucht, kann ein teures All-Flash-Universum Overkill sein. Wenn massive Working Sets häufigen Zugriff brauchen, klettert der Preis schnell. Wenn das Zugriffsmuster vorhersehbar ist, lässt sich Tiering optimieren. Wenn Nutzer plötzlich erwarten, dass alles für immer heiß ist, sollte jemand das Finanzteam ins Zimmer holen, bevor irgendjemand Wunder verspricht. Petabyte-skalige Performance fügt man nicht beiläufig hinzu. Sie ist eine Lebensstil-Entscheidung mit einer erschreckenden Rechnung.

„Nehmt einfach SSDs" ist technisch korrekt und finanziell brutal

Jemand schlug vor, den Festplatten-Tier durch ein SSD-Array zu ersetzen, weil das extrem schnell wäre. Das stimmt, auf dieselbe Weise wie „kauft einfach einen Jet" ein Pendelproblem löst. Es funktioniert, und es ist trotzdem nicht automatisch die richtige erste Antwort.

Ein anderer Kommentator scherzte sich durch die Mathematik und sagte, wenn die Performance-Anforderungen über das hinausgehen, was ZFS-SSD-Cache und rotierende Disks bewältigen können, sollte das Management sich darauf vorbereiten, für dichte NVMe-Boxen voller großer Kioxia-Laufwerke zu zahlen. Er warf die grobe Idee von Tausenden 30-TB-NVMe-Laufwerken in den Raum und schlug leichte Sedierung für denjenigen vor, der die Rechnung bezahlen muss. Es ist witzig, weil die Flash-Ökonomie im Petabyte-Maßstab sehr schnell sehr real wird.

Die Debatte legte eine nützliche Spannung offen. Manche unterschätzen, wie viel Performance bestimmte Umgebungen tatsächlich brauchen. Eine Antwort widersprach der Idee, dass nur Hyperscaler großen hochperformanten Storage brauchen, und verwies auf Medienproduktion als Beispiel. Selbst ein kleineres Postproduktionsstudio könnte sich durch Petabytes fressen und Workstations brauchen, die Rohvideo direkt von einem SAN bearbeiten, ohne lokale Kopien anzulegen. Das war vor einem Jahrzehnt, bevor neuere Videoformate den Storage-Appetit noch hässlicher machten.

Die richtige Antwort lautet also weder „das braucht niemand" noch „kauft einfach All-Flash". Manche Organisationen brauchen wirklich hochperformanten Storage in erschreckendem Maßstab. Medien, Forschung, wissenschaftliches Rechnen, Simulation, Verteidigung, Bildgebung, Genomik, Überwachung und KI-nahe Workloads können alle seltsame Mischungen aus Kapazität und Geschwindigkeit erzeugen. Das hebt die Ökonomie nicht auf, es bedeutet nur, dass die Architektur brutal ehrlich sein muss, was heiß sein muss, was warm sein kann und was auf Tape gehört. Die Storage-Tiering-Strategie wird damit selbst zum Produkt.

VAST Data und IBM ESS ergeben Sinn, weil das kein Spielzeugproblem ist

Wenn jemand zwischen VAST Data und IBM ESS wählt, befindet sich die Umgebung nicht mehr im Bereich „stellt einfach ein NAS in die Ecke". Das sind ernsthafte Plattformen für ernsthaften Maßstab. IBM ESS passt natürlich in Gespräche, in denen das Spectrum-Scale-Erbe, große sequenzielle Workloads, HPC-artige Muster und tiefe IBM-Storage-Ökosysteme zählen. VAST kommt ins Spiel, wenn hochperformanter unstrukturierter Storage, Datenservices, Skalierung und moderne Architektur attraktiv werden. Automatisch richtig ist damit keines von beiden.

IBM ESS mag sich wie die sicherere institutionelle Wahl anfühlen, besonders nahe an vorhandener IBM-Tape-Infrastruktur. Der Komfort, nahe an einem bekannten Anbieter zu bleiben, kann in geschlossenen Umgebungen mit hohem Maßstab zählen. Beschaffung mag es bevorzugen, Support-Prozesse existieren vielleicht bereits, Skills lassen sich vielleicht leichter übertragen, und die Plattform passt vielleicht gut zu wissenschaftlichen oder HPC-Mustern.

VAST hingegen hat starken Reiz, wenn sich der heiße Tier modern, schnell und skalierbar anfühlen muss, ohne alte Storage-Gewohnheiten mitzuschleppen. Ein Kommentator mit Erfahrung nannte es hervorragend, stabil, hochperformant und eine gute Grundlage für Datenmanagement. Ein solches Praxislob zählt, sollte aber trotzdem zu einem Proof of Concept führen und nicht zu blindem Vertrauen.

In diesem Maßstab sollte sich das Anbieter-Bake-off um mehr drehen als um glänzende Durchsatzzahlen. Es sollte Recall von Tape testen, Ingest in Tier 1, Metadaten-Verhalten, Namespace-Skalierung, Ausfallwiederherstellung, Rebuild-Auswirkungen, Nutzerzugriffsmuster, Migrationswerkzeuge, Lifecycle-Policies und operative Sichtbarkeit. Die heiße Plattform muss mit dem Tape-Bestand kooperieren, statt so zu tun, als gäbe es ihn nicht. Das Archiv ist Teil des Systems, und es zu ignorieren wäre architektonisches Fehlverhalten.

Ceph und TrueNAS sind verlockend, aber die Eigenverantwortung wiegt schwer

Ceph tauchte als mögliche Antwort auf, weil es skaliert und auf viele Arten geformt werden kann. Das stimmt, Ceph ist mächtig. Es kann massive Object-, Block- und File-artige Deployments leisten, wenn es von Leuten betrieben wird, die wissen, was sie tun. Es verlangt auch Respekt: Bei zig Petabyte kann „nehmt einfach Ceph" zu „Glückwunsch, Sie betreiben jetzt eine Storage-Engineering-Organisation" werden. Das mag für manche Teams passen und für andere katastrophal sein.

TrueNAS bekam eine ähnliche Behandlung. Manche argumentierten, große ZFS-Deployments seien möglich, andere waren skeptisch, es als primäre Kopie in diesem Maßstab zu vertrauen. Darin liegt der entscheidende Unterschied. Kann etwas technisch skalieren? Vielleicht. Sollte diese bestimmte Organisation ihren primären Backup- und Archiv-Workflow darauf verwetten? Andere Frage.

Offene Systeme können im Voraus günstiger und flexibler sein, aber die Rechnung kommt oft in Form von Personal, Tuning, Lifecycle-Management, Anbieterkoordination und operativem Risiko. Kommerzielle Plattformen kosten mehr, können aber die Last verringern, jede Integration und jeden Fehlerfall selbst zu besitzen. Kein Modell ist moralisch überlegen. Das richtige hängt vom Können des Teams ab, der Toleranz gegenüber Vendor-Lock-in, der Budgetstruktur, den Uptime-Erwartungen und davon, wie hässlich die Folgen sind, wenn etwas kaputtgeht.

Bei 50PB wird aus Storage ein ganzes Programm, und dieses Programm braucht Menschen, Prozess, Tests, Lifecycle-Planung und eine ehrliche Sicht darauf, was das Team um 3 Uhr morgens ohne heroische Improvisation betreiben kann.

Tape verschwindet nicht, braucht aber ein besseres Frontend

Ein Thema, das im Thread verborgen liegt, ist, dass Tape oft hinter einem schnelleren Frontend überlebt. Genau so sollte es funktionieren. Nutzer und Anwendungen sollten nicht über Kassetten nachdenken müssen, außer ihre Arbeit betrifft ausdrücklich Archivvorgänge. Der heiße oder warme Tier sollte Schreibvorgänge absorbieren, aktive Workloads bedienen und gealterte Daten gemäß Policy nach unten migrieren. Tape sollte die tiefe, günstige, physisch kontrollierte Schicht darunter werden. Dieses Modell ist alt, aber die Umsetzung braucht Modernisierung.

Ein veralteter NL-SAS-Tier-1 mag vor Jahren Sinn ergeben haben. Wenn sich jetzt die Performance-Anforderungen geändert haben, muss sich auch das Frontend ändern. Vielleicht bedeutet das VAST, vielleicht IBM ESS, vielleicht eine Hybrid-Architektur mit Flash-Metadaten-Beschleunigung und Disk-Kapazität, vielleicht eine Object-Schicht, vielleicht eine Aufteilung zwischen Produktionsleistungsstorage und Backup- und Archiv-Landingzonen. Die Antwort hängt von der Form der Workload ab.

Was nicht passieren sollte, ist ein binäres Streitgespräch, in dem Tape entweder die Zukunft oder die Vergangenheit ist. Tape kann das Archiv bleiben, während sich der aktive Tier dramatisch weiterentwickelt, und genau das könnte der sinnvollste Weg sein: die TS4500-Investition und die Vorteile des air-gapped, lokalen, geschlossenen Standorts behalten, den müden Tier 1 durch etwas ersetzen, das aktuellen Performance-Anforderungen entspricht, die Lifecycle-Bewegung zwischen Tiers verbessern, Restore- und Recall-Workflows messbar machen und alles testen. Tape ist jedenfalls nicht der Flaschenhals, nur weil es alt ist, und manchmal ist das alte Ding der Teil, der noch seine Arbeit macht.

Die Frage „nutzt überhaupt noch jemand Tape?" hat eine peinlich klare Antwort

Ja, Menschen nutzen immer noch Tape: ernsthafte Menschen, ernsthafte Umgebungen, ernsthafte Datenmengen. Sie nutzen es, weil es im Maßstab günstig ist, weil die Cloud nicht immer erlaubt ist, weil Offline-Medien immer noch zählen, weil Archive nicht dasselbe sind wie aktive Daten und weil Petabytes Ideologie teuer machen.

Die bessere Frage ist deshalb, ob die Storage-Architektur rund um Tape mitgehalten hat. In diesem Fall scheint die Antwort Nein zu sein. Die Tape-Bibliotheken sind nicht der offensichtliche Schwachpunkt, der alternde Tier-1-Storage ist es. Die Organisation braucht jetzt Performance, muss aber auch die Ökonomie und das Sicherheitsmodell bewahren, die Tape ursprünglich wertvoll gemacht haben. Das deutet auf ein modernes hochperformantes Frontend hin, bei dem Tape als tiefer Archiv-Tier erhalten bleibt. Ein dramatisches Abfackeln des bestehenden Systems wäre dagegen die Art einfacher Ersetzung, die das Internet liebt, während echte Infrastruktur meist mit geschichteten Kompromissen besser fährt.

Tape wird wahrscheinlich unsichtbarer, bleibt aber wichtig

Die Zukunft von Tape wird wahrscheinlich nicht so aussehen, dass Admins den ganzen Tag manuell an Kassetten denken. Sie wird versteckt sein hinter Policy-Engines, Archiv-Software, Object-Gateways, Medienmanagern und Workflows, die tiefen Storage weniger primitiv wirken lassen. Die Kassette bleibt, aber die menschliche Erfahrung verbessert sich. Das ist die Version von Tape, die Sinn ergibt: eine unsichtbare kalte Schicht, die günstige Bewahrung leistet, während schnellere Systeme die aktive Arbeit übernehmen.

Für einen geschlossenen Standort mit bereits 50PB hinter TS4500-Bibliotheken bräuchte es einen sehr triftigen Grund, sich von Tape abzuwenden. Performance allein ist kein solcher Grund, wenn der Performance-Schmerz in Tier 1 liegt. Die Cloud ist keine Antwort, wenn der Standort nicht hochladen kann. All-Flash-für-alles mag technisch wunderschön und finanziell absurd sein, DIY-Scale-out mag möglich und operativ riskant sein. Eine ernsthafte kommerzielle Plattform gepaart mit vorhandenem Tape mag die am wenigsten dramatische und dafür die reifste Antwort sein.

Tape hat überlebt, weil kalte Daten stur sind, Budgets real sind und Physik sich nicht schert um