Firebirdforum.de

Hallo.

Es gibt aktuell in diesem Forum 'Dienstprogramme vier Themen, in denen das Firebird Backup Tool gbak besprochen wird. Und, wenn ich richtig liege, geht es dabei ausschließlich um dessen Verwendung unter Windows.

Dieses Thema soll sich ebenfalls mit dem Backup Tool gbak befassen, aber es wird hier mit der Distro Linux Mint (ab: v19.3, Cinnamon 4.4.8 64-bit) benutzt. Am meisten werden wohl Windows-Umsteiger sowie Linux Mint- und Firebird-Einsteiger profitieren - hoffentlich. Bitte bei Euren Beiträgen auch immer die von Euch benutzte Version von Firebird mit angeben.

Es soll darum gehen, den einen oder anderen LösungsANSATZ vorzustellen. Allerdings die Entscheidung darüber, wie viel Aufwand zum Thema Backup / Restore betrieben wird, die muss jeder für sich selbst treffen.

Hilfreicher, und um so interessanter wird es, wenn hier auch wieder 'Linux-Füchse' etwas beisteuern könnten egal, ob sie Firebird im Unternehmen oder Privat nutzen. Vorteilhaft wäre es, dass jeder sich etwas Mühe gibt, damit das hier für Um- und/oder Einsteiger verständlich ist.

Und bspw. das Folgende könnte hier rein gepackt werden:
:: gbak unter Linux Mint (Speicherort / Terminal-Aufruf)
:: gbak ausgeführt in einer Netzwerkumgebung (Backup/Restore)
:: gbak lokal ausgeführt Backup/Restore)
:: gbak Erläuterungen zu den hier dargestellten Optionen (Backup/Restore)
a) Allgeimeine Optionen
b) Backup Optionen
c) Restore Optionen
d) ggfls. Optionsunterschiede a - c (z. B. Restore: -r(eplace_database) / -rep(lace_database) ab Firebird 2.0 und höher.)
:: Konzepte
:: manuelles Backup
:: automatisiertes Backup (bash-Script, Cronjob, shutdown)
:: Aufbewahrung der Sicherungsdatei (Unternehmen, Privat)
:: Funktionale Kontrolle der Sicherungsdatei - wie
:: Tipps
:: Profi-Funktionen (E-Mail-Benachrichtigung einrichten. Hier wohl besser ein neues Thema eröffnen?)

Sacken lassen und los geht's


Viele Grüße
Gerd

Hallo.

Ich beginne einfach mal ...

Also, das Kommandozeilentool gbak wird von mir unten lokal, manuell, als Systemdatenbankadministrator minimalistisch und danach mit eine Reihe explizit hinzugefügter Optionsschalter ausgeführt. Letzteres bringt nützliche Informationen (z.B. Optionsschalter -z) einerseits zum Tool - andererseits zum Verlauf des Backup-Vorgangs.
Aber zunächst erst einmal folgt jetzt die Bekanntgabe des Speicherorts von gbak nach manueller Firebird-Installation.

gbak Speicherort:
Der Speicherort des Firebird Backup Tools gbak befindet sich unter Linux Mint hier:
/opt/firebird/bin

Sicherung erstellen:
Manuell, Lokal als Systemdatenbankadministrator (sysdba)

MINIMUM
Allgemeine Optionen:
-user sysdba = Der Nutzer Systemadimistrator.
-password 'sysdba_passwort' = Das Passwort des Nutzers Systemadministrator in Hochkommata.

Backup-Optionen:
Keine.

:: Das Terminal starten (z. B. mit STRG+ALT+T)
Eingabe: :: Eingabetaste

* * *

OPTIONSSCHALTER
Allgemeine Optionen:
-z = Zeigt die gbak- und Server-Version an.
-v = Erbringt ausführliche Informationen über den gbak Vorgang.
-user sysdba = Der Nutzer Systemadimistrator.
-password 'sysdba_passwort' = Das Passwort des Nutzers Systemadministrator in Hochkommata.

