`Vorangehender Teil`   /   `Fortsetzung` 
allegro Systemhandbuch V26

0.7	Datensicherung: Konzept und Methoden

Im Normalfall ist es ganz einfach:  `h backp`  eingeben, dann "Sicherungskopie" wählen. 

Hier wird für interessierte Systemverwalter erklärt, welche Überlegungen dahinterstecken.

Bedenken Sie: Ihre Daten sind die weiche Frucht harter Arbeit - Sicherung tut not. Die unbedingt zu sichernden Daten stehen nur in den .cLD-Dateien - die anderen lassen sich rekonstruieren. Veränderungen an diesen Dateien werden nur durch PRESTO (und dessen Varianten, auch a99) und  UPD  in einer Datei  CAT.LOG  protokolliert, wenn CAT der Name Ihrer Datenbank ist. 
Nehmen wir als Beispiel an, Ihre Datenbank befindet sich auf  C:\ALLEGRO\KATALOG. 
Um im Katastrophenfall die Datenbank  CAT  rekonstruieren zu können, geht man folgendermaßen vor. Hier ist auch der "Handbetrieb" beschrieben, um den interessierten Allegrologen ein detailliertes Verständnis zu vermitteln und damit alles genau dokumentiert ist. 

Der CockPit-Pilot hat es im Normalfall viel leichter: man aktiviert nur µr s bzw. µr w  (-Ø 0.11.2) und wählt dann das "Private Backup" bzw. "Private Restore" (das sind die Prozeduren  PBACKUP.BAT und PRESTORE.BAT). 
Also: Starten Sie auf C:\ALLEGRO das Programm CP.BAT, dann den Menüpunkt "sichern", und den Unterpunkt "Private Datensicherung" 
Noch einfacher: Datenbank auf eine andere Platte kopieren. Im Windows-System wird das durch den FLEX `BACKUP` unterstützt, die genau die richtigen Dateien kopiert und im Bedarfsfall auch die Wiederherstellung regelt. 

Manuelle Methode bis DOS 5 (danach gibt es die Programme BACKUP und RESTORE von Microsoft nicht mehr)

1.	Anfertigen einer Sicherungskopie  	                  µr s
	Eine genügende Anzahl formatierter Disketten muß bereitliegen. 
	Man wählt mit dem Befehl CD das Verzeichnis KATALOG an, auf dem sich die Datenbank befindet. Dann gibt man die Befehle 
	rename cat.log xxx.log	(.LOG-Datei darf nicht mit gesichert werden!)
	backup c:cat*.* a:	(o.a., z.B. TAPE für die Sicherung auf einem "streamer tape")
	del xxx.log			(jetzt .LOG-Datei löschen)
	wenn A: das zur Sicherung zu benutzende Diskettenlaufwerk ist und die Daten auf dem Laufwerk C: liegen (sonst statt c: das aktuelle Laufwerk angeben). MS-DOS fordert weitere Disketten an, wenn eine nicht reicht. Konsequent: feuersichere Aufbewahrung der Kopie an einem vom Rechner entfernten Ort. 
	Es ist sehr wichtig, die .LOG-Datei nicht mit zu sichern, sondern gleich nach dem Kopieren zu löschen, bevor man wieder an der Datenbank arbeitet. (Auch wenn Ihnen dies nicht einleuchtet, machen Sie es unbedingt trotzdem so!) Bei der nächsten Bearbeitung wird automatisch eine neue .LOG-Datei begonnen. Diese braucht man zum Rekonstruieren, denn sie enthält die nach der Sicherung entstandenen Daten! 
2.	Man arbeitet mit der Datenbank. In gewissen, frei bestimmbaren Abständen wiederholt man den Vorgang 1. oder kopiert die .LOG-Datei ihrerseits auf eine Diskette (siehe unten). 
3.	Wenn irgendwann durch Plattenfehler, Stromausfall oder andere Störungen die Datenbank "abgestürzt" und nicht mehr brauchbar ist (keine Registeranzeige oder offensichtliche Fehler), löscht man die unbrauchbar gewordenen Dateien, aber nicht die .LOG-Datei, und speist die Sicherungskopie ein. 
	Das geht so:  man gibt nach Anwählen des Datenbank-Verzeichnisses die folgenden Befehle: 
	del cat*.cLD 
	del cat.tbl 
	del cat.cDX 
	del cat.stl 
	del cat.res 
	restore a: c:      (bzw. entspr. Befehl für ein "streamer tape")
	und führt danach die Schritte 4. bis 6. aus. 
	Alternativ, oder wenn man keine Sicherungskopie gemacht hat und wenn die .cLD-Dateien noch da sind, kann man auch so vorgehen: man löscht CAT.cDX und CAT.TBL und regeneriert dann mit dem Programm 7 (= INDEX) die Datenbank aus den noch vorhandenen .cLD-Dateien (-Ø Kap.7). Dazu nutzt man die Funktion -fi des Programms INDEX, dabei bleiben auch die Satznummern erhalten! Mit diesem Schritt wäre die Rekonstruktion abgeschlossen, d.h. die folgenden Schritte entfallen dann. 
