Dateisysteme und Datenträger

Vom Datenträger zur Datei: mehrere Schichten statt eines einzigen „Speichers“

Ein Datenträger ist zunächst nur ein adressierbarer Speicherraum. Erst mehrere darüberliegende Schichten machen daraus Laufwerke, Partitionen, Volumes, Verzeichnisse und Dateien. Physisches Medium, Controller, Übertragungsprotokoll, Partitionsschema und Dateisystem erfüllen unterschiedliche Aufgaben. Eine SATA-Festplatte kann beispielsweise GPT-partitioniert und mit NTFS formatiert sein; eine NVMe-SSD kann dieselbe GPT-/NTFS-Kombination verwenden, obwohl die Hardware darunter völlig anders arbeitet.

Für Fehlersuche und Archivierung ist diese Trennung entscheidend. Ein Laufwerk kann elektrisch erreichbar sein, während die Partitionstabelle beschädigt ist. Eine Partition kann vorhanden sein, während das Dateisystem inkonsistent ist. Ein Dateisystem kann korrekt eingebunden werden, obwohl einzelne Dateien inhaltlich beschädigt sind. Wer alle Ebenen nur als „Platte kaputt“ bezeichnet, verliert genau die Information, die für eine saubere Diagnose benötigt wird.

Sektor, Block, Cluster, Extent, Volume und Datei

Die klassische Speichersprache ist voller Begriffe, die ähnlich klingen, aber nicht dasselbe bedeuten. Ein Sektor beziehungsweise logischer Block ist eine adressierbare Einheit des Geräts. Ein Dateisystemblock ist eine vom Dateisystem verwendete Verwaltungseinheit. Ein Cluster bezeichnet insbesondere in der FAT-/NTFS-Welt eine Zuordnungseinheit aus einem oder mehreren Sektoren. Ein Extent beschreibt einen zusammenhängenden Bereich mehrerer Blöcke. Ein Volume ist ein logisch nutzbarer Speicherbereich, auf dem typischerweise ein Dateisystem liegt.

Diese Begriffe sollten bei einer technischen Dokumentation nicht beliebig austauschbar verwendet werden. Gerade bei Imaging, Partitionserkennung oder Dateisystemreparatur kann ein falscher Begriff zu einer falschen Handlung führen.

512 Byte, 4 KiB, 512e und 4Kn

Historische PC-Festplatten wurden über lange Zeit mit 512-Byte-Sektoren adressiert. Moderne Festplatten und SSDs arbeiten intern häufig mit größeren physischen Einheiten. Bei 512e präsentiert das Laufwerk nach außen weiterhin 512-Byte-logische Sektoren, obwohl physisch typischerweise 4-KiB-Sektoren verwendet werden. 4Kn verzichtet auf diese Emulation und stellt 4096 Byte als logische Sektorgröße bereit.

Die Unterscheidung betrifft Ausrichtung, Kompatibilität und Schreibverhalten. Eine ungünstig ausgerichtete Partition kann dazu führen, dass ein logischer Schreibvorgang mehrere physische Einheiten berührt. Bei älteren Betriebssystemen, Imaging-Werkzeugen oder Bootumgebungen ist außerdem nicht selbstverständlich, dass 4Kn verstanden wird. Ein sektorweises Image sollte deshalb nicht nur die Bytefolge sichern, sondern auch die logische Sektorgröße dokumentieren.

CHS: Zylinder, Köpfe und Sektoren als historische Adressierungswelt

Frühe Festplatten wurden mit der Vorstellung von Cylinder/Head/Sector adressiert. CHS passte zu einer mechanisch gedachten Geometrie, wurde aber mit wachsender Kapazität zunehmend zu einer Übersetzungs- und Kompatibilitätsschicht. BIOS, Controller und Laufwerk konnten unterschiedliche Geometrien melden, obwohl dieselben Datenblöcke gemeint waren.

Für historische Images und alte Partitionstabellen bleibt CHS wichtig, weil MBR-Einträge neben LBA-Feldern auch CHS-Informationen enthalten. Bei späteren Systemen sind diese Angaben häufig nur noch abgeleitet oder auf Grenzwerte gesetzt. Ein scheinbarer Widerspruch zwischen CHS und LBA ist deshalb nicht automatisch ein Defekt; entscheidend ist, welche Adressierungslogik das jeweilige System tatsächlich verwendet.

LBA: lineare Blockadressen statt künstlicher Geometrie

Logical Block Addressing behandelt den Datenträger als lineare Folge nummerierter Blöcke. Für Betriebssystem und Dateisystem ist damit nicht mehr entscheidend, auf welchem Zylinder oder unter welchem Kopf ein Block physisch liegt. Das Laufwerk beziehungsweise dessen Controller übernimmt die Umsetzung auf die interne Medienorganisation.

Diese Abstraktion war Voraussetzung für immer größere Laufwerke und ist heute selbstverständlich. Auch SSDs, die überhaupt keine Zylinder oder Köpfe besitzen, präsentieren dem Host einen LBA-Adressraum. Das zeigt exemplarisch, wie lange historische Begriffe in Benutzeroberflächen weiterleben können, obwohl die darunterliegende Hardware längst anders funktioniert.

MBR: Bootcode, Partitionstabelle und historische Grenzen

Der klassische Master Boot Record liegt im ersten logischen Sektor eines traditionell partitionierten PC-Datenträgers. Er enthält Bootcode, vier Partitionseinträge und die Signatur am Ende des Sektors. Diese Einfachheit machte den MBR über Jahrzehnte kompatibel, brachte aber enge Grenzen mit sich: nur vier primäre Einträge, erweiterte Partitionen als Verkettungskonstruktion und 32-Bit-LBA-Felder im Partitionsschema.

Ein MBR ist deshalb zugleich Bootstruktur und Partitionsverzeichnis. Wird er überschrieben, sind die Dateidaten in den Partitionen nicht automatisch verloren. Umgekehrt beweist ein plausibler MBR nicht, dass die darin bezeichneten Dateisysteme intakt sind. Bei Wiederherstellung ist diese Trennung fundamental: zuerst Layout rekonstruieren, erst danach Dateisystemstrukturen beurteilen.

GPT: GUIDs, Redundanz und 64-Bit-LBAs

Die GUID Partition Table löst die wichtigsten strukturellen Grenzen des MBR. GPT verwendet 64-Bit-LBAs, kann deutlich mehr Partitionen beschreiben und hält sowohl einen primären als auch einen Backup-Header vor. Header und Partitionseintragsarray werden mit CRC32-Werten abgesichert. Jede Partition kann außerdem eine eindeutige GUID, einen Typ-GUID, Attribute und einen lesbaren Namen tragen.

Bei einem typischen GPT-Datenträger liegt an LBA 0 ein Protective MBR, der ältere Werkzeuge davon abhalten soll, den Datenträger als unpartitioniert zu betrachten. Der primäre GPT-Header folgt an LBA 1, der Backup-Header liegt am Ende des Mediums. Diese Redundanz ist kein Ersatz für ein Backup, verbessert aber die Chance, strukturelle Schäden an einer Kopie der Partitionstabelle zu erkennen oder zu rekonstruieren.

Partition, Volume, Laufwerksbuchstabe und Mountpoint

Eine Partition ist ein Bereich im Partitionsschema; ein Volume ist die logische Speichereinheit, die ein Betriebssystem tatsächlich einbindet. In einfachen Fällen decken sich beide Begriffe fast vollständig. Bei LVM, Storage Spaces, Software-RAID, verschlüsselten Containern oder dynamischen Datenträgern können Volumes jedoch über mehrere Partitionen oder Geräte reichen beziehungsweise innerhalb anderer Strukturen liegen.

Auch ein Laufwerksbuchstabe ist kein Bestandteil des Dateisystems. Er ist eine Zuordnung des Betriebssystems. Windows kann Volumes ebenso in NTFS-Verzeichnisse einhängen; Unix-artige Systeme kennen traditionell einen gemeinsamen Verzeichnisbaum mit Mountpoints. Für Archivnotizen ist daher sinnvoll, die ursprüngliche logische Einbindung getrennt von der eigentlichen On-Disk-Struktur festzuhalten.

Bootsektoren und Volume-Bootstrukturen

Viele Dateisysteme besitzen am Beginn eines Volumes einen besonderen Boot- oder Superblockbereich. Bei FAT enthält der Bootsektor unter anderem das BIOS Parameter Block mit Geometrie- und Layoutangaben. NTFS speichert im Volume Boot Record grundlegende Parameter zur Geometrie des Volumes und zur Lage zentraler Strukturen. Unix-Dateisysteme verwenden andere Superblockkonzepte, verfolgen aber denselben Grundgedanken: Das Dateisystem benötigt einen definierten Einstieg in seine Metadaten.

Ein beschädigter Bootsektor kann dazu führen, dass ein ansonsten weitgehend intaktes Dateisystem nicht automatisch erkannt wird. Deshalb sollte bei Diagnose nicht sofort auf Dateiebene gesucht werden. Zunächst ist zu klären, ob Partition, Volume-Start und zentrale Strukturparameter überhaupt plausibel sind.

Was ein Dateisystem eigentlich leisten muss

Ein Dateisystem verbindet Namen mit Datenbereichen und Metadaten. Es muss freien und belegten Speicher verwalten, Verzeichnisse organisieren, Dateien lokalisieren, Größen und Zeitstempel pflegen und nach Möglichkeit einen konsistenten Zustand erhalten. Moderne Dateisysteme ergänzen Rechte, Journaling, Prüfsummen, Kompression, Verschlüsselung, Sparse Files, Links oder Snapshots.

Die sichtbare Datei ist damit nur die oberste Ebene. Darunter liegen Verzeichniseinträge, Zuordnungsinformationen, Freispeicherstrukturen und gegebenenfalls Transaktionsprotokolle. Ein Dateisystemfehler kann deshalb beispielsweise nur die Namenszuordnung beschädigen, während die eigentlichen Nutzdatenblöcke noch vorhanden sind. Umgekehrt kann ein korrekt benannter Eintrag auf bereits beschädigte Daten zeigen.

Speicherzuordnung: Ketten, Bitmaps, Bäume und Extents

Dateisysteme unterscheiden sich stark darin, wie sie belegte Bereiche beschreiben. FAT bildet Clusterketten über eine zentrale Tabelle ab. NTFS beschreibt Dateiinhalte über Attribute und Run-Listen beziehungsweise Extents in der MFT. ext4 verwendet Inodes, Blockgruppen und in modernen Konfigurationen Extent-Bäume. exFAT ergänzt zur FAT-Familie eine Allocation Bitmap und kann zusammenhängende Dateien besonders effizient markieren.

