Diskussion:Datensicherung

Neue Seiten bitte in Datensicherung: Seiten eintragen, verschobene Seiten nachtragen!

---

Hinweis

• Datenbanken gehören ebenfalls zu den Daten, man besser sichert. (Backup- und Restore-Prozeduren im jeweiligen Datenbank-Handbuch nachlesen)
• Versionsverwaltungssysteme (CVS, SVN) erlauben Sicherungen von Quelltexten und Konfigurationsdateien - bspw. im Falle von Fehlkonfigurationen (Hier ist die Datenbank des Versionsverwaltungssystems mit in die Liste der zu sichernden Daten einzutragen)

-- Benutzer:ThePacker 03:14, 13. Aug. 2008

Versionsverwaltungstools

Auch @ThePacker:

Versionsverwaltungssysteme eignen sich allerdings auch für Nicht-Textdaten teilweise hervorragend als (u.U. sogar verteiltes (!)) Backup-System, oder zumindest als "Kritikalitäts-Dämpfer" bei einem Datenverlust. Plus: Man hat noch die Vorteile, die sich bei einem solchen System ergeben wie

• Daten auf verschiedenen Rechnern relativ einfach synchron halten
• Man hat die komplette Versionsgeschichte jeder Datei (Speicherplatz ist heute relativ günstig, d.h. wenn ich 50 Versionen einer Binärdatei habe, die aufgrund der Eigenschaften mancher Binärformate - schlechte Diff- und Komprimierbarkeit - *relativ* viel Platz einnehmen, tut das auch nicht viel mehr weh, als wenn ich eine Version davon habe [hängt natürlich auch alles von der Größe der Dateien ab, klar - CD-Images zu versionieren wäre ziemlicher Schwachsinn])

Mit "Kritikalitäts-Dämpfer" meine ich im Übrigen: Angenommen man hat einen Server S mit dem Repository und 3 Client-PCs C_i, davon ist einer ein mobiles Notebook, einer im Büro und einer zu Hause (d.h. man hat bereits einen auf verschiedene Orte verteilten Storage-Pool).

Wenn man sich bemüht, die ausgecheckten Daten auf den verschiedenen Clients möglichst immer synchron zu halten, kann man ohne Probleme den Ausfall eines bis aller dieser Rechner C_i verkraften: Der Server ist ja noch da. Trifft es den Server S mit einem Ausfall, hat man zwar das Problem, dass die Versionsgeschichte futsch ist, aber man kann zumindest den aktuellen Stand ohne Probleme wieder herstellen, indem man ein neues Repository auf einem neuen Server (bzw. einer *neuen*, hoffentlich ausfallunfreudigeren Festplatte des Servers) mit den Daten von dem Client C_j erstellt, der den aktuellsten Stand an Dateien hatte.

Die meisten "normalen" User werden sowieso noch nie mit Versionierung gearbeitet haben, somit ist für sie der Wegfall der Versionsgeschichte im "worst case" (Server ausgefallen) irrelevant. Sollte sich doch jemand dafür interessieren, muss er halt bei klassischen Versionierungs-Tools daran denken, das Server-Repository zu backuppen. Man könnte meinen, damit wieder am Anfang des Problems zu sein - aber nein, dem ist nicht so: Gegenüber einem User, der blind auf seine Primärdaten plus bestenfalls noch ein 1 Jahr altes Backup vertraut, ist das doch schon ein gehöriger Vorteil ;).

Es gibt im Übrigen auch Versionierungstools (ich glaube, auf Git trifft das z.B. zu, auch wenn ich es noch nicht so richtig durchblickt habe), die auf *jedem* Client-PC eine Kopie des kompletten Repositories vorhalten (auch aus Caching-Gründen), sprich virtuell wird jeder Client gleichzeitig zum Server - bzw. das Client-Server-Modell greift hier nicht mehr.

So oder so: Ich bin gerade dabei, alle meine wichtigen Benutzerdaten in ein SVN-Repository zu bringen. Jemand anderes hat das auch schon mal gemacht und online beschrieben: [1]. Man sollte aber insbesondere als Windows-User darauf achten, dass Subversion auch wieder einige Probleme mit sich bringt, da es aus der Unix-Welt stammt (zum Glück nur kleinere), z.B. werden die aktuellen Datumsangaben der Dateien nicht mitgesichert*), v.a. das CreatedDate unter Windows nicht (das nervt mich etwas, weil es meinen "First Import" gerade ziemlich kompliziert macht). Für viele Menschen sind diese neuen Flaws aber wahrscheinlich irrelevant.