4.	Danach kopiert man die .LOG-Datei, falls sie beim Zusammenbruch verschwunden war (das ist sehr unwahrscheinlich), von ihrer Sicherungsdiskette auf das Datenverzeichnis. Sie muß CAT.LOG heißen. 
5.	Schließlich gibt man, vom \ALLEGRO-Programmverzeichnis aus, den Befehl 
		upd -fp -dkatalog\cat -ucat.log -n1	µr w
	Hier muß man -S ergänzen, wenn man auf einem Einzelplatzsystem arbeitet. Daraus kann man sich ein Makro namens PLAYBACK machen. Oder (bequemer!) man setzt CockPit ein (-Ø 0.11.2). 
6.	Nach Ablauf dieses Programms wird die Datenbank wieder in dem Zustand sein, den sie vor dem Zusammenbruch (nach der letzten noch fehlerfreien Speicherung) hatte. 
7.	Gelegentlich beginnt man wieder neu bei 1, wenn die .LOG-Datei eine gewisse Größe erreicht hat. Eine vorgeschriebene Grenze gibt es nicht - zu empfehlen sind ca. 500 KB bis 1 MB, damit im Fall des Falles die Wiederherstellung nicht zu lang dauert. CockPit macht  Sie ab 1.2 MB darauf aufmerksam, daß es an der Zeit wäre, eine Sicherung vorzunehmen. 