Backup-Optionen:
-b = Backup (Der Schalter ist optional. Er kann, muss aber nicht eingegeben werden.)
-g = Führt während des Vorgangs keine Speicherbereinigung durch. (--> Sweeping --> Tool gfix)

:: Das Terminal starten (z. B. mit STRG+ALT+T)
:: Eingabe: :: Eingabetaste

Viele Grüße
Gerd

Hallo.

Und weiter geht es mit der 'automatisierten Backup-Erstellung' (so nenne ich das mal.)

Bekannt ist, dass nur der Systemdatenbankadministrator (SYSDBA) oder der Datenbankbesitzer (z.B. User: Gerd) eine Sicherung durchführen können.
Jedoch kann jeder Benutzer eine Sicherung in einer neuen Datenbank wiederherstellen. Nur das betrifft den gbak-Funktionsbereich 'Wiederherstellung' (Restore) und der soll ja einzeln für sich beschrieben werden.

Um gbak auszuführen muss die Datenbank nicht heruntergefahren werden. In der Firebird Dokumentation wird darauf hingewiesen, dass eine Leistungsverschlechterung festgestellt werden kann. So kommt man schnell auf die Idee gbak bspw. am Abend oder in der Nacht ausführen zu lassen. Nur, wer soll das tun und wie?
Das WIE ist einfach zu beantworten. Es gibt nämlich die Möglichkeit ein Bash-Script zu erstellen, um dieses von einem geeigneten Cronjob, der zuvor in der Crontab angelegt werden muss, vom Dienst CRON aufrufen zu lassen. Allerdings WER das umsetzt, kann ich hier nicht beantworten. Es wird wohl an Ihnen hängen bleiben. Weitere Infos zu CRON...

Schauen wir uns diese zwei Schritte, in ein einfaches Beispiel gehüllt, als Lösungsansatz einmal an:
1. Schritt
A) Verzeichnisse
Hier im Beispiel werden diese beiden Verzeichnisse benötigt und manuell erstellt:
/home/gerd/Firebird/Datenbanken/
/home/gerd/Firebird/FB-Logs/
Sie müssen diese bei sich entsprechend anpassen.

B) Bash-Script
Ein Bash-Script erstellen - mit Datum und es beispielhaft benennen gbak_b_adressen.sh: Ergebnis: gbak erzeugt eine Sicherungsdatei adressen_TT-MM-JJJJ.fbk

Oder auch ...

Ein Bash-Script erstellen - mit Datum und Uhrzeit und es beispielhaft benennen gbak_b_adressen.sh: Ergebnis: gbak erzeugt eine Sicherungsdatei adressen_TT-MM-JJJJ_HH:MM:SS.fbk

Wie in der Dokumentation erwähnt erhalten Sie auch mit der automatisierten Ausführung von gbak einen konsistenten Schnappschuss der Datenbank (hier adressen.fdb) zum Zeitpunkt des Starts von gbak. (Auch wissenswert: gbak --> Garbage Collection).

2. Schritt
Der Aufruf der Crontab (versinnbildlicht eine Datei --> Cron-Table dt. Zeit-Tabelle).
Die Crontab wird über das Terminal aufgerufen.
:: Das Terminal aufrufen mit STRG+ALT+T
:: Eingabe: Mittels GNU nano Editor lässt sich die angezeigte Datei bearbeiten.
Die englisch-sprachige Beschreibung in grüner Schriftfarbe kann bleiben.
Es muss nun eine Sicherungsaufgabe für gbak und zwar in eine einzige Zeile geschrieben werden.
Diese Zeile ist der Job, den das Programm Cron zu fälligen Zeitpunkten ausführen wird. So geht es: Also:
20:15 Uhr täglich wird das Script gbak_b_adressen.sh (mit Datum oder mit Datum und Uhrzeit) ausgeführt.
Die Folge:
Das in diesem Rhythmus vom CRON-Dienst ausgeführte Script gbak_b_adressen.sh erstellt ein Backup der Firebird Datenbank adressen.fdb , die im Verzeichnis /home/gerd/Firebird/Datenbanken/ liegt und legt es als Backupdatei (adressen_TT-MM-JJJJ.fbk oder adressen_29-03-2020_HH:MM:SS.fbk) in das Vereichnis /home/gerd/Firebird/Datenbanken/.
Außerdem veranlassen Sie mit dieser Crontabzeile, dass eine Log-Datei (Backup_adressen.log) erzeugt werden soll, die in das Verzeichnis /home/gerd/Firebird/FB-Logs/ gelegt wird. Die Log-Datei wird nur ein Mal erzeugt und bei jeder folgenden Sicherung nach unten erweitert.

