datensicherung-und-backups

Warum Backup mehr ist als Kopieren

Der grundlegende Irrtum beginnt früh: Viele nennen jede zweite Kopie schon Datensicherung. Das stimmt nur oberflächlich. Eine Kopie auf demselben Medium, im selben Verzeichnis oder sogar auf demselben physikalischen Gerät ist in vielen realen Fehlerlagen kaum mehr als ein kosmetischer Trost. Sie mag gegen einen einzelnen Löschfehler helfen, aber nicht gegen Medienversagen, Fehlbedienung, logische Unordnung oder das schlichte Vergessen, welche Fassung eigentlich die richtige war.

Ein Backup ist deshalb immer auch eine Zeit- und Zustandsfrage. Es reicht nicht, dass etwas doppelt existiert. Entscheidend ist, ob klar ist, welche Sicherung zu welchem Zeitpunkt gehört, wie sie geprüft wurde, auf welchem Medium sie liegt und wie sie im Notfall zurückgeführt wird. Ohne diese Ordnung bleibt Sicherung unangenehm vage.

„Die Frage ist nie nur: Gibt es noch eine Datei? Die eigentliche Frage lautet: Weiß ich im Ernstfall genau, welche Datei ich zurückholen muss – und kann ich das auch?“

Datenbestand und Abhängigkeiten zuerst erfassen

Ein Sicherungsjob kann technisch fehlerfrei laufen und trotzdem unbrauchbar sein, wenn wichtige Bestandteile nie ausgewählt wurden. Deshalb beginnt die Praxis nicht mit dem Kopierprogramm, sondern mit einem Inventar.

Das Inventar nennt außerdem Eigentümer, Speicherort, Änderungsrate, Schutzbedarf und gewünschten Wiederherstellungsweg. Was dort fehlt, wird im Notfall meist auch nicht plötzlich aus der Sicherung erscheinen.

Vom möglichen Schaden rückwärts planen

Sicherungsintervall und Aufbewahrung hängen davon ab, wie viel Arbeit verloren gehen darf und wie schnell ein nutzbarer Zustand wieder vorhanden sein muss. Die strategischen Begriffe RPO und RTO werden auf backups.htm ausführlicher behandelt.

Voll-, inkrementelle und differenzielle Sicherung

Das schnellste Sicherungsverfahren ist nicht automatisch der schnellste Restore. Je länger eine Inkrementkette, desto mehr Medien, Dateien, Kataloge und fehlerfreie Zwischenschritte werden für die Rückholung benötigt.

Snapshot, Spiegelung und Synchronisation sind nicht automatisch Backup

Ein Snapshot friert einen Zustand innerhalb eines Speicher- oder Dateisystems ein. Eine Spiegelung hält zwei Systeme möglichst gleich. Synchronisation verteilt Änderungen auf weitere Geräte oder Dienste. Alle drei können Teil einer Sicherungsstrategie sein.

Medien: Disketten, Wechselplatten, Festplatten

Datensicherung hängt immer am Medium. Und Medien sind keine abstrakten Behälter, sondern reale, alternde, empfindliche Gegenstände mit eigenem Verhalten. Disketten waren dafür ein gutes Lehrstück. Man konnte mit ihnen geordnet arbeiten, aber nur dann, wenn man wusste, dass auch Magnetmedien nicht aus reiner Treue zur eigenen Mühe funktionieren. Kontaktflächen altern, Hüllen verformen sich, Laufwerke sind nicht immer sauber justiert, und eine Diskette, die gestern noch halbwegs wirkte, kann morgen schon unangenehm unlesbar sein.

Festplatten brachten größere Kapazität und andere Ruhe, aber keine grundsätzliche Unsterblichkeit. Ihr Vorteil lag im Alltag vor allem darin, konsistenter und schneller größere Datenmengen zu halten. Für echte Sicherung mussten Daten trotzdem aus dem laufenden Arbeitskontext heraus. Genau deshalb wurden Wechselmedien so wichtig: Wer eine Sicherung aus dem System entfernen kann, trennt Risiko und Arbeit überhaupt erst sauber voneinander.

Ordnung: Namen, Stände, Verzeichnisse

