Wie oben gezeigt, können Sie die speziellen Dateinamen stdin und stdout verwenden, um eine Datenbank in einer separaten Datenbank auf demselben Server zu sichern und wiederherzustellen.Sie können jedoch auch dieselben Tools über eine SSH-Verbindung zu einem Remoteserver verwenden und die Sicherung einer Datenbank direkt an eine Wiederherstellung einer separaten Datenbank übergeben.

Im ersten Beispiel wird eine lokale Datenbank auf einen Remote-Server kopiert, auf dem Firebird ausgeführt wird und die Umgebung des Firebird-Benutzers so eingerichtet ist, dass sich das gbak-Tool bei der Anmeldung standardmäßig auf $PATH befindet.

Wenn das oben Gesagte ausgeführt wird, werden Sie aufgefordert, ein Kennwort für den Remote-Firebird-Benutzer auf dem Server tuxrep einzugeben, vorausgesetzt, Sie haben noch kein ordnungsgemäßes SSH-Schlüsselpaar eingerichtet und sind aktiv.Der Befehl ersetzt die lokale Datenbank gemäß dem Aliasnamen emptest. Sie können jedoch bei Bedarf vollständige Pfadnamen für die Datenbanken angeben.Das Folgende zeigt ein Beispiel für die Ausführung des oben genannten Vorgangs.

Wie Sie sehen, steht der Ausgabe nicht viel im Wege, aber Sie können eine Remoteverbindung herstellen und Folgendes überprüfen:

Das nächste Beispiel zeigt eine Remote-Datenbank, die auf ähnliche Weise in einer lokalen Datenbank gesichert wird.

Sie können sehen, dass eine neue Datenbank tuxrep_emptest.fdb erstellt wurde.Funktioniert sie?Die Überprüfung mit isql zeigt, dass dies der Fall ist.

Das letzte Beispiel zeigt, wie eine entfernte Datenbank auf einem Server in einer entfernten Datenbank auf einem anderen Server gesichert wird.

gbak und nbackup sind die besten Tools zum Sichern und / oder Wiederherstellen von Firebird-Datenbanken.Sie wurden ausgiebig getestet und kennen die Interna der Datenbank und deren Funktionsweise. Daher ist die Wahrscheinlichkeit, dass diese Tools Ihre wertvollen Daten beschädigen, sehr gering.Einige Datenbankadministratoren verwenden jedoch weiterhin gerne externe Tools (die nicht mit Firebird geliefert werden), um aus irgendeinem Grund Backups zu erstellen.

Da externe Tools anhand des Aliasnamens nicht wissen können, wo sich eine Datenbank befindet, müssen der Skriptschreiber und / oder der Datenbankadministrator explizit den korrekten Speicherort der Datenbankdatei(en) ermitteln und diese an die externe Datei weitergeben Werkzeug.Um dies für Skriptautoren zu vereinfachen, verwendet meine eigene Installation einen Standard in meiner Datei "aliases.conf" wie folgt:

Die letzte Regel gilt nur für meine Installation und bedeutet, dass das folgende einfache Sicherungsskript funktioniert.Wenn mehrere Dateidatenbanken verwendet würden, wäre mehr Code erforderlich, um eine Sicherung mit externen Tools durchzuführen.

Im Folgenden wird die Verwendung des Dienstprogramms "gzip" auf einem Linux-Server zum Erstellen und Komprimieren einer Sicherung einer laufenden Datenbank gezeigt.Folgendes wird als Root-Benutzer ausgeführt, da gfix ausgeführt werden muss, um die Datenbank herunterzufahren.

Der Wiederherstellungsprozess für diese Datenbank wäre umgekehrt.Wieder läuft das Folgende als root.

In diesem Beispiel wird eine Sicherung erstellt und die ursprüngliche Datenbank mit der neuen Sicherung sofort überschrieben.Dies ist normalerweise keine gute Idee, da die erste Aktion einer Wiederherstellung darin besteht, die Datenbank zu löschen.

