backups.htm

Backup, Synchronisation, Replikation, Snapshot und Archiv

Mehrere technische Verfahren erzeugen zusätzliche Datenstände, erfüllen aber nicht automatisch dieselbe Aufgabe. Eine belastbare Strategie benennt deshalb ausdrücklich, welches Verfahren wovor schützen soll.

Ein Verfahren kann mehrere Rollen übernehmen. Ein unveränderlicher Snapshot in einer getrennten Verwaltungsdomäne kann Bestandteil einer Backup-Strategie sein. Ein gewöhnlicher lokaler Snapshot auf demselben kompromittierten System ist dagegen allein keine ausreichende Trennung.

„Eine zweite Darstellung derselben Daten ist erst dann ein Backup, wenn sie den vorgesehenen Schaden tatsächlich überlebt.“

Fehlerdomänen: Welche Ereignisse müssen Kopien überleben?

Redundanz ist nur sinnvoll, wenn die Kopien nicht durch dasselbe Ereignis gleichzeitig verloren gehen. Zwei Festplatten im selben Gehäuse schützen gegen andere Risiken als eine ausgeschaltete Kopie an einem anderen Ort.

Jede Kopie erhält deshalb eine Rolle: schnelle lokale Wiederherstellung, zeitlich tiefe Versionierung, Schutz vor Angriff, Schutz vor Standortverlust oder langfristige Archivierung. Erst die Kombination deckt mehrere Fehlerdomänen ab.

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.

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.

Heute erhalten: erst lesen, dann reparieren

Bei historischen Disketten ist ein vollständiges Image wichtiger als das sofortige Kopieren einzelner Dateien. Track-, Sektor- oder Flux-Abbilder können Informationen bewahren, die ein normales Dateisystemkopieren bereits verwirft. Beschriftung, Laufwerk, Lesefehler, Wiederholungen und verwendetes Format gehören zur Dokumentation.

• Schreibschutz setzen: Originalmedien nicht versehentlich verändern.
• Geeignetes Laufwerk wählen: Spurbreite, Drehzahl und Format müssen zur Diskette passen.
• Image zuerst: vollständigen Zustand sichern, bevor Dateisystemreparaturen versucht werden.
• Mehrfach lesen: instabile Sektoren können bei Wiederholungen unterschiedliche Ergebnisse liefern.
• Original lagern: nach erfolgreicher Erfassung nicht unnötig weiter benutzen.

„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.

Band ist ein System, nicht nur eine Kassette

Ein Bandbestand bleibt nur nutzbar, wenn Laufwerk, Schnittstelle, Reinigung, Backupsoftware, Kataloge, Schlüssel und Mediengeneration zusammenpassen. Ein ordentlich beschriftetes Band ohne verfügbares kompatibles Laufwerk kann ebenso wertlos werden wie ein funktionierendes Laufwerk ohne passende Software oder Entschlüsselungsdaten.

Band eignet sich weiterhin für getrennte und zeitlich tiefe Kopien, weil ein ausgelagertes Medium nicht dauerhaft online sein muss. Die sequentielle Struktur verlangt aber einen getesteten Ablauf und realistische Zeitplanung.

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.

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.

Direkte Nutzbarkeit ist nicht automatisch Isolation

Eine eingelegte und schreibbar eingebundene SyQuest-Cartridge war bequem, aber in diesem Moment auch für Fehlbedienung und Softwarefehler erreichbar. Der eigentliche Schutz entstand durch Rotation und das physische Herausnehmen der nicht benötigten Cartridges.

„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.

3-2-1 als Startpunkt – nicht als vollständiger Beweis

Die bekannte 3-2-1-Regel ist eine verständliche Mindeststruktur: drei Kopien, zwei unterschiedliche Speicherarten und eine Kopie räumlich beziehungsweise technisch getrennt. Sie zwingt dazu, nicht alle Datenstände in derselben Fehlerdomäne zu halten.

Die Zählregel beantwortet jedoch nicht automatisch, ob Kopien ausreichend alt, unveränderlich, verschlüsselt, geprüft, entschlüsselbar oder in der benötigten Zeit wiederherstellbar sind. Drei gleichzeitig verschlüsselte Kopien bleiben drei unbrauchbare Kopien.

Für heutige Angriffsmodelle wird deshalb zusätzlich mindestens eine offline oder logisch isolierte und möglichst gegen nachträgliche Veränderung geschützte Version benötigt. Ebenso wichtig ist die Forderung nach regelmäßig getesteter Wiederherstellung.