Ohne Ordnungslogik ist Datensicherung sehr schnell wertlos. Selbst mehrere funktionierende Sicherungsmedien helfen wenig, wenn niemand mehr erkennt, was dort eigentlich liegt. Für mich begann brauchbare Sicherung deshalb immer bei Namen und Strukturen. Dateinamen mussten eindeutig genug sein, Stände nachvollziehbar, Verzeichnisbäume ruhig und nicht mit wechselnden Gewohnheiten zugeschüttet.

Gerade bei längeren Arbeitsphasen ist die Versuchung groß, Sicherungen beiläufig anzulegen: hier eine Kopie, dort eine schnelle Umbenennung, daneben noch eine „neu“-Version. Genau daraus entsteht später die unangenehmste Fehlerlage: Das Material ist vorhanden, aber die Zuordnung nicht mehr sauber. Man verliert dann nicht Daten, sondern Klarheit. Das ist oft fast genauso schlimm.

Die ergänzende Redundanzseite dazu bleibt backups.htm. Datensicherung hängt direkt an derselben Denkweise.

Manifest: Was ein Sicherungssatz nachweisen sollte

Eine bloße Meldung „Backup erfolgreich“ ist zu wenig. Ein Satz sollte so dokumentiert sein, dass Herkunft, Umfang, Erstellungszeit und Prüfergebnis nachvollziehbar bleiben.

Getrennte Sicherungssätze und Rotation

Eine einzige Sicherung ist beruhigend, aber technisch dünn. Wirklich brauchbar wird Datensicherung erst, wenn mehrere Stände existieren und nicht alles permanent überschrieben wird. Gerade dabei hilft Rotation: verschiedene Sätze, unterschiedliche Zeitpunkte, nachvollziehbare Beschriftung, möglichst klare Trennung zwischen aktuell und älter.

Rotation bedeutet nicht automatisch komplizierte Theorie. Schon eine einfache Aufteilung in aktuelle Sicherung, vorherigen Stand und länger aufgehobenen Archivstand kann real viel Ruhe bringen. Entscheidend ist, dass nicht jede neue Sicherung blind den einzigen noch vorhandenen älteren Zustand vernichtet.

• aktueller Satz für den jüngsten Stand,
• vorheriger Satz als Rückfallebene,
• älterer Satz für gröbere Fehler oder verspätet bemerkte Beschädigungen.

Genau dort zeigt sich, dass Datensicherung Zeitstruktur braucht. Nicht jeder Fehler wird sofort entdeckt. Manche Beschädigung zieht sich erst später durch. Wer dann nur den letzten überschriebenen Stand hat, besitzt technisch gesehen fast nichts.

Aufbewahrung und kontrollierte Löschung

Aufbewahrung muss alte Fehler noch erreichbar machen, ohne jede Kopie unbegrenzt anzusammeln. Ein Plan verbindet Sicherungsfrequenz, Generationen, Schutzbedarf, Speicherbedarf und Löschregeln.

• Kurzfristige Stände: viele dichte Versionen für versehentliche Änderungen.
• Mittelfristige Stände: weniger, aber über Wochen oder Monate verteilte Rückfallpunkte.
• Langfristige Stände: bewusst ausgewählte Meilensteine oder rechtlich beziehungsweise historisch benötigte Bestände.
• Löschfreigabe: erst nach Ablauf der definierten Frist und ohne laufenden Vorfall.
• Vernichtung: sensible Datenträger und Schlüssel nicht nur aus dem Katalog entfernen.

Eine Aufbewahrungsregel verhindert sowohl das vorschnelle Überschreiben des einzigen guten Zustands als auch eine unkontrollierte Sammlung personenbezogener oder vertraulicher Altbestände.

3-2-1 als verständliche Mindestheuristik

Die bekannte 3-2-1-Regel fordert drei Kopien wichtiger Daten, zwei unterschiedliche Speicherarten und eine Kopie außerhalb des unmittelbaren Standorts. Sie ist kein Beweis für ein vollständiges Konzept, aber ein brauchbarer Gegencheck gegen eine einzige ständig angeschlossene Kopie.

Die strategische Einordnung dieser Regel bleibt auf backups.htm. In der Praxisakte zählt, wie jeder einzelne Satz erzeugt, geprüft und zurückgeholt wird.

Offline und unveränderlich gegen denselben Schadensweg

Eine ständig eingebundene Sicherung ist bequem, aber für Schadsoftware, kompromittierte Administratorkonten und Fehlbedienung oft ebenso erreichbar wie die Produktionsdaten.