Es ist möglich, gbak zu verwenden, um eine leere Datenbank neu zu erstellen, die nur die verschiedenen Domains, Tabellen, Indizes usw. der ursprünglichen Datenbank enthält, jedoch keine der Daten.Dies kann hilfreich sein, wenn Sie Ihre Anwendung in einer Testumgebung geprüft haben und das System beispielsweise in eine Produktionsumgebung migrieren möchten, aber ohne Ihre Testdaten neu beginnen möchten.

Wenn die obige Dump-Datei auf dem Produktionsserver wiederhergestellt wird, sind nur die Metadaten vorhanden.

Es gibt eine andere Möglichkeit, eine Datenbank ohne Daten und nur mit den Metadaten zu erstellen.Stellen Sie einfach aus einem vorhandenen Speicherauszug wieder her, der die Daten enthält, und geben Sie den Schalter -m[eta_data] in die Wiederherstellungsbefehlszeile ein.Die Datenbank wird wiederhergestellt, aber keine der Originaldaten sind vorhanden.

Der Schalter -m[eta_data] kann entweder für eine Sicherung oder eine Wiederherstellung verwendet werden, um die Erstellung einer Klondatenbank (oder das Überschreiben einer vorhandenen) ohne tatsächliche Daten zu erleichtern.

Die in einem eigenen Handbuch dokumentierte Filteranwendung gsplit funktioniert nicht mehr.Dieser Filter wurde mit alten Versionen von InterBase und Firebird geliefert, damit große Datenbanksicherungen auf mehrere Dateien aufgeteilt werden können, damit die Dateisystemgrenzen eingehalten werden können.Solche Beschränkungen können die Größe einer CD sein, die Beschränkung auf 2 GB für einzelne Dateigrößen auf einer DVD, wobei einige Unix-Dateisysteme eine Beschränkung auf 2 GB usw. haben.

Mit gbak können die Speicherauszugsdateien in verschiedene Größen (mit mindestens 2048 Byte) aufgeteilt werden, und es werden nur die benötigten Dateien erstellt.

Die Größen nach jedem Dateinamen geben an, wie groß diese bestimmte Datei sein darf.Die Standardgröße ist Byte, aber Sie können ein Suffix von k, m oder g angeben, um Einheiten von Kilo, Mega oder Gigabyte zu verwenden.

Wenn der Speicherauszug abgeschlossen ist, bevor in einige Dateien geschrieben wird, werden diese Dateien nicht erstellt.Eine Dump-Datei wird immer nur erstellt, wenn dies erforderlich ist.

Die Größe der endgültigen Speicherauszugsdatei wird stillschweigend ignoriert, wenn die Datenbank zu groß geworden ist, um eine abgeschnittene Sicherung abzuschließen.Wenn im obigen Beispiel die Sicherung insgesamt 1500MB benötigt, wird die letzte Datei auf eine endgültige Größe von 900m anstatt der angegebenen 600m geschrieben.

Um eine solche Sicherung mit mehreren Dateien wiederherzustellen, müssen Sie alle Dateinamen im Speicherauszug und in der richtigen Reihenfolge angeben.Das folgende Beispiel zeigt, wie die oben genannte Mitarbeiterdatenbank aus den beiden oben gespeicherten Dateien wiederhergestellt wird:

Normalerweise ist das verwendete ODS dasjenige, welches von der wiederherstellenden Firebird-Version verwendet wird.Die obigen Beispiele ändern also tatsächlich den ODS, wenn die Datenbank wiederhergestellt wird.Die Sicherung sollte mit dem Dienstprogramm gbak durchgeführt werden, das von der alten ODS-Version von InterBase oder Firebird bereitgestellt wird.Die Wiederherstellung sollte mit gbak aus der neueren Version von Firebird durchgeführt werden.

Danach wurde die alte 2.0 Firebird-Datenbank als Firebird 2.1-Datenbank mit dem entsprechenden Upgrade auf das ODS von 11.0 auf 11.1 neu erstellt — und die alte Datenbank gelöscht.