Voll-, inkrementelle und differentielle Sicherungen

Eine Backup-Kette kann Daten vollständig oder nur als Änderungen seit einem früheren Stand speichern. Die Wahl beeinflusst Sicherungsdauer, Speicherbedarf, Restore-Komplexität und Abhängigkeit von Zwischenständen.

Keine Methode ist grundsätzlich immer überlegen. Entscheidend sind Datenmenge, Änderungsrate, Aufbewahrung, verfügbare Bandbreite und vor allem die gewünschte Wiederherstellungszeit.

Versionen und Aufbewahrung: Zeit ist eine Schutzdimension

Ein aktuelles Backup hilft nicht, wenn die Beschädigung bereits Wochen unbemerkt in den Datenbestand gelangt ist. Deshalb braucht eine Strategie mehrere Wiederherstellungspunkte über einen ausreichend langen Zeitraum.

Rotation statt endloser Gleichstände

Tages-, Wochen-, Monats- und gegebenenfalls Jahresstände können unterschiedliche Rollen übernehmen. Die genaue Dauer richtet sich nach Risiko, Änderungsrate, Speicherbedarf, rechtlichen Anforderungen und der Zeit, die ein Fehler unentdeckt bleiben kann.

Eine zeitbasierte Aufbewahrungsfrist schützt besser gegen das schnelle Überschreiben aller guten Stände als ein bloßes Limit „behalte die letzten zehn Jobs“. Ein Angreifer oder defekter Prozess könnte sonst in kurzer Zeit viele beschädigte Sicherungen erzeugen und die letzten guten Versionen verdrängen.

RPO und RTO: Wie viel Verlust und Ausfall sind tragbar?

Sicherungsintervalle und Restore-Technik sollten nicht nach Gewohnheit, sondern nach zwei praktischen Zielen geplant werden.

Ein häufiges Backupintervall verbessert das RPO, garantiert aber noch kein kurzes RTO. Eine Wiederherstellung von mehreren Terabyte über eine langsame Leitung kann trotz stündlicher Sicherung Tage dauern. Umgekehrt kann ein schnell startbares Ersatzsystem kurze Ausfallzeit bieten, aber nur einen älteren Datenstand enthalten.

RPO und RTO werden deshalb pro Datenklasse oder Dienst festgelegt. Eine statische Archivseite, aktuelle Buchungsdaten, Systemkonfiguration und private Fotos können unterschiedliche Prioritäten haben.

Ransomware-resistente Backups

Moderne Angreifer suchen häufig gezielt nach Backupservern, administrativen Konten, Katalogen und angeschlossenen Medien. Die Sicherung darf deshalb nicht nur Daten kopieren, sondern muss gegen absichtliches Löschen und Manipulieren geschützt sein.

• Management isolieren: Backupverwaltung nicht unnötig aus normalen Arbeitsplatz- und Servernetzen erreichbar machen.
• Getrennte Konten: Backupadministration nicht mit denselben privilegierten Zugangsdaten wie das Produktionssystem betreiben.
• MFA für destruktive Aktionen: Löschen, Aufbewahrungsänderungen und Schlüsselzugriff zusätzlich absichern.
• Unveränderliche Zeitfenster: Versionen innerhalb ihrer Aufbewahrungsfrist nicht nachträglich überschreibbar machen.
• Alarme: ungewöhnliche Löschungen, Massenänderungen und privilegierte Eingriffe außerhalb des kompromittierten Hauptsystems melden.
• Regelmäßig testen: nicht nur Jobstatus, sondern tatsächliche Wiederherstellung und Datenintegrität prüfen.

Ein Backupserver ist selbst ein sicherheitskritisches System. Ungepatchte Software, frei erreichbare Verwaltungsoberflächen und gemeinsam verwendete Administratorpasswörter können die gesamte Schutzwirkung aufheben.

Offline, Air-Gap, WORM und logische Unveränderlichkeit

„Offline“ bedeutet, dass der Datenbestand außerhalb des normalen Zugriffswegs des laufenden Systems liegt. Das kann ein herausgenommenes Band, eine getrennte Wechselplatte oder ein Cloud-Backup sein, dessen vorhandene Versionen über einen separaten Schutzmechanismus nicht verändert werden können.

Physische Trennung ist stark gegen Netzwerkangriffe, verlangt aber sichere Rotation und Lagerung. Logische Unveränderlichkeit ist automatisierbar, hängt jedoch von korrekten Konten, Schlüsseln, Richtlinien und der Vertrauenswürdigkeit der Plattform ab.

