Datensicherung/ Beispiel/ Dokumente stündlich sichern

Dokumente stündlich sichern

Bearbeiten

Dieses Kapitel baut auf dem vorhergehenden Kapitel Texte täglich sichern auf, dort ist auch die Grundidee erläutert.

Ist das nicht übertrieben?

Bearbeiten

Wenn Sie den ganzen Tag intensiv an Ihren Dokumenten arbeiten, kann eine täglich einmalige Sicherung zu wenig sein. Stellen Sie sich vor, kurz vor Feierabend geht eine Datei verloren, an der Sie den ganzen Tag gearbeitet haben. Wenn Sie nur die Vortagsversion haben, ist ein Arbeitstag verloren.

Das hier beschriebene Verfahren ermöglicht eine Sicherung mehrmals am Tag, maximal stündlich. Sie können im Scheduler eine geringere Häufigkeit programmieren, zum Beispiel alle zwei oder vier Stunden.

Diesmal verwenden wir statt %date% die Systemvariable %time%, aus der die Stunde herausgeschnitten wird. Jedes Sicherungsverzeichnis wird am nächsten Tag von der neuen Version überschrieben. Wenn Sie einen Schaden nicht innerhalb von 24 Stunden feststellen, haben Sie hoffentlich das im vorherigen Kapitel beschriebene Backup Texte täglich sichern sowie die Datensicherungen der vorhergehenden Wochen und Monate, die nach dem Drei-Generationen-Prinzip regelmäßig durchgeführt werden.

Ein Experiment

Bearbeiten

Öffnen Sie die Eingabeaufforderung: Start - Ausführen - cmd - OK. Tippen Sie den folgenden Befehl ein, gefolgt von Enter:

time

Sie erhalten eine Meldung, die etwa so aussieht:

Aktuelle Zeit: 13:23:57,34
Geben Sie die neue Zeit ein:

Sie könnten jetzt die genaue Uhrzeit eingeben oder einfach Enter drücken.

Tippen Sie jetzt ein

echo  %time%

liefert

13:23:57,34

Wir brauchen nur die ersten beiden Ziffern. Probieren Sie:

echo  %time:~0,2%

Der Befehl gibt die Nummer der aktuellen Stunde als zweistellige Zahl auf den Bildschirm aus.

Die Ausführung

Bearbeiten

Um die zu kopierende Datenmenge gering zu halten, werden nur Dateien kopiert, die in den letzten beiden Tagen erstellt oder verändert worden sind (maxage:2). Für den hier genannten Verwendungszweck kann man die Daten auf eine andere Partition der gleichen Festplatte kopieren, im Beispiel nach Laufwerk e:

robocopy c:\  e:\Stunde_%time:~0,2%\  *.doc *.rtf *.txt *.xls /mir /maxage:2 /w:1 /r:1

erzeugt je nach Uhrzeit auf Laufwerk e: die Verzeichnisse Stunde_00 bis Stunde_23. Dahinein werden alle .doc, .rtf, .txt und .xls Dateien kopiert, die maximal 2 Tage alt sind. Ändern Sie die Liste der Dateitypen nach ihren Bedürfnissen.

Erstellen Sie eine Stapeldatei mit diesem Befehl als einzigen Befehl oder ergänzen Sie weitere Befehle für andere Laufwerke. Lassen sie dieses Programm vom Scheduler stündlich ausführen. Natürlich können Sie den Scheduler so einrichten, dass er um 08:00 beginnt und nach 10 Stunden mit den Sicherungen aufhört. Dann entstehen nur zehn oder elf Verzeichnisse, von 08 bis 18.

Noch häufigere Sicherungen

Bearbeiten
robocopy c:\  e:\Minute_%time:~3,1%0\  *.doc *.rtf *.txt *.xls /mir /maxage:1 /w:1 /r:1

wechselt alle 10 Minuten zu einem neuen Sicherungsverzeichnis, und

robocopy c:\  e:\Minute_%time:~3,2%\  *.doc *.rtf *.txt *.xls /mir /maxage:1 /w:1 /r:1

legt für jede Minute ein neues Sicherungsverzeichnis an. Ein vorhandenes Verzeichnis wird überschrieben.