„Offline“ und „unveränderlich“ sind nicht identisch. Ein offline gelagertes Medium kann nach dem erneuten Anschließen verändert werden; ein unveränderlicher Speicher kann weiterhin online erreichbar sein.

Verschlüsselung schützt die Kopie – der Schlüssel schützt den Restore

Außer Haus gelagerte oder transportierte Sicherungen können Vertraulichkeit benötigen. Verschlüsselung reduziert das Risiko bei Verlust des Mediums, erzeugt aber eine zusätzliche Abhängigkeit: Ohne Schlüssel oder Passphrase ist auch eine vollständig erhaltene Sicherung unbrauchbar.

• Schlüssel getrennt sichern: nicht ausschließlich im verschlüsselten Backup ablegen.
• Zugriff dokumentieren: berechtigte Personen und Notfallweg festlegen.
• Wiederherstellung testen: nicht nur Verschlüsselung, sondern Entschlüsselung mit der archivierten Anleitung prüfen.
• Rotation beachten: alte Sätze benötigen gegebenenfalls alte Schlüssel oder weiterhin kompatible Software.
• Geheimnisse minimieren: unnötige Zugangsdaten nicht wahllos in jeden Sicherungssatz kopieren.

Integritätsprüfung: lesbar ist nicht automatisch unverändert

Ein erfolgreicher Kopiervorgang und ein später noch mountbares Medium beweisen nicht, dass jede Datei unverändert und vollständig geblieben ist. Prüfsummen und Manifeste helfen, stille Veränderungen zu erkennen.

Ein Hash beweist Gleichheit zum Zeitpunkt der Vergleichsberechnung, aber nicht, dass die ursprüngliche Quelldatei fachlich richtig, vollständig oder frei von Schadsoftware war.

Dateikopie, absturzkonsistent und anwendungskonsistent

Geöffnete Datenbanken, Mailbestände, virtuelle Maschinen und Anwendungen können mehrere Dateien gleichzeitig verändern. Eine Kopie mitten in diesem Vorgang kann einzelne Dateien aus unterschiedlichen Zeitpunkten enthalten.

Für statische HTML-Dateien ist eine normale Dateisicherung oft ausreichend. Für Datenbanken, CMS oder laufende Dienste ist der vorgesehene Export- beziehungsweise Snapshotmechanismus der Anwendung maßgeblich.

Restore-Denken statt Blindvertrauen

Der technisch wichtigste Punkt wird erstaunlich oft ausgelassen: Ein Backup zählt nur dann, wenn sich daraus auch wirklich etwas zurückholen lässt. Restore ist deshalb nicht das späte Ende der Sicherung, sondern ihre eigentliche Bewährungsprobe. Wer nie testet, ob ein Medium lesbar, ein Stand vollständig und die Rückführung logisch sauber möglich ist, betreibt eher Hoffnung als Technik.

Gerade alte Medien lehren das besonders hart. Eine Sicherung kann formal vorhanden sein und trotzdem praktisch wertlos, wenn Dateisystemfehler, Leseschwächen, still beschädigte Blöcke oder schlicht unklare Verzeichnislage die Rückholung unangenehm unsicher machen. Deswegen gehört Probebackup immer auch mit Proberestore zusammen.

„Ein Backup, das nie zurückgelesen wurde, ist eher ein Versprechen als ein Beweis.“

Restore-Proben auf mehreren Ebenen

Eine Datei-Rückholung ist wichtig, beweist aber nicht automatisch, dass ein kompletter Webserver, eine Datenbank oder ein historischer Rechner wieder betriebsfähig wird.

Wiederherstellungsanweisung statt Gedächtnisprobe

Ein Restore-Runbook beschreibt den Ablauf so, dass er nicht nur von der Person durchgeführt werden kann, die den Sicherungsjob eingerichtet hat.

1. Schaden eingrenzen: Quelle stoppen und kompromittierten Zustand nicht weiter replizieren.
2. Ziel festlegen: saubere Ersatzumgebung oder getrennten Restore-Pfad bereitstellen.
3. Satz auswählen: letzten nachweislich guten Zustand anhand Manifest und Vorfallzeit bestimmen.
4. Werkzeuge beschaffen: Laufwerk, Backupsoftware, Schlüssel, Passwörter, Installationsmedien und Dokumentation.
5. Reihenfolge einhalten: Basissystem, Konfiguration, Anwendung, Daten, Rechte und öffentliche Freigabe.
6. Validieren: Integrität, Funktion, Berechtigungen und fachliche Plausibilität prüfen.
7. Dokumentieren: verwendeter Satz, Dauer, Abweichungen und neue Sicherung nach Wiederanlauf.