Diese internen Modelle bestimmen Fehlersymptome. Bei einer beschädigten FAT kann eine Clusterkette abbrechen oder in eine andere Datei laufen. Bei einer defekten Bitmap können Blöcke fälschlich als frei oder belegt gelten. Beschädigte Baumstrukturen können dazu führen, dass große Dateien nur teilweise erreichbar sind. „Dateisystem beschädigt“ ist daher nur der Oberbegriff für sehr verschiedene konkrete Defekte.

Fragmentierung: logisch verstreute Daten und ihre Folgen

Wenn freie Bereiche nicht mehr zusammenhängend zur Verfügung stehen, muss eine Datei auf mehrere Stellen verteilt werden. Auf mechanischen Festplatten kostet das zusätzliche Kopfbewegungen und kann die Leistung deutlich reduzieren. Auf SSDs entfällt die mechanische Suchzeit, trotzdem bleibt Fragmentierung als Metadaten- und Verwaltungsproblem relevant. Die optimale Behandlung hängt deshalb vom Medium und Dateisystem ab.

Defragmentierung ist keine Datenrettungsmethode. Auf einem instabilen oder physisch auffälligen Laufwerk erzeugt sie zusätzliche Schreib- und Lesevorgänge und kann die Lage verschlechtern. Archiv- und Wiederherstellungsarbeit beginnt mit einem möglichst schonenden Abbild, nicht mit einer kosmetischen Neuordnung des Originalmediums.

Metadaten: Name, Größe, Zeit, Rechte und mehr

Zu einer Datei gehören mehr Informationen als ihr Inhalt. Dateiname, Größe, Zeitstempel, Attribute, Eigentümer, Zugriffsrechte, Verweise und gegebenenfalls alternative Datenströme oder erweiterte Attribute bilden den Metadatenrahmen. Unterschiedliche Dateisysteme können diese Informationen sehr verschieden speichern.

Bei Migrationen gehen deshalb häufig Informationen verloren, obwohl die Nutzdaten bytegleich bleiben. Eine Datei von NTFS auf FAT32 verliert beispielsweise NTFS-spezifische ACLs und kann keine Alternate Data Streams mitnehmen. Umgekehrt können Unix-Rechte, Symlinks oder Extended Attributes bei einer Übertragung auf ein einfacheres Zielformat verloren gehen. Für Archivmigration ist also nicht nur die Dateiprüfsumme relevant, sondern auch die Frage, welche Metadaten erhalten werden müssen.

Zeitstempel und ihre Tücken

Erstellungs-, Änderungs-, Zugriffs- und Metadatenzeitpunkte sind nicht über alle Dateisysteme gleich definiert. FAT speichert Zeiten mit anderen Auflösungen und Zeitzonenannahmen als NTFS oder ext4. Beim Kopieren zwischen Systemen können Werte gerundet, lokal interpretiert oder neu gesetzt werden. Auch Archivprogramme und Netzwerkprotokolle können Zeitinformationen verändern.

Historische Zeitstempel sind deshalb Indizien, keine absolute Wahrheit. Eine Dokumentation sollte möglichst festhalten, ob ein Datum vom Originalmedium stammt, durch Kopieren entstanden sein könnte oder aus einer späteren Archivierung übernommen wurde. Besonders bei alten DOS-/Amiga-Beständen ist die Plausibilitätsprüfung oft wichtiger als die scheinbare Genauigkeit einer modernen Anzeige.

FAT-Familie: einfache Tabellen mit großer historischer Wirkung

Die File Allocation Table gehört zu den prägendsten Dateisystemfamilien der PC-Geschichte. Das Grundprinzip ist leicht verständlich: Verzeichniseinträge beschreiben Dateien, während die FAT für jeden Cluster festhält, ob er frei ist, reserviert ist, defekt markiert wurde, das Ende einer Kette darstellt oder auf den nächsten Cluster verweist. Diese Einfachheit erleichterte Implementierungen und den Austausch zwischen Systemen.

FAT12, FAT16 und FAT32 unterscheiden sich vor allem in der Breite der Clusterindizes und daraus folgenden Größenbereichen. Die Zahl im Namen bezeichnet nicht einfach die Dateigröße und auch nicht unmittelbar die Sektorgröße. Entscheidend ist die Zahl der Bits, die für Clusterverweise im jeweiligen Format zur Verfügung stehen.

FAT12 und die Diskettenwelt

FAT12 ist eng mit Disketten und kleinen DOS-Volumes verbunden. Zwölf Bit pro FAT-Eintrag erlauben nur eine begrenzte Zahl von Clustern, passen aber gut zu Medien mit geringer Kapazität. Gerade auf Disketten ist die Struktur überschaubar: Bootsektor, FAT-Kopien, Root Directory und Datenbereich bilden ein kompaktes Layout.

Für Archivierung alter Disketten ist wichtig, nicht nur die sichtbaren Dateien zu kopieren. Ein sektorgetreues Image bewahrt Bootsektor, gelöschte Verzeichniseinträge, unzugeordneten Raum, Dateisystemfehler und gegebenenfalls ungewöhnliche Formatierungen. Eine bloße Dateikopie kann für Alltagsnutzung genügen, ist aber keine vollständige Abbildung des historischen Mediums.

FAT16: Festplatten und die Grenzen wachsender Volumes

FAT16 erweiterte den Adressraum gegenüber FAT12 deutlich und wurde zum typischen Dateisystem vieler DOS- und früher Windows-Festplatten. Mit steigender Volumegröße mussten größere Cluster verwendet werden, wodurch kleine Dateien mehr Verschnitt erzeugen konnten. Diese Abhängigkeit zwischen Clusterzahl, Clustergröße und Volumegröße prägte die praktische Partitionierung der Zeit.

Die berühmten Größenlimits sind nicht nur vom abstrakten FAT16-Format abhängig, sondern auch von Betriebssystem, Partitionstyp, Sektorgröße und konkreter Implementierung. Historische Aussagen wie „FAT16 kann nur X“ sollten deshalb immer im Kontext der jeweiligen DOS-/Windows-Version betrachtet werden.

FAT32: kleinere Cluster, größere Volumes und neue Metadatenbereiche

FAT32 vergrößert die Zahl adressierbarer Cluster erheblich und ermöglicht damit größere Volumes bei vernünftigen Clustergrößen. Die Root Directory ist nicht mehr auf einen festen Bereich unmittelbar hinter den FATs beschränkt, sondern wird wie ein normales Clusterobjekt behandelt. Zusätzlich existiert ein FSInfo-Sektor, der Hinweise auf freien Speicher und Suchpositionen enthalten kann.

Trotz des Namens werden nicht alle 32 Bits eines FAT32-Eintrags als Clusteradresse verwendet. Außerdem bleibt die klassische maximale Dateigröße von knapp 4 GiB ein wesentliches praktisches Limit. Genau deshalb ist FAT32 bis heute sehr kompatibel für kleinere Wechselmedien, aber für große einzelne Images, Videos oder Archivcontainer ungeeignet.

VFAT und lange Dateinamen

Das klassische DOS-Verzeichnisformat arbeitet mit 8.3-Namen. Windows 95 führte lange Dateinamen über zusätzliche Verzeichniseinträge ein, die mit dem traditionellen Eintrag kombiniert werden. Dadurch konnten alte Systeme den kurzen Alias weiterhin sehen, während VFAT-fähige Systeme den langen Unicode-Namen zusammensetzten.

Diese Konstruktion erklärt ungewöhnliche Recovery-Situationen: Ein beschädigter Satz langer Namenseinträge kann dazu führen, dass nur der 8.3-Name erhalten bleibt, obwohl die Datei selbst vollständig ist. Bei Rohanalysen sollten lange Namenseinträge deshalb nicht als unabhängige Dateien fehlinterpretiert werden.

Typische FAT-Fehlerbilder

FAT-Dateisysteme können durch verlorene Clusterketten, Cross-Links, beschädigte Verzeichniseinträge, inkonsistente FAT-Kopien oder einen falschen Bootsektor auffallen. Ein harter Abbruch während eines Schreibvorgangs kann Metadaten und Daten in unterschiedlichen Zuständen hinterlassen, weil kein allgemeines Journal die gesamte Operation als Transaktion beschreibt.

Automatische Reparaturprogramme versuchen, Konsistenz wiederherzustellen. Das ist nützlich für Betriebsfähigkeit, aber nicht immer optimal für Beweiserhalt oder maximale Datenrettung. Eine Reparatur kann verwaiste Clusterketten neuen Dateinamen zuordnen, Verzeichniseinträge entfernen oder eine Struktur zugunsten einer anderen korrigieren. Deshalb sollte bei wichtigen Originalmedien zuerst ein unverändertes Image existieren.

exFAT: FAT-Idee für große Wechselmedien weiterentwickelt

exFAT wurde für große Dateien und große Wechselmedien entwickelt, ohne die komplette Komplexität eines Desktop-Dateisystems wie NTFS zu übernehmen. Microsofts veröffentlichte Spezifikation beschreibt 64-Bit-Dateigrößen, eine Allocation Bitmap, eine Up-case Table für Namensvergleiche, einen Cluster Heap und redundante Bootbereiche. Das Format kann sehr große Clustergrößen abbilden und bleibt strukturell leichter als NTFS.

Im Unterschied zu FAT32 entfällt die 4-GiB-Grenze für einzelne Dateien. Das macht exFAT für große Images, Video- und Austauschmedien attraktiv. Gleichzeitig fehlen klassische NTFS-Funktionen wie ACLs, Hardlinks, eingebaute Dateikompression oder ein Metadaten-Journal. exFAT ist deshalb kein „besseres NTFS“, sondern ein anderes Design mit anderem Einsatzprofil.

NTFS: Metadatenzentrierte Struktur statt zentraler Clusterkette

NTFS organisiert ein Volume um die Master File Table. Praktisch jede Datei und auch viele Dateisystemstrukturen werden durch MFT-Datensätze beschrieben. Dateiname, Sicherheit, Zeitinformationen und Datenzuordnung erscheinen als Attribute. Kleine Dateiinhalte können sogar resident im MFT-Datensatz liegen; größere Inhalte werden über nichtresidente Datenläufe beschrieben.

Diese Architektur ermöglicht Funktionen, die FAT nicht besitzt: Sicherheitsdeskriptoren und ACLs, Journaling, Sparse Files, Hardlinks, Reparse Points, Kompression, EFS-Verschlüsselung, Alternate Data Streams und weitere Metadaten. Gleichzeitig steigt die Komplexität einer Rohrekonstruktion deutlich. Ein NTFS-Volume ist nicht sinnvoll als „FAT mit größerer Tabelle“ zu verstehen.