_*) Genauer: Jeder Commit ins Repository erhält zwar einen Timestamp, allerdings repräsentiert ein Commit nicht eine Datei. D.h.: Wenn ich eine Datei am 01.12. ändere und am 02.12. erst committe, steht im Repository hinterher nur das Commit- nicht das letzte Änderungsdatum. Genauso, wenn ich eine Datei am 11.11. erstellt habe, und mich erst jetzt (02.12.) entscheide, sie wirklich ins Repository hinzuzufügen: Im Repository sieht es dann so aus, als wäre die Datei am 02.12. "erstellt" (bzw. geaddet) worden, sprich die "11.11. created"-Information geht verloren.

--Red*Star 20:30, 2. Dez. 2010 (CET)

Ich habe nicht behauptet, dass man keine Binärdateien "versionieren" kann. Aber bekannt ist, dass SVN nicht sehr effizient bei der Versionierung von Binärdateien ist. Dazu ist der interne Diff-Algorithmus nicht optimiert. Ich sehe zu meiner obigen Aussage keinen Widerspruch und ich selbst nutze Subversion seit 2002. Mich brauchst Du von der Qualität nicht überzeugen, Du rennst nur unnötig offene Türen ein. Ich persönlich spiele jedoch langsam mit dem Gedanken, ein Versionsverwaltungssystem der 3. Generation zu benutzen, doch der Leidensdruck ist noch nicht besonders hoch, auf ein schlechter unterstütztes System umzusteigen. (Linux, Windows, Cygwin und Solaris müssen vernünftig unterstützt werden. 'Ne ordentliche GUI (Windowsintegration in den Explorer) und ein Eclipse-Plugin sind meine Anforderungen.) -- ThePacker 21:16, 2. Dez. 2010 (CET)

Eigentlich war mein Diskussionsbeitrag auch eher dazu gedacht, noch einmal genauer zu erläutern, was man mit Versionsverwaltungsprogrammen in Hinsicht auf Backups anfangen kann - mit der Intention, dass evtl. mal jemand Zeit findet, das in "schöner" Form in das Buch zu integrieren.

Ein Widerspruch zu deinem Beitrag zu erzeugen, lag demnach auch nicht in meiner Absicht - aber du hast dich in deinem Kommentar halt auf Text-Dateien beschränkt, das wollte ich lediglich etwas ausführen, bevor jemand denkt, dass man *nur* Textdateien versionieren kann. Obendrein ging aus deinem Beitrag so unmittelbar nur hervor, dass man das Repository *zusätzlich* sichern muss, nicht, dass man das Repository bereits als Backup-ähnliche, Redundanz bereitstellende Entität ansehen kann ;-). (Wenn man besagtes Versionshistorie-Problem ignoriert.) --Red*Star 00:35, 6. Dez. 2010 (CET)

Zielgruppe

"Alle Computer-Benutzer, vor allem die mit einem oder wenigen Computern". Das kann man so nun wirklich nicht sagen, da sich das Buch ausschließlich mit Windows beschäftigt. Mit etwas Zeit sollte man einen Abschnitt über Unix-typische Abläufe und Tools zur Datensicherung hinzufügen, oder, falls das nicht gewünscht ist die Zielgruppe anpassen. -- Usr 001 14:56, 17. Jul. 2009 (CEST)

Da hast du natürlich recht. Ich werde wohl ein eine Gliederung für Linux entwerfen, vielleicht findet sich jemand, der etwas dazu schreibt. -- Klaus 16:32, 17. Jul. 2009 (CEST)

Die Gliederung für Linux habe ich entworfen. Eineinhalb Jahre sind vergangen und kein Linux-Fan hat etwas geschrieben. Ich nehme die Gliederung wieder raus, denn ein (fast) fertiges Buch sollte keine roten Links enthalten. -- Klaus 22:11, 2. Dez. 2010 (CET)

Eisen ätzt nicht

Hallo Klaus, ich habe dein Buch gelesen. Der Abschnitt mit der "Datenbeständigkeit" könnte noch mal überarbeitet werden. Siehe hier w:Eisengallustinte. Ausserdem war Papier bis in die 80er hergestellt worden, ohne zu beachten, das der PH-Wert zu hoch lag. Deshalb ist das darauf Geschriebene dem schnelleren Verfall preisgegeben. Heutzutage ist so gut wie jedes Blatt Papier, das man im Laden kaufen kann, Säurefrei. Grüße --Svon 13:02, 26. Feb. 2009 (CET)

Vielen Dank!

Ein sehr hilfreiches und wunderbares Buch! Vor allem das grundsätzliche Anliegen, das Bewusstsein für die Notwendigkeit von Datensicherung zu schärfen, wird hier konsequent und eindringlich verfolgt. Man sollte diese Lektüre generell empfehlen! -- WernerPopken 01:22, 18. Mai 2010 (CEST)