Sollte man niemals auf diese automatischen Zwischensicherungen zugreifen müssen, desto besser. Das ist das Prinzip der Datensicherung. Was man nicht hat, auf das kann man nicht zurückgreifen. Und all der Aufwand wird nur getrieben für den Fall, dass Datenverluste auftreten. Wie bei einer Versicherung darf man sich freuen, wenn man die Gegenleistung für die ständig gezahlten Prämien niemals in Anspruch nehmen muss. Im Gegensatz dazu ist der Aufwand hier extrem gering; sowohl die Einrichtung als auch der Platzverbrauch und der laufende Energieeinsatz der Maschine - die muss ja schließlich was tun, aber den zusätzlichen Energieverbrauch kann man vermutlich nicht beziffern.

(Siehe auch Werkzeuge / Regelmäßige Ausführung planen / Ausführung unsichtbar machen - je häufiger die Sicherung erfolgt, desto notwendiger erscheint diese Maßnahme)

Beispiele

Bearbeiten

In der Buchhaltung kann man sich sehr leicht vertun und möchte dann vielleicht gerne auf einen früheren Stand zurückwechseln; das ist unter Umständen mit dem Buchhaltungsprogramm gar nicht vorgesehen - mit dieser Methode ist das sehr einfach möglich. Ganz allgemein kann man mit dieser Methode jedes beliebige Programm mit einer Versionierung versehen; dazu muss man nur die Verzeichnisse, in denen die Daten dieses Programms gesichert werden, in die Batch-Datei aufnehmen.

Programmierer können bei komplexen Systemen durch Fehler in Schwierigkeiten kommen, deren Ursache sich nicht leicht finden lässt. Man kann ja immerhin froh sein, dass der Fehler sich gezeigt hat - schlimmer sind Fehler, die unentdeckt bleiben. Wenn der Fehler schon sehr lange unentdeckt war, kann man auf länger zurückliegende Sicherungen zurückgreifen. Was aber, wenn erst vor wenigen Minuten noch alles in Ordnung war? Die Suche nach dem Fehler kann sich zeitaufwändiger gestalten, als einem lieb ist - schließlich möchte man vorankommen. Unfertige Zwischenzustände werden durch Versionskontrollsysteme typischerweise nicht erfasst, da diese nicht automatisch angelegt werden, sondern durch Entschluss des Programmierers, der meint, einen fehlerfreien Zwischenzustand erreicht zu haben; diese Intervalle können sehr unterschiedlich lang sein. Die Versionskontrolle hilft hier also nicht weiter.

Von einer automatischen Sicherung der Arbeit kann bei Versionskontrollsystemen ohnehin keine Rede sein, da sie immer von der Auslösung durch den Programmierer abhängig ist. Ein Zurückgehen auf die letzte erfasste Version würde die gesamte Arbeit der Zwischenzeit vernichten. Die letzte zurückliegende, automatisch angelegte stündliche Sicherung würde natürlich ebenfalls die Arbeit der seither verflossenen Zeit vernichten und sich also nur dann lohnen, wenn die Suche nach dem Fehler länger als die seither verflossene Zeit dauern würde, was man natürlich nicht absehen kann. Je mehr Zeit vergangen ist, desto mehr Arbeit würde man also verlieren. (Nach Murphys Gesetz tritt ein solcher undurchsichtiger Fehler natürlich immer kurz vor der nächsten automatischen Sicherung auf.)

Die für die Programmierung verwendeten Editoren speichern üblicherweise den aktuellen Stand zwar automatisch in jeder Minute, überschreiben aber jeweils alle vorherigen Zustände, legen also keine Versionsgeschichte an. Höchstwahrscheinlich ist also die letzte gespeicherte Fassung bereits mit diesem Fehler behaftet und hilft daher ebenfalls nicht weiter. Diese Sicherung ist auch lediglich als Schutz gegen Programmabstürze gedacht, diese Eigenschaft stellt also an sich keinen Mangel dar.