MFT: Dateien über Datensätze und Attribute beschreiben

Jeder reguläre NTFS-Dateieintrag besitzt typischerweise einen MFT-Datensatz. Darin befinden sich Attribute wie Standardinformationen, Dateinamen, Sicherheitsreferenzen und Daten. Verzeichnisse nutzen zusätzliche Indexstrukturen. Sehr kleine Daten können direkt im Datensatz gespeichert werden; größere Dateien verweisen über Run-Listen auf Clusterbereiche des Volumes.

Die MFT selbst ist wiederum eine Datei mit fest definierter Rolle. NTFS hält außerdem eine Spiegelstruktur für zentrale MFT-Informationen vor. Diese Selbstbeschreibung macht das Dateisystem mächtig, aber auch rekursiv: Ein Defekt an der MFT betrifft nicht nur eine einzelne Datei, sondern kann die Interpretation vieler weiterer Objekte erschweren.

NTFS-Journaling: Konsistenz der Metadaten, nicht magische Datensicherheit

NTFS führt ein transaktionsorientiertes Log für Dateisystemmetadaten und nutzt Checkpoint-Informationen, um nach einem ungeplanten Abbruch einen konsistenten strukturellen Zustand wiederherzustellen. Das reduziert typische Schäden durch unterbrochene Metadatenänderungen erheblich.

Journaling bedeutet jedoch nicht, dass jede Nutzdatei automatisch in alter Fassung wiederhergestellt werden kann. Wenn eine Anwendung Daten überschreibt und der Strom ausfällt, schützt das Dateisystemjournal primär die strukturelle Konsistenz seiner Metadaten. Versionierung und Backup bleiben eigenständige Aufgaben.

NTFS-Rechte, ACLs und Eigentümer

NTFS kann Sicherheitsdeskriptoren mit Zugriffssteuerungslisten speichern. Dadurch lassen sich Rechte nicht nur für „Datei vorhanden oder nicht“ abbilden, sondern für Benutzer, Gruppen und unterschiedliche Operationen differenzieren. Vererbung ermöglicht, Regeln aus übergeordneten Verzeichnissen auf Unterobjekte zu übertragen.

Bei Archivkopien auf FAT32 oder exFAT gehen diese Informationen verloren, wenn sie nicht separat gesichert werden. Auch das Kopieren zwischen zwei NTFS-Volumes garantiert nicht automatisch, dass Sicherheitsinformationen in jeder Situation identisch bleiben; Werkzeug, Berechtigungen und Kopiermodus spielen eine Rolle. Für eine revisionssichere Archivdokumentation müssen Inhalt und Sicherheitsmetadaten getrennt betrachtet werden.

Alternate Data Streams, Sparse Files, Reparse Points und Kompression

NTFS-Dateien können mehrere benannte Datenströme besitzen. Der gewöhnliche Dateiinhalt ist nur der namenlose Standardstream. Alternate Data Streams sind im Explorer oft nicht sichtbar und können beim Kopieren auf andere Dateisysteme verloren gehen. Sparse Files reservieren logisch große Adressräume, ohne für nicht belegte Bereiche physisch Cluster zu speichern. Reparse Points bilden die Grundlage verschiedener Umleitungs- und Virtualisierungsfunktionen.

NTFS unterstützt außerdem transparente Dateikompression und EFS-Dateiverschlüsselung. Diese Eigenschaften zeigen, warum eine Dateigröße allein wenig über den physischen Platzbedarf oder die vollständige Semantik einer Datei aussagt. Archivwerkzeuge müssen wissen, ob sie nur den Standarddatenstrom oder das gesamte Dateisystemobjekt erhalten sollen.

Amiga OFS und FFS: eigene Dateisystemwelt statt PC-Schema

AmigaDOS verwendete mit OFS und später FFS eine eigene Dateisystemfamilie. Die Strukturen unterscheiden sich grundlegend von FAT. Blöcke enthalten typisierte Verwaltungsinformationen, Header, Verzeichnisverkettungen und Prüfsummen. FFS verbesserte vor allem den Umgang mit Dateidaten gegenüber dem ursprünglichen Old File System und reduzierte Verwaltungsaufwand im Datenpfad.

Für das SSLXY-Archiv ist wichtig, Amiga-Datenträger nicht durch PC-Begriffe zu vereinfachen. Ein Amiga-Volume besitzt andere Bootblöcke, Root-Strukturen, Blockverkettungen und Namensregeln. Die technische Vertiefung zur Betriebssystemseite steht in amiga-dos.htm; diese Querschnittsseite ordnet OFS/FFS vor allem gegenüber den anderen Speicherwelten ein.

Amiga-Blöcke, Header und Prüfsummen

Klassische Amiga-Dateisystemstrukturen arbeiten mit Blocktypen und Prüfsummen. Der Rootblock verweist auf zentrale Dateisysteminformationen; Verzeichnisse und Dateien besitzen Headerblöcke, die wiederum weitere Daten- oder Erweiterungsblöcke referenzieren können. Diese Struktur ist für Rohrettung anders zu lesen als eine FAT-Kette oder ein NTFS-MFT-Datensatz.

Ein defekter Block kann deshalb unterschiedliche Auswirkungen haben: Ein Dateikopf kann fehlen, während Datenblöcke noch vorhanden sind; eine Verzeichnisverknüpfung kann beschädigt sein, ohne dass alle untergeordneten Inhalte überschrieben wurden. Auch hier gilt: logische Unerreichbarkeit ist nicht automatisch physischer Datenverlust.

Amiga-Validierung und historische Betriebsrealität

Klassische Amiga-Dateisysteme kennen Validierungszustände, in denen das System die Konsistenz des Volumes überprüft. Nach Abstürzen oder unsauberen Abbrüchen konnte ein Volume zeitweise als nicht vollständig validiert erscheinen. Für damalige Benutzer war das ein sichtbarer Hinweis darauf, dass Dateisystemkonsistenz aktiv wiederhergestellt werden musste.

Solche historischen Mechanismen gehören zum Verständnis alter Datenträger. Ein modernes Image kann den damaligen inkonsistenten Zustand vollständig konservieren. Das ist archivisch wertvoll, sollte aber getrennt von einer später erzeugten reparierten Arbeitskopie aufbewahrt werden.

ext2: Inodes, Blockgruppen und Unix-Metadaten

ext2 organisiert den Datenträger in Blockgruppen mit Superblockinformationen, Bitmaps und Inode-Tabellen. Dateien werden über Inodes beschrieben; Verzeichnisse ordnen Namen den Inode-Nummern zu. Rechte, Eigentümer, Zeitstempel und Linkzähler sind damit natürliche Bestandteile der Dateisystemstruktur.

Die Trennung zwischen Dateiname und Inode ist für Unix-Dateisysteme fundamental. Mehrere Hardlinks können auf denselben Inode zeigen. Wird ein Verzeichniseintrag entfernt, bedeutet das deshalb nicht zwangsläufig, dass der zugrunde liegende Inode sofort unreferenziert ist. Dieses Modell unterscheidet sich stark von der intuitiven Vorstellung „eine Datei = ein Verzeichniseintrag“ der einfachsten DOS-Welt.

ext3 und ext4: Journal, Extents und weiterentwickelte Metadaten

ext3 ergänzte die ext2-Welt um Journaling. ext4 entwickelte das Grundmodell weiter und verwendet unter anderem Extents, größere Adressräume, flexiblere Blockgruppenstrukturen und Metadatenprüfsummen. Die Linux-Kerneldokumentation beschreibt ext4 weiterhin als Blockgruppen-Dateisystem mit Superblock, Block- und Inode-Bitmaps, Inode-Tabellen, Journal und dynamischen Strukturen.

Extents beschreiben zusammenhängende Blockbereiche effizienter als lange Listen einzelner Blockadressen. Das ist besonders bei großen Dateien und großen Volumes wichtig. Auch hier gilt: Journal und Checksummen erhöhen Robustheit, ersetzen aber kein versioniertes Backup und keine unabhängige Integritätsprüfung der Nutzdaten.

Groß-/Kleinschreibung, Hardlinks und Symlinks

Dateinamenregeln unterscheiden sich erheblich. FAT und exFAT sind typischerweise nicht case-sensitive, bewahren aber die Schreibweise. NTFS kann Groß-/Kleinschreibung in bestimmten Kontexten differenzierter behandeln. Unix-Dateisysteme wie ext4 unterscheiden Namen standardmäßig nach Groß- und Kleinschreibung. Eine Migration kann daher Dateinamenskollisionen erzeugen, die auf dem Ursprungsdateisystem nicht existierten.

Hardlinks verweisen auf dasselbe Dateisystemobjekt; symbolische Links enthalten dagegen einen Pfadverweis. Werden solche Strukturen in ein Dateisystem kopiert, das sie nicht darstellen kann, muss ein Werkzeug entscheiden, ob es Links auflöst, als normale Dateien dupliziert oder Metadaten separat speichert. Genau deshalb ist „alle Dateien kopiert“ nicht automatisch gleichbedeutend mit „Dateisystemstruktur erhalten“.

ISO 9660: optische Austauschbarkeit mit engen historischen Regeln

ISO 9660 entstand für CD-ROM-Medien und legt eine stark standardisierte Verzeichnis- und Dateidarstellung fest. Die frühen Konformitätsstufen waren bei Namen, Verzeichnistiefe und Zeichensatz deutlich restriktiver als moderne Desktop-Dateisysteme. Erweiterungen wurden deshalb schnell wichtig, um längere Namen und reichere Metadaten abzubilden.

Für Archivimages optischer Medien ist das Dateisystem nur ein Teil der Information. Eine CD kann mehrere Sessions, Audio-Tracks, Daten-Tracks oder besondere Layouts enthalten. Ein gewöhnliches ISO-Image bildet nicht zwangsläufig jede dieser Eigenschaften vollständig ab. Das passende Imageformat hängt vom Medientyp und Archivziel ab.

Joliet und Rock Ridge: mehr Namen und Metadaten auf CD-ROM

Joliet erweitert ISO 9660 insbesondere um lange Unicode-Dateinamen für die Windows-Welt. Rock Ridge nutzt System-Use-Bereiche, um Unix-artige Dateieigenschaften wie längere Namen, symbolische Links und POSIX-Metadaten abzubilden. Ein Medium kann mehrere dieser Sichtweisen gleichzeitig bereitstellen.