Das Skript setenv_firebird wird nicht mit Firebird geliefert und setzt einfach PATH usw., um die richtige Version von Firebird gemäß dem angegebenen Parameter zu verwenden.

Der Standard-Datenbank-Cache wird beim Erstellen der Datenbank oder anschließend mit gfix erstellt.gbak kann eine Datenbank wiederherstellen und auch die Standard-Cache-Größe zurücksetzen.Der Prozess ist wie folgt:

Die Standard-Cache-Größe wird verwendet, wenn die Anzahl der Puffer Null ist, wie im ersten Beispiel oben.Mit gbak kann dies bei Bedarf geändert werden.gbak kann die Cache-Größe jedoch nicht auf Null zurücksetzen.Sie müssen dazu gfix verwenden.

Ähnlich wie im obigen Beispiel zum Ändern der Standardgröße des Datenbankcaches kann die Größe der Datenbankseite auch mit gbak geändert werden.

Manchmal möchten Sie nicht, dass Ihre Berichtersteller intensive Abfragen für Ihre Produktionsdatenbank ausführen.Zu diesem Zweck können Sie ganz einfach täglich einen Klon Ihrer Produktionsdatenbank erstellen und schreibschützen.Auf diese Weise kann das Berichtsteam so viele intensive Berichte erstellen, wie es möchte, ohne dass dies negative Auswirkungen auf die Produktionsdatenbank hat, und es wird verhindert, dass versehentlich Änderungen vorgenommen werden.

Das folgende Beispiel zeigt die Produktionsmitarbeiterdatenbank, die auf dem Linux-Server tux ausgeführt wird und auf den Linux-Server tuxrep des Berichtsteams geklont wird.Zuerst auf dem Produktionsserver:

Dann auf dem tuxrep-Server des Berichtsteams:

Sie können gbak verwenden, um einen Klon einer Datenbank auf demselben Server zu erstellen, ohne eine potenziell große Dump-Datei erstellen zu müssen.Zu diesem Zweck leiten Sie die Ausgabe einer gbak-Sicherung wie folgt direkt an die Eingabe einer gbak-Wiederherstellung weiter.

Sie werden feststellen, dass der Name der Ausgabedatei für die Sicherung stdout und der Name der Eingabedatei für die Wiederherstellung stdin lautet.Durch diese Möglichkeit, die Standardausgabe eines Prozesses an die Standardeingabe eines anderen Prozesses weiterzuleiten, können Sie vermeiden, dass eine Zwischen-Dump-Datei erstellt wird.Die obigen Befehle setzen voraus, dass geeignete Aliasnamen sowohl für emptest als auch für emptest_2 eingerichtet sind.Wenn nicht, müssen Sie den vollständigen Pfad zu den beiden Datenbanken und nicht den Alias ​​angeben.

Die Option -replace beim Wiederherstellungsprozess überschreibt den angegebenen Datenbanknamen — als Alias ​​oder als vollständigen Pfad --, falls vorhanden, und erstellt ihn neu, wenn dies nicht der Fall ist.Alternativ können Sie auch die Option recreate overwrite verwenden.Beide haben das gleiche Ergebnis.

Wenn Sie keine vorhandenen Datenbanken überschreiben möchten, verwenden Sie -create. Dadurch wird eine Datenbank nur erstellt, wenn sie noch nicht vorhanden ist, und wenn dies der Fall ist, wird sie mit einem Fehler beendet.In POSIX-kompatiblen Systemen ist der Fehlercode in $? In diesem Fall 1.

Weitere Beispiele für das Sichern und Wiederherstellen von Remote-Datenbanken über ssh unter Verwendung der Dateinamen stdin und stdout finden Sie unten.

Wenn Sie keinen Modusschalter wie -b[ackup] oder -c[reate] usw. angeben, führt gbak eine Sicherung durch, als ob der Schalter -b[ackup] angegeben worden wäre — vorausgesetzt, die anderen angegebenen Schalter sind für eine Sicherung korrekt.