Das Runbook gehört selbst in einen getrennt erreichbaren Sicherungssatz. Eine Anleitung, die ausschließlich auf dem ausgefallenen Server liegt, hilft im Ernstfall nicht.

SyQuest und Wechselmedien im Alltag

Wechselmedien waren für mich nie Sammlerromantik, sondern geordnete Arbeitsmittel. Gerade SyQuest war in diesem Zusammenhang interessant, weil diese Medien den Gedanken der physischen Trennung ernsthaft in den Alltag brachten. Ein laufendes System konnte mit einem Wechselmedium Sicherungs- oder Projektstände auslagern, sauber trennen und im Problemfall zügig auf einen anderen Satz umschwenken.

Der große praktische Vorteil lag nicht nur im Volumen, sondern in der Denkweise dahinter: Medium raus, Medium beschriften, Medium separat lagern, bei Bedarf gezielt wieder einlegen. Das ist nüchterner und oft sicherer als die diffuse Hoffnung, eine einzige ständig angeschlossene Platte werde alle Probleme schon irgendwie abfangen.

Natürlich waren auch Wechselmedien nicht frei von Fehlerlagen. Kontaktflächen, Mechanik, Gehäusequalität, Laufwerkszustand und das Verhalten einzelner Cartridge-Sätze spielten real hinein. Gerade deshalb war disziplinierte Behandlung wichtig: keine grobe Mischung verschiedener Zustände, keine schlampige Lagerung, keine blinde Annahme, dass ein altes Medium aus Respekt vor seiner eigenen Geschichte automatisch lesbar bleibt.

Die große Mediumsseite dazu bleibt syquest.htm. Für Datensicherung ist sie nicht nur Randthema, sondern Kern.

Backups für Webseiten und Textbestände

Bei Webseiten wirkt Datensicherung zunächst einfacher als bei binären Spezialdateien. HTML, CSS, Skripte und Texte sind meist klarer lesbar, kleiner und vergleichbarer. Gerade das darf aber nicht in Selbstzufriedenheit führen. Auch hier gibt es falsche Stände, Überschreibungen, halbfertige Bearbeitungen, versehentlich entfernte Blöcke und das Problem, dass ein „neuester“ Stand nicht automatisch der beste oder vollständigste ist.

Für statische Webseiten liegt ein Vorteil in ihrer Transparenz. Man kann einzelne Dateien sichern, vergleichen, archivieren und bei Bedarf gezielt zurückholen. Das funktioniert aber nur gut, wenn Dateistruktur und Benennung konsequent bleiben. Wer selbst in Textbeständen chaotisch arbeitet, macht sich die Wiederherstellung unnötig unangenehm.

Genau deshalb gilt auch hier: Ein sauberer älterer Stand ist oft wertvoller als ein vermeintlich „neuer“ Zustand, der zwar frisch, aber bereits beschädigt oder unangenehm unvollständig ist.

Was zu einer vollständigen Website-Sicherung gehört

Bei einer handgeschriebenen Website liegt der Vorteil in klaren Dateien. Trotzdem reicht es nicht, nur die sichtbaren HTML-Seiten zu kopieren.

Typische Fehler bei Datensicherung

Die unangenehmsten Fehler sind selten spektakulär. Meist beginnen sie klein: ein Medium wird nicht mehr geprüft, eine Beschriftung bleibt vage, ein Satz wird vorschnell überschrieben, zwei ähnliche Versionen werden verwechselt, ein Restore wurde nie ernsthaft geprobt. Genau daraus entstehen im Ernstfall die großen Lücken.

Jobprotokolle, Alarme und stille Fehler

Automatisierung hilft nur, wenn Fehlschläge sichtbar werden. Ein jahrelang laufender Zeitplan kann nutzlos sein, wenn Zielmedium voll, Zugang abgelaufen oder eine Quelle unbemerkt ausgeschlossen wurde.

• Laufstatus: Beginn, Ende, Dauer und Exitstatus aufzeichnen.
• Datenmenge: ungewöhnlich kleine oder große Läufe als Abweichung melden.
• Quelle: nicht erreichbare Volumes und ausgelassene Pfade klar auflisten.
• Ziel: freier Speicher, Medienzustand und Schreibschutz prüfen.
• Alter: Zeit seit letzter erfolgreicher Voll- und letzter geprüfter Sicherung überwachen.
• Restore-Test: nicht nur Joblauf, sondern auch letzte erfolgreiche Rückholung terminieren.

