Snelle handleiding voor Gbak back-up en herstel

Wat is gbak?

Gbak is een standaard Firebird-opdrachtregelprogramma (zie de officiële documentatie hier), ontworpen om 1) een volledige back-up van de database uit te voeren: het leest elk record in de database en slaat deze op in het back-upbestand, 2) back-up herstellen naar de nieuwe database.

Voor ontwikkelaars en beheerders met ervaring met andere RDBMS-systemen kan de term “back-up” een beetje verwarrend zijn, omdat gbak niet de exacte kopie van de database produceert, maar het bestand in een niet-databaseformaat, alleen met gegevens (indexen worden opgeslagen als declaraties).

Om een database te maken uit het gbak-back-upbestand, moet het herstelproces met gbak worden uitgevoerd.

1. Back-ups onder de knie krijgen met Gbak

1.0. Voorbereiding

Laten we map C:\data maken en daar een database plaatsen. We gebruiken een database van 5 GB van Firebird OLTP-EMUL-test, maar je kunt natuurlijk ook je eigen database gebruiken.

Voor Linux-gebruikers: laten we map /db maken en de eigenaar ervan wijzigen naar “firebird”, en de database daarheen kopiëren (zorg ervoor dat de eigenaar ook firebird is).

Code

mkdir /db
chown firebird -R /db

1.1 De eenvoudigste Firebird-back-up met het gbak-commando

Windows

Code

gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

In dit voorbeeld heeft het gbak-programma toegang tot het databasebestand via lokale of embedded toegang.

Firebird 3.0: Embedded toegang in de standaardconfiguratie voor Firebird 3.0 (met parameter in firebird.conf ServerMode = SuperServer) zal proberen een exclusieve vergrendeling op de database te plaatsen, zodat andere verbindingen geen toegang tot de database kunnen krijgen (of de gbak-poging zal mislukken vanwege actieve verbindingen).

Firebird 2.5: Met Firebird 2.5 op Windows werkt het commando prima via het XNET-protocol (als je natuurlijk maar één Firebird-instantie hebt draaien). Op Linux zal Firebird proberen embedded toegang te gebruiken; als die niet beschikbaar is, zal het automatisch (en impliciet) proberen verbinding te maken via TCP/IP. (Als je niet weet wat XNET, INET, enz. betekenen, raadpleeg dan Firebird Connection Strings Cheat Sheet).

Opmerking 1: Dit commando wordt uitgevoerd onder het account van de OS-gebruiker (dus van jou) en gebruikt diens machtigingen om toegang te krijgen tot back-up- en databasebestanden.

Normaal gesproken draait de Firebird-service op Windows met het LocalSystem-account en op Linux onder gebruiker “firebird”, maar de console wordt meestal uitgevoerd onder je eigen gebruikersaccount.

