backups.htm
Die physische Realität der Daten.
Ein Backup war früher kein unsichtbarer Prozess, der lautlos im Hintergrund auf fremden Servern lief. Ein Backup war ein physischer Vorgang. Man hörte ihn, man spürte ihn, und man musste ihn bewusst anstoßen.
Wer heute achtlos Terabytes in eine Cloud schiebt, vergisst leicht die grundlegende Mechanik von Datenhaltung. Die Werkzeuge haben sich radikal verändert, das Prinzip der Redundanz und die Realität eines Datenverlusts aber nicht.
Diese Seite sammelt deshalb nicht nur alte Mediennamen. Sie beschreibt eine Haltung: Daten, die nur an einer Stelle liegen, sind nicht wirklich gesichert. Ein Backup ist erst dann brauchbar, wenn es im Ernstfall lesbar, erreichbar, unabhängig und tatsächlich wiederherstellbar ist.
System Diagnostic
Disketten – Das Hoffen auf Block 0
Die frühe Form der Datensicherung war eng mit Unsicherheit verbunden. Eine 5,25-Zoll- oder spätere 3,5-Zoll-Diskette bot nicht nur wenig Speicherplatz, sondern oft auch nur begrenzte Verlässlichkeit. Ein Lesefehler, eine beschädigte Oberfläche oder ein problematisches Laufwerk konnten reichen, und tagelange Arbeit war verloren.
Wer damals kopierte, ob am Amiga mit X-Copy oder unter DOS auf der Kommandozeile, hörte auf das Laufwerk. Gleichmäßiges Rattern bedeutete Hoffnung. Stocken, erneutes Ansetzen und das bekannte lange Rödeln bedeuteten meist nichts Gutes.
> Track 40 ... OK
> Track 41 ... OK
> Track 42 ... Read Error on DF0:
> Result: Data corruption. Retry / Cancel?
Die Konsequenz war einfach: Man hatte nie nur eine Arbeitsdiskette. Es gab die aktuelle Arbeitskopie, das Backup vom Vorabend und oft noch eine weitere Sicherheitskopie an einem anderen Ort. Redundanz war keine Theorie, sondern Erfahrung.
„Eine Diskette war erst beruhigend, wenn es mindestens eine zweite gab.“
Bandsicherung – Linear, langsam, aber ernst zu nehmen
Mit wachsenden Festplattenkapazitäten reichten Disketten irgendwann nicht mehr aus. Wer hunderte Megabyte sichern wollte, konnte das zwar auf viele einzelne Disketten verteilen, aber praktisch war das nicht. Es war zeitaufwendig, fehleranfällig und im Alltag wenig brauchbar.
Streamer und andere Bandlösungen änderten das. Sie arbeiteten sequentiell, nicht elegant, nicht schnell beim gezielten Wiederherstellen einzelner Dateien, aber sie brachten zum ersten Mal eine Form von Datensicherung in Bereiche, die man vorher nur mit viel Geduld oder Improvisation abdecken konnte.
Man startete den Lauf am Abend, ließ den Rechner arbeiten und nahm am Morgen das Medium heraus. Dann wurde es beschriftet, gesichert abgelegt und möglichst nicht direkt neben dem eigentlichen System aufbewahrt.
Gerade diese Langsamkeit war lehrreich. Sie machte deutlich, dass Datensicherung nicht erst im Katastrophenfall beginnt. Wer beim Schadenfall erstmals über Restore nachdenkt, hat das Konzept schon vorher zu spät verstanden.
SyQuest – Wechselplatte statt bloßem Archiv
Für SCSI-Systeme waren SyQuest-Laufwerke ein echter Fortschritt. Anders als Bandlösungen waren sie nicht nur als Archivmedien nützlich, sondern als direkt nutzbare, herausnehmbare Arbeits- oder Sicherungsplatten. Das veränderte den gesamten Ablauf.
Man sicherte nicht mehr nur einzelne Dateien weg, sondern komplette Arbeitsstände. Wenn ein System beschädigt war, konnte eine andere Cartridge eingelegt und direkt mit einem sauberen Stand weitergearbeitet werden. Das war im Alltag ein großer Unterschied.
> ID 0: Quantum Fireball (System)
> ID 4: SyQuest SQ5200C (200MB, Backup)
> ID 5: SyQuest SQ5200C (200MB, Archive)
> Strategy: Direkter Spiegel der Projektdaten auf ID 4 am Feierabend.
Das Entscheidende war die Trennung. Eine Platte, die nicht dauerhaft im laufenden System hing, war gegen viele alltägliche Fehler besser geschützt. Genau diese physische Distanz war oft mehr wert als jede theoretische Komfortfunktion.
Zur SyQuest-Linie im sslxy-Archiv gehört zusätzlich die eigene Seite syquest.htm. Dort liegt der Fokus stärker auf den Laufwerken und Wechselmedien selbst.
„Wenn die Platte ausfiel, kam die Wechselplatte hinein – und es ging weiter.“
Warum Redundanz keine Nebensache war
Früher gab es keine Selbstverständlichkeit von Dateiversionsverläufen, Papierkörben, Snapshots oder komfortablen Undelete-Funktionen. Wenn Daten überschrieben oder beschädigt waren, waren sie oft schlicht verloren. Hardwareausfälle waren ebenfalls keine Ausnahme, sondern etwas, womit man rechnen musste.
Daraus ergab sich eine klare Haltung: Daten, die nur an einem Ort existieren, sind im Grunde ungesichert. Diese Einsicht war nicht dramatisch gemeint, sondern praktisch.
- RAID ist kein Backup: Spiegelung schützt vor einem einzelnen Hardwareausfall, aber nicht vor Fehlbedienung, Überschreiben, stiller Beschädigung oder Schadsoftware.
- Trennung ist der Punkt: Ein Medium, das ständig mitläuft, kann auch ständig mit beschädigt oder gelöscht werden.
- Offsite bleibt sinnvoll: Eine Kopie an einem anderen Ort war früher klug und ist es heute noch.
- Restore zählt: Eine Sicherung, die nie testweise wiederhergestellt wurde, ist eher Hoffnung als Nachweis.
Wer sichern wollte, musste sein eigenes System verstehen. Genau daraus entstand ein nüchterner Blick auf Datenhaltung, der bis heute brauchbar geblieben ist.
> one copy: working state
> second copy: local recovery
> third copy: separated from the running system
> rule: Daten müssen den Fehler des Hauptsystems überleben können
Cloud heute – bequem, aber nicht magisch
Moderne Cloud-Dienste haben Speicherung, Synchronisation und Verfügbarkeit stark vereinfacht. Für Zugriff, Zusammenarbeit und Verteilung sind sie oft sehr nützlich. Das ändert aber nichts daran, dass Bequemlichkeit keine Backup-Strategie ersetzt.
Der eigentliche Denkfehler beginnt dort, wo Synchronisation mit Sicherung verwechselt wird. Beides ist nicht dasselbe.
Auch heute bleibt deshalb dieselbe Grundhaltung sinnvoll:
- Bequemlichkeit ersetzt keine Strategie: Cloud-Speicher ist hilfreich, aber nicht automatisch ein vollständiges Sicherungskonzept.
- Air-Gap bleibt relevant: Eine Kopie, die nicht permanent online oder verbunden ist, hat weiterhin ihren Wert.
- Wiederherstellung mitdenken: Nicht nur das Speichern zählt, sondern auch die Frage, wie schnell und vollständig Daten im Ernstfall tatsächlich zurückkommen.
3 Kopien der Daten
2 unterschiedliche Speichermedien
1 Kopie außer Haus oder isoliert vom Hauptsystem
Ich nutze selbst moderne Dienste. Aber ich behandle sie nicht als Magie. Die Oberfläche ist heute glatter, die Grundlogik darunter aber unverändert: Im Ernstfall zählt nur das, was unabhängig, lesbar und intakt geblieben ist.
„Ob SyQuest-Cartridge oder S3-Bucket – der Wert eines Backups zeigt sich erst am Tag des Schadens.“
Restore – der eigentliche Test
Backups werden oft nach dem Sichern bewertet. Das ist falsch. Ein Backup ist erst dann bewiesen, wenn die Wiederherstellung gelingt. Genau dort trennen sich beruhigende Anzeigen von brauchbarer Datensicherung.
Früher war das sofort spürbar: Lässt sich die Diskette lesen? Läuft die SyQuest-Cartridge an? Findet der Controller das Medium? Ist das Band überhaupt noch sauber lesbar? Heute sieht die Oberfläche anders aus, aber die Frage bleibt dieselbe: Kommen die Daten vollständig, in brauchbarer Form und rechtzeitig zurück?
> locate backup medium
> mount or access backup
> restore sample files
> verify integrity and usability
> backup status: credible only after restore test
Genau deshalb war Datensicherung nie nur eine Medienfrage. Sie war immer auch eine Frage der Dokumentation: Was liegt wo? Welche Version ist die letzte gute? Welche Medien gehören zusammen? Welche Software oder Hardware wird zum Lesen gebraucht? Ohne diese Antworten kann selbst eine vorhandene Kopie im Ernstfall nutzlos werden.
Querverweise im SSLXY-Archiv
Diese Seite gehört zu den Speicher-, Medien- und Infrastrukturthemen im sslxy-Bereich. Verwandte Seiten liegen bei SyQuest, Datensicherung, Laufwerken und Hardware.
Rechtliche Hinweise
Diese Seite liegt im eigenständigen sslxy-Bereich der Domain. Inhaltlich behandelt sie technische Archivthemen, Datensicherung, Redundanz und persönliche technische Einordnung.
Genannte Marken- und Produktnamen dienen ausschließlich der sachlichen technischen Einordnung. Diese Seite ist keine Herstellerseite und steht in keiner Verbindung zu den genannten Markeninhabern.
Verantwortlich für die Domain ist der Betreiber des Hotel Goldener Ochsen in Göppingen-Hohenstaufen. Detaillierte Angaben zum Verantwortlichen sowie Informationen zum Datenschutz stehen auf den offiziellen Hauptseiten der Domain.
Kontakt für technische Rückfragen: mail@sslxy.de
- Zur SSLXY-Hauptseite
- Vorherige Datei alphabetisch: audio-und-midi.htm
- Nächste Datei alphabetisch: bildbearbeitung-und-grafikalltag.htm
- Zum Impressum der Domain
- Zur Datenschutzerklärung der Domain
Hinweis zur Datenverarbeitung
Auch diese Unterseite ist als rein informative, statische HTML-Seite konzipiert. Es werden keine Tracker, keine Analyse-Tools und keine zustimmungspflichtigen Cookies eingesetzt.
Statische Seite. Schlanke Struktur. Technischer Inhalt ohne unnötigen Überbau.