Storage: Block, Datei, Objekt und Datenintegrität

Storage ist die Zustandsgrundlage fast jeder Infrastruktur: Mailboxen, Queues, Suchindizes, Verzeichnisse, Datenbanken, virtuelle Maschinen und Backups bestehen aus Bytes plus Metadaten und einer Zusage darüber, wann Änderungen sichtbar und dauerhaft sind. Das Medium allein liefert diese Zusage nicht. Anwendung, Betriebssystemcache, Dateisystem, Volume Manager, Controller, Netzwerk, Redundanzverfahren und entfernte Replikation bilden gemeinsam den Datenpfad.

Für Admins sind deshalb drei Fragen vor jeder Produktwahl wichtiger als Kapazität und nominelle IOPS: Welches Zugriffsmodell sieht die Anwendung? Welche Commit- und Konsistenzsemantik gilt? Welche Ausfallbereiche überlebt eine bestätigte Änderung? Erst danach lassen sich Performance, Backup, Verschlüsselung und Kosten sinnvoll bewerten.

Die Erklärung folgt einem Schreibvorgang von der Anwendung über Dateisystem oder Objekt-API bis zu Volume, Controller und Medium. Erst danach werden Replikation, Konsistenz, Performance, Verschlüsselung, Backup und Recovery verglichen.

Storage beginnt mit einer Schreibanforderung der Anwendung und endet erst, wenn die Daten nach dem zugesagten Modell dauerhaft und wieder lesbar sind. Dazwischen liegen Cache, Dateisystem oder Objekt-API, Netzwerk, Controller und Medium. Der Artikel folgt diesem Datenpfad statt nur Speichertypen aufzuzählen.

Technische Einordnung und Datenpfad

Storage wird nach der Schnittstelle eingeordnet, die ein Consumer erhält:

• Blockspeicher adressiert Bereiche eines logischen Geräts. Dateisystem oder Datenbank besitzen die höhere Struktur.
• Dateispeicher exponiert hierarchische Namen, Verzeichnisse, Attribute, Berechtigungen und Operationen wie Öffnen, Lesen oder Umbenennen.
• Objektspeicher adressiert Objekte über Namespace/Bucket und Key; Daten und Metadaten werden durch APIoperationen verwaltet.

SNIA beschreibt Block-, File- und Object Storage als unterschiedliche Service- und Zugriffsmodelle, nicht bloss als drei Produktklassen (SNIA – Storage Networking Primer). Ein S3-Gateway vor einem Dateisystem ändert beispielsweise das externe Objektmodell, ohne dass die interne Datenhaltung zwingend objektbasiert ist.

Ein synchroner Schreibpfad kann folgende Schichten durchlaufen:

1. Anwendung und Laufzeit mit eigenem Buffering oder Write-ahead Log;
2. Systemaufruf, Virtual File System oder Raw-Blockzugriff;
3. Page Cache, Dateisystem und Volume Manager;
4. Kernel-Blocklayer und I/O-Scheduler;
5. Gerätetreiber, HBA, Netzwerkprotokoll oder virtuelle Storageebene;
6. Controllercache, Redundanz-/Erasure-Coding-Schicht und Medium;
7. Replikate, Journal, Quorum oder entfernten Standort.

Der Linux-Blocklayer dokumentiert Queues, Requests und Gerätetopologie als eigene Kernelschicht (Linux Kernel – Block subsystem). Windows abstrahiert physische Datenträger, Storage Pools, virtuelle Disks, Partitionen, Volumes und Dateisysteme ebenfalls getrennt (Microsoft Learn – Storage overview).

Blockspeicher

Blockspeicher stellt einen linearen logischen Adressraum bereit. SCSI LUN, iSCSI Target, Fibre-Channel-Volume, NVMe Namespace, virtuelle Disk und Cloudvolume sind unterschiedliche Transporte oder Implementierungen desselben Grundmodells. Der Initiator sieht Blöcke; Dateinamen, Verzeichnisse und häufig auch Sperrsemantik entstehen darüber.

iSCSI kapselt SCSI-Kommandos über TCP und trennt Discovery/Login, Session und Connections. RFC 7143 definiert die Protokollsemantik; Multipathing, Authentisierung, Netzwerkdesign und Filesystem-Clusterfähigkeit bleiben zusätzliche Betriebsebenen (RFC 7143 – iSCSI). NVMe wurde für nichtflüchtigen Speicher über PCIe entworfen und verwendet Submission/Completion Queues; NVMe over Fabrics überträgt das Modell unter anderem über RDMA oder TCP (NVM Express Specifications).