Wenn man LOG-Dateien auf Disketten oder auf ein anderes Laufwerk bzw. Dateisystem (UNIX) kopiert, muß man über die Vorgänge sorgfältig Buch führen und sich für eine von drei Methoden entscheiden: 

  A	Man kopiert jeweils die gesamte LOG-Datei und löscht sie nur zum Zeitpunkt einer Gesamtsicherung (Vorgang 1.) Diese einfachste Methode empfiehlt sich, wenn man genügend Platz auf der Platte hat. Man beachte aber die unten folgende Anmerkung.
  B	Man numeriert die LOG-Dateien (cat1.LOG, cat2.LOG, ...) und löscht sie nach dem Kopieren. 
	Dann muß man die Vorgänge 4. und 5. im Bedarfsfall mehrfach ausführen, zuerst mit cat1.log ... 
  C	Man kopiert die jeweils neu entstandene LOG-Datei an das Ende der beim letzten Mal gesicherten LOG-Datei (z.B. mit copy /b`A:cat.LOG + C:cat.LOG) und löscht sie nach dem Kopieren. Dann brauchen 4. und 5. nur einmal ausgeführt zu werden. So geht es mit CockPit: Gesamtsicherung mit µr s b, für die erste .LOG-Datei µr s L , dann immer µr s + ("additiv") bis zur nächsten Gesamtsicherung. 
	Man beachte aber: 

Wichtige Anmerkung:
Nur Methode B kommt in Frage, wenn man mit INDEX zwischendurch neue Dateien einspielt. Die Regenerierung einer Datenbank muß dann so erfolgen, daß die LOG-Dateien in chronologischer Folge eingespielt werden und die neuen Dateien dazwischen, ebenfalls in korrekter Folge, erneut mit dem Programm INDEX einsortiert werden. Man führe also Vorgang B jeweils vor einem INDEX-Lauf durch, kopiere auch die neuen Dateien auf eine Sicherungsdiskette und numeriere sie ebenfalls chronologisch. 
Es wäre zu riskant, das INDEX-Programm ebenfalls seine Vorgänge in der LOG-Datei protokollieren zu lassen. Ein Absturz während eines INDEX-Laufes würde eine anschließende Regenerierung sehr schwierig gestalten und nicht immer zuverlässig ermöglichen. Wenn ein solcher Absturz passiert, führe man das PLAYBACK-Verfahren durch und wiederhole den INDEX-Lauf. 
Wenn man mit  UPD  statt mit INDEX neue Daten einspeist, ist keine besondere Aktion vonnöten, denn UPD protokolliert wie PRESTO alles in der .LOG-Datei. Einen abgestürzten  UPD-Lauf können Sie wiederholen - wenn der Index danach noch in Ordnung ist, denn die schon vorhandenen Sätze werden nicht verdoppelt. 
Der Platzbedarf für die .LOG-Datei ergibt sich daraus, daß jede Aufnahme bei jedem Bearbeitungsvorgang, den man mit dem Speicherbefehl (F10 oder #r) abschließt, vollständig kopiert wird. Besonders dann, wenn man mit dem Platz sparsam umgehen muß, überprüfe man nach mehreren längeren Bearbeitungssitzungen die Größe der .LOG-Datei und wende nicht die Methode A an, weil dabei die .LOG-Datei auf der Platte bleibt und ständig wächst. (Wie oben schon erwähnt: CockPit paßt auf und macht Sie ab einer einstellbaren Dateigröße darauf aufmerksam (-Ø 0.11.6, Befehl L). 

Eine völlig andere Sicherungsmethode ist diese: 
Wenn man zwei oder mehr getrennte (nicht vernetzte) Rechner hat, auf denen dieselbe Datenbank installiert ist, gehe man so vor: 
 •	Bearbeitung findet nur auf Rechner 1 statt, auf Rechner 2 etc. wird die Datenbank nur lesend benutzt. Rechner 2 kann z.B. auch ein UNIX-System sein. 
 •	Zu gewissen Zeiten kopiert man die .LOG-Datei von Rechner 1 auf eine Diskette und speist sie mit dem UPD-Programm in die Datenbank auf Rechner 2 ein. Dazu genügt ein Befehl: 
			upd -d dbp\dbn -fp -u a:cat.log
	den man auf Rechner 2 von C:\ALLEGRO aus gibt, wobei dbp der Datenbankpfad und dbn der Datenbankname ist. Die Diskette mit cat.LOG muß zu dem Zeitpunkt in Laufwerk A: sein. Natürlich wird man für einen Routinebetrieb diesen Befehl in einem Makro, z.B. mit dem Namen NEWDATA.BAT verstecken. 
 •	Auf Rechner 1 löscht man anschließend die .LOG-Datei. Die Datenbank auf Rechner 2 stellt nun quasi die Sicherungskopie dar! 

Auf einem lokalen Netz mit Mehrplatzzugriff liegt diese Situation natürlich nicht vor, denn dort hat man nur ein Exemplar der Datenbank, an dem von mehreren Plätzen aus gearbeitet werden kann. Es kann aber sein, daß einer der angeschlossenen Rechner (der nicht im selben Raum steht!) eine genügend große Platte hat, die man zur Sicherung benutzen kann. Das ist dann schneller und bequemer als alles andere. man kopiert nur schlicht das ganze Datenverzeichnis und löscht dann die LOG-Datei. 

Im Kap. 9.2 wird erklärt, wie man zwei Datenbanken gegenseitig aktualisieren kann, wenn in beiden katalogisiert wird. 

0.8	Was gehört alles zu einer Datenbank?

Hier ist zusammengestellt, welche Dateien zum Kern und Umfeld einer allegro-Datenbank gehören. Wenn man z.B. eine Datenbank mit allem Zubehör sichern, auf ein anderes System kopieren oder auch verbreiten will ("Database Publishing"), ist diese Aufstellung als Checkliste brauchbar. (Eingeklammert: die nur in Nichtstandardfällen notwendigen Dateien). Bei den einzelnen Dateien ist angegeben, ob und wie sie im Katastrophenfall regenerierbar (d.h. automatisch wiederherstellbar) oder (manuell-intellektuell) rekonstruierbar sind, oder ob nicht. Das Regenerieren geht über das Menü `Reorganisieren`.
Nicht aufgeführt sind die Programme (Typ .EXE). Soll eine Datenbank auf einen anderen Rechner kopiert und dort nur zur Recherche benutzt werden, genügt das Programm APAC.EXE. Ansonsten müßte auf dem Zielrechner das normal erworbene und komplett installierte allegro-System vorhanden sein. 
Nochmals der Hinweis: Unter UNIX sind alle Namen vollständig mit Kleinbuchstaben zu schreiben. 

Beispiel:
Nehmen wir mal an, die Datenbank heißt  DAT  und benutzt die Konfiguration K.CFG. Es ist hier unerheblich, auf welchem Unterverzeichnis die Dateien angesiedelt sind. 
Empfehlung: alle datenbankspezifischen Dateien auf das Datenverzeichnis bringen, alles andere auf das Programmverzeichnis. (Ersetzen Sie DAT durch Ihren eigenen Datenbanknamen und evtl. K durch Ihren Konfigurationsbuchstaben, z.B. A oder P.) 
An den Farben sehen Sie gewisse Zusammenhänge: Der Konfigurationsbuchstabe K muß in einigen Namen hinter dem Punkt stehen, der Datenbankname DAT bildet den Anfangsteil im Namen aller Dateien, die wirklich zur Datenbank gehören. 

Kernbestandteile
K.CFG	Die Konfiguration : Das Datenschema ; regenerierbar  (-Ø Anh.A) 
DAT_n.KLD	Die Datendateien (n = 1...255); vollständig regenerierbar, aber nur aus einer Sicherungskopie mit Hilfe von UPD  und der aktuellen .LOG-Datei  (-Ø 0.7) 
DAT.KDX	Indexdatei; zusammen mit DAT.TBL regenerierbar : benötigt werden die .KLD-Dateien, DAT.KPI und das Programm INDEX (Optionen -fi und -fn, siehe  Kap.7), dabei wird auch DAT.STL erneuert und DAT.TBL, wenn sie nicht mehr da ist.
DAT.TBL	Satztabelle; regenerierbar durch das Programm INDEX mit Option -ft. Ausführung über CockPit µr o t) 
DAT.STL	Kurztitelregister; regenerierbar durch das Programm INDEX, und zwar mit der Funktion "Kurztiteldatei erneuern" (Option -fs : CockPit µr o k ). 
DAT.RES	Restriktionsdatei; regenerierbar durch Programm INDEX mit Funktion "Restriktionsdatei erneuern" (Option -fx : CockPit µr o x ). Datenbank ist auch ohne solche Datei benutzbar.
DAT.KPI	Index-Parameterdatei; bei genauer Kenntnis der Datenbank und der Parametersprache rekonstruierbar (-Ø 10) 
	enthält die Vorschriften für die Indexdatei, das Kurztitelregister und die Restriktionsdatei. Beispiele: CAT.API, BANK.NPI
[ DAT.LOG ]	Sicherungsdatei (-Ø 0.7); nicht regenerierbar. Wird nur benötigt, wenn eine beschädigte Datenbank wiederherzustellen ist. Man muß aber dann eine Sicherungskopie haben! 
	Achtung: Nicht mit kopieren, nicht mit ausliefern! Es wäre sinnlos.
D-?.KPR	Anzeigeparameter. (-Ø Kap.10); rekonstruierbar 
	Beispiele (für $A.CFG) : D-1.APR (für PRESTO)  und D-WRTF.APR (für a99)

Peripherie	(diese Dateien sind bei hinreichender Dokumentation alle rekonstruierbar, außer den UIF-Dateien ist keine zwingend erforderlich!

CP.OPT	Datei mit den Vorgaben für das CockPit (-Ø 0.11), falls man damit arbeitet. Diese Datei kann auch anders heißen; sie wird über CP.BAT aufgerufen. (Muß auf Startverz. liegen) 
DAT.ini	Einstellungen für die Windows-Programme. Dokumentation in A99.INI (-Ø Kap.2.5) 
_start.flx	Dieses FLEX-Makro wird nach dem Start von a99 ausgeführt, bevor der Nutzer etwas tun kann.  
DAT.frm	`Formulardatei`: Eingabe und Bearbeitungsformulare für a99.
DAT.sgf	Signalfile: Kleine Textdatei. Wenn sie mit '1' beginnt, kann keiner einsteigen.
HDAT	Datenbankspezifische DOS-Hilfeseite; erscheint bei Shift+F1 vom Funktionsmenü. 
DAT.RTF 	Die Entsprechung für die Windows-Programme
HCDAT	Datenbankspezifischer Hilfetext bei Shift+F1 im Editor (Hinweise für die Erfassung)
H*spr	evtl. abgewandelte H-Dateien  (spr = Sprachkennung: GER, ENG, etc.) 
UIF?spr	evtl. abgewandelte UIF-Dateien (UIF0, UIF1, UIFA, UIFE, spr = Sprachkennung) 
*.FLX	Datenbankspezifische Makros, geschrieben in der FLEX-Sprache
*.KPR	evtl. datenbankspezifische Export-Parameterdateien für die Listenproduktion etc.
*.KPT	zugehörige Tabellendateien, z.B. Druckertreiber (-Ø 10.2) 
*.KIM	evtl. spezifische Import-Parameterdateien für die Zufuhr von Fremddaten
*.BAT	evtl. Stapeldateien für bestimmte Produktionen, z.B. CP.BAT, PR-LIST.BAT. 
`Vorangehender Teil`   /   `Fortsetzung` 

?Vorangehender Teil=h ac0-4 
?BACKUP=h backp  
?Fortsetzung=h ac0-9 
?Formulardatei=h form 
?Reorganisieren=h org 
?h backp=h backp