Re: FastObjects Server Sichern
Verfasst: Mittwoch 18. November 2015, 09:37
an uro_fs aber eine andere Frage:
Gibts auch eine Doku, wie man beeinflußt, wo die relevanten Logfiles geschrieben werden und wie das mit dem Backup und Roll-forward da gelöst ist.
Ich kenne das schon JAHRZEHNTE lang so:
Während des Betriebs schreibt der DB-Prozess alle Änderungen nicht nur in die DBsondern auch in klitzekleine Logfiles(auf physisch andere Platte sinnvollerweise), die werden dann immer wieder frei und werden zB auf eine andere Computer im Netz gesichert oder nach irgendwo (Google drive meinetwegen)
Hauptsache weit weg..
Abends oder nachts macht man einen Gesamtbackup und löscht dann die Logfiles.
Kracht es, dann holt man den gestrigen Backup , kopiert die Log-files ins definierte Verzeichnis
und startet den Datenbankprozess. Die DB mach dann einen Roll-forward von gestern bis auf Crash-zeitpunkt.
Vorteil: Weniger Kopieraufwand ( Logfile-Megabyte anstatt Gesamt-Db-Gigabite) und weit weniger Verlust beim Crash.
Wenn ihnen zB nur die Platte, auf der die DB residiert ausfällt, nicht aber die Logfiles, dann ist der Verlust=NULL.
Bei TM kenn ich derzeit nur die Gesamtsicherung unter Verwendung von mit TMADMIN,
aber das macht man ja nicht alle 5 Minuten sondern bei uns ca alle 1,5Stunden
mfg rLap
Gibts auch eine Doku, wie man beeinflußt, wo die relevanten Logfiles geschrieben werden und wie das mit dem Backup und Roll-forward da gelöst ist.
Ich kenne das schon JAHRZEHNTE lang so:
Während des Betriebs schreibt der DB-Prozess alle Änderungen nicht nur in die DBsondern auch in klitzekleine Logfiles(auf physisch andere Platte sinnvollerweise), die werden dann immer wieder frei und werden zB auf eine andere Computer im Netz gesichert oder nach irgendwo (Google drive meinetwegen)
Hauptsache weit weg..
Abends oder nachts macht man einen Gesamtbackup und löscht dann die Logfiles.
Kracht es, dann holt man den gestrigen Backup , kopiert die Log-files ins definierte Verzeichnis
und startet den Datenbankprozess. Die DB mach dann einen Roll-forward von gestern bis auf Crash-zeitpunkt.
Vorteil: Weniger Kopieraufwand ( Logfile-Megabyte anstatt Gesamt-Db-Gigabite) und weit weniger Verlust beim Crash.
Wenn ihnen zB nur die Platte, auf der die DB residiert ausfällt, nicht aber die Logfiles, dann ist der Verlust=NULL.
Bei TM kenn ich derzeit nur die Gesamtsicherung unter Verwendung von mit TMADMIN,
aber das macht man ja nicht alle 5 Minuten sondern bei uns ca alle 1,5Stunden
mfg rLap