Tipp:
So können Sie sich Ihre Cronjobs im Terminal anzeigen lassen:
:: Das Terminal aufrufen mit STRG+ALT+T
:: Eingabe: So können Sie Ihre Cronjobs löschen.
:: Das Terminal aufrufen mit STRG+ALT+T
:: Eingabe: Nun mit der Einfügemarke zur jeweiligen Zeile mit dem Cronjob navigieren und diese Zeile löschen.
Änderungen übernehmen mit ...
Tastenkombination: STRG+X
Taste: J
Eingabetaste

Falls Sie es möchten, dass vor der Sicherung erst noch eine Meldung (Ja - Nein Abfrage) eingeblendet werden soll, dann statten Sie das Bash-Script (hier nur Datum) in etwa so aus: Voraussetzung ist, dass zenity installiert ist (was bei der Distri Linux Mint Standard sein soll).
Nur überlegen Sie - es muss erst die Meldung mit mit Klick auf Ja bestätigen werden, bevor das Backup durchgeführt wird. Somit läuft es nicht mehr automatisch im Hintergrund (zum Abend - in der Nacht) ab.


Viele Grüße
Gerd

Hallo.

Der vorangegangene Beitrag befasste sich mit dem automatisierten Aufruf von gbak unter Verwendung eines Cronjobs. Dem soll nun noch etwas nachgereicht werden:

Insbesondere dann, wenn der Backup-Vorgang mittels Cronjob in den Abend bis Nachtstunden durchgeführt wird und der Rechner (lokal) danach abgeschaltet werden soll, muss dafür noch etwas getan werden. Hier ein möglicher Ansatz:

Man könnte jeden Tag neu festlegen, dass der Rechner nach dem Backup-Vorgang heruntergefahren wird.
Wird also das Backup mittels Cronjob 20:15 Uhr durchgeführt (siehe oben), dann stellt man den Shutdown - je nach zeitlichen Backup-Umfang - auf bspw. 20:20 Uhr ein. So:
:: Terminal aufrufen: STRG+ALT+T
:: Eingabe: shutdown -h 20:20
:: Eingabetaste Man erhält die Mitteilung, dass der Shutdown für 20:20:00 Uhr geplant ist.

Soll der (für den jeweiligen Tag) so gesetzte Shutdown für 20:20 Uhr nicht stattfinden - also abgebrochen werden - gibt man in das Terminal das Folgende ein:

:: Terminal aufrufen: STRG+ALT+T
:: Eingabe: shutdown -c
:: Eingabetaste Es wird keine Mitteilung ausgegeben.

Weitere Informationen zum Thema Shutdown (u. a. diesbezügliche Befehle, Programme, ...) gibt es u. a. hier.

Viele Grüße
Gerd

Hallo.

Die Datenbank-Wiederherstellung (lokal) mittels Kommandozeilentool gbak - hoffentlich eine Orientierungshilfe.

Die vorangegangenen drei Beiträge beschäftigten sich mit der manuellen und automatisierten Erstellung von Backups einer Firebird Datenbank unter Verwendung des dafür vorgesehenen Firebird Tools gbak.

Mir sind zwei Gründe bekannt, weshalb man seine Firebird Datenbank mit gbak sichern und wiederherstellen sollte:

1. Grund: Man bringt die Datenbank (*.fdb) samt Einstellungen und Daten in Sicherheit. Wie bereits erwähnt, stellt eine solche Sicherung ein Schnappschuss der kompletten Datenbank dar.