Dadurch kann dieselbe CD je nach Betriebssystem unterschiedlich erscheinen, ohne dass verschiedene Nutzdaten gespeichert sein müssen. Bei Archivierung sollte deshalb dokumentiert werden, welche Namens- und Metadatenansicht geprüft wurde und ob mehrere Verzeichnisrepräsentationen vorhanden sind.

UDF: optische Medien und paketorientiertes Schreiben

UDF wurde für optische Datenträger und später weitere Wechselmedien entwickelt. Gegenüber klassischem ISO 9660 bietet es modernere Dateinamen, größere Dateien und Strukturen, die auch wiederbeschreibbare Medien besser unterstützen. DVD- und Blu-ray-Umgebungen verwenden UDF in verschiedenen Profilen und Kombinationen.

Microsoft führt UDF neben NTFS, exFAT und FAT32 als eines der zentral unterstützten Windows-Dateisysteme. Für Archivpraxis ist wichtig, nicht von der Dateiendung eines Images auf das tatsächliche On-Disk-Dateisystem zu schließen. Ein optisches Abbild kann UDF, ISO-9660-Strukturen oder Mischformen enthalten.

Disketten: Magnetisierung, Mechanik und Formatgeometrie

Disketten verbinden magnetische Speicherung mit präziser Mechanik. Spur, Sektor, Drehzahl, Kopfpositionierung, Indexsignal und Datenkodierung bilden ein Gesamtsystem. 5,25-Zoll- und 3,5-Zoll-Medien unterscheiden sich nicht nur äußerlich, sondern auch in Dichte, Laufwerksmechanik und typischen Formaten.

Ein scheinbar „leeres“ oder „unlesbares“ Medium kann deshalb verschiedene Ursachen haben: falsches Laufwerk, falsche Dichte, ungeeignete Geometrie, verschmutzte Mechanik, magnetische Alterung oder ein nicht zum Betriebssystem passendes Dateisystem. Vor Schreibversuchen sollte das Format bestimmt und ein Rohabbild erzeugt werden, sofern das Medium noch ausreichend stabil lesbar ist.

720 KiB, 1,44 MiB und proprietäre Geometrien

PC-Diskettenformate wie 720 KiB und 1,44 MiB sind nur ein Ausschnitt der historischen Vielfalt. Heimcomputer und Workstations verwendeten andere Sektorzahlen, Kodierungen, Interleaves und Dateisysteme. Selbst gleiche physische Medien konnten mit völlig unterschiedlichen logischen Formaten beschrieben sein.

Daraus folgt eine wichtige Archivregel: Ein Dateisystemtreiber kann nur interpretieren, was die darunterliegende Floppy-Hardware und das Imaging-Werkzeug korrekt erfassen. Bei ungewöhnlichen Formaten sind fluxbasierte Abbildungen oder spezialisierte Controller oft aussagekräftiger als ein reines Sektorimage, weil sie mehr Information über das ursprüngliche Magnetsignal erhalten.

Festplatten: Platter, Köpfe, Servo und interne Fehlerkorrektur

Eine Festplatte speichert Daten magnetisch auf rotierenden Scheiben. Schreib-/Leseköpfe schweben im Betrieb in extrem geringem Abstand über der Oberfläche. Servo-Informationen positionieren die Köpfe, während interne Fehlerkorrektur und Defektmanagement für den Host weitgehend unsichtbar arbeiten. Moderne Laufwerke verbergen ihre reale physische Geometrie vollständig hinter LBA.

Geräusche, wiederholte Anlaufversuche, starke Lesefehler oder plötzlich verschwindende Laufwerke sind Hinweise, bei denen weitere Belastung problematisch sein kann. Ein mechanisch auffälliges Laufwerk sollte nicht durch Defragmentierung, Dateisystemprüfung oder wiederholtes Vollscannen „getestet“ werden. Bei wichtigen Daten ist ein schonendes, fehlertolerantes Image auf ein separates Ziel die technisch sinnvollere Grundlage.

IDE/PATA und ATA: Controllerlogik wandert ins Laufwerk

IDE – später präziser als Parallel ATA eingeordnet – verlagerte wesentliche Controllerfunktionen in das Laufwerk. Host und Gerät kommunizieren über definierte Register- und Befehlsmodelle. Master/Slave-Konfigurationen, Kabeltypen, PIO- und DMA-Modi sowie BIOS-Grenzen prägten den PC-Alltag über viele Jahre.

Für Datenträgerarchivierung ist ATA das Transport- und Kommandoprotokoll, nicht das Dateisystem. Dieselbe IDE-Platte kann FAT, NTFS, ext2, Amiga-Dateisysteme oder völlig proprietäre Strukturen enthalten. Adapter von PATA auf USB ändern nichts am gespeicherten Dateisystem, können aber beeinflussen, welche Gerätefunktionen und Fehlerzustände dem Host sichtbar bleiben.

SCSI: Bus, Geräteklassen und mehr als nur Festplatten

SCSI beschreibt eine umfassende Kommandowelt für Massenspeicher und andere Geräte. Historisch verbanden parallele SCSI-Busse Festplatten, Streamer, CD-ROM-Laufwerke, Scanner und weitere Geräte. IDs, Terminierung, Busbreite und Kabelqualität waren praktische Bestandteile des Aufbaus.

Das grundlegende SCSI-Kommandokonzept lebt in modernen Transporten weiter. USB Mass Storage kann SCSI-Befehle kapseln; SAS gehört zur SCSI-Familie; auch andere Speicherstacks nutzen ähnliche Semantik. Das zeigt erneut, dass Steckverbinder, Transportprotokoll und Dateisystem getrennte Ebenen sind.

Im SSLXY-Archiv ergänzen interfaces.htm und schnittstellen-und-kabel.htm die physische und elektrische Schnittstellenperspektive.

SATA: serielle Verbindung, AHCI und der Übergang vom Parallelbus

Serial ATA ersetzte den breiten Parallel-ATA-Kabelbaum durch serielle Punkt-zu-Punkt-Verbindungen. Neben der elektrischen Schnittstelle änderte sich auch die Systemintegration. AHCI standardisierte eine Host-Controller-Schnittstelle mit Funktionen wie Native Command Queuing und Hot-Plug-Unterstützung, sofern Plattform und Betriebssystem diese Möglichkeiten nutzen.

SATA ist jedoch kein SSD-Protokoll im engeren Sinn. Sowohl magnetische Festplatten als auch Flash-SSDs können SATA verwenden. Eine SATA-SSD bleibt durch das ATA/AHCI-Modell und die SATA-Schnittstelle geprägt, während eine NVMe-SSD einen anderen Software- und Kommandopfad nutzt.

USB-Massenspeicher: bequem, aber eine zusätzliche Übersetzungsschicht

USB-Gehäuse, Kartenleser und Adapter machen verschiedenste Medien einfach anschließbar. Technisch sitzt dabei jedoch ein Bridge-Controller zwischen Host und eigentlichem Laufwerk. Je nach Gerät werden SCSI-Kommandos über Bulk-Only Transport oder UAS übertragen und anschließend auf SATA, NVMe, Flash oder proprietäre Medienlogik umgesetzt.

Diese Brücke kann Informationen verbergen. SMART-Daten, Geräteseriennummern, native Sektorgrößen, TRIM/UNMAP oder besondere Fehlercodes werden nicht von jedem Adapter gleich weitergereicht. Für normale Dateikopien ist das oft unerheblich; bei Diagnose und Imaging kann der konkrete Adapter jedoch den sichtbaren Gerätecharakter verändern.

SyQuest: Wechselplatten zwischen Diskette und Festplatte

SyQuest-Wechselplatten kombinierten austauschbare Cartridges mit festplattenähnlicher Technik und waren in einer Zeit attraktiv, in der Disketten zu klein und Netzwerke noch nicht selbstverständlich waren. Kapazität, Geschwindigkeit und direkte Dateisystemnutzung machten sie für Grafik-, Backup- und Datentransportaufgaben interessant.

Im SSLXY-Archiv besitzt dieses Thema mit syquest.htm eine eigene Vertiefungsseite. Für die Querschnittsbetrachtung ist SyQuest besonders lehrreich, weil Medium, Laufwerk, SCSI-/IDE-Anbindung, Partitionierung und Dateisystem klar getrennte Fehlerquellen darstellen. Eine Cartridge kann mechanisch lesbar sein, aber logisch beschädigt; ein Laufwerk kann korrekt erkannt werden, aber das Medium nicht sauber einziehen oder kalibrieren.

Zip, Jaz, magneto-optische Medien und andere Wechselwelten

Neben SyQuest existierten zahlreiche Wechselmedien mit sehr unterschiedlichen technischen Ansätzen. Iomega Zip und Jaz setzten auf magnetische Scheiben in Cartridges; magneto-optische Laufwerke kombinierten Lasererwärmung mit magnetischer Schreibtechnik; weitere Systeme nutzten proprietäre Mechaniken und Kapazitätsstufen.

Archivisch ist nicht nur das Medium entscheidend, sondern die Abhängigkeit von funktionierenden Laufwerken, Treibern, Kabeln und Hostadaptern. Ein gut erhaltenes Medium ist wertlos, wenn kein passender Lesepfad mehr vorhanden ist. Deshalb gehört zur Langzeitstrategie auch die rechtzeitige Migration, solange funktionierende Hardware und Software noch verfügbar sind.

CD-ROM, CD-R und CD-RW

CD-ROM speichert gepresste Strukturen, während CD-R organische beziehungsweise anorganische Aufzeichnungsschichten irreversibel verändert und CD-RW wiederbeschreibbare Phasenwechselmaterialien nutzt. Das optische Medium sieht äußerlich ähnlich aus, besitzt aber je nach Typ ein anderes Alterungs- und Schreibverhalten.

Daten-CDs können ISO 9660, Joliet, Rock Ridge oder UDF enthalten; Audio-CDs folgen dagegen keiner normalen Dateisystemstruktur. Ein Betriebssystem kann Audio-Tracks als scheinbare Dateien präsentieren, obwohl diese Darstellung nur eine Benutzeroberflächenabstraktion ist. Für eine vollständige Archivierung muss daher zuerst der tatsächliche Disc-Typ bestimmt werden.

DVD und Blu-ray: mehr Kapazität, mehr Schichten, weiterhin optische Abhängigkeiten

DVD und Blu-ray erhöhen die Datendichte und verwenden andere Laserwellenlängen sowie Medienstrukturen. Mehrschichtige Varianten, beschreibbare und wiederbeschreibbare Formate sowie unterschiedliche UDF-Profile erweitern die Vielfalt. Die größere Kapazität löst aber nicht das Grundproblem optischer Archive: Lesbarkeit hängt langfristig von Medienqualität, Lagerung und funktionsfähigen Laufwerken ab.