Mit der oben geschilderten Methode ist es leicht möglich, pro Minute automatisch einen Zwischenzustand zu speichern und diese Sicherungen nach einem vernünftigen Zyklus dann wieder zu überschreiben, also etwa alle 10 min oder alle 30 min oder alle 60 min etc. Im Falle einer undurchsichtigen und schwierigen Fehlersuche kann es dann sehr hilfreich sein, auf beliebige Zwischenstufen beliebiger Programmdateien zurückgreifen zu können: So kann man schnell den Zeitpunkt eingrenzen, an dem der Fehler eingebaut worden war. Wenn man Glück hat, zeigt der Debugger an dieser Stelle sogar direkt auf die Zeile, in der der Fehler gemacht wurde. Anschließend kann man dann wieder auf die aktuelle Fassung zurückgehen und den Fehler an der gefundenen Stelle beseitigen.

Der Typ der Dateien würde in diesem Fall natürlich *.php *.css *.js *.h *.c *.c++ *.cpp *.java usw. lauten müssen. Alle die zu sichernden Dateien befinden sich normalerweise an einer wohldefinierten Stelle und der Umfang hält sich in vernünftigen Grenzen, so dass die Zwischensicherung in wenigen Sekunden erledigt ist und den Rechner in keiner Weise belastet.

Auch für Autoren könnte sich ein solches System bezahlt machen. Bekanntlich entwickeln sich die Formulierungen beim Schreiben beziehungsweise Denken, und zuweilen löscht man Formulierungen, die man später gerne zumindest wiedersehen möchte, um sie eventuell im Original zu verwenden oder umzuformulieren.

In einigen Textverarbeitungen kann man dazu eine automatische Protokollierung einstellen, die nicht nur sämtliche Zwischenzustände festhält, sondern auch noch den jeweiligen Autor vermerkt, falls mehrere Autoren dasselbe Dokument bearbeiten. Sollte die Textverarbeitung aus welchen Gründen auch immer abstürzen, darf man sich freuen, wenn diese auf eine automatisch angelegte Zwischensicherung zurückgreift. Das ist nicht immer der Fall. Vielen Benutzern der Textverarbeitung sind diese Möglichkeiten auch gar nicht bekannt. Wer entsprechende Datenverluste schon erlitten hat und deshalb empfindlich geworden ist, hat sich vielleicht angewöhnt, ständig zwischenzusichern - damit wird zwar die letzte Version festgehalten, aber nicht die Zwischenzustände, es sei denn man speichert jeweils unter einem neuen Namen. Auf jeden Fall hat man damit zwar eine Sicherung, aber eine, die von manuellem Eingreifen abhängt, keine automatische Sicherung, die wirklich sicher ist. Statt sich beruhigt auf die Arbeit konzentrieren zu können, lauert im Hintergrund ständig die Angst vor Datenverlusten und nötigt zur Unterbrechung der Arbeit zwecks Sicherung. Keine angenehme Situation.

Ich persönlich (Werner) benutze seit mittlerweile 17 Jahren ein Diktiersystem in den jeweils aktuellen Varianten. Dabei diktiere ich längere Texte in die Spezialanwendung des Diktiersystems, kürzere in die Anwendungen selbst, zum Beispiel hier in das Bearbeitungsfenster. Dabei habe ich bei der Spezialanwendung immer wieder fürchterliche Datenverluste erlitten, weil in manchen Versionen unter nicht geklärten Umständen das System plötzlich ausstieg. Ich empfand es als außerordentlich unangenehm, die zuvor entwickelten Gedanken noch einmal neu entwickeln zu müssen. Ob die zweite Fassung dann genauso gut, besser oder schlechter als die erste geworden ist, konnte ich natürlich nicht feststellen.

Eine automatische Zwischensicherung kennt dieses System nicht; je größer ein Datenverlust war und je kürzer dieser zurücklag, desto größer die Angst vor weiteren Datenverlusten und je häufiger die oben geschilderte manuelle Zwischensicherung, mit der Folge, dass diese Aufmerksamkeit bei fehlenden weiteren Abstürzen nachließ und dann eventuell wieder zu ganz empfindlichen Verlusten führte. Einfach fürchterlich. Mit Hilfe der hier geschilderten Technik bekommt man nicht nur eine automatische Zwischensicherung pro Minute, sondern sogar ein Versionierungsystem.