Zugangsdaten, Verschlüsselung und Schlüsselwiederherstellung

Verschlüsselte Backups schützen vertrauliche Daten bei Verlust oder Diebstahl eines Mediums. Gleichzeitig entsteht eine neue Abhängigkeit: Ohne Schlüssel, Passwort oder erforderlichen zweiten Faktor ist die Sicherung selbst bei perfekter Medienlesbarkeit nicht mehr nutzbar.

• Schlüssel getrennt sichern: nicht ausschließlich im zu sichernden Hauptsystem aufbewahren.
• Wiederherstellungszugang dokumentieren: Konten, MFA-Verfahren, Recovery-Codes und Verantwortlichkeiten festhalten.
• Mindestens zwei befugte Wege: Ausfall einer Person oder eines Geräts darf den Restore nicht blockieren.
• Backupkonten trennen: normale Domänen- oder Arbeitsplatzkonten nicht als alleinige Backupadministratoren verwenden.
• Schlüsseltest: ein Restore-Test muss auch Entschlüsselung und Anmeldung einschließen.
• Notfalldokumentation offline: Kontakt- und Wiederanlaufinformationen müssen verfügbar bleiben, wenn das Hauptsystem ausfällt.

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.

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.

Fragen an einen Cloud-Backupdienst

• Versionen: Wie lange bleiben frühere Stände erhalten?
• Löschschutz: Kann ein kompromittierter Administrator alle Versionen sofort vernichten?
• Kontentrennung: Sind Backupkonto und normales Benutzerkonto wirklich getrennt?
• Export: Lassen sich Daten vollständig und in einem dokumentierten Format zurückholen?
• Restore-Geschwindigkeit: Wie lange dauert eine vollständige Rückübertragung?
• Schlüssel: Wer besitzt und sichert die Entschlüsselungsdaten?
• Dienstende: Was geschieht bei Kündigung, Sperrung, Anbieterwechsel oder Kontoverlust?

Cloud kann eine räumlich getrennte und automatisierte Kopie sehr gut unterstützen. Eine zweite unabhängige Export- oder Offlinekopie bleibt dennoch sinnvoll, wenn der Zugriff auf dasselbe Konto, denselben Anbieter oder dieselbe Internetverbindung ausfällt.

„Ob SyQuest-Cartridge oder S3-Bucket – der Wert eines Backups zeigt sich erst am Tag des Schadens.“

Integritätsprüfung: „Job erfolgreich“ ist nur die erste Stufe

Eine grüne Meldung zeigt zunächst nur, dass der Sicherungsprozess seinen vorgesehenen Ablauf ohne erkannten Fehler beendet hat. Sie beweist nicht automatisch, dass jede Datei lesbar, konsistent und anwendungsfähig ist.

Prüfsummen erkennen Veränderungen, beweisen aber nicht, dass die ursprüngliche Datei inhaltlich richtig war. Wurde bereits ein beschädigter Stand gesichert, kann dessen Prüfsumme dennoch perfekt stimmen. Deshalb braucht Integrität zusätzlich zeitliche Versionen und fachliche Plausibilitätsprüfungen.

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?

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.

Restore ist nicht gleich Rückkopieren

Ein vollständiger Wiederanlauf kann Firmware, Betriebssystem, Treiber, Benutzerkonten, Schlüssel, Anwendungen, Datenbanken, Konfiguration, Zertifikate und externe Dienste benötigen. Dateien allein reichen nicht, wenn die Umgebung fehlt, die sie interpretieren und sicher bereitstellen kann.

Wiederherstellungsreihenfolge und Abhängigkeiten

Systeme werden nicht beliebig zurückgespielt. Eine sinnvolle Reihenfolge richtet sich nach technischen und organisatorischen Abhängigkeiten.

1. Schaden eingrenzen: kompromittierte oder defekte Umgebung isolieren und Ursache untersuchen.
2. Vertrauenswürdige Basis: saubere Firmware, Betriebssysteme und Verwaltungszugänge bereitstellen.
3. Identität und Namensauflösung: notwendige Konten, Verzeichnisdienste, DNS und Zeitdienste herstellen.
4. Schlüssel und Zertifikate: Entschlüsselung, TLS, Signaturen und Anwendungszugänge verfügbar machen.
5. Speicher und Datenbanken: konsistente Datenstände in der dokumentierten Reihenfolge einspielen.
6. Anwendungen: Versionen und Konfigurationen passend zu den Daten wiederherstellen.
7. Schnittstellen: externe Dienste, Freigaben und Automatisierung kontrolliert aktivieren.
8. Validierung: technische und fachliche Tests durchführen.
9. Freigabe: erst danach Benutzer und produktive Verbindungen zulassen.