Ein optisches Medium sollte deshalb nicht als „ewiges Backup“ betrachtet werden. Regelmäßige Lesetests, Prüfsummen und Migration auf neue Speicherträger sind belastbarer als Vertrauen auf eine theoretische Medienlebensdauer.

Flash-Speicher: Seiten löschen, Blöcke schreiben, Mapping verstecken

NAND-Flash kann Daten nicht wie magnetische Medien beliebig an jeder Stelle überschreiben. Lesen, Programmieren und Löschen arbeiten mit unterschiedlichen Granularitäten; Löschvorgänge erfolgen blockweise, während Seiten programmiert werden. Controller müssen deshalb Daten umorganisieren, freie Blöcke verwalten und Verschleiß verteilen.

Der Host sieht diese Komplexität normalerweise nicht. SSDs, USB-Sticks und Speicherkarten präsentieren logische Blockadressen, während der interne Flash Translation Layer diese Adressen auf wechselnde physische NAND-Seiten abbildet. Dadurch ist die Beziehung zwischen LBA und physischem Speicher nicht dauerhaft stabil.

SD-, SDHC- und SDXC-Karten

Speicherkarten integrieren NAND-Flash und Controller in einem kleinen Gehäuse. Kapazitätsklassen, Busmodi, Geschwindigkeitsklassen und Dateisystemkonventionen entwickelten sich über Jahre weiter. SDXC wird typischerweise mit exFAT verbunden, während kleinere Karten historisch häufig FAT-Varianten verwenden.

Die sichtbare Geschwindigkeitsangabe sagt wenig über Langzeitrobustheit oder Verhalten bei Stromverlust aus. Controllerqualität, Flash-Typ, Firmware und Schreibmuster beeinflussen die Zuverlässigkeit. Für wichtige Originalaufnahmen oder historische Bestände ist eine Speicherkarte deshalb Transportmedium, nicht alleinige Archivkopie.

USB-Sticks: extrem praktisch, technisch sehr unterschiedlich

USB-Sticks reichen von hochwertigen Controllern mit guter Fehlerkorrektur bis zu minimalen Designs mit wenig Reserve. Nach außen sehen sie ähnlich aus, intern können NAND-Typ, Wear-Leveling, Over-Provisioning und Firmwarequalität stark variieren. Ein Stick, der jahrelang problemlos Dateien transportiert, ist dadurch noch kein belastbares Langzeitarchiv.

Bei auffälligem Verhalten – Schreibschutz, Kapazitätssprünge, verschwindende Dateien, extrem langsame Zugriffe – sollte nicht weiter auf das Original geschrieben werden. Ein Image und Prüfsummen sind die bessere Diagnosebasis. Besonders bei Flash kann jede weitere interne Garbage-Collection oder Remapping-Aktivität den Zustand verändern.

SSDs: NAND, Controller, DRAM und Firmware als Gesamtsystem

Eine SSD ist kein „schneller Datenträger ohne Mechanik“, sondern ein komplexes Speichersystem. NAND-Flash, Controller, Fehlerkorrektur, Mappingtabellen, Wear-Leveling, Garbage Collection, Over-Provisioning und gegebenenfalls DRAM-Cache arbeiten zusammen. Der Host sieht davon meist nur logische Blöcke und standardisierte Befehle.

Diese Abstraktion verbessert Alltagstauglichkeit, erschwert aber klassische Datenrettungsannahmen. Ein gelöschter logischer Block kann nach TRIM freigegeben und intern später gelöscht oder neu zugeordnet werden. Ein physischer NAND-Chip enthält ohne Controllerwissen nicht ohne Weiteres eine linear lesbare Kopie des ursprünglichen LBA-Raums.

Wear-Leveling und Garbage Collection

Flash-Zellen besitzen begrenzte Programm-/Löschzyklen. Wear-Leveling verteilt Schreiblast deshalb über viele physische Blöcke. Garbage Collection konsolidiert gültige Seiten und schafft freie Löschblöcke. Beide Vorgänge können Daten intern verschieben, ohne dass sich ihre logische Adresse aus Sicht des Betriebssystems ändert.

Für Archivpraxis bedeutet das: Ein sektorweises Image ist die logische Sicht des Geräts, nicht eine physische Momentaufnahme jeder NAND-Zelle. Für normale Sicherung und Migration ist genau diese logische Sicht richtig. Chip-off-Forensik ist dagegen eine Spezialdisziplin und liegt außerhalb einer normalen Archiv- oder Reparaturroutine.

TRIM und UNMAP: freie logische Bereiche dem Speicher melden

Bei Flash-Speichern weiß der Controller zunächst nicht automatisch, welche vom Dateisystem freigegebenen LBAs künftig nicht mehr benötigt werden. TRIM beziehungsweise entsprechende Deallocate-/UNMAP-Mechanismen geben diese Information weiter. Dadurch kann der Speicher freie Bereiche effizienter für Garbage Collection und zukünftige Schreibvorgänge vorbereiten.

Für Datenrettung verändert das die Lage gelöschter Dateien grundlegend. Auf einer klassischen Festplatte können freigegebene Sektoren bis zur Überschreibung unverändert lesbar bleiben. Bei einer SSD kann TRIM dazu führen, dass die logischen Bereiche bereits kurze Zeit später nicht mehr die alten Daten liefern. Deshalb ist die Annahme „gelöscht, aber sicher noch da“ auf SSDs besonders unzuverlässig.

NVMe: Protokoll für nichtflüchtigen Speicher, kein Dateisystem

NVM Express definiert ein Host-/Controller-Protokoll für nichtflüchtige Speichersubsysteme. NVMe ist für parallele Queues und moderne Speicherlatenzen ausgelegt und wird häufig über PCI Express transportiert. Die aktuelle NVM-Express-Spezifikationsfamilie führt 2026 die Base Specification 2.3 als ratifizierte Basis.

NVMe sagt nichts darüber aus, ob auf dem Gerät NTFS, ext4, exFAT oder überhaupt ein Dateisystem liegt. Ebenso ist M.2 nur ein Formfaktor beziehungsweise Steckkartenstandard und kann verschiedene elektrische Schnittstellen tragen. Die verbreitete Gleichsetzung „M.2 = NVMe = SSD-Dateisystem“ vermischt drei völlig unterschiedliche Ebenen.

SMART und Gesundheitswerte: Hinweise statt Orakel

Self-Monitoring, Analysis and Reporting Technology stellt Laufwerksattribute und Statusinformationen bereit. Bei Festplatten können unter anderem wiederzugewiesene Sektoren, schwebende Sektoren oder Fehlerzähler relevant sein; SSDs melden andere verschleiß- und medienbezogene Größen. Hersteller definieren Rohwerte und Schwellen jedoch nicht vollkommen einheitlich.

Ein „PASSED“-Status beweist daher nicht, dass ein Laufwerk fehlerfrei ist, und ein einzelner hoher Rohwert ist ohne Herstellerspezifikation nicht automatisch kritisch. SMART ist ein Diagnosebaustein. Entscheidend bleiben beobachtbare Lesefehler, Zeitüberschreitungen, Gerätestabilität, Protokollmeldungen und das Verhalten beim Imaging.

Defekte Sektoren, Remapping und schwebende Bereiche

Moderne Laufwerke besitzen Reservestrukturen und können problematische physische Bereiche intern neu zuordnen. Bei Festplatten kann ein Sektor zunächst schwer lesbar sein und erst bei späterem Schreibvorgang remapped werden. Bei SSDs sind Bad-Block-Management und Fehlerkorrektur noch stärker Bestandteil der Controllerlogik.

Für Datenrettung ist deshalb entscheidend, ob ein LBA noch lesbar ist, nicht nur ob der Controller bereits einen Defektzähler erhöht hat. Wiederholtes Lesen derselben schwachen Stelle kann auf mechanischen Medien zusätzliche Belastung erzeugen. Gute Imaging-Strategien lesen zunächst die leicht erreichbaren Bereiche und behandeln Problemzonen später gezielt.

Caches und Stromausfall: bestätigt ist nicht immer dauerhaft gespeichert

Controller und Betriebssysteme puffern Schreibvorgänge, um Leistung zu erhöhen. Ein Schreibbefehl kann daher auf mehreren Ebenen zwischengespeichert sein, bevor die Daten tatsächlich dauerhaft im Medium liegen. Flush- und Barrieremechanismen sollen sicherstellen, dass kritische Reihenfolgen eingehalten werden.

Bei plötzlichem Stromverlust können deshalb nicht nur Dateiinhalte, sondern auch Metadaten betroffen sein. Journaling-Dateisysteme reduzieren strukturelle Risiken, Flash-Controller können zusätzliche Schutzmechanismen besitzen, und professionelle Geräte nutzen teils Power-Loss-Protection. Dennoch bleibt ein unerwarteter Energieverlust ein realer Fehlerfall, insbesondere während umfangreicher Metadaten- oder Mappingänderungen.

RAID: Verfügbarkeit und Performance, aber kein Backup

RAID kann Daten über mehrere Laufwerke spiegeln, verteilen oder mit Parität absichern. Das erhöht je nach Level Verfügbarkeit, Leistung oder Fehlertoleranz gegenüber einzelnen Laufwerksausfällen. Es schützt jedoch nicht gegen versehentliches Löschen, Dateisystemkorruption, Malware, Fehlkonfiguration, Brand, Diebstahl oder eine fehlerhafte Anwendung, die gültige Daten überschreibt.

Ein RAID repliziert auch Fehler sehr zuverlässig. Wird eine Datei gelöscht, verschwindet sie auf allen gespiegelten Mitgliedern. Wird ein Dateisystem logisch beschädigt, bleibt die Beschädigung Teil des Arrays. Deshalb ist „RAID ist kein Backup“ keine Floskel, sondern eine direkte Konsequenz der Schichtenarchitektur.

Backupmodelle: Voll, inkrementell, differentiell und versioniert

Ein Vollbackup enthält den definierten Datenbestand vollständig. Inkrementelle Sicherungen speichern Änderungen seit der letzten Sicherung, differentielle Sicherungen Änderungen seit dem letzten Vollbackup. Moderne versionierte Systeme können diese Konzepte intern anders umsetzen, entscheidend bleibt aber die Fähigkeit, einen gewünschten historischen Zustand zuverlässig wiederherzustellen.