Nur der SYSDBA oder der Eigentümer einer Datenbank kann eine Sicherung der Datenbank erstellen. Jeder authentifizierte Benutzer kann jedoch eine Datenbanksicherung mit dem Schalter -c[reate] wiederherstellen.Dies bedeutet, dass Sie sicherstellen müssen, dass Ihre Sicherungsdateien nicht in die falschen Hände geraten, da nichts dann Unbefugte daran hindert, Ihre Daten zu sehen, indem Sie einfach Ihre Sicherungen auf Ihrem Server wiederherstellen.

Die Datenbankwiederherstellung schlägt natürlich fehl, wenn der Benutzer, der sie ausführt, nicht der Datenbankeigentümer ist und bereits eine Datenbank mit demselben Dateinamen vorhanden ist.

Der Schalter -y suppress_output unterdrückt jegliche Ausgaben.Ähnlich wie beim Ausführen mit -v[erify] nicht angegeben.Es scheint jedoch nur zu bewirken, dass die Ausgabe (gemäß der Schaltereinstellung -v[erify]) in eine Datei mit dem Namen suppress_output geschrieben wird. Dies funktioniert jedoch nur einmal, da der nächste Durchlauf von gbak mit -y suppress_output fehlschlägt, da die Datei suppr_output bereits vorhanden ist.

Es ist möglich, dass dieses Problem in Version 2 für Firebird eingeführt wurde, da sowohl die 2.0- als auch die 2.1-Version tatsächlich den Schalter -y suppress anstelle von -y suppress_output verwenden.Die Verwendung dieser (kürzeren) Option funktioniert wie beabsichtigt und die Ausgabe wird tatsächlich unterdrückt.

Wenn Sie mit dem Schalter -y <Protokolldatei> einen Protokolldateinamen angeben und die Datei bereits vorhanden ist, kann gbak sie nicht überschreiben, obwohl der Firebird-Benutzer die Datei besitzt und über Schreibberechtigungen verfügt.Sie müssen immer den Namen einer Protokolldatei angeben, die nicht vorhanden ist.Auf Linux-Systemen kann Folgendes hilfreich sein:

Dies ist insofern sehr nützlich, als es Sie daran hindert, frühere Sicherungen zu überschreiben, die möglicherweise erforderlich sind.Der Nachteil ist, dass Sie jetzt ein Reinigungssystem einführen müssen, um alte, unerwünschte Sicherungen zu beseitigen und zu verhindern, dass sich Ihr Sicherungsbereich füllt.

gbak erkennt die Literalzeichenfolgen 'stdin' und 'stdout' als Quell- oder Zieldateinamen.In POSIX-Systemen ist es bei Verwendung der Standardeingabe- und / oder Standardausgangskanäle nicht zulässig, Suchoperationen auf diesen Kanälen auszuführen.Wenn Sie 'stdin' oder 'stdout' als Dateinamen mit gbak verwenden, wird 'gbak' gezwungen, eine Verarbeitung zu verwenden, die nicht auf den Eingangs- oder Ausgangskanälen sucht, sodass sie für die Verwendung in Pipes geeignet sind — wie in den Beispielen in den Rezepten angegeben Abschnitt oben.

Diese Dateinamen scheinen zwar POSIX-Namen zu sein, sind aber definitiv keine Synonyme für /dev/stdin oder /dev/stdout. Sie sind einfach Literale, nach denen gbak bei der Verarbeitung seiner Parameter sucht.Versuchen Sie nicht, die Namen /dev/stdin oder /dev/stdout in einem Pipeline-Prozess zu verwenden, da dies höchstwahrscheinlich fehlschlagen wird.

Wenn Sie eine Dump-Datei mit dem Namen stdin oder stdout erstellen möchten, sollten Sie den Dateinamen als vollständigen oder relativen Pfadnamen wie ./stdin oder ./stdout angeben, wodurch "gbak" ausgelöst wird Behandeln Sie sie als wörtlichen Dateinamen und nicht als speziellen Dateinamen, der sich von der normalen Verarbeitung während des Dump- oder Wiederherstellungsprozesses unterscheidet.