Als dit gebruikersaccount geen toegang heeft tot het databasepad of back-uppad, zal gbak mislukken met de fout “Cannot open backup file” (zie voorbeeld in Bijlage A. Fouten, #5).

Opmerking 2: gbak -b overschrijft het back-upbestand stilzwijgend. Dus als je al backup1.fbk hebt, wordt deze overschreven.

Opmerking 3: Op Linux maakt dit gbak-commando een back-upbestand aan met de consolegebruiker als eigenaar.

Back-uptijd voor dit commando: 120 seconden

1.2. Lokale back-up met gbak die online op Windows kan worden uitgevoerd

Dit gedeelte is alleen voor Windows-gebruikers! Meestal moeten we een back-up uitvoeren terwijl er actieve verbindingen met de database zijn, dus in plaats van een embedded verbinding is het beter om expliciet het lokale protocol op te geven om te voorkomen dat gbak zelf een exclusieve vergrendeling op het databasebestand plaatst in Firebird 3, d.w.z. XNET.

Voor Firebird 3.0:

Code

gbak -b xnet://c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Voor Firebird 2.5 kunnen we een lokale verbindingsreeks gebruiken, en die zal ook XNET gebruiken:

Code

gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Op Linux ondersteunt Firebird geen specifiek lokaal protocol zoals XNET op Windows, dus is het noodzakelijk om een TCP/IP-verbindingsreeks te gebruiken (zie sectie 1.3).

Bovendien werkt XNET alleen voor de enkele instantie van Firebird, dus als je meerdere Firebird-instanties op Windows draait, kan het eenvoudiger zijn om een INET-stijl verbindingsreeks te gebruiken om de doel-serverinstantie op te geven.

Back-uptijd: 139 seconden

1.3. Back-up met gbak met TCP/IP-verbindingsreeks

Dit is het meest universele gbak-commando om een online back-up uit te voeren.

Windows

Code

gbak -b localhost:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b localhost:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

In dit geval wordt door het specificeren van localhost: aan het begin van het databasepad de verbinding tot stand gebracht via het netwerksubsysteem van Firebird.

Het is iets langzamer dan lokale toegang, maar werkt in alle gevallen waarin we een draaiende server hebben die verbindingen accepteert.

Niet-standaardpoort voor Firebird

Als Firebird op een niet-standaardpoort draait (bijv. 3051 in plaats van 3050), kun je de back-up op deze manier uitvoeren:

Windows

Code

gbak -b localhost/3051:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b localhost/3051:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

Back-uptijd: 182 seconden

1.4. Snellere back-up met gbak met Service Manager

Hoe kunnen we de universaliteit van TCP/IP-verbinding, met ondersteuning van niet-standaardpoorten, en snelle lokale back-up bereiken? Laten we Service Manager gebruiken! Service Manager is, in eenvoudige woorden, de manier om standaardtools via de Firebird-engine uit te voeren. Houd er rekening mee dat bij Service Manager de servernaam niet in het pad naar de database hoeft te worden opgegeven, alleen in de parameter -se.

Windows

Code

gbak -b -se localhost:service_mgr c:\Data\test1.fdb  c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey

Dit commando gebruikt de schakelaar -service om aan te geven dat we de Service Manager van de Firebird-instantie op poort 3050 willen gebruiken om de back-up uit te voeren.

In dit geval wordt de back-up rechtstreeks binnen het Firebird-proces uitgevoerd (het bevat een kopie van de gbak-code), en aangezien de communicatie binnen het proces veel sneller is, zal de back-up in dit geval aanzienlijk sneller zijn.

Als Firebird op een niet-standaardpoort draait (bijv. 3051), kan het commando er als volgt uitzien:

Code

gbak -b -se localhost/3051:service_mgr c:\Data\test1.fdb  c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Opmerking: Er is een belangrijke beperking in Firebird 2.5 en Firebird 3.0.0-3.0.5 (pas verwijderd in 3.0.6): de opdrachtregel (alle parameters en paden voor de database en de back-up) moet korter zijn dan 256 tekens.

Als je deze limiet overschrijdt, bijvoorbeeld vanwege lange paden van database en back-up, kun je een alias voor de database declareren in databases.conf (3.0 en hoger) of aliases.conf (2.5):

Code

mydb1=c:\Data\test1.fdb #Windows

Code

mydb1=/db/test1.fdb  #linux

en deze vervolgens gebruiken in ons commando:

Windows

Code

gbak -b -se localhost:service_mgr mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey

Back-uptijd: 115 seconden

1.5. De snelste back-up met gbak met geremde garbage collection

Om de back-up nog sneller te maken, voegen we de schakelaar -g toe

Code

 -G(ARBAGE_COLLECT)    garbage collection remmen

Het back-upcommando zal dus als volgt zijn:

Windows

Code

gbak -b -se localhost:service_mgr -g mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Linux

Code

gbak -b -se localhost:service_mgr -g mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey

Schakelaar -g dwingt de Firebird-engine om garbage collection voor het back-upproces in het databasebestand uit te schakelen.

Dit betekent niet dat garbage-recordversies in het back-upbestand worden opgeslagen; het betekent dat de server tijdens de back-up niet zal proberen bestaande garbage in de database op te ruimen, en de back-up zal sneller zijn.

We raden sterk aan deze schakelaar te gebruiken, omdat we geloven dat garbage collection en de bijbehorende opschoning door sweep (gfix -sweep of autosweep) moeten worden uitgevoerd, dus beschouw gbak beter niet als een alternatief voor de sweep.

Back-uptijd: 105 seconden

1.6. Back-up naar een netwerkshare of netwerklocatie

Wat als we het back-upbestand naar een netwerkshare moeten plaatsen?

Op Windows

De vaak voorkomende verwarring bij nieuwe Firebird-gebruikers: handmatige back-up (wanneer je een commando start vanaf een opdrachtprompt), met eenvoudige gbak -b, naar de netwerkshare werkt prima, maar de snelle versie van gbak met -se localhost:service_mgr werkt niet.

De reden is dat Firebird op Windows draait onder het LocalSystem-account, dat geen toegang heeft tot netwerklocaties (tenzij deze netwerkshares toegang hebben geconfigureerd voor de groep “Iedereen”, maar dat is in ons tijdperk van ransomware heel erg gevaarlijk).

De oplossing is om de Firebird-service op Windows uit te voeren onder een account met voldoende rechten om toegang te krijgen tot de netwerkshare en tegelijkertijd voldoende rechten om toegang te krijgen tot lokale databasebestanden en systeembestanden in C:\ProgramData\Firebird. Ook is het een goed idee om de parameter RestrictAccess in firebird.conf te configureren.

Op Linux

Aangezien Firebird op Linux draait onder account “firebird”, moet je de netwerkshare mounten met toewijzing aan gebruiker “firebird”, zodat de Firebird-service op dezelfde manier toegang heeft tot de netwerklocatie als tot een lokale schijf.

1.7. Eenvoudige back-up van de externe server naar de lokale machine

Het is mogelijk om een back-up van de database van de externe server naar de lokale machine te maken.

De onderstaande voorbeeldopdracht start op een Windows-computer, heeft toegang tot de database op een Linux-server (met IP-adres 192.168.0.108, maar ook de hostnaam van de server kan uiteraard worden gebruikt), en het back-upbestand wordt opgeslagen in de map C:\Data op Windows):