Bei einem Sicherheitsvorfall darf nicht ungeprüft in die alte Umgebung zurückgespielt werden. Sonst können Schadsoftware, gestohlene Konten oder unsichere Konfigurationen sofort wieder wirksam werden.

Restore-Testplan: Stichprobe, Systemtest und Vollübung

Nicht jeder Test muss sofort das gesamte System zurückholen. Verschiedene Teststufen prüfen unterschiedliche Risiken.

Jeder Test erhält Datum, verwendeten Wiederherstellungspunkt, Dauer, aufgetretene Probleme und gemessene Abweichung von RPO und RTO. Nur so wird aus einer Übung eine Verbesserung der Strategie.

Notfallwiederherstellung nach Angriff oder Datenverlust

Im Ernstfall ist hektisches Rückspielen gefährlich. Zuerst wird verhindert, dass der Schaden weiterläuft oder die letzte gute Sicherung ebenfalls erreicht.

1. Betroffene Systeme isolieren: Netzwerkzugriff kontrolliert unterbrechen und Beweise nicht unnötig verändern.
2. Backups schützen: laufende automatische Jobs stoppen, wenn sie beschädigte Daten oder Angreiferzugriff weitertragen könnten.
3. Zeitpunkt bestimmen: erste Anzeichen und möglichen Beginn der Kompromittierung eingrenzen.
4. Guten Stand wählen: Wiederherstellungspunkt vor der Beschädigung auswählen, nicht nur den neuesten.
5. Backup auf Schadsoftware prüfen: Daten und Systemabbilder vor produktiver Nutzung untersuchen.
6. Zugangsdaten erneuern: kompromittierte Konten, Schlüssel, Tokens und Zertifikate ersetzen.
7. Sauber wiederaufbauen: vertrauenswürdige Basis statt ungeprüftem Rückspielen des gesamten alten Zustands.
8. Kontrolliert freigeben: Systeme beobachten und Verbindungen schrittweise wiederherstellen.

Historische Medien: Daten, Lesegerät und Wissen gemeinsam sichern

Ein altes Medium ist nur eine Hälfte des Archivs. Die andere Hälfte besteht aus Laufwerk, Controller, Kabel, Treiber, Dateisystemwissen, Softwareversion, Passwörtern und Dokumentation.

• Medieninventar: eindeutige Kennung, Typ, Kapazität, Datum, Inhalt und Zustand.
• Lesepfad: passendes Laufwerk, Schnittstelle, Terminierung, Adapter und funktionierende Testhardware.
• Images: vollständige Datenträgerabbilder zusätzlich zu extrahierten Dateien.
• Dateiformate: Originaldateien erhalten und bei Bedarf dokumentierte Nutzungskopien erzeugen.
• Prüfsummen: Images und wichtige Dateien gegen unbeabsichtigte Veränderung überwachen.
• Migration: gefährdete Medien rechtzeitig auf moderne Träger kopieren, ohne Originale vorschnell zu entsorgen.

Die Migration ersetzt die historische Quelle nicht, verlängert aber den praktischen Zugriff. Ein SyQuest-Image auf moderner Speicherung ist leichter zu duplizieren und prüfen; die Cartridge bleibt dennoch Teil der Geräte- und Mediengeschichte.

Technische und organisatorische Referenzen

Die aktuellen Sicherheitsabschnitte orientieren sich an Empfehlungen von BSI, CISA, NCSC und NIST. Gemeinsam betonen diese Quellen die Bedeutung getrennter beziehungsweise offline verfügbarer Backups, regelmäßiger Wiederherstellungstests, klarer Notfallplanung und eines Schutzes der Backupumgebung vor destruktiven Aktionen.

Diese Seite ist eine technische Archiv- und Überblicksdarstellung. Konkrete Aufbewahrungsfristen, Datenschutzanforderungen, branchenspezifische Vorschriften und betriebliche Wiederanlaufziele müssen für den jeweiligen Datenbestand und Einsatzfall gesondert festgelegt 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.

• Zur SSLXY-Hauptseite
• Zur Seite syquest.htm
• Zur Seite datensicherung-und-backups.htm
• Zur Seite laufwerke-und-diskettenstationen.htm
• Zur Seite hardware.htm
• Zur Seite systems.htm