2. Grund: Eine stattfindende Wartung der Datenbank. Durch das Sichern und Wiederherstellen mit gbak wird auch Einfluss auf den Metadatenänderungszähler, der jeder Tabelle zugewiesen ist, genommen. Der Zähler kann den maximalen Wert von 255 annehmen. Bei einer Wiederherstellung wird er wieder auf den Startwert gesetzt. Bspw. das Hinzufügen einer Tabellenspalte erhöht den Metadatenänderungszähler. Welche weiteren Aktionen diesen Zähler erhöhen, lesen Sie u. a. in dieser Firebird-Dokumentation. Die Werte des Metadatenänderungszählers werden in der Systemtabelle RDB$FORMATS gespeichert.

Es wird sehr empfohlen diese Firebird-Dokumentation und diese Firebird-Dokumentation zu lesen, bevor man sich mit gbak an die Wiederherstellung (Schalter: -REPLACE_DATABASE, -RECREATE_DATABASE, -CREATE_DATABASE) einer Firebird Datenbank macht.

Die Firebird Datenbank adressen_TT-MM-JJJJ.fbk (bzw. auch: adressen_TT-MM-JJJJ_HH:MM:SS.fbk) mit dem Schalter -REPLACE_DATABASE wiederherstellen:

Schalter -REPLACE_DATABASE
Datenbank nicht da. OK Schalter -REPLACE_DATABASE
Datenbank da und nicht in Verwendung.) OK Schalter -REPLACE_DATABASE
Datenbank da und in Verwendung. Nicht OK
Die Firebird Datenbank adressen_TT-MM-JJJJ.fbk (bzw. auch: adressen_TT-MM-JJJJ_HH:MM:SS.fbk) mit dem Schalter: -RECREATE_DATABASE neu erstellen:

Schalter -RECREATE_DATABASE
Datenbank nicht da. OK Schalter -RECREATE_DATABASE
Datenbank da und nicht in Verwendung. Nicht OK Es wird der Hinweis gegeben: Um sie zu ersetzen, verwenden Sie den Schalter -REP (= Schalter: -REPLACE_DATABASE).

Empfehlenswert ist es, das Wiederherstellen einer Firebird Datenbank mit gbak zunächst an einer Dummy-Datenbank zu testen.

Viele Grüße
Gerd

Hallo Gerd,

danke für die Zusammenfassung. Habe ich mir gleich mal als Lesezeichen abgelegt.

Gruß
Martin

Hallo Gerd,

danke für die schöne Zusammenfassung, das wird einigen neulingen sicher viel helfen. Ich würde aber eine wichtige Sache anmerken wollen:
Man sollte DRINGEND das erstellte Backup validieren lassen, jedes mal. Ich hatte vor einigen Jahren einmal einen Server im Kundenstamm, der sporadisch sowohl defekte Datenbanken als auch Backups per gbak fabriziert hat. Wenn mand da etwas nachliest passiert das aus diversesten Gründen, defekter RAM, defekte CPU, RAID Controller, Platten/SSD. Wir haben einige Sachen getauscht, aber nie heraus gefunden, warum da Errors auftraten.

Jedenfalls habe ich mir angewöhnt, im bash Script immer erst ein gbak backup, dann copy der Datei in eine remote location, dann einen test-restore durchzuführen. Das läuft zwar, bei einer DB die mehrere 100Gb groß ist, eine Weile...aber das ist es wert.

MfG Michael

RS667 hat geschrieben: Mo 2. Sep 2024, 12:05 ...
Man sollte DRINGEND das erstellte Backup validieren lassen, jedes mal. ...

Jedenfalls habe ich mir angewöhnt, im bash Script immer erst ein gbak backup, dann copy der Datei in eine remote location, dann einen test-restore durchzuführen. Das läuft zwar, bei einer DB die mehrere 100Gb groß ist, eine Weile...aber das ist es wert.

MfG Michael

Hallo Michael.

Ja, das ist ein sehr wichtiger Hinweis von Dir.

In den Firebird FAQs habe ich dazu (offiziell) gefunden:

"Wie validiere ich ein Backup?

Am besten ist es, es in einer temporären Datenbank wiederherzustellen. Wenn die Wiederherstellung fehlerfrei verläuft, ist das Backup in Ordnung.