Code

gbak -b -user SYSDBA -pass masterkey 192.168.0.108:/db/test1.fdb c:\data\remotebackup1.fbk

Tijd voor back-up: 568 seconden

Deze opdracht zal meestal veel langzamer zijn dan de lokale back-up, omdat gbak gegevens van de externe server leest en records via het netwerk overdraagt.

1.8. Snellere back-up van externe server naar lokaal met Service Manager

De onderstaande opdracht is sneller dan de traditionele back-up van de externe server naar de lokale machine, beschreven in #1.7

Code

gbak -b -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb stdout > C:\Data\remoteback1.fbk

Deze maakt gebruik van Service Manager om de back-up op de externe server uit te voeren, maar de uitvoer wordt naar de stdout-pijplijn gestuurd en vervolgens omgeleid naar het lokale bestand.

Deze opdracht is meestal 15%-20% sneller dan in #1.7 (Eenvoudige back-up van de externe server naar lokaal), vanwege het volgende:

het voert de back-up uit via Service Manager op de externe server, zodat alle lees- en compressiebewerkingen op de snelste manier worden uitgevoerd,
het verzendt via het netwerk alleen het resulterende back-upbestand, met een grootte die kleiner is dan de gegevens in de database

Met deze opdracht is het echter niet mogelijk om de uitgebreide modus in te schakelen en gedetailleerde uitvoer naar het logbestand op te slaan.

Tijd voor back-up: 473 seconden

1.9. Back-up van Firebird-database op de externe server naar dezelfde externe server met behulp van Service Manager