Für das SSLXY-Archiv ergänzen datensicherung-und-backups.htm und backups.htm die organisatorische und praktische Sicherungsperspektive. Diese Seite konzentriert sich auf die Speicher- und Dateisystemseite: Was muss erhalten werden, damit ein Backup später technisch vollständig interpretierbar bleibt?

Datenträgerabbilder: sektorgetreu statt nur dateibasiert

Ein Dateibackup speichert ausgewählte Dateien und Verzeichnisse. Ein Datenträgerimage bildet dagegen logische Blöcke eines ganzen Geräts oder Volumes ab. Dadurch bleiben Partitionstabellen, Bootsektoren, Dateisystemmetadaten, unzugeordneter Raum und gelöschte Strukturen erhalten. Für historische Medien ist das oft die reichere Archivform.

Ein Image sollte von Metadaten begleitet werden: Quellgerät, Kapazität, logische Sektorgröße, Anschlussweg, verwendetes Werkzeug, Datum, Lesefehler, Hashwerte und gegebenenfalls Besonderheiten wie HPA/DCO oder ungewöhnliche Geometrie. Ohne diese Informationen bleibt zwar eine Bytefolge, aber ein Teil des technischen Kontextes geht verloren.

Originalmedien möglichst schreibgeschützt behandeln

Bei unbekannten oder historischen Datenträgern ist jede Schreiboperation ein Risiko. Betriebssysteme können beim Einhängen Journale aktualisieren, „dirty“-Flags ändern, Zeitstempel schreiben oder automatische Reparaturen starten. Deshalb ist ein schreibgeschützter beziehungsweise read-only Zugriff für die erste Analyse vorzuziehen.

Hardware-Schreibblocker sind in professionellen Forensikumgebungen üblich; im privaten Archivkontext können je nach Medium auch physische Schreibschutzmechanismen, read-only Mounts oder kontrollierte Imaging-Umgebungen helfen. Entscheidend ist das Prinzip: Das Original bleibt Referenz, Änderungen finden an einer Arbeitskopie statt.

Prüfsummen: Integrität nachweisbar machen

Kryptographische Hashfunktionen wie SHA-256 erzeugen aus einer Datei oder einem Image einen kompakten Prüfwert, der sich bei jeder inhaltlichen Änderung mit überwältigender Wahrscheinlichkeit ändert. Dadurch lässt sich später prüfen, ob eine Archivkopie bytegleich zum dokumentierten Stand geblieben ist.

Ein Hash beweist jedoch nicht, dass die Quelle ursprünglich fehlerfrei war. Wird ein beschädigtes Image gehasht, ist lediglich dessen beschädigter Zustand eindeutig dokumentiert. Deshalb gehören Prüfsumme und Zustandsbeschreibung zusammen. Für mehrere Kopien sollte regelmäßig kontrolliert werden, ob alle Hashwerte weiterhin dem Referenzstand entsprechen.

Gelöschte Dateien: Verzeichniseintrag, Freispeicher und tatsächliche Daten

Löschen bedeutet in vielen Dateisystemen zunächst, dass Metadaten angepasst und die zugehörigen Blöcke wieder als frei markiert werden. Der eigentliche Inhalt kann auf magnetischen Datenträgern bis zur Überschreibung noch vorhanden sein. Welche Metadaten erhalten bleiben, hängt vom Dateisystem ab.

Auf SSDs verändert TRIM diese Erwartung erheblich. Außerdem können Journale, Copy-on-Write-Strukturen oder Hintergrundprozesse weitere Kopien beziehungsweise neue Zustände erzeugen. Eine allgemeine Aussage „gelöscht ist leicht wiederherstellbar“ ist deshalb technisch falsch. Medium, Dateisystem, Löschvorgang und seitdem erfolgte Schreibaktivität bestimmen die Chancen.

File Carving: Nutzdaten ohne intakte Verzeichnisstruktur

File Carving sucht nach bekannten Dateisignaturen und internen Strukturen, wenn Dateisystemmetadaten fehlen oder unbrauchbar sind. Das kann bei zusammenhängenden Dateien gute Ergebnisse liefern, verliert aber häufig Dateinamen, ursprüngliche Pfade, Zeitstempel und andere Metadaten. Fragmentierte Dateien sind schwieriger, weil ihre Teile ohne Zuordnung nicht zuverlässig zusammengesetzt werden können.

Carving ist damit eine Rettungsebene unterhalb des Dateisystems, kein Ersatz für Dateisystemrekonstruktion. Wenn MFT, FAT, Inodes oder Verzeichnisstrukturen noch auswertbar sind, liefern sie wesentlich reichere Informationen als eine reine Signatursuche.

Schnellformatierung, vollständige Formatierung und Neuinitialisierung

„Formatieren“ kann sehr unterschiedliche Vorgänge bedeuten. Eine Schnellformatierung legt typischerweise neue Dateisystemmetadaten an, ohne jeden Datenblock mit Nutzdaten zu überschreiben. Vollständige Formatierung kann zusätzliche Prüf- oder Schreibvorgänge durchführen. Herstellerwerkzeuge und Secure-Erase-Funktionen wiederum arbeiten auf einer ganz anderen Ebene.

Deshalb ist nach einer versehentlichen Formatierung entscheidend, was tatsächlich ausgeführt wurde und auf welchem Medium. Auf einer Festplatte kann eine Schnellformatierung viele alte Datenbereiche physisch unangetastet lassen; auf einer SSD können Dateisystemneuaufbau und TRIM dazu führen, dass freigegebene LBAs intern rasch verworfen werden.

Fehlerhafte Medien klonen: erst retten, dann analysieren

Bei instabilen Datenträgern sollte die Diagnose möglichst an einer Kopie stattfinden. Fehlertolerante Imaging-Werkzeuge können lesbare Bereiche zuerst sichern, Problemzonen überspringen und später gezielt erneut versuchen. Das reduziert die Zahl unnötiger Wiederholungszugriffe auf bereits auffällige Stellen.

Das Zielmedium muss mindestens ausreichend groß sein und darf nicht mit der Quelle verwechselt werden. Schreibfehler auf das falsche Gerät sind eine der banalsten und gleichzeitig zerstörerischsten Gefahren bei manueller Recovery-Arbeit. Eindeutige Geräteidentifikation, Seriennummern und dokumentierte Befehle sind daher wichtiger als Geschwindigkeit.

CHKDSK, fsck und Reparaturwerkzeuge: Konsistenz vor Historientreue

Dateisystemprüfprogramme sind für die Wiederherstellung eines benutzbaren konsistenten Zustands konzipiert. Sie vergleichen Metadaten, korrigieren Zähler, entfernen unzulässige Referenzen, verbinden verwaiste Strukturen oder markieren fehlerhafte Bereiche. Für den normalen Betrieb ist das oft genau richtig.

Archivisch kann eine solche Reparatur aber Spuren des ursprünglichen Defekts verändern. Deshalb sollte der unreparierte Image-Stand erhalten bleiben. Eine reparierte Kopie kann anschließend als zweite Fassung dokumentiert werden. So bleiben sowohl der historische Zustand als auch die praktisch nutzbare Rekonstruktion nachvollziehbar.

Partitionen rekonstruieren ohne Dateidaten vorschnell anzutasten

Wenn MBR oder GPT beschädigt sind, können Dateisystemsignaturen und bekannte Startstrukturen helfen, frühere Partitionsgrenzen zu erkennen. Wichtig ist, gefundene Start- und Endpositionen zunächst nur zu dokumentieren und in einem Image zu prüfen. Ein vorschnell neu geschriebener Partitionseintrag kann weitere Informationen überschreiben oder eine falsche Geometrie festschreiben.

Bei GPT bieten primäre und Backup-Strukturen zusätzliche Vergleichsmöglichkeiten. Stimmen Header, Eintragsarrays und CRC-Werte nicht überein, kann eine Kopie noch konsistent sein. Auch hier ist Redundanz aber nur eine Strukturhilfe, kein Ersatz für externe Sicherungen.

Verschlüsselung: Dateisystem, Container und Gerät unterscheiden

Verschlüsselung kann auf Dateiebene, Volumeebene oder im Speichergerät selbst stattfinden. EFS verschlüsselt ausgewählte NTFS-Dateien, BitLocker arbeitet auf Volumeebene, andere Systeme verwenden Container oder vollständige Blockgeräteverschlüsselung. Selbstverschlüsselnde Laufwerke wiederum integrieren Kryptografie in den Controller.

Für Archive ist der Schlüsselbestand ebenso wichtig wie das verschlüsselte Image. Eine perfekte Bytekopie ist ohne die benötigten Schlüssel, Wiederherstellungsinformationen und Softwarekontexte möglicherweise dauerhaft unbrauchbar. Kryptographische Metadaten gehören deshalb in die Archivplanung, nicht erst in den Notfall.

Kompression: weniger physischer Platz, zusätzliche Abhängigkeiten

Kompression kann innerhalb des Dateisystems, in Archivformaten oder im Speicherstack stattfinden. NTFS-Kompression arbeitet transparent auf Dateiebene; komprimierte Archivcontainer bündeln mehrere Dateien; Images können blockweise komprimiert werden. Jede Variante verändert die Fehler- und Wiederherstellungseigenschaften.

Ein einzelner beschädigter Bereich kann in einem komprimierten Container unter Umständen mehr Nutzdaten betreffen als derselbe Defekt in einer unkomprimierten linearen Ablage. Andererseits können blockweise komprimierte Imageformate Prüfsummen und Sparse-Bereiche effizient verwalten. Entscheidend ist, das Format selbst langfristig dokumentiert und lesbar zu halten.

Sparse Files und logisch große Dateien

Sparse Files können logisch sehr groß sein, ohne für jeden Nullbereich physisch Speicher zu belegen. Virtuelle Festplatten, Datenbanken und wissenschaftliche Daten profitieren davon. Das Dateisystem merkt sich, welche Bereiche echte Daten tragen und welche beim Lesen als Nullen erscheinen.

Beim Kopieren auf ein Dateisystem ohne Sparse-Unterstützung kann eine solche Datei vollständig materialisiert werden und plötzlich erheblich mehr Platz benötigen. Ein Archivwerkzeug sollte daher unterscheiden, ob nur der logische Inhalt oder auch die Sparse-Eigenschaft erhalten bleiben soll.

Copy-on-Write, Reflinks und moderne Dateisystemideen

Moderne Dateisysteme und Storage-Stacks nutzen zunehmend Copy-on-Write-Mechanismen. Neue Daten oder Metadaten werden zunächst an anderer Stelle geschrieben; erst danach werden Referenzen umgeschaltet. Das erleichtert Snapshots und kann Konsistenz verbessern, erzeugt aber eine andere Fragmentierungs- und Recovery-Charakteristik als klassische In-place-Updates.