Ein Blockvolume darf nicht gleichzeitig von mehreren Hosts mit gewöhnlichen lokalen Dateisystemen beschreibbar gemountet werden. Shared-Block-Betrieb benötigt ein Clusterdateisystem oder eine Anwendung mit eigener verteilten Koordination. «Das SAN präsentiert die LUN an beide Server» ist keine Schreibsperre.

Dateisystem und VFS

Ein Dateisystem ordnet Blockbereiche oder andere Backends zu Dateien, Verzeichnissen und Metadaten. Das Virtual File System stellt Anwendungen eine gemeinsame Systemaufrufschnittstelle bereit; konkrete Dateisysteme implementieren Operationen, Caching und Dauerhaftigkeit unterschiedlich (Linux Kernel – Overview of the Linux Virtual File System).

Journaling protokolliert Metadaten oder zusätzlich Daten, um nach einem Crash einen konsistenten Dateisystemzustand wiederherzustellen. Es ist kein Backup und verhindert nicht, dass eine fachlich falsche Änderung korrekt journalisiert wird. ext4 dokumentiert Modi wie journal, ordered und writeback; XFS verwendet ein Metadatenjournal und eigene Recoverymechanismen (Linux Kernel – ext4, XFS Documentation).

Copy-on-write-Dateisysteme wie Btrfs und OpenZFS schreiben geänderte Blöcke an neue Orte und aktualisieren Referenzen. Das ermöglicht effiziente Snapshots und Prüfsummenmodelle, verlangt aber Raum für neue Blöcke, Metadaten und Garbage Collection (Btrfs Documentation, OpenZFS – Basic Concepts).

Remote Files: NFS und SMB

NFSv4.1 definiert ein zustandsbehaftetes Remote-Dateiprotokoll mit Sessions, Opens, Locks, Delegations und einer Compound-Operation. Clientcache und Server-Recovery sind Teil des Protokolls; ein NFS-Mount ist nicht bloss «lokales POSIX über TCP» (RFC 8881 – NFSv4.1).

SMB 2/3 verwendet Credits, Sessions, Tree Connects, Opens und Leases/Oplocks. Microsoft veröffentlicht die Protokollspezifikation; Features wie Multichannel, Transparent Failover, Encryption und Persistent Handles verändern Performance und Failoversemantik (Microsoft Open Specifications – MS-SMB2).

Bei Remote Files werden mindestens dokumentiert:

• Namensauflösung, Ziel/VIP und Ports;
• Authentisierung und Identitätsabbildung, etwa Kerberos, NTLM oder UID/GID;
• Dialect/Protokollversion, Mountoptionen und Verschlüsselung;
• Cache-, Lock-, Lease- und Failoververhalten;
• Semantik bei Netztrennung, Timeout und Server-Recovery;
• Quotas, Snapshots und Backupverantwortung.

Get-SmbConnection | Select-Object ServerName,ShareName,Dialect,Encrypted,ContinuouslyAvailable
Get-SmbMapping
Test-NetConnection $env:FILESERVER -Port 445
Get-Volume | Sort-Object DriveLetter

findmnt --json | jq '.filesystems[] | select(.fstype | test("nfs|cifs"))'
nfsstat --client
smbclient --list="//$FILESERVER" --use-kerberos=required
nc -vz "$FILESERVER" 445

Get-SmbConnection und Get-SmbMapping zeigen aktive SMB-Dialects und Mappings; Get-Volume ergänzt die lokale Volumesicht. findmnt, nfsstat und smbclient prüfen Unix-Mounts und Protokollsichten; jq filtert deren JSON-Ausgabe. Test-NetConnection und nc belegen nur den TCP-Pfad, nicht Shareautorisierung oder I/O-Semantik.

Objektspeicher

Objektspeicher verwendet keine offenen Dateihandles im klassischen Sinn. Eine Operation liest, schreibt, listet, kopiert oder löscht ein Objekt unter einem Key. «Ordner» sind häufig Präfixe oder UIprojektionen. Ein Rename kann dadurch als serverseitige Kopie plus Löschen implementiert sein. AWS dokumentiert die S3-API als REST-orientierte Schnittstelle über Buckets, Objects und Operationen (Amazon S3 API Reference).