Met Service Manager is het mogelijk om een gbak-back-up van de database op de externe server aan te roepen en deze ook op dezelfde externe server op te slaan.

Code

gbak -b -se  192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb /db/back12.fbk

Deze opdracht roept via Service Manager een back-up aan op de externe server, met de instructie om het back-upbestand ook op dezelfde netwerkserver op te slaan.

Natuurlijk moet de back-uplocatie toegankelijk zijn voor de Firebird-service (op Linux draait deze als gebruiker “firebird”, op Windows als LocalSystem-account).

1.10. Back-up van Firebird-database 6x sneller met multi-thread back-up in Firebird 5 (of HQbird 2.5/3.0/4.0/5.0)

Als u nog steeds niet tevreden bent met de back-upprestaties van Firebird gbak, overweeg dan om over te stappen naar Firebird 5 (of gebruik de enterprise Firebird-distributie: HQbird voor andere versies).

Deze ondersteunt multi-thread back-up, wat back-upbewerkingen met gbak tot 6x sneller maakt.

Code

gbak -b -par 8  -se localhost:service_mgr -g C:\Data\testbigdb1.fdb c:\Data\backup1.fbk -user SYSDBA -pass masterkey

Zoals u kunt zien, is er een nieuwe parameter -par 8, die ervoor zorgt dat gbak 8 threads gebruikt om een back-up te maken.

HQbird voert onderhoudstaken (sweep, back-up, restore) veel sneller uit (de resultaten in de onderstaande afbeelding zijn uiteraard afkomstig van een andere database):

2. Herstel met Gbak-tool

We hebben een back-upbestand backup1.fbk, gemaakt door een van de bovenstaande opdrachten, en we moeten dit op een snelle en efficiënte manier herstellen.

Laten we aannemen dat het bestand zich in C:\Data\backup1.fbk bevindt in het geval van Windows, of /db/backup1.fbk in het geval van Linux.

2.1. De eenvoudigste herstelopdracht

Op Windows

Code

gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Op Linux

Code

gbak -c /db/backup1.fbk /db/new1.fdb -user SYSDBA -pass masterkey

Allereerst, let op dat gbak -c het databasebestand niet overschrijft, en als er een bestand C:\data\new1.fdb of /db/new1.fdb bestaat, zal gbak een foutmelding geven dat de database al bestaat.

Deze opdracht werkt overigens heel anders op 2.5/3.0+ en Windows/Linux.

Op Linux zal deze opdracht embedded toegang tot de aangemaakte database gebruiken (als u de volgorde van Firebird-providers in firebird.conf niet hebt gewijzigd, uiteraard) voor zowel 3.0 als 2.5.

Op Windows, op Firebird 3.0 met de standaard volgorde van providers, zal het embedded toegang zijn, op 2.5 - XNET.

Deze opdracht maakt een bestand aan met de rechten van de gebruiker die gbak heeft gestart; dit is vooral belangrijk op Linux - als u gbak als root uitvoert, zal de eigenaar van het databasebestand root zijn, en het Firebird-proces, dat draait onder gebruiker “firebird”, zal geen toegang hebben tot het herstelde bestand.

Opmerking voor Linux-gebruikers

Veel mensen passen, om het eigendom te “repareren”, rechten toe zodat iedereen toegang heeft tot de herstelde database, d.w.z. zoiets als “chmod 777 database”, maar dit is zeer onveilig; de juiste manier is om de eigenaar van de database te wijzigen naar firebird, met de volgende opdracht

Code

chown firebird /db/new1.fdb

Over het algemeen is deze opdracht goed genoeg voor het eenvoudige herstel van niet-productiedatabases (gebruikt voor testen of in ontwikkeling).

Tijd voor herstel: 275 seconden

2.2. Herstel met localhost-verbindingsreeks

De meest universele, maar niet de snelste hersteloptie is de volgende:

Windows

Code

gbak -c C:\Data\backup1.fbk localhost:C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey

Niet-standaard poort