Ein Alarm muss an einem Ort ankommen, der nicht vom selben ausgefallenen System abhängt. Ein Fehlerbericht ausschließlich auf dem nicht gesicherten Server ist keine verlässliche Überwachung.

Ransomware: Sicherungen können selbst Ziel des Angriffs sein

Moderne Erpressungssoftware und kompromittierte Administratorkonten suchen häufig gezielt nach erreichbaren Sicherungen. Deshalb zählt nicht nur, ob Kopien existieren, sondern ob der Angriffsweg sie verändern, verschlüsseln oder löschen kann.

• Getrennte Berechtigungen: Produktionskonto darf Sicherungsbestände nicht beliebig verwalten.
• Offline-/unveränderliche Kopie: mindestens ein belastbarer Satz außerhalb desselben Schreibpfads.
• Mehrere Zeitstände: schleichende Kompromittierung kann bereits in jüngeren Sicherungen enthalten sein.
• Saubere Wiederherstellungsumgebung: kompromittierte Systeme nicht einfach über einen guten Satz schreiben.
• Schadenszeit bestimmen: Restore-Punkt vor der nachweislichen Kompromittierung wählen.

Wiederanlauf nach einem Vorfall

Bei einem echten Vorfall wird nicht zuerst hektisch zurückkopiert. Zunächst müssen Ursache, Ausbreitung und letzter vertrauenswürdiger Zustand so weit wie möglich eingegrenzt werden.

1. Beweise erhalten: relevante Logs, Zeitpunkte und betroffene Systeme dokumentieren.
2. Angriffsweg schließen: Zugangsdaten, Schwachstelle oder Fehlkonfiguration vor öffentlichem Wiederanlauf behandeln.
3. Saubere Basis schaffen: neues oder verifiziertes System statt ungeprüfter Weiterbetrieb.
4. Guten Satz auswählen: Manifest, Zeitlinie und Restore-Proben heranziehen.
5. Schlüssel erneuern: kompromittierte Passwörter, Token und Zertifikate nicht unverändert zurückbringen.
6. Stufenweise freigeben: Funktion und Sicherheit vor externer Erreichbarkeit prüfen.

Medienpflege, Beschriftung und Lagerung

Wechselmedien schützen nur, wenn Medium, Laufwerk und Zuordnung erhalten bleiben. Etiketten, Hüllen und Lagerort sind Teil des technischen Systems.

• eindeutig beschriften: Satz-ID, Datum, Mediumfolge und Schutzstufe.
• Umgebung beachten: Hitze, Feuchte, Staub, Magnetfelder und mechanische Belastung vermeiden.
• Schreibschutz verwenden: wo das Medium eine belastbare Sperre bietet.
• Laufwerk erhalten: Lesegerät, Kabel, Terminierung, Treiber und Schnittstelle mitdenken.
• regelmäßig lesen: Stichprobe oder vollständige Prüfung nach Risiko und Alter.
• Fehler nicht „wegprobieren“: alternde Medien zuerst schonend als Image sichern.

Für SyQuest gilt das auf syquest.htm ausführlicher. Hier ist entscheidend, dass ein Medium ohne funktionierenden Leser und dokumentierte Schnittstelle keinen vollständigen Restore-Pfad bildet.

Medien- und Formatmigration vor dem Ausfall

Langfristige Lesbarkeit entsteht nicht dadurch, dass ein Medium möglichst lange unangetastet bleibt. Schnittstellen, Laufwerke, Dateisysteme und Software können früher verschwinden als die magnetischen oder optischen Daten selbst.

1. Altbestand lesen: bevorzugt mit bekannt gutem Laufwerk und schreibgeschützt.
2. Rohabbild erzeugen: bei historischen Datenträgern neben extrahierten Dateien auch Image sichern.
3. Prüfsumme bilden: Übertragungsweg und spätere Fixity kontrollierbar machen.
4. Metadaten erhalten: Medium, Format, Geometrie, Dateisystem und Lesewerkzeug dokumentieren.
5. neuen Satz prüfen: nicht nur kopieren, sondern aus dem Zielmedium wieder lesen.
6. Original bewahren: Migration ersetzt die Quellhistorie nicht automatisch.