Objektoperationen besitzen eigene Grenzen:

• Multipart Upload erzeugt Teile und einen abschliessenden Commit; abgebrochene Uploads benötigen Lifecyclebereinigung.
• ETag ist nicht universell eine MD5-Prüfsumme, insbesondere nicht bei Multipart- oder verschlüsselten Objekten.
• Listing, Versioning, Delete Marker und Lifecycle sind getrennte Zustände.
• Pre-signed URLs delegieren eine konkrete Operation bis zum Ablauf und gehören wie Credentials behandelt.
• Object Lock/WORM benötigt Retention-, Legal-Hold-, Schlüssel- und Administrationsmodell.

Amazon S3 dokumentiert starke Read-after-write- und Listkonsistenz für erfolgreiche PUTs und Deletes. Diese Produktzusage gilt nicht automatisch für S3-kompatible Implementierungen, Caches oder überlagerte Gateways (Amazon S3 – Data consistency model).

aws s3api head-bucket --bucket $env:BUCKET
aws s3api get-bucket-versioning --bucket $env:BUCKET
aws s3api get-object-attributes --bucket $env:BUCKET --key $env:OBJECT_KEY `
  --object-attributes ETag,Checksum,ObjectSize,StorageClass
rclone size $env:REMOTE

aws s3api head-bucket --bucket "$BUCKET"
aws s3api get-bucket-versioning --bucket "$BUCKET"
aws s3api get-object-attributes --bucket "$BUCKET" --key "$OBJECT_KEY" \
  --object-attributes ETag,Checksum,ObjectSize,StorageClass | jq .
rclone size "$REMOTE"

aws s3api arbeitet auf S3-APIoperationen; die gezeigten Unterbefehle prüfen Bucketzugang, Versionierung und Objektattribute. rclone size zählt Objekte und Bytes über ein konfiguriertes Backend. Beide zeigen die Sicht ihrer Credentials und ihres Endpoints; Region, Account und Alias werden deshalb mitprotokolliert.

Ob Block, Datei oder Objekt: Eine bestätigte Schreiboperation muss im Kontext von Cache und Flush verstanden werden. «Erfolgreich geschrieben» bedeutet nicht bei jedem Stack denselben Punkt physischer Dauerhaftigkeit.

Cache, Flush und Dauerhaftigkeit

Ein erfolgreicher write()-Aufruf kann nur bedeuten, dass Bytes in einen Betriebssystemcache kopiert wurden. POSIX-nahe Systeme verwenden fsync() beziehungsweise fdatasync(), um geänderte Daten und erforderliche Metadaten bis zum Gerät zu übertragen. Die Linux-Manpage weist darauf hin, dass bei einer neu angelegten Datei zusätzlich das enthaltende Verzeichnis synchronisiert werden kann, damit der Directory Entry dauerhaft ist (fsync(2)).

Darunter müssen Controller und Medium Flush/FUA korrekt umsetzen. Ein batterie- oder flashgesicherter Write Cache kann bestätigte Writes über Stromverlust bewahren; ein flüchtiger Cache ohne Schutz kann Performance vortäuschen. Virtualisierung und Netzstorage verlängern die Kette. Der Admin benötigt die End-to-End-Commitzusage, nicht nur eine aktivierte Checkbox «Write Cache».

Datenbanken verwenden Write-ahead Logging, Checksums und Recoveryprotokolle, weil ein Dateisystemcommit keine fachliche Transaktion definiert. Snapshot oder Replikat wird erst anwendungskonsistent, wenn die Anwendung einen unterstützten Freeze-, Backup- oder Logpositionierungsmechanismus verwendet.

Konsistenz in verteilten Speichersystemen

Verteilte Systeme replizieren Daten über Prozesse und Ausfallbereiche. Eine Operation kann an einem Knoten bestätigt, an einem anderen noch unsichtbar oder bei Netzpartitionen nicht entscheidbar sein. Konsistenzmodelle beschreiben, welche Beobachtungsreihenfolgen Clients erwarten dürfen. Eine Übersicht von Viotti und Vukolić ordnet starke und schwächere Modelle anhand von Verlaufsgarantien ein (Consistency in Non-Transactional Distributed Storage Systems).

Praktische Parameter sind:

• Zahl und Ort der Replikate beziehungsweise Erasure-Coding-Fragmente;
• Write- und Read-Quorum sowie Acknowledgementgrenze;
• synchrone oder asynchrone Standortreplikation;
• Verhalten bei Split Brain, verlorener Mehrheit und Rejoin;
• Repair, Backfill, Rebalance und Scrub;
• Staleness-, Read-after-write- und monotone-read-Zusage;
• Konfliktauflösung und bevorzugte Datenhoheit.

Ceph beschreibt CRUSH als deterministische Platzierung von Objekten über hierarchische Failure Domains und RADOS als verteilte Objektbasis für Block-, Datei- und Objektinterfaces (Ceph Architecture). Die konkrete Pool-, Replikat-, Erasure-Coding- und Failure-Domain-Konfiguration entscheidet, welche Ausfälle das System tatsächlich überlebt.

Konsistenz beschreibt die Sicht auf Daten; Redundanz schützt gegen den Ausfall einzelner Komponenten. RAID und Erasure Coding erhöhen Verfügbarkeit, ersetzen aber keine unabhängige Sicherung.

RAID, Erasure Coding und Rebuild

RAID kombiniert mehrere Geräte zu Verfügbarkeits- oder Performanceeigenschaften. Mirroring hält vollständige Kopien; Parity-RAID berechnet Redundanzinformationen. Die klassische Berkeley-Arbeit prägte die RAID-Level als Architekturalternativen (Patterson, Gibson, Katz – A Case for Redundant Arrays of Inexpensive Disks).

Erasure Coding teilt Daten in Daten- und Paritätsfragmente; aus einer Mindestzahl lässt sich das Objekt rekonstruieren. Es spart gegenüber voller Replikation Kapazität, erhöht aber Codierungs-, Netzwerk- und Repairkosten. Kleine zufällige Writes können besonders teuer sein.

RAID und Replikation schützen nicht vor:

• logischem Löschen oder Verschlüsselung durch autorisierte Software;
• stiller Beschädigung, die korrekt repliziert wird;
• kompromittierten Admin- oder Control-Plane-Credentials;
• Fehlern ausserhalb der gewählten Failure Domain;
• inkompatiblen Software-/Metadatenzuständen;
• Verlust von Verschlüsselungsschlüsseln.

SNIA beschreibt RAID als Datenschutzalgorithmus über mehrere unabhängige Geräte und behandelt Backup als davon getrennte Schutztechnik; aus RAID folgt daher keine Backupsemantik (SNIA – Data Protection Best Practices). Während Rebuild oder Backfill sinkt die Sicherheitsmarge, und Latenz sowie Ausfallwahrscheinlichkeit können steigen. Fortschritt, verbleibende Redundanz und Fehlerrate gehören ins Monitoring.

Snapshots und Clones

Ein Snapshot ist eine Referenz auf einen Zustand zu einem Zeitpunkt. Copy-on-write oder Redirect-on-write speichert spätere Änderungen separat; ein Clone kann aus derselben Blockbasis einen beschreibbaren Zweig erzeugen. Snapshots sind schnell und nützlich für Recoverypunkte, Tests und Replikation.

Sie teilen jedoch häufig Storagehardware, Control Plane, Credentials und Ausfallbereich mit der Quelle. Ein Poolverlust oder kompromittierter Storageadmin kann Quelle und Snapshots gemeinsam treffen. Snapshotketten verbrauchen Metadaten und Kapazität; das Löschen eines alten Snapshots kann erhebliche Hintergrundarbeit auslösen.

Crashkonsistenz entspricht ungefähr einem abrupten Stromverlust. Anwendungskonsistenz erfordert Flush, Quiesce, Filesystem Freeze, VSS oder eine produktspezifische Backup-API. Microsoft VSS koordiniert Requester, Writer und Provider für konsistente Shadow Copies unter Windows (Microsoft Learn – Volume Shadow Copy Service).

Prüfsummen, Scrub und End-to-End-Integrität

Prüfsummen erkennen Änderungen nur, wenn ein vertrauenswürdiger Sollwert existiert und der überprüfte Bereich klar ist. Transport-CRC, Geräte-ECC, Filesystemchecksum, Objektchecksum und Anwendungshash schützen unterschiedliche Strecken. Eine ETag- oder Dateizeit ist kein universeller Integritätsbeweis.

OpenZFS speichert Prüfsummen für Daten und Metadaten in übergeordneten Blockpointern und kann bei Redundanz eine fehlerhafte Kopie erkennen und reparieren (OpenZFS – Checksums). Btrfs bietet Checksums und Scrub über seine Geräte; Scrub liest Daten und Metadaten, verifiziert und repariert bei vorhandener guter Kopie (Btrfs – Scrub).

Ein Scrub ist I/O-Last und benötigt Zeitfenster, Priorisierung und Alarmierung. «Scrub abgeschlossen» ist nur dann aussagekräftig, wenn unkorrigierbare Fehler, reparierte Fehler, ausgelassene Bereiche und betroffene Objekte ausgewertet werden.

Get-FileHash -Algorithm SHA256 $env:SOURCE_FILE
Get-FileHash -Algorithm SHA256 $env:RESTORED_FILE
Get-StorageReliabilityCounter -PhysicalDisk (Get-PhysicalDisk)
Repair-Volume -DriveLetter $env:DRIVE_LETTER -Scan

sha256sum "$SOURCE_FILE" "$RESTORED_FILE"
smartctl --xall "$BLOCK_DEVICE"
zpool status -v "$ZPOOL"
btrfs scrub status "$BTRFS_MOUNT"

Get-FileHash und sha256sum vergleichen kontrollierte Dateien. Get-StorageReliabilityCounter und smartctl lesen Gerätegesundheitsdaten; Repair-Volume, zpool status und btrfs scrub zeigen Dateisystem-/Poolperspektiven. Diese Werkzeuge dürfen nur auf klar identifizierten Zielen ausgeführt werden.

Thin Provisioning, Discard und Kapazität

Thin Provisioning präsentiert mehr logischen als physisch zugewiesenen Raum. Das erhöht Auslastung, erzeugt aber eine zusätzliche Ausfallgrenze: Ein Host sieht freien Platz, während Pool oder Metadatenbereich erschöpft sind. Wachstum, Snapshotverbrauch, Reserven und Reclaim müssen gemeinsam überwacht werden (Red Hat – Thinly-provisioned logical volumes).

TRIM/UNMAP/Discard meldet nicht mehr benötigte Blöcke an darunterliegende Schichten. Ob die Information bis zum Array oder Cloudbackend gelangt, hängt von Dateisystem, Mountoption, Hypervisor, Protokoll und Gerät ab. Reclaim kann Performance und Datenschutz beeinflussen; bei verschlüsselten Volumes kann Discard Belegungsmuster sichtbar machen.

Kapazitätsmonitoring umfasst:

• logische und physische Bytes sowie Overcommit;
• Dateisystemblöcke, Inodes oder Objektanzahl;
• Snapshot-, Journal-, WAL- und Metadatenraum;
• Reserved Space, Rebuild-/Backfillreserve und Quota;
• Trash, Delete Marker, alte Versionen und Multipartreste;
• Wachstum je Datenklasse und Zeitpunkt bis zur Erschöpfung.

HDD, Flash und NVMe

HDDs besitzen mechanische Positionierungszeiten; zufällige I/O und sequentieller Durchsatz unterscheiden sich stark. SSDs verwenden Flash Translation Layer, Garbage Collection, Over-Provisioning und Wear Leveling. Schreibverstärkung und verbleibende Lebensdauer hängen von Workload und Firmware ab. NVMe reduziert Protokoll- und Queueengpässe, beseitigt aber keine Medien- oder Dauerhaftigkeitsfragen.

SMART-/NVMe-Healthwerte sind herstellerspezifische Signale, keine Garantie. Kritische Warnungen, Media/Data Integrity Errors, Unsafe Shutdowns, Temperatur, Spare und Percentage Used werden zusammen mit Anwendungsfehlern und Controllerlogs ausgewertet. Das NVMe-Projekt veröffentlicht die Spezifikationen für Controller, Management und Transporte (NVM Express Specifications).

Verschlüsselung und Schlüsselgrenzen

Storageverschlüsselung kann auf Medium, Controller, Volume, Dateisystem, Objekt oder Anwendung erfolgen. Jede Ebene schützt gegen ein anderes Bedrohungsmodell:

NIST SP 800-209 fordert für Storageinfrastrukturen unter anderem Zugriffskontrolle, sichere Verwaltung, Datenintegrität, Verschlüsselung, Isolation und Monitoring als zusammenhängendes Sicherheitsmodell (NIST SP 800-209 – Security Guidelines for Storage Infrastructure).

Key Rotation und Restore werden gemeinsam getestet. Ein Backup ohne die zum Zeitpunkt der Sicherung gültigen Schlüssel und Metadaten ist nicht wiederherstellbar; ein exportierter Schlüssel ohne IAM-/Wrappingkontext kann ebenso nutzlos sein.

Kapazität allein sagt wenig über das Verhalten einer Anwendung. Entscheidend sind Latenz, IOPS, Durchsatz und Warteschlangen entlang des gesamten Datenpfads.

Performance: Latenz, IOPS, Durchsatz und Queue

Nominelle IOPS ohne Blockgrösse, Read/Write-Mix, Zugriffsmuster, Queue Depth, Synchronität und Latenzpercentile sind nicht vergleichbar. Durchsatz ergibt sich näherungsweise aus IOPS mal Transfergrösse, bis Bus-, Netzwerk-, Controller- oder Mediengrenzen dominieren. Cachehits können das Medium vollständig umgehen.

Gemessen werden mindestens:

• End-to-End-Latenz aus Anwendungssicht, einschliesslich p95/p99;
• IOPS und Bytes/s getrennt nach Lesen/Schreiben;
• Queue Depth, Auslastung und Wartezeit je Gerät/Volume;
• Sync-Write-Latenz und Flushrate;
• Cachehit, Dirty Data und Throttling;
• Backend-/Replikationslag, Rebuild oder Garbage Collection;
• Fehler, Retries, Timeouts und Pfadfailover.

fio kann kontrollierte I/O-Workloads erzeugen; seine Dokumentation warnt implizit durch die flexiblen Schreiboptionen: Ein falsches Ziel zerstört Daten. Tests laufen nur auf dedizierten Testdateien oder freigegebenen Geräten mit verifiziertem Pfad (fio Documentation). Microsofts DiskSpd ist ein entsprechendes synthetisches Storagewerkzeug für Windows (Microsoft DiskSpd).

Get-Counter '\PhysicalDisk(*)\Avg. Disk sec/Transfer','\PhysicalDisk(*)\Disk Transfers/sec' `
  -SampleInterval 2 -MaxSamples 15