Schließlich könnte ein solches Versionierungsystem auch für die Bildbearbeitung interessant sein. Wenn man sehr intensiv vorhandene Vorlagen manipuliert, kann sich das über lange Zeiträume hinziehen mit sehr unterschiedlichen Ergebnissen, die nicht leicht miteinander in Beziehung zu setzen sind. Insbesondere ist es nicht ganz einfach, zu entscheiden, welche Version die bessere ist. Dazu muss man die unterschiedlichen Versionen festhalten und anschließend miteinander vergleichen, indem man sie nebeneinander legt oder hin und her schaltet und dann gegebenenfalls in einem wiederum langwierigen Prozess die brauchbaren von den unbrauchbaren Varianten scheidet.

Natürlich würde man Zwischenergebnisse, die man für brauchbar hält, manuell unter einem neuen Namen sichern. Diese Entscheidung des Bearbeiters kann aber möglicherweise zu spät kommen. Mit Hilfe der History des Bildbearbeitungsprogramms kann man zwar auf vorherige Zustände zurückwechseln, aber normalerweise nur den letzten zurückgenommenen Bearbeitungsschritt wiederholen. Eine automatische Versionskontrolle könnte Material festhalten, für das man später einmal dankbar ist.

Soweit Beispiele aus meiner eigenen Arbeitswelt; wer durch diese Beispiele Parallelen zu seiner eigenen Arbeitswelt ziehen kann, wird vielleicht weitere Beispiele nennen können.

Optimierung

Bearbeiten

Wenn man zur Erhöhung der Generationssicherheit sowohl minütlich als auch stündlich als auch täglich sichert und zwar immer dieselben Verzeichnisse, kann man sich die Arbeit wie folgt erleichtern:

  • In einer allgemeinen Steuerdatei wird festgelegt, welche Verzeichnisse wohin gesichert werden sollen. Der Rhythmus wird dabei aus einer Variablen übernommen, die von den speziellen Steuerdateien gesetzt wird. Wenn Änderungen anfallen, müssen diese nur in dieser Datei geändert werden.
  • In den speziellen Steuerdateien wird der Rhythmus festgelegt und das davon abhängige Unterverzeichnis. Die eigentlichen Angaben, was wohin gesichert werden soll, werden aus der allgemeinen Steuerdatei entnommen. Diese speziellen Steuerdateien müssen nie wieder bearbeitet werden.

Beispiel

Bearbeiten

Die allgemeine Steuerdatei heiße bak_interval.bat; mit der Variablen bak wird der Teil des Verzeichnisnamens bezeichnet, der als Schlüsselverzeichnis im Backup auftauchen soll, damit man dieses dort leicht wiederfindet; das Ursprungsverzeichnis kann bekanntlich beliebig geschachtelt und somit sehr unübersichtlich sein.

Diese Variable muss pro Verzeichnis gesetzt werden und außerdem das Ursprungsverzeichnis, das aber als Formel automatisch erzeugt wird. Beim Ursprungsverzeichnis kann die Variable ersetzt werden oder nicht - das ist im Ergebnis gleich. Die Ersetzung ist vielleicht verständlicher, bei der Neuanlage ist allerdings die Nichtersetzung natürlicher, weil dann das Verzeichnis einfach mit Copy und Paste eingefügt werden kann. Im Beispiel werden beide Varianten angeführt. Als Parameter empfiehlt sich statt /mir besser /s, da sonst alle Verzeichnisse, in denen sich nichts geändert hat, als leere Verzeichnisse gesichert werden, was bei einer umfangreichen Unterverzeichnisstruktur unangenehm ist.

  • allgemeine Steuerdatei bak_interval.bat, bei Bedarf zu ändern - zur besseren Erläuterung ein ausführliches Beispiel


rem --- Allgemeine Einstellungen --- 
@set param=/s /a /maxage:1 /w:1 /r:1  
@set backup_vol=H

rem --- Auswahl der zu sichernden Partition --- 
@set src_vol=D

rem --- Auswahl des zusichernden Unterverzeichnisses: Allgemeine Notizen --- 