Als Firebird op een niet-standaard poort draait, bijvoorbeeld 3051, kan deze worden opgegeven in de herstelopdracht:

Windows

Code

gbak -c C:\Data\backup1.fbk localhost/3051:C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c /db/backup1.fbk localhost/3051:/db/new1.fdb -user SYSDBA -pass masterkey

Tijd voor herstel: 1225 seconden

2.3. Herstel met XNET op Windows

Om het herstel iets sneller te maken, kunnen we op Windows XNET gebruiken (voor Firebird 3.0 en hoger):

Code

gbak -c C:\Data\backup1.fbk xnet://C:\Data\New2.fdb -user SYSDBA -pass masterkey

Op Firebird 2.5 op Windows wordt XNET-toegang gebruikt met de eenvoudige opdrachtregel (als er slechts één Firebird-instantie draait):

Code

gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Tijd voor herstel: 585 seconden

2.4. Sneller herstel met Service Manager

En de snelste manier om te herstellen is het gebruik van Service Manager

Windows

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c -se localhost:service_mgr /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey

Met de schakelaar -se roepen we Service Manager aan op het localhost-adres en instrueren we deze om de herstelcode binnen de Firebird-engine uit te voeren.

Wanneer het herstel door Service Manager wordt uitgevoerd, zal het aangemaakte databasebestand eigendom zijn van het account van de draaiende Firebird-instantie (proces) - dit is “firebird” op Linux en LocalSystem op Windows.

Tijd voor herstel: 244 seconden

2.5. Niet-aanbevolen schakelaar

Op een gegeven moment zou u in de verleiding kunnen komen om de volgende schakelaar te gebruiken:

Code

   -R(ECREATE_DATABASE) [O(VERWRITE)] create (or replace if OVERWRITE used)                               database from backup file (restore)

Code

om het overschrijven van de bestaande database door de nieuwe te forceren.

Naar onze ervaring vergroot deze schakelaar de kans om per ongeluk de productiedatabase te overschrijven aanzienlijk.

We raden sterk aan om de database elke keer met een nieuwe naam te herstellen en deze te hernoemen, evenals de oude database expliciet te verwijderen.

We zullen zelfs geen voorbeeld geven van de opdracht met deze schakelaar.

2.6. Database herstellen met behulp van alias

Het is mogelijk om de database te herstellen met behulp van de alias, gedeclareerd in databases.conf (of aliases.conf in Firebird 2.5)

We hebben bijvoorbeeld de volgende declaratie

Code

restdb=c:\Data\newrest1.fdb  #Windows

restdb=/db/newrest1.fdb  #Linux

Dus we kunnen de volgende opdracht uitvoeren om de back-up te herstellen naar het pad, gespecificeerd door de alias

Windows

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk restdb -user SYSDBA -pass masterkey

Linux

Code

gbak -c -se localhost:service_mgr /db/backup1.fbk restdb -user SYSDBA -pass masterkey

2.7. Lokale back-up herstellen naar de externe server

Het is mogelijk om het lokale back-upbestand te herstellen naar de externe Firebird-server.

In dit voorbeeld herstellen we het back-upbestand dat op Windows is opgeslagen, naar de Linux-server (IP-adres 102.168.0.108):

Code

gbak  -c C:\Data\backup1.fbk 192.168.0.108:/db/newdb1.fdb -user SYSDBA -pass masterkey

Tijd voor herstel: 7009 seconden

Zoals u wellicht merkt, werkt het externe herstelproces zeer langzaam; kunnen we dit versnellen met Service Manager?

2.8. Lokale back-up herstellen naar de externe server met Service Manager

Om de lokale back-up op de externe server te herstellen met Service Manager, is het noodzakelijk om de truc met de stdin-invoerstroom toe te passen:

Code

gbak -c -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey stdin /db/new3.fdb <  C:\Data\backup1.fbk

Deze opdracht roept herstel aan op de externe server met de standaardinvoer stdin als bron van de back-up - en levert de invoer via het gedeelte < C:\Data\backup1.fbk van de opdracht.

