Bevor Sie andere Tools zum Erstellen einer Sicherung Ihrer Firebird-Datenbank in Betracht ziehen, stellen Sie sicher, dass Sie wissen, was die Tools tun und wie sich eine laufende Datenbank auf sie auswirkt.Wenn Sie beispielsweise Winzip verwenden, um eine komprimierte Kopie einer Datenbank zu erstellen, und dies tun, wenn Benutzer auf das System zugreifen, sind die Chancen für eine erfolgreiche Wiederherstellung dieser Datenbank gering.Sie müssen entweder immer die Tools gbak
oder nbackup
verwenden, die wissen, wie die Datenbank funktioniert, oder gfix
verwenden, um die Datenbank vollständig herunterzufahren, bevor Sie überhaupt versuchen, die Datenbankdatei(en) zu sichern.
gbak
erstellt eine konsistente Sicherung der Datenbank, indem eine Transaktion gestartet wird, die sich über den Sicherungszeitraum erstreckt.Wenn die Sicherung abgeschlossen ist, wird die Transaktion beendet. Dies bedeutet, dass der Sicherungsprozess ausgeführt werden kann, während Benutzer in der Datenbank arbeiten.Bei Transaktionen, die nach Beginn des Sicherungsvorgangs gestartet werden, werden jedoch keine der geänderten Daten in die Sicherungsdatei geschrieben.Die Sicherung stellt eine Kopie der gesamten Datenbank zum Zeitpunkt des Beginns der Sicherung dar.
Die Dump-Datei, die durch ein Standard-Backup mittels gbak
erstellt wurde, ist plattformübergreifend (transportabel), sodass ein auf einem Windows-Server erstelltes Backup verwendet werden kann, um dieselbe Datenbank auf einem Linux-Server oder einer anderen von Firebird unterstützten Plattform neu zu erstellen.Dies gilt nicht für Kopien Ihrer Datenbank (während die Datenbank geschlossen wurde!), Die mit Tools wie Winzip usw. erstellt wurden.Diese Kopien sollten immer nur zum Wiederherstellen einer Datenbank auf derselben Plattform wie die kopierte verwendet werden.
Important
|
Sichern Sie die Datenbank immer mit der Version von gbak , die mit dem laufenden Datenbankserver geliefert wird.
|
Und ein letzter Gedanke zu Sicherungen, unabhängig davon, ob die Sicherung fehlerfrei abgeschlossen wurde, mit einem Fehlercode von 0 beendet wurde und alles in Ordnung zu sein scheint. Woher wissen Sie eigentlich, dass die erstellte Sicherungsdatei verwendbar ist? Die kurze Antwort lautet: Sie tun es nicht.Wann immer Sie eine wertvolle Datenbank haben — und das sollten sie alle sein --, wird dringend empfohlen, Ihre Sicherungsdateien zu verwenden, um eine Testwiederherstellung einer Datenbank entweder auf demselben Server oder noch besser auf einem anderen Server zu erstellen.Nur so können Sie sicher sein, dass die Sicherung erfolgreich ist.
Das folgende Beispiel zeigt eine Sicherung, die auf einem Server mit dem Namen linux erstellt und zum Erstellen eines Klons der Datenbank auf einem anderen Linux-Server mit dem Namen tux verwendet wird, um sicherzustellen, dass alles in Ordnung ist.Zunächst das Backup unter linux:
linux> gbak -backup -verify -y backup.log employee employee.fbk
linux> gzip -9 employee.fbk
Note
|
Beachten Sie, dass der obige gbak -Befehl wie folgt geschrieben werden kann, wobei der Schalter -b[ackup] weggelassen wird, da gbak standardmäßig eine Sicherung ausführt, wenn keine anderen geeigneten Schalter angegeben sind:
linux> gbak -verify -y backup.log employee employee.fbk
|
Dann, auf dem Server tux:
tux> scp norman@linux:employee.fbk.gz ./
Using keyboard-interactive authentication.
Password:
employee.fbk.gz | 19 kB | 19.3 kB/s | ETA: 00:00:00 | 100%
tux> gunzip employee.fbk.gz
tux> gbak -replace -verify -y restore.log employee.fbk employee.restore.test
Zu diesem Zeitpunkt hat die Wiederherstellung funktioniert und die vorherige Datenbank mit dem Namen employee.restore.test
überschrieben.
Der tatsächliche Speicherort der Datenbank für die Datenbank employee.restore.test
wird in der Datei aliases.conf
in /opt/firebird
auf dem Server definiert.In diesem Test wird es in /opt/firebird/database/employee.restore.fdb
aufgelöst.
Zum weiteren Nachweis der Zuverlässigkeit kann die Anwendung anhand dieses Klons der Live-Datenbank getestet werden, um sicherzustellen, dass alles in Ordnung ist.