Darüber hinaus können Sie das Tool IBBackupSurgeon ausprobieren, das das Backup für Sie überprüft. Es kann auch verwendet werden, um beschädigte Backupdateien zu reparieren und Ihnen die Wiederherstellung von Backups zu ermöglichen, die sonst mit gbak nicht wiederherstellbar wären."


Viele Grüße
Gerd

Hinweis:
Um einen Resore in die DB zu machen, sollte man den Dienst beenden, da gbak alle Ressourcen für den Restore enthält.
Um einen Wiederanlauf zu haben, sollte man dann auch nicht in den Originalnamen zurückspeichern, da im Absturzfall dann das Original kaputt ist und ggf. auch das Backup kaputt sein kann.
Wenn der Restore fertig ist, können die Dateinamen ausgetauscht werden, Original => Save, Resore => Original.

Gründe für den regelmäßigen Backup + Restore:
Leider ist die 3.0 noch nicht so stabil, wie man sie gerne hätte. Und in Kundeninstallationen wird dann gerne der Server gesichert und da der FB-Server unter Windows keinen VolumeSchattenKopie-Treiber hat, kann dadurch die DB zerstört werden.
Der Grad der Zerstörung ist meist gering, führt aber i.d.R. zum Anwachsen der DB, da der Sweep nichts mehr zum Bereinigen findet. Die "Oldest Active Transaction" wird aus unerfindlichen Gründen nicht mehr verändert.
Hier hilft tatsächlich nur noch ein Save/Restore, was eine DB manchmal um 50% verkleinert, 30% ist eher die Regel.
Fazit: Bei Server-Backup den FB-Server stoppen.

Da der Backup tabellenweise sichert, erfolgt beim Restore ein Kompaktierung, was z.T. auch bis 30% Performancegewinn bringen kann. Durch die Satzversionen erfolgt immer ein Splitting der Datenbank-Blöcke, was einer Fragmentierung der Tabelle entspricht.
Durch den Restore wird wieder defragmentiert.
Erfahrungswerte: Save 70GB und Restore dann 50GB durchschnittlich 1 Stunde.
Inzwischen machen wir das wöchentlich.

Interessant in diesem Zusammenhang ist auch das parallele Sichern und WIederherstellen per Pipe:

gbak -b ....... | gbak -r .......

Wenn man keine Backup-Kopie benötigt, ist das der schnellste Weg.
Dies kann man auch zum Versionupgrade verwenden:

...FB3/bin/gbak -b ....... | ...FB5/bin/gbak -r .......

Übrigens: Mit der Pagesize 16K habe ich die besten Performanceergebnisse erzielt. Größere oder kleinere Blöcke waren immer langsamer, zumindest auf Windows.

Ich habe heute mal den "neuen" gbak auf Ubuntu genutzt, um eine DB mit 12 parallelen Threads zu restoren. Da auf der Maschine zur Zeit aufgrund eines Cache Jobs auf unserem MariaDB Server relativ viel los ist laufen die Sachen generell etwas langsamer, aber:

3.0.8er gbak restore, 1 thread: 02:42h für 180Gb
5.01er gbak restore, 12 threads: 00:25h für 180Gb

Das finde ich schon nice. Leider sind mir noch ein paar Inkompatibilitäten aufgefallen, die die produktive Verwendung vom 5er Server verhindern, aber das platziere ich in einer gesonderten Frage.

Übrigens, bfuerchau : Die Testrestores gehen nicht in die Ursprungs-DB. Das wäre mittelschwer unschlau.
Wir sichern auf ein gesondertes Volume, nach dem Namensschema YYYY-MM-DD_databasename.bak und halten diese Backups 45 Tage vor.
Restored wird auf das gleiche Volume, in ein gesondertes Verzeichnis namens "Testrestores", da aber im Namensformat Dayofweekname_restored.fdb

Da wird logischerweise nach 7 Tagen überschrieben. Mir gehts da nur um die reine validierung, da wir wie gesagt schon mehrfach, bei mehreren Kunden korrupre Datenbanken UND backups hatten.

MfG Michael