Ziet er een beetje lastig uit? Maar het is een eenvoudige manier om de gbak-prestaties voor herstel naar de externe server 10x te verhogen!

Tijd voor herstel: 450 seconden

2.9. Extreem lange tabellen herstellen

Als u een echt grote database heeft met een totaal aantal rijen van meer dan 2 miljard, is het noodzakelijk om de schakelaar -o[ne_at_a_time] op te geven, om elke tabel in een afzonderlijke transactie te herstellen, om interne overflow te voorkomen.

Code

gbak -c -se localhost:service_mgr -one C:\Data\backup1.fbk C:\data\new44.fdb -user SYSDBA -pass masterkey

3. Afstemmen en loggen van back-up- en herstelprocessen

3.1. Gbak met uitgebreide uitvoer

Standaard is gbak een zeer stil hulpmiddel; het retourneert niets bij succesvolle uitvoering. Om het uitgebreid te maken, kunnen we de schakelaar -v[erify] toevoegen

Code

gbak -b -se localhost/3050:service_mgr -g mydb1  c:\Data\backup1.fbk -v -user SYSDBA -pass masterkey

Als resultaat zullen er meer details zijn. Het kleine maar vervelende probleem is dat het afdrukken van uitvoer naar de console uitgebreide back-up aanzienlijk langzamer kan maken dan de stille variant, dus het is een goed idee om het logboek op te slaan in een bestand met de schakelaar - y logfile:

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1  c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