@set bak=pad
@set dest=%dir%\%subdir%\%bak%
@set bak=pad
robocopy %src_vol%:\g\%bak%\save  %backup_vol%:\%dest% %param%
rem --- Variante mit Ersetzung durch %bak% ---

rem --- Wechsel der Partition --- 
@set src_vol=J

rem --- Auswahl des zusichernden Unterverzeichnisses: Buchhaltung ---

@set bak=zero
@set dest=%dir%\%subdir%\%bak%
robocopy %src_vol%:\data\Programme\Grips\zero   %backup_vol%:\%dest% %param%
rem --- Variante Nichtersetzung zur besseren Lesbarkeit ---

rem --- Auswahl des zusichernden Unterverzeichnisses: aktuelles Projekt ---

@set bak=1.7.1
@set dest=%dir%\%subdir%\%bak%
robocopy %src_vol%:\www\%bak%  %backup_vol%:\%dest% *.php *.js *.txt *.doc *.xls *.htm* %param% /xd *.git* user_guide
rem Nur die angeführten Dateitypen sichern, Versionierung ausschließen.

rem --- Wechsel der Partition --- 
@set src_vol=E

rem --- Auswahl des zusichernden Unterverzeichnisses: Dokumentenverwaltung ---

@set bak=DIEWDATA
@set dest=%dir%\%subdir%\%bak%
robocopy "%src_vol%:\Dokumente und Einstellungen\Rem\Eigene Dateien\DIEWDATA  %backup_vol%:\%dest% %param%
rem --- Variante Nichtersetzung zur besseren Lesbarkeit ---

Die eigentlichen Steuerdateien, die über die Zeitschaltung aktiviert werden, unterscheiden sich dann nur noch im Intervall und dem Zielverzeichnis, welche dann an die allgemeine Steuerdatei übergeben werden:

  • Minütliche Sicherung bak_min.bat, nie zu ändern
@set dir=backup_minute
@set subdir=%time:~3,2%
call bak_interval.bat
  • Stündliche Sicherung bak_hor.bat, nie zu ändern
@set dir=backup_hour
@set subdir=%time:~0,2%
call bak_interval.bat
  • Tägliche Sicherung bak_day.bat, nie zu ändern
@set dir=backup_day
@set subdir=%date:~0,2%
call bak_interval.bat

Bei Erweiterungsbedarf trägt man also in der allgemeinen Steuerdatei mit einem neuen Steuerblock ein neues Ursprungsverzeichnis ein und bestimmt, mit welchem Schlüsselverzeichnis (bak) dieses Verzeichnis im Backup auftauchen soll. Gegebenenfalls trägt man noch die zu sichernden Dateitypen ein, wenn nicht generell alles gesichert werden soll. Damit sind alle drei Sicherungstypen auf einmal geändert.

Wenn man sich noch gegen den Verlust oder Ausfall des Backupmediums absichern möchte, kann man das gesamte Backup anschließend auf eine weitere Festplatte sichern, die im Fall des Falles die Rolle des ersten Mediums nahtlos übernehmen könnte, wobei lediglich ein neues als Ersatz hinzugefügt werden müsste, was das Backup wiederum absichert (die Zuordnung der Laufwerke müsste natürlich ebenfalls angepasst werden). Sei das erste Backupmedium mit L bezeichnet, das zweite mit H, so ergibt sich die Sicherung des Backups wie folgt:

@set Logfile="H:/backup_L_H.log"
@set param=/s 
@robocopy L:\backup H:\backup /MIR /LOG:%Logfile%

bzw., falls auf L auch noch anderweitig Daten vorhanden sind, die zwar nicht gesichert werden, deren Rekonstruktion aber doch lästig wäre:

@set Logfile="H:/backup_L_H.log"
@set param=/s 
@robocopy L: H: /MIR /LOG:%Logfile%

Über die Wahl des Parameters (/mir bzw /s) steuert man, ob gelöschte Dateien auch im Backup gelöscht werden sollen. Wer hinreichend vorsichtig ist, kann sich bei den heutigen Festplattengrößen durchaus leisten, gelöschte Dateien im Becker weiter zur Verfügung zu halten.