Reflinks erlauben mehreren Dateien, zunächst dieselben Datenblöcke zu teilen, bis eine Kopie verändert wird. Für Archive ist wichtig, dass eine logische Dateikopie dadurch nicht zwangsläufig sofort eine vollständige zweite physische Kopie darstellt. Verfügbarkeit innerhalb desselben Storage-Pools ist nicht dasselbe wie unabhängige Sicherung.

ReFS als moderne Windows-Ergänzung

Microsoft führt ReFS als separates modernes Dateisystem für bestimmte Windows- und Server-Szenarien. Der Entwurf legt besonderen Wert auf Skalierbarkeit und Integritätsfunktionen. ReFS ersetzt NTFS jedoch nicht allgemein in jeder Windows-Rolle und besitzt ein anderes Featureprofil.

Für die historische SSLXY-Linie bleibt NTFS das zentralere Windows-Dateisystem. ReFS ist hier deshalb bewusst als Entwicklungslinie eingeordnet, nicht als Hauptkapitel der PC-Geschichte. Die Existenz mehrerer moderner Dateisysteme zeigt erneut, dass „Windows-Laufwerk“ keine eindeutige On-Disk-Struktur bezeichnet.

ZFS und Btrfs: Integrität, Pools und Snapshots als andere Denkschule

ZFS und Btrfs verbinden Dateisystem- und Storage-Funktionen enger als klassische FAT-/NTFS-Modelle. Prüfsummen, Copy-on-Write, Snapshots und Poolkonzepte verändern die Art, wie Redundanz und Datenintegrität organisiert werden. Damit verschiebt sich die Grenze zwischen „Dateisystem“ und „Volume-Manager“.

Diese Systeme sind für das SSLXY-Archiv vor allem als Kontrast wichtig. Sie zeigen, dass moderne Speicherarchitektur nicht zwangsläufig aus einer festen Partition plus einem darauf liegenden Dateisystem bestehen muss. Für Migration und Recovery ist daher immer zuerst das konkrete Schichtenmodell des Quellsystems zu erfassen.

Bit Rot, stille Korruption und die Grenzen bloßer Kopien

Speichermedien können Daten nicht nur vollständig verlieren, sondern einzelne Bits oder Sektoren unbemerkt verändern. Hardware-ECC korrigiert viele Fehler intern; Dateisysteme mit Metadaten- oder Datenprüfsummen können weitere Inkonsistenzen erkennen. Ein einfaches Dateisystem ohne End-to-End-Prüfsummen bemerkt stille Nutzdatenänderungen jedoch nicht zwangsläufig.

Langzeitarchive sollten deshalb unabhängige kryptographische Prüfsummen führen und mehrere Kopien regelmäßig vergleichen. Eine Kopie, die zehn Jahre unberührt in einer Schublade liegt, ist kein überprüftes Archivzustand. Integrität entsteht durch wiederholte Verifikation, dokumentierte Migration und Redundanz.

Medienalterung: magnetisch, optisch und elektrisch unterschiedlich

Magnetische Medien verlieren durch Materialalterung, Beschädigung und mechanische Probleme an Zuverlässigkeit. Optische Medien können unter Delamination, Farbstoff- oder Reflexionsschichtalterung leiden. Flash-Speicher hält Ladungszustände nur begrenzt und ist von Temperatur, Zellverschleiß und Controllerfunktion abhängig.

Es gibt deshalb keine universelle Haltbarkeitszahl für „Datenträger“. Herstellerqualität, Schreibzustand, Lagerung, Nutzungsdauer und Lesegerät spielen zusammen. Eine realistische Archivstrategie verlässt sich nicht auf die Lebensdauer eines Mediums, sondern auf rechtzeitige Migration und verifizierte Mehrfachkopien.

Migration: rechtzeitig kopieren, bevor das Lesegerät zum Engpass wird

Historische Medien werden oft nicht zuerst durch Datenverlust problematisch, sondern durch fehlende Lesegeräte. SCSI-Hostadapter, proprietäre Wechselplattenlaufwerke, bestimmte Diskettencontroller oder optische Laufwerke verschwinden aus dem Alltag. Solange ein vollständiger Lesepfad existiert, ist Migration vergleichsweise einfach; später kann schon die Hardwarebeschaffung zum Hauptproblem werden.

Eine gute Migration bewahrt das Originalimage, erzeugt zusätzlich nutzbare Arbeitskopien und dokumentiert die Transformation. Wird beispielsweise ein altes FAT-Image auf moderne Speicherung kopiert, sollte nicht nur der extrahierte Dateibaum erhalten bleiben, sondern auch das originale Image samt Prüfsumme.

Archivformate: Rohimage, Container und extrahierter Dateibaum

Kein einzelnes Format erfüllt jedes Archivziel. Ein Rohimage ist transparent und leicht zu interpretieren, kann aber viel Platz benötigen und keine Metadaten über den Imaging-Vorgang enthalten. Containerformate können Kompression, Sparse-Bereiche, Prüfsummen oder mehrere Streams integrieren, erhöhen aber die Abhängigkeit von ihrer Spezifikation und Softwareunterstützung.

Praktisch ist häufig eine Kombination: originales oder möglichst verlustfreies Image, dokumentierte Hashwerte, extrahierter Dateibaum für schnellen Zugriff und eine Begleitdatei mit Geräte- und Lesekontext. So bleibt sowohl die historische Struktur als auch die heutige Nutzbarkeit erhalten.

Was zu einem Datenträger archivisch dokumentiert werden sollte

Eine belastbare Beschreibung umfasst mehr als Hersteller und Kapazität. Sinnvoll sind Gerätetyp, Modell, Seriennummer soweit relevant, Medium, Schnittstelle, Adapter, logische Sektorgröße, Partitionsschema, erkannte Dateisysteme, Imaging-Werkzeug, Datum, Lesefehler, Reparaturschritte und Prüfsummen. Bei Wechselmedien gehört auch die Zuordnung zum verwendeten Laufwerk dazu.

• Quelle: Medium, Laufwerk, Modell, Kapazität und sichtbare Beschriftung.
• Lesepfad: Controller, Adapter, Kabel, Betriebssystem und Treiber.
• Logische Struktur: LBA-Größe, Partitionen, Volumes und Dateisysteme.
• Imaging: Werkzeug, Optionen, Fehlerkarte und Zeitpunkt.
• Integrität: SHA-256 oder vergleichbare Hashwerte für Image und wichtige Derivate.
• Bearbeitung: jede Reparatur oder Konvertierung getrennt vom unveränderten Ausgangsstand dokumentieren.

Systematische Diagnose: von außen nach innen

Eine gute Speicherdiagnose beginnt bei der untersten fraglichen Ebene und arbeitet sich nach oben. Zuerst wird geklärt, ob das Gerät stabil erkannt wird, welche Kapazität und Sektorgröße es meldet und ob Lesefehler auftreten. Danach folgen Partitionstabelle, Volume-Start, Dateisystemsignaturen, Metadaten und schließlich einzelne Dateien.

Dieses Vorgehen verhindert, dass eine Dateisystemmeldung vorschnell als Hardwaredefekt interpretiert wird oder ein physisch sterbendes Laufwerk durch intensive logische Reparaturen zusätzlich belastet wird.

Typische Symptome und ihre wahrscheinlichen Ebenen

GB, GiB, TB und TiB: warum Kapazitätsangaben scheinbar schrumpfen

Datenträgerhersteller geben Kapazitäten traditionell dezimal an: ein Gigabyte entspricht dabei einer Milliarde Byte, ein Terabyte einer Billion Byte. Betriebssysteme und ältere Werkzeuge verwenden dagegen häufig binäre Größen auf Basis von 1024 und zeigen Werte in GiB oder TiB an, teilweise aber weiterhin mit der Beschriftung GB/TB. Dadurch wirkt ein frisch eingebautes Laufwerk kleiner, obwohl kein Speicher „fehlt“.

Zusätzlich reduzieren Partitionstabellen, Dateisystemmetadaten, Reservestrukturen, Over-Provisioning und Wiederherstellungspartitionen den als freie Nutzdatenfläche sichtbaren Bereich. Für technische Dokumentation sind deshalb Bytezahl und logische Sektorzahl eindeutiger als eine gerundete Kapazitätsanzeige.

Partitionsausrichtung: von Zylindergrenzen zu 1-MiB-Startpunkten

Historische Partitionierungswerkzeuge richteten Partitionen häufig an künstlichen Zylindergrenzen aus. Mit Advanced Format, SSDs und RAID-Stripes wurde eine andere Eigenschaft wichtiger: Dateisystemblöcke und Partitionen sollten sinnvoll zu den physischen beziehungsweise internen Zuordnungseinheiten des Storage passen. Moderne Werkzeuge verwenden deshalb typischerweise MiB-basierte Ausrichtungen.

Eine Fehlalignment-Situation kann bewirken, dass ein logischer 4-KiB-Schreibvorgang zwei physische 4-KiB-Sektoren oder mehrere interne Flash-Seiten betrifft. Das erzeugt Read-Modify-Write-Zyklen und zusätzliche Arbeit. Für alte Images ist eine historische, heute unübliche Ausrichtung jedoch kein Grund zur „Korrektur“ am Original; sie ist Teil des dokumentierten Datenträgerzustands.

EFI-Systempartition: FAT als Boot-Infrastruktur moderner UEFI-Systeme

UEFI-Systeme verwenden typischerweise eine EFI System Partition als standardisierten Ort für Bootloader und Firmware-zugängliche Dateien. Die ESP verwendet eine FAT-Variante und wird innerhalb einer GPT durch einen eigenen Partitionstyp gekennzeichnet. Firmware kann dadurch Bootdateien lesen, ohne das Betriebssystemdateisystem selbst verstehen zu müssen.

Die ESP ist kein Ersatz für die eigentliche Systempartition und sollte nicht mit dem Windows-Laufwerk oder einer Recovery-Partition verwechselt werden. Bei Images moderner Systemplatten gehört sie jedoch zur Bootfähigkeit des Gesamtaufbaus. Ein Backup nur des sichtbaren Systemlaufwerks kann daher weniger vollständig sein als ein Abbild des gesamten Datenträgers.

LVM, dynamische Datenträger und Storage Spaces: Volumes über Partitionen hinaus