Opmerking: gbak zal het bestaande logbestand niet overschrijven! Als u in dit voorbeeld al C:\data\backuplog1.txt heeft, zal de back-up een foutmelding geven (zie #3 in Bijlage A).

Opmerking 2: er is de optie -verbint om het interval te regelen voor het rapporteren van het aantal verwerkte records tijdens back-up of herstel.

3.2. Prestatiestatistieken toevoegen aan uitgebreide uitvoer

In de uitgebreide gbak-uitvoer voor back-up en herstel kunnen we berichten zien zoals deze:

Code

gbak:    writing data for table COUNTRY
gbak:16 records written

voor elke tabel en andere database-objecten.

Het is interessant om te achterhalen welke tabellen/objecten de meeste tijd in beslag nemen, toch?

Hiervoor is het noodzakelijk om de schakelaar -st(atistics) te gebruiken:

Code

 -ST(ATISTICS) TDRW    show statistics:
     T                 time from start
     D                 delta time
     R                 page reads
     W                 page writes

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1 -st tdrw c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

Wanneer toegepast, zal het de volgende kolommen aan het logboek toevoegen:

Code

gbak: time   delta  reads  writes

zodat we de tijd en IO kunnen zien die aan elke regel zijn besteed.

3.3. Tabellen uitsluiten van de back-up en/of van het herstel

Als u denkt dat sommige tabellen kunnen worden uitgesloten van de back-up (een goed voorbeeld is een zeer lange logtabel), kunt u deze opgeven in de parameter SK[IP_DATA], met een reguliere expressie als parameter.

In het onderstaande voorbeeld sluiten we gegevens van de tabellen COUNTRY en JOB uit van de back-up:

Code

gbak -b -se localhost/3050:service_mgr -g -v mydb1 -SKIP_D ‘(COUNTRY|JOB)’ c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt

En in het onderstaande voorbeeld sluiten we tabel CLIENT uit van het herstel:

Code

gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new33.fdb -user SYSDBA -pass masterkey -SKIP_D "CLIENT"

Houd er rekening mee dat de parameter voor SKIP_DATA als één enkele parameter moet worden doorgegeven, dus deze moet tussen aanhalingstekens staan!

Op Linux moeten de aanhalingstekens enkelvoudig zijn, op Windows - dubbel.

Voorzorgsmaatregelen bij het uitsluiten van tabellen van back-up en/of herstel

We raden sterk aan om de reguliere expressievoorwaarde vóór gebruik te controleren met de volgende query - deze retourneert een lijst met tabellen die overeenkomen met de filtervoorwaarde (in de query zijn aanhalingstekens altijd enkelvoudig):

Code

SQL> SELECT RDB$RELATION_NAME FROM RDB$RELATIONS WHERE TRIM(RDB$RELATION_NAME) SIMILAR TO '(COUNTRY|JOB)';

RDB$RELATION_NAME
===============================
COUNTRY
JOB

Houd er rekening mee dat tabellen van de back-up of het herstel worden uitgesloten, ongeacht de bestaande beperkingen (Foreign Keys). Als u een dergelijke uitsluiting niet zorgvuldig hebt gepland, is het dus heel gemakkelijk om tijdens het herstelproces de fout “Cannot commit foreign key index” te ontvangen.

3.4. Wachtwoord voor back-up of herstel uit een bestand ophalen

Als u geen voorstander bent van het idee om het wachtwoord bloot te stellen aan iedereen die uw opdrachten ziet, zult u de volgende schakelaar waarderen: -fetch passwordfile

Laten we het bestand met het wachtwoord in C:\Data\passfile.txt maken en het gebruiken (hier gebruiken we een zeer eenvoudige embedded variant; de schakelaar werkt natuurlijk ook met Service Manager):

Code

gbak -b c:\Data\test1.fdb c:\Data\backup5.fbk -user SYSDBA -fetch C:\Data\passfile.txt

Er zijn 2 praktische voordelen:

Als we het wachtwoord in één enkel bestand opslaan, kunnen we ervoor zorgen dat al onze opdrachtbestanden altijd het actuele wachtwoord gebruiken.
We stellen het wachtwoord niet bloot in elk opdrachtbestand.

4. Back-up-herstel in één stap

Vaak is het doel van de back-up om onmiddellijk herstel uit te voeren, om bijvoorbeeld een nieuwe verse database te krijgen, om het nieuwe paginaformaat voor de database toe te passen, of om de bestaande database van 2.5 naar 3.0 te migreren.

In dit geval is het mogelijk om back-up-herstel uit te voeren met één enkele opdracht, met behulp van standaardinvoer en -uitvoer als bronnen voor de betreffende opdrachten, om het maken van een tussenliggend back-upbestand te omzeilen, de vereisten voor vrije ruimte te verminderen en het proces te versnellen.

De opdracht is als volgt:

Code

gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey C:\Data\test1.fdb stdout | gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin C:\Data\new10.fdb

In essentie voeren we hier 2 opdrachten uit, verenigd door het symbool |,

de eerste voor back-up naar stdout:

Code

gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey C:\Data\test1.fdb stdout

en de tweede voor herstel vanaf stdin:

Code

gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin C:\Data\new10.fdb

Deze opdracht is de snelste manier om back-up-herstel uit te voeren op dezelfde Firebird-instantie.

Houd er rekening mee: voor het converteren van databases met back-up-herstel in één stap van 2.5 naar 3.0 is het noodzakelijk om 2 Firebird-instanties te gebruiken, zie details hier.

5. Prestatiesamenvatting

De volgende afbeelding bevat informatie over de snelheid van verschillende back-upopdrachten van lokale back-up van de testdatabase:

Zoals u kunt zien, is de snelste manier om een lokale back-up uit te voeren het gebruik van Service Manager (schakelaar -se[rvice]) en het remmen van garbage collection (schakelaar -ig).

Voor de back-up van de externe server naar de lokale machine is Service Manager ook de beste optie:

De situatie met herstelprestaties is vergelijkbaar: Service Manager is de snelste manier om te herstellen.

Wat betreft het vrij zeldzame geval waarin herstel wordt uitgevoerd vanaf de lokale back-up naar de externe server, is het gebruik van Service Manager met de stdin-truc de enige haalbare keuze:

Zeer veelgestelde vraag over VM- en Firebird-back-ups

Waarom zou ik Firebird-back-uptools gebruiken, terwijl er populaire back-uptools beschikbaar zijn die beloven alles te back-uppen?

Of: ik maak een volledige image-back-up van de virtuele machine, waarom zou ik me druk maken over de back-up van de Firebird-database?

Het antwoord is hier.

Bijlage A. Fouten tijdens back-up/herstel

Een poging om gbak zonder parameters uit te voeren, of met een niet-eigenaar van de database/niet-SYSDBA, leidt tot de volgende fout:

Code

gbak: ERROR:Unable to perform operation.  You must be either SYSDBA or owner of the database
gbak:Exiting before completion due to errors

Als u het verkeerde wachtwoord opgeeft, verschijnt de volgende fout:

Code

gbak: ERROR:Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
gbak:Exiting before completion due to errors

Er treedt een fout op wanneer het bestaande bestand wordt opgegeven als bestemming voor het uitgebreide logboek:

Code

gbak: ERROR:cannot open status and error output file C:\data\backuplog1.txt
gbak: ERROR:    Exiting before completion due to errors
gbak:Exiting before completion due to errors

Er treedt een fout op wanneer de bestaande database wordt opgegeven als bestemming in de gbak-herstelopdracht:

Code

gbak: ERROR:database C:\data\new1.fdb already exists.  To replace it, use the -REP switch
gbak:Exiting before completion due to errors

Er treedt een fout op wanneer gbak een back-up probeert te schrijven naar de locatie waar het niet voldoende rechten heeft om te schrijven.

Code

gbak: ERROR:cannot open file  /db/test1.fbk
gbak:Exiting before completion due to errors

Wanneer gbak toegang probeert te krijgen tot het bestand zonder toestemming - bijvoorbeeld wanneer het bestand een andere eigenaar heeft dan gebruiker “firebird” op Linux:

Code

gbak: ERROR:no permission for read-write access to database /db/test1.fdb
gbak: ERROR:    IProvider::attachDatabase failed when loading mapping cache
gbak:Exiting before completion due to errors

Poging om uitgebreide uitvoer te gebruiken:

Code

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -v -st tdrw -user SYSDBA -pass masterkey /db/test1.fdb stdout  >
 c:\data\rembackup2.fbk
gbak: ERROR:standard output is not supported when using split operation or in verbose mode
gbak: ERROR:    Exiting before completion due to errors
gbak:Exiting before completion due to errors

Poging om een back-up uit te voeren met Service Manager op de externe server met ingeschakelde uitgebreide modus en opslaan naar het logbestand.

Code

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -v -st tdrw -y lg1.txt  -user SYSDBA -pass masterkey /db/test1.f
db stdout  > c:\data\rembackup2.fbk
gbak: ERROR:Invalid clumplet buffer structure: string length doesn't match with clumplet
gbak:Exiting before completion due to errors

Fout bij back-up-herstel in één stap wanneer de back-up om de een of andere reden mislukt:

Code

gbak: ERROR:No request from user for stdin data
gbak:Exiting before completion due to errors

Als u probeert een niet-back-upbestand aan gbak door te geven:

Code

gbak: ERROR:unavailable database
gbak:Exiting before completion due to errors
gbak: ERROR:expected backup description record
gbak:Exiting before completion due to errors

Back-up van een beschadigd databasebestand met de verkeerde pagina rapporteert de volgende fout (nummer en databasebestand zullen uiteraard verschillen):

Code

gbak: ERROR:database file appears corrupt (E:\DATABASE1.FDB)
gbak: ERROR:    wrong page type
gbak: ERROR:    page 9294588 is of wrong type (expected 8, found 0)
gbak: ERROR:gds_$get_segment failed
gbak:Exiting before completion due to errors
gbak: ERROR:Unexpected I/O error while reading from backup file
gbak:Exiting before completion due to errors

Contacten

Neem gerust contact met ons op met eventuele vragen, of meld fouten of typefouten: [email protected]