Bei proprietären Backupformaten gehört die notwendige Softwareversion ebenfalls zur Migration. Ein Container ohne kompatiblen Leser ist nur scheinbar modernisiert.

Archivierung ist nicht dasselbe wie Backup

Archivierung und Datensicherung werden oft durcheinandergeworfen. Technisch sind es aber zwei verschiedene Dinge. Backup zielt auf Wiederherstellung eines nutzbaren Zustands nach Verlust oder Beschädigung. Archivierung zielt darauf, bestimmte Stände, Dokumente oder Artefakte langfristig geordnet zu erhalten – auch dann, wenn sie nicht mehr im täglichen Betrieb gebraucht werden.

Gerade im SSLXY-Kontext ist dieser Unterschied wichtig. Ein altes Gerätedokument, ein historischer HTML-Stand, eine frühe Beschreibung, eine technische Notiz oder ein bestimmter Dateisatz kann archivwürdig sein, ohne deshalb der laufende Rückfallstand für aktuelle Arbeit zu sein. Umgekehrt kann eine reine Sicherung für den Alltag wichtig sein, ohne später historisch bedeutsam zu werden.

Die größere Archivseite dazu bleibt the-vault.htm. Dort verschiebt sich der Schwerpunkt von Rückholbarkeit stärker in Richtung Erhalt und dokumentierter Spur.

Datenschutz, Berechtigungen und Datenminimierung

Sicherungen vervielfachen Daten und verlängern ihre Verfügbarkeit. Deshalb müssen Zugriffsrechte, Aufbewahrung und Löschung auch für Backupbestände geregelt sein.

• Schutzbedarf übernehmen: eine Sicherung personenbezogener Daten bleibt personenbezogen.
• Zugriff begrenzen: Backupadministration nicht unnötig mit allgemeiner Systemadministration gleichsetzen.
• Testdaten schützen: Restore-Umgebungen dürfen vertrauliche Bestände nicht offen zugänglich machen.
• Aufbewahrung begrenzen: alte Sätze nach definierten Regeln löschen oder sicher vernichten.
• Transport sichern: außer Haus gelagerte Medien gegen Verlust und Einsicht schützen.

Diese Seite gibt technische Grundsätze wieder und ersetzt keine rechtliche oder organisatorische Prüfung eines konkreten Betriebs.

Technische Referenzen

Die modernen Sicherungs-, Notfall- und Erhaltungsabschnitte orientieren sich an behördlichen Leitlinien. Persönliche Aussagen zu Disketten, SyQuest, Verzeichnisordnung und Arbeitsweise bleiben als eigene Erfahrung gekennzeichnet.

Kein einzelnes Regelwerk ersetzt die Auswahl nach tatsächlichem Datenbestand, Schutzbedarf und Wiederherstellungsziel.

Fazit

Datensicherung ist keine sentimentale Geste gegenüber wichtigen Dateien. Sie ist geordnete Technik. Wer sie ernst nimmt, denkt in Medien, Trennung, Zeitständen, Lesbarkeit und Wiederherstellung. Wer sie unterschätzt, merkt das oft erst im unangenehmsten Moment.

Für mich war Backup deshalb immer eng mit derselben Ruhe verbunden wie gute Hardware- oder Codepflege: nicht laut, nicht dekorativ, nicht aufgeregt. Einfach sauber. Ein brauchbares Sicherungssystem fällt im besten Fall kaum auf. Es trägt nur still im Hintergrund – bis es einmal gebraucht wird. Dann zeigt sich, ob es wirklich eins war.

„Gesichert ist etwas erst dann, wenn ich es geordnet wiederbekomme – nicht dann, wenn ich glaube, es irgendwo doppelt zu haben.“

Die ergänzende Redundanzseite bleibt backups.htm, die Medienseite syquest.htm und die Archivseite the-vault.htm.

Querverweise im SSLXY-Archiv

Diese Datei gehört zu den Sicherungs-, Archiv-, Medien- und Ordnungsseiten im sslxy-Bereich.

• Zur SSLXY-Hauptseite
• Backups, Redundanz und Wiederherstellung
• SyQuest-Wechselmedien
• The Vault – langfristige Archivierung
• Laufwerke und Diskettenstationen
• Server-Härtung und Notfallvorsorge
• Software- und Werkzeugalltag