Klassische Partitionierung verbindet einen zusammenhängenden Bereich eines Datenträgers direkt mit einem Dateisystem. Volume-Manager lösen diese starre Zuordnung. Linux LVM, Windows Dynamic Disks oder Storage Spaces können physische Bereiche zu Pools zusammenfassen und daraus logische Volumes bilden. Ein Dateisystem sieht dann einen virtuellen Blockraum, dessen physische Bestandteile an anderer Stelle verwaltet werden.

Für Recovery bedeutet das eine zusätzliche Schicht: Ein intaktes NTFS- oder ext4-Dateisystem kann ohne die darüber beziehungsweise darunter liegenden Volume-Metadaten nicht korrekt zusammengesetzt werden. Beim Imaging komplexer Storage-Pools reicht deshalb das Kopieren einer vermeintlichen „Datenpartition“ nicht immer aus.

Bandlaufwerke: sequenzieller Speicher statt Direktzugriff

Magnetband folgt einer anderen Zugriffsidee als Disketten, Festplatten oder SSDs. Daten liegen sequenziell auf dem Band; um einen späteren Bereich zu erreichen, muss das Medium positioniert werden. Dafür bieten Bandkassetten hohe Kapazitäten und sind für große Sicherungssätze und Offline-Aufbewahrung geeignet.

Historische Streamer verwendeten zahlreiche proprietäre oder generationsabhängige Formate. Moderne LTO-Generationen standardisieren Bandkassetten und Laufwerksklassen deutlich stärker, bleiben aber von Laufwerkskompatibilität, Reinigungszustand, Softwareformat und gegebenenfalls Verschlüsselung abhängig. Ein Band ohne dokumentierten Sicherungskatalog und passende Software kann technisch intakt und trotzdem schwer nutzbar sein.

Bandarchive: Medienrotation, Kataloge und Lesepfade

Ein Bandbackup ist mehr als eine Folge kopierter Dateien. Backupsoftware speichert häufig eigene Kataloge, Sets, Kompressions- oder Verschlüsselungsinformationen. Für Langzeitaufbewahrung müssen deshalb nicht nur die Bänder, sondern auch Informationen über Softwareversion, Laufwerkstyp, Sicherungsformat und Schlüssel erhalten bleiben.

Bänder eignen sich gut als räumlich getrennte Offline-Kopie, sind aber kein Grund, auf andere Sicherungsebenen zu verzichten. Eine belastbare Strategie kombiniert unterschiedliche Medien und hält mindestens eine regelmäßig verifizierte Kopie außerhalb des primären Systems vor.

HFS, HFS+ und APFS: Macintosh-Dateisysteme im Querschnitt

Die Macintosh-Welt entwickelte eigene Dateisystemmodelle. HFS und HFS+ arbeiteten mit Katalogstrukturen und unterstützten traditionelle Macintosh-Eigenschaften wie Resource Forks und Finder-Metadaten. Solche Informationen können beim simplen Kopieren auf FAT oder andere fremde Dateisysteme verloren gehen oder in Hilfsdateien ausgelagert werden.

APFS verfolgt eine modernere Architektur mit Copy-on-Write, Containern, Volumes, Snapshots und enger Integration in Flash-basierte Apple-Systeme. Für diese SSLXY-Seite dient APFS vor allem als Vergleich: Die Dateisystementwicklung führt von einfachen Allocation-Tabellen zu Systemen, die Volume-Management, Snapshots und Metadatenintegrität deutlich enger miteinander verbinden.

SMB und NFS: Dateien über das Netz sind keine lokalen On-Disk-Strukturen

SMB und NFS stellen Dateien über ein Netzwerk bereit. Ein Client sieht Verzeichnisse, Dateien und Attribute, ohne das tatsächliche Dateisystem des Servers direkt zu interpretieren. Hinter einer SMB-Freigabe kann NTFS, ReFS, ext4, ZFS oder ein Cluster-Dateisystem liegen; NFS kann ebenso verschiedenste lokale Speicherstrukturen exportieren.

Dadurch entstehen zusätzliche Semantikfragen: Dateisperren, Rechteabbildung, Groß-/Kleinschreibung, Zeitstempel, Links und Sonderattribute können zwischen Clientprotokoll und Serverdateisystem unterschiedlich umgesetzt werden. Ein Netzwerkbackup, das nur die sichtbare Clientansicht kopiert, muss nicht jede serverseitige Metadateninformation erhalten.

Object Storage: Schlüssel und Objekte statt Blockgerät und klassischem Dateisystem

Object Storage organisiert Daten nicht als lokales Blockgerät mit Partition und Dateisystem, sondern als Objekte mit Schlüsseln und Metadaten innerhalb eines Dienstes oder Storage-Systems. Anwendungen greifen über APIs auf diese Objekte zu. Die klassische Frage „welches Dateisystem liegt darauf?“ ist aus Clientperspektive deshalb oft nicht sinnvoll.

Cloud-Speicheroberflächen können trotzdem wie Ordner wirken. Diese Ordner sind häufig nur Namenspräfixe oder eine Dienstabstraktion. Für Archive muss daher dokumentiert werden, ob eine Kopie aus einer lokalen synchronisierten Dateisystemansicht oder aus dem eigentlichen Objektspeicher exportiert wurde, weil Metadaten und Versionen unterschiedlich erhalten bleiben können.

ECC und Prüfsummen auf mehreren Ebenen

Speicherintegrität wird an verschiedenen Stellen kontrolliert. Festplatten und SSDs besitzen interne Fehlerkorrektur für gespeicherte Sektoren beziehungsweise Flash-Seiten. Transportprotokolle verwenden eigene Integritätsmechanismen. GPT schützt Header und Partitionseinträge mit CRC32. Dateisysteme können Metadatenprüfsummen oder sogar Nutzdatenprüfsummen führen. Archive ergänzen unabhängige kryptographische Hashwerte.

Diese Ebenen ersetzen sich nicht. Ein Laufwerks-ECC kann einen Sektor korrekt ausliefern, dessen Nutzdatei bereits Jahre zuvor logisch falsch gespeichert wurde. Eine SHA-256-Prüfsumme erkennt dagegen jede spätere Änderung des archivierten Images, kann aber keinen Hardwarefehler korrigieren. Gute Speicherarchitektur nutzt mehrere unabhängige Kontrollpunkte.

„Sicher entfernen“: Caches und offene Metadaten vor dem Abziehen

Wechselmedien werden häufig als jederzeit abziehbar wahrgenommen. Betriebssystem und Dateisystem können jedoch noch Schreibdaten puffern, Verzeichniseinträge aktualisieren oder Journale abschließen. Ein physisches Entfernen während offener Schreibvorgänge kann deshalb zu beschädigten Dateien oder inkonsistenten Metadaten führen.

Das ordnungsgemäße Aushängen beziehungsweise „Sicher entfernen“ sorgt dafür, dass Dateisystem und Treiber den Datenträger freigeben und ausstehende Operationen abgeschlossen werden. Selbst bei Einstellungen mit reduziertem Schreibcache bleibt dieser Ablauf die technisch saubere Gewohnheit.

Signaturen, Magic Values und Byte-Reihenfolge

Dateisysteme und Partitionstabellen enthalten charakteristische Signaturen, Versionsfelder und Strukturwerte. Solche Marker helfen, unbekannte Images zu identifizieren und plausible Volume-Starts zu finden. Sie sind jedoch keine vollständige Validierung: Eine zufällige Bytefolge kann wie eine Signatur aussehen, und beschädigte Strukturen können trotz korrektem Magic Value unbrauchbar sein.

Zusätzlich muss die Byte-Reihenfolge beachtet werden. PC-nahe Formate speichern viele Mehrbytewerte little-endian, während andere Protokolle oder Dateisystemstrukturen abweichende Regeln verwenden. Rohdatenanalyse ohne Kenntnis der Endianness produziert scheinbar plausible, aber falsche Größen und Adressen.

Technischer Stand 2026

Die grundlegenden historischen Formate bleiben 2026 relevant, weil Archive, Firmware, Wechselmedien und bestehende Systeme weiterhin FAT, NTFS, ext- und Amiga-Dateisysteme enthalten. Gleichzeitig sind moderne Datenträger fast vollständig durch lineare LBA-Modelle abstrahiert. UEFI 2.11 beschreibt GPT mit primärem und Backup-Header, 64-Bit-LBAs, GUIDs und CRC32-geschützten Strukturinformationen als modernes Partitionsschema.

Microsoft veröffentlicht die exFAT-On-Disk-Spezifikation offen und führt NTFS, exFAT, UDF und FAT32 weiterhin als zentrale Windows-Dateisysteme mit deutlich unterschiedlichen Funktionsprofilen. Die Linux-Kerneldokumentation beschreibt ext4 mit Blockgruppen, Inodes, Extents, Journal und Metadatenprüfsummen. NVM Express führt die Base Specification 2.3 als aktuelle ratifizierte Grundlage der NVMe-Spezifikationsfamilie. Diese Entwicklungen ändern die historische Speicherwelt nicht, setzen sie aber in einen aktuellen technischen Rahmen.

Für SSDs ist TRIM beziehungsweise Deallocation weiterhin Teil der normalen Speicheroptimierung. Das unterstreicht den wesentlichen Recovery-Unterschied zu klassischen magnetischen Medien: Freigegebene LBAs können vom Flash-Controller bewusst zur Wiederverwendung vorbereitet werden. Moderne Speichersysteme verlangen deshalb noch stärker nach frühzeitigen Backups statt nach Vertrauen auf nachträgliche Wiederherstellbarkeit.

Querverweise im SSLXY-Archiv

Dateisysteme und Datenträger berühren fast jeden anderen technischen Bereich des Archivs. Die folgenden Seiten vertiefen konkrete Medien, Schnittstellen, Betriebssysteme und Sicherungspraktiken.

• SyQuest-Wechselplatten – konkrete Wechselplattenpraxis und Geräteumfeld.
• Laufwerke und Diskettenstationen – Mechanik und historische Laufwerkswelten.
• Interfaces und Schnittstellen und Kabel – elektrische und logische Verbindungsebenen.
• AmigaDOS – Amiga-Dateisysteme im Betriebssystemkontext.
• PC, DOS und Windows – FAT, NTFS, BIOS, Partitionierung und Windows-Speicherwelt.
• Datensicherung und Backups sowie Backups – Sicherungsstrategie und Archivpraxis.
• Hardware – übergreifender Gerätebestand und Systemkontext.
• The Vault – Archivgedanke und bewahrte technische Bestände.

Die Querschnittsseite ersetzt diese Vertiefungen nicht. Sie schafft den gemeinsamen technischen Rahmen von physischem Medium über Adressierung und Dateisystem bis zu Imaging, Integritätsprüfung und Migration.