diskspd.exe -c2G -d30 -r -w30 -b8K -o4 -t2 $env:TEST_FILE
Get-PhysicalDisk | Get-StorageReliabilityCounter

iostat -x -d 2 15
fio --name=controlled-test --filename="$TEST_FILE" --size=2G \
  --rw=randrw --rwmixread=70 --bs=8k --iodepth=4 --runtime=30 --time_based
pidstat -d 2 15

Get-Counter, iostat und pidstat beobachten reale Last. diskspd und fio erzeugen synthetische Last und werden nie gegen produktive Blockgeräte oder ungesicherte Dateien gerichtet.

Multipathing und Failure Domains

Mehrere Pfade können Controller-, HBA-, Switch- oder Fabricausfälle überleben, wenn sie tatsächlich unabhängig sind. Multipathing erkennt mehrere Wege zum selben logischen Gerät und führt Failover oder Load Balancing aus. Pfadzahl allein beweist keine Redundanz: Zwei Sessions über denselben Switch und Controller fallen weiterhin gemeinsam aus.

Asymmetric Logical Unit Access kann bevorzugte und nicht bevorzugte Controllerpfade kennzeichnen. Timeoutwerte müssen über Anwendung, Dateisystem, Multipath, Transport und Array zusammenpassen; zu kurze Timeouts erzeugen falsche Ausfälle, zu lange blockieren Queues.

Get-Disk | Sort-Object Number
Get-PhysicalDisk | Sort-Object FriendlyName
Get-MPIOPath
Get-IscsiSession | Format-List *

lsblk --json -o NAME,KNAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS,MODEL,SERIAL,WWN | jq .
multipath -ll
iscsiadm -m session -P 3
nvme list -o json | jq .

Get-Disk, Get-PhysicalDisk, Get-MPIOPath und Get-IscsiSession zeigen Windows-Geräte und Pfade. lsblk, multipath, iscsiadm und nvme zeigen Linuxzuordnung, Sessions und Namespaces. Seriennummer, WWN, LUN und Mountpoint werden vor jeder Änderung gegengeprüft.

Cloud-Speicherklassen und Lifecycle

Cloudobjektspeicher bietet Klassen mit verschiedenen Preisen, Mindestaufbewahrung, Abrufkosten und Wiederherstellungszeiten. Archive kann asynchron rehydriert werden; Lifecycle Policies können Objekte über Klassen bewegen oder Versionen löschen. Eine billige Kapazitätszahl ohne Request-, Retrieval-, Egress- und Mindestdauerpreis ist unvollständig.

AWS dokumentiert Storage Classes samt Zugriffsmustern und Einschränkungen; andere Anbieter verwenden eigene Klassen und Zusagen (Amazon S3 Storage Classes). Für einen Recoveryplan werden deshalb pro Datenklasse RPO, RTO, Restorebandbreite, Requestrate, Egresskosten und Schlüsselverfügbarkeit getestet.

Replikation hält weitere Kopien für Verfügbarkeit bereit, übernimmt aber häufig auch Fehler und Löschungen. Backup und Archiv erfüllen andere Zeit- und Unveränderlichkeitsziele.

Backup, Replikation und Archiv trennen

Replikation hält eine oder mehrere Kopien synchron oder zeitversetzt verfügbar. Snapshot referenziert einen Zeitpunkt im selben Storagekontext. Backup erzeugt eine verwaltete, wiederherstellbare Kopie mit Aufbewahrung und Katalog. Archiv bewahrt Daten langfristig nach Governance- und Zugriffsregeln. Ein System kann mehrere Rollen kombinieren; die Zusagen bleiben getrennt.

Ein belastbarer Schutzplan folgt Backup und Disaster Recovery und enthält:

• Anwendungsquieszenz oder produktspezifische Online-Backupsemantik;
• Daten, Metadaten, ACLs, Eigentümer, Extended Attributes und Schlüssel;
• getrennte Fehler- und Administrationsdomäne;
• Retention, Immutability, Lösch- und Legal-Hold-Modell;
• Katalog und Abhängigkeiten zu Software-/Schemaversionen;
• regelmässigen Restore in eine saubere Zielumgebung;
• Integritäts- und fachlichen Abgleich nach dem Restore.

Datenlöschung und Medienende

Dateilöschen oder Objekt-Delete entfernt häufig nur Namens- oder Metadatenreferenzen. Snapshots, Versionen, Replikate, Caches, Backups, Flash Translation Layer und defekte Medien können Kopien behalten. NIST SP 800-88 beschreibt Clear, Purge und Destroy als unterschiedliche Sanitizationverfahren abhängig von Medium, Schutzbedarf und Wiederverwendung (NIST SP 800-88 Rev. 1 – Media Sanitization).

Bei verschlüsseltem Storage kann Crypto Erase Schlüsselmaterial unbrauchbar machen, wenn alle Daten wirksam mit den betroffenen Schlüsseln geschützt sind und keine Klartextkopien existieren. Key Hierarchy, Escrow, Replikate und Backups müssen in den Nachweis einbezogen werden.

Technische Geschichte

Frühe Computersysteme verbanden Speicher direkt mit einem einzelnen Rechner. Standardisierte Blockprotokolle wie SCSI trennten Host und Gerätefunktion; RAID kombinierte Geräte zu Performance- und Redundanzmodellen. Storage Area Networks über Fibre Channel und iSCSI zentralisierten Blockvolumes, während Network Attached Storage Dateifreigaben über NFS und SMB bereitstellte.

Logische Volume Manager und Copy-on-write-Dateisysteme trennten physische Geräte weiter von Volumes, Snapshots und Datenintegrität. Verteilte Dateisysteme und Objektspeicher skalierten Metadaten und Daten über viele Nodes. Cloud-APIs machten Storage zu einem per Request provisionierten Dienst mit Lifecycle, Versioning und nutzungsbasierter Abrechnung.

Flash und NVMe veränderten die Leistungsgrenzen: parallele Queues und Mikrosekundenlatenzen machten Softwarepfad, CPU, NUMA und Netzwerk wichtiger. Gleichzeitig abstrahieren Software-defined Storage und das Container Storage Interface die physische Lage. Die zentrale Adminfrage blieb unverändert: Welche bestätigten Bytes überleben welchen Ausfall, und wie wird dieser Nachweis regelmässig wiederholt?

Admin-Checkliste auf einen Blick

Eine Storagefreigabe ist erst verständlich, wenn Schreibbestätigung, Redundanz, Ausfallverhalten und Restore gemeinsam dokumentiert sind. Die Tabelle fasst diese Betriebsfragen unabhängig vom Produktnamen zusammen.