Cos'è gbak?
1. Padroneggiare i backup con Gbak
1.0 Preparazione
1.1 Il più semplice backup di Firebird con il comando gbak
1.2. Backup locale con gbak che può essere eseguito online su Windows
1.3. Backup con gbak con stringa di connessione TCP / IP
1.4. Backup più veloce con gbak con Service Manager
1.5. Il backup più veloce con gbak con Service Manager e garbage collection inibita
1.6. Backup nella condivisione di rete o nel percorso di rete
1.7. Backup semplice dal server remoto alla macchina locale
1.8. Backup più veloce da un server remoto alla macchina locale con Service Manager
1.9. Backup del database Firebird sul server remoto sullo stesso server remoto utilizzando Service Manager
2. Ripristina con lo strumento Gbak
2.1. Il comando di ripristino più semplice
2.2. Ripristina con stringa di connessione localhost
2.3. Ripristina con XNET su Windows
2.4. Ripristino più veloce con Service Manager
2.5. Interruttore non consigliato
2.6. Ripristina il database utilizzando l'alias
2.7. Ripristina il backup locale sul server remoto
2.8. Ripristina il backup locale sul server remoto con Service Manager
2.9. Ripristina tabelle estremamente lunghe
3. Modifica e registrazione dei processi di backup e ripristino
3.1. Gbak con output dettagliato
3.2. Aggiungi statistiche sulle prestazioni all'output dettagliato
3.3. Escludi tabelle dal backup e / o dal ripristino
3.4. Recupera la password per il backup o il ripristino dal file
4. Backup-ripristino in un passaggio
5. Riepilogo delle prestazioni
Domanda molto frequente sui backup di VM e Firebird
Appendice A. Errori durante il backup / ripristino
Gbak è uno strumento da riga di comando standard di Firebird (vedere la sua documentazione ufficiale qui), progettato per eseguire 1) backup completo del database: legge tutti i record nel database e li memorizza nel file di backup, 2) ripristina il backup nel nuovo Banca dati.
Per sviluppatori e amministratori con esperienza con altri RDBMS, il termine "backup" potrebbe creare confusione, poiché gbak non produce la copia esatta del database, ma il file nel formato non database, solo con i dati (gli indici sono memorizzati come dichiarazioni).
Per creare un database dal file di backup gbak, è necessario eseguire il processo di ripristino con gbak.
Creiamo la cartella C: \ data e mettiamo lì un database. Useremo il database 5Gb dal test OLTP-EMUL di Firebird, ma puoi usare il tuo database, ovviamente.
Per gli utenti Linux: creiamo la cartella / db e cambiamo il suo proprietario in "firebird", quindi copiamo il database lì (assicurati che anche il suo proprietario sia firebird).
mkdir /db chown firebird -R /db
Windows
gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey
Linux
gbak -b /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey
In questo esempio, lo strumento gbak accede al file di database utilizzando l'accesso locale o incorporato.
Firebird 3.0: l'accesso integrato nella configurazione predefinita per Firebird 3.0 (con parametro in firebird.conf ServerMode = SuperServer) proverà a mettere un blocco esclusivo sul database, quindi altre connessioni non saranno in grado di accedere al database (o il tentativo di gbak fallirà a causa delle connessioni attive).
Firebird 2.5: con Firebird 2.5 su Windows il comando funzionerà bene attraverso il protocollo XNET (se hai l'unica istanza Firebird in esecuzione, ovviamente). Su Linux, Firebird proverà a utilizzare l'accesso incorporato, se non è accessibile, proverà automaticamente (e implicitamente) a connettersi tramite TCP / IP. (Se non sai qual è il significato di XNET, INET, ecc., Leggi Protocolli di connessione in Firebird 3)
Nota 1: questo comando viene eseguito con l'account dell'utente del sistema operativo (ovvero il tuo) e utilizza le sue autorizzazioni per accedere ai file di backup e database.
Normalmente, il servizio Firebird su Windows viene eseguito con l'account LocalSystem e su Linux con l'utente "firebird", ma la console di solito viene eseguita con il proprio account utente.
Se questo account utente non ha accesso al percorso del database o al percorso di backup, gbak fallirà con l'errore "Impossibile aprire il file di backup" (vedere l'esempio nell'Appendice A. Errori, n. 5).
Nota 2: gbak -b sovrascrive silenziosamente il file di backup. Quindi, se hai già backup1.fbk, verrà sovrascritto.
Nota 3: su Linux, questo comando gbak creerà un file di backup con il proprietario uguale all'utente della console.
Tempo di backup per questo comando: 120 secondi
Questa sezione è solo per utenti Windows! Di solito, dobbiamo eseguire il backup mentre abbiamo connessioni attive al database, quindi invece di una connessione incorporata, è meglio specificare esplicitamente il protocollo locale per evitare di mettere un blocco esclusivo sul file del database da parte di gbak stesso in Firebird 3, cioè XNET.
Per Firebird 3.0:
gbak -b xnet://c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey
Per Firebird 2.5, possiamo utilizzare una stringa di connessione locale e utilizzerà anche XNET:
gbak -b c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey
Su Linux, Firebird non supporta un protocollo locale specifico come XNET su Windows, quindi è necessario utilizzare la stringa di connessione TCP / IP (vedere la sezione 1.3).
Inoltre, XNET funziona solo per la singola istanza di Firebird, quindi se esegui più istanze di Firebird su Windows, potrebbe essere più semplice usare la stringa di connessione in stile INET per specificare l'istanza del server di destinazione
Tempo per il backup: 139 secondi
Questo è il comando gbak più universale per eseguire il backup online.
Windows
gbak -b localhost:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey
Linux
gbak -b localhost:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey
In questo caso, specificando localhost: all'inizio del percorso del database, la connessione avviene tramite il sottosistema di rete di Firebird.
È leggermente più lento dell'accesso locale ma funziona in tutti i casi quando abbiamo un server in esecuzione che accetta connessioni.
Se hai Firebird in esecuzione su una porta non standard (ad esempio, 3051 invece di 3050), puoi eseguire il backup in questo modo:
Windows
gbak -b localhost/3051:c:\Data\test1.fdb C:\data\backup1.fbk -user SYSDBA -pass masterkey
Linux
gbak -b localhost/3051:/db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey
Tempo per il backup: 182 secondi
Come possiamo ottenere l'universalità della connessione TCP / IP, con supporto di porte non standard e backup locale veloce? Usiamo Service Manager! Service Manager, in parole semplici, è il modo per eseguire strumenti standard tramite il motore Firebird. Si noti che nel caso di Service Manager, non è necessario specificare il nome del server nel percorso del database, solo nel parametro -se.
Windows
gbak -b -se localhost:service_mgr c:\Data\test1.fdb c:\Data\backup1.fbk -user SYSDBA -pass masterkey
Linux
gbak -b -se localhost:service_mgr /db/test1.fdb /db/backup1.fbk -user SYSDBA -pass masterkey
Questo comando utilizza switch -service per specificare che si desidera utilizzare Service Manager dell'istanza Firebird sulla porta 3050 per eseguire il backup.
In questo caso, il backup verrà eseguito direttamente all'interno del processo Firebird (ha una copia del codice gbak) e poiché la comunicazione in-process è molto più veloce, il backup sarà notevolmente più veloce in questo caso.
Se Firebird è in esecuzione su uno standard non standard (ad esempio, 3051), il comando può essere simile a:
gbak -b -se localhost/3051:service_mgr c:\Data\test1.fdb c:\Data\backup1.fbk -user SYSDBA -pass masterkey
Nota: esiste una limitazione significativa in Firebird 2.5 e Firebird 3.0.0-3.0.5 (rimossi solo nella 3.0.6): la riga di comando (tutti i parametri e percorsi per il database e per il backup) deve essere inferiore a 256 simboli .
Se si raggiunge questo limite, ad esempio, a causa dei lunghi percorsi del database e del backup, è possibile dichiarare un alias per il database in databases.conf (3.0 e versioni successive) o aliases.conf (2.5):
mydb1=c:\Data\test1.fdb #Windows
o
mydb1=/db/test1.fdb #linux
e poi usalo nel comando :
Windows
gbak -b -se localhost:service_mgr mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey
Linux
gbak -b -se localhost:service_mgr mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey
Tempo per il backup: 115 secondi
Per rendere il backup ancora più veloce, aggiungiamo switch -g
-G(ARBAGE_COLLECT) inhibit garbage collection
Quindi, il comando di backup sarà il seguente
Windows
gbak -b -se localhost:service_mgr -g mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey
Linux
gbak -b -se localhost:service_mgr -g mydb1 /db/backup1.fbk -user SYSDBA -pass masterkey
Switch -g forza il motore Firebird a disabilitare la garbage collection per il processo di backup nel file di database.
Ciò non significa che le versioni dei record spazzatura verranno archiviate nel file di backup, significa che il server non tenterà di pulire i rifiuti esistenti nel database durante il backup e il backup sarà più veloce.
Consigliamo vivamente di utilizzare questo interruttore, perché riteniamo che la raccolta dei rifiuti e la pulizia associata debbano essere eseguite mediante sweep (gfix -sweep o autosweep), quindi è meglio non considerare gbak come alcun tipo di alternativa allo sweep.
Tempo per il backup: 105 secondi
E se avessimo bisogno di mettere il file di backup nella condivisione di rete?
Windows
La spesso confusione dei nuovi utenti Firebird: backup manuale (quando si avvia il comando da un prompt dei comandi), con semplice gbak -b, alla condivisione di rete funziona bene, ma la versione veloce di gbak con -se localhost: service_mgr, non funziona .
Il motivo è che Firebird su Windows funziona con l'account LocalSystem, che non ha accesso ai percorsi di rete (a meno che queste condivisioni di rete non abbiano configurato l'accesso per il gruppo "Everyone", ma questo è molto molto pericoloso nella nostra era di ransomware).
La soluzione è eseguire il servizio Firebird su Windows con l'account con diritti sufficienti per accedere alla condivisione di rete e, contemporaneamente, diritti sufficienti per accedere ai file del database locale e ai file di sistema in C: \ ProgramData \ Firebird. Inoltre, una buona idea è configurare il parametro RestrictAccess in firebird.conf.
Linux
Poiché Firebird su Linux funziona con l'account "firebird", monta la condivisione di rete con mappatura all'utente "firebird", in modo che il servizio Firebird possa accedere alla posizione di rete allo stesso modo di un'unità locale.
È possibile eseguire il backup del database dal server remoto alla macchina locale.
Il comando di esempio seguente si avvia su un computer Windows, accede al database su server Linux (con indirizzo IP 192.168.0.108, ma ovviamente si può utilizzare anche il nome host del server) e il file di backup viene archiviato nella cartella C: \ Data on Finestre):
gbak -b -user SYSDBA -pass masterkey 192.168.0.108:/db/test1.fdb c:\data\remotebackup1.fbk
Tempo per ilbackup: 568 secondi
Questo comando di solito sarà molto più lento del backup locale, perché gbak legge i dati dal server remoto e trasferisce i record attraverso la rete.
Il comando seguente è più veloce del backup tradizionale dal server remoto alla macchina locale, descritto in #1.7
gbak -b -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb stdout > C:\Data\remoteback1.fbk
Utilizza Service Manager per eseguire il backup sul server remoto, ma l'output viene inviato alla pipe stdout e quindi reindirizzato al file locale.
Questo comando è in genere più veloce del 15% -20% rispetto a # 1.7 (backup semplice dal server remoto al locale), per i seguenti motivi:
Tuttavia, con questo comando, non è possibile abilitare la modalità dettagliata e memorizzare l'output dettagliato nel file di registro.
Tempo per il backup: 473 secondi
Con Service Manager, è possibile invocare il backup gbak del database sul server remoto e archiviarlo anche sullo stesso server remoto.
gbak -b -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey /db/test1.fdb /db/back12.fbk
Questo comando tramite Service Manager richiama il backup sul server remoto, con l'istruzione di archiviare anche il file di backup sullo stesso server di rete.
Ovviamente, il percorso di backup dovrebbe essere accessibile dal servizio Firebird (su Linux funziona come utente "firebird", su Windows come account LocalSystem).
Abbiamo il file di backup backup1.fbk, creato da uno dei comandi sopra, e dobbiamo ripristinarlo, in modo veloce ed efficiente.
Supponiamo che il file sia in C: \ Data \ backup1.fbk in caso di Windows, o /db/backup1.fbk in caso di Linux.
2.1. Il comando di ripristino più semplice
Windows
gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey
Linux
gbak -c /db/backup1.fbk /db/new1.fdb -user SYSDBA -pass masterkey
Prima di tutto, tieni presente che gbak -c non sovrascrive il file del database e se esiste il file C: \ data \ new1.fdb o /db/new1.fdb, gbak restituirà un errore dicendo che il database esiste già.
Quindi, questo comando funziona effettivamente in modo molto diverso su 2.5 / 3.0 + e Windows / Linux.
Su Linux, questo comando userà l'accesso integrato al database creato (se non hai cambiato in firebird.conf l'ordine dei provider di Firebird, ovviamente) sia per 3.0 che per 2.5.
Su Windows, su Firebird 3.0 con l'ordine predefinito dei provider, sarà integrato l'accesso, su 2.5 - XNET.
Quindi, questo comando crea un file con i diritti dell'utente che ha avviato gbak, è particolarmente importante su Linux: se esegui tale gbak sotto root, il proprietario del file di database sarà root e il processo Firebird, che viene eseguito sotto user "Firebird", non sarà in grado di accedere al file ripristinato.
Note per gli utenti Linux
Molte persone, al fine di "aggiustare" la proprietà, chiedono a tutti il permesso di accedere al database ripristinato, cioè qualcosa come "chmod 777 database", ma questo è molto insicuro, il modo corretto è cambiare il proprietario del database in firebird, con il seguente comando
chown firebird /db/new1.fdb
In generale, questo comando è abbastanza buono per il semplice ripristino di database non di produzione (utilizzati per test o in fase di sviluppo).
Tempo per il restore: 275 secondi
L'opzione di ripristino più universale, ma non la più veloce, è la seguente:
Windows
gbak -c C:\Data\backup1.fbk localhost:C:\data\new1.fdb -user SYSDBA -pass masterkey
Linux
gbak -c /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey
Se Firebird è in esecuzione su una porta non standard, ad esempio 3051, può essere specificato nel comando di ripristino:
Windows
gbak -c C:\Data\backup1.fbk localhost/3051:C:\data\new1.fdb -user SYSDBA -pass masterkey
Linux
gbak -c /db/backup1.fbk localhost/3051:/db/new1.fdb -user SYSDBA -pass masterkey
Tempo per il restore: 1225 secondi
Per rendere il ripristino un po 'più veloce, su Windows possiamo usare XNET (per Firebird 3.0 e superiori):
gbak -c C:\Data\backup1.fbk xnet://C:\Data\New2.fdb -user SYSDBA -pass masterkey
Su Firebird 2.5 su Windows, l'accesso a XNET verrà utilizzato con la semplice riga di comando (se è in esecuzione una sola istanza di Firebird):
gbak -c C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey
Tempo per il restore: 585 secondi
E il modo più veloce per ripristinare è utilizzare Service Manager
Windows
gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new1.fdb -user SYSDBA -pass masterkey
Linux
gbak -c -se localhost:service_mgr /db/backup1.fbk localhost:/db/new1.fdb -user SYSDBA -pass masterkey
Con l'opzione -se, invochiamo Service Manager sull'indirizzo localhost e gli chiediamo di eseguire il codice di ripristino all'interno del motore Firebird.
Quando il ripristino viene eseguito da Service Manager, il file di database creato sarà di proprietà dell'account che esegue l'istanza (processo) Firebird: è "firebird" su Linux e LocalSystem su Windows.
Tempo per il restore: 244 secondi
Ad un certo punto potresti avere la tentazione di utilizzare il seguente interruttore:
-R(ECREATE_DATABASE) create (or replace if OVERWRITE used) database from backup file (restore)
in order to force replacing of the existing database with the new one.
Nella nostra esperienza, questa opzione aumenta notevolmente le possibilità di sovrascrivere accidentalmente il database di produzione.
Si consiglia vivamente di ripristinare il database ogni volta con il nuovo nome e rinominarlo, nonché di eliminare esplicitamente il vecchio database.
Non forniremo nemmeno l'esempio del comando con questo interruttore.
È possibile ripristinare il database utilizzando l'alias, dichiarato in databases.conf (o aliases.conf in Firebird 2.5)
Ad esempio, abbiamo la seguente dichiarazione
restdb=c:\Data\newrest1.fdb #Windows restdb=/db/newrest1.fdb #Linux
Quindi possiamo eseguire il seguente comando per ripristinare il backup nel percorso, specificato dall'alias
Windows
gbak -c -se localhost:service_mgr C:\Data\backup1.fbk restdb -user SYSDBA -pass masterkey
Linux
gbak -c -se localhost:service_mgr /db/backup1.fbk restdb -user SYSDBA -pass masterkey
È possibile ripristinare il file di backup locale sul server Firebird remoto.
In questo esempio, ripristiniamo il file di backup archiviato su Windows, sul server Linux (il suo indirizzo IP 102.168.0.108):
gbak -c C:\Data\backup1.fbk 192.168.0.108:/db/newdb1.fdb -user SYSDBA -pass masterkey
Tempo per il restore: 7009 secondi
Come puoi notare, il processo di ripristino remoto funziona molto lentamente, possiamo velocizzarlo con Service Manager?
Per ripristinare il backup locale sul server remoto con Service Manager, è necessario eseguire il trucco con il flusso di input stdin:
gbak -c -se 192.168.0.108:service_mgr -user SYSDBA -pass masterkey stdin /db/new3.fdb < C:\Data\backup1.fbk
Questo comando richiama il ripristino sul server remoto con lo standard input stdin come origine del backup e fornisce l'input utilizzando la parte <C: \ Data \ backup1.fbk del comando.
Sembra un po 'complicato? Ma è un modo semplice per aumentare di 10 volte le prestazioni di gbak per ripristinarle sul server remoto!
Tempo per il restore: 450 secondi
Se si dispone di un database molto grande con un numero totale di righe superiore a 2 miliardi, è necessario specificare switch -o , per ripristinare ogni tabella nella transazione separata, per evitare un overflow interno.
gbak -c -se localhost:service_mgr -one C:\Data\backup1.fbk C:\data\new44.fdb -user SYSDBA -pass masterkey
Per impostazione predefinita, gbak è uno strumento molto silenzioso, non restituisce nulla in caso di esecuzione riuscita. Per renderlo dettagliato, possiamo aggiungere l'opzione -v
gbak -b -se localhost/3050:service_mgr -g mydb1 c:\Data\backup1.fbk –v -user SYSDBA -pass masterkey
Di conseguenza, ci saranno più dettagli. Il problema minore, ma fastidioso, è che la stampa dell'output sulla console può rendere il backup dettagliato molto più lento rispetto alla variante silenziosa, quindi la buona idea sarà quella di salvare il log nel file con switch -y logfile:
gbak -b -se localhost/3050:service_mgr -g -v mydb1 c:\Data\backup1.fbk -user SYSDBA -pass masterkey -y C:\data\backuplog1.txt
Nota: gbak non sovrascriverà il file di registro esistente! Se hai già C: \ data \ backuplog1.txt in questo esempio, il backup genererà l'errore (vedi # 3 nell'Appendice A).
Nota 2: esiste l'opzione -verbint per controllare l'intervallo per riportare il numero di record elaborati durante il backup o il ripristino.
Nell'output dettagliato di gbak per il backup e il ripristino, possiamo vedere messaggi come questi:
gbak: writing data for table COUNTRY gbak:16 records written
per ogni tabella e altri oggetti di database.
È interessante capire quali tabelle / oggetti impiegano più tempo, giusto?
Per questo, è necessario utilizzare switch -st(atistics):
-ST(ATISTICS) TDRW show statistics:
T time from start
D delta time
R page reads
W page writes
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
Quando applicato, aggiungerà al registro le seguenti colonne:
gbak: time delta reads writes
così saremo in grado di vedere il tempo e l'IO spesi su ogni riga.
Se pensi che alcune tabelle possano essere escluse dal backup (un buon esempio è una tabella di log molto lunga), puoi specificarle nel parametro SK , con un'espressione regolare come parametro.
Nell'esempio seguente, escludiamo i dati dalle tabelle COUNTRY e JOB dal backup:
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
E, nell'esempio seguente, escludiamo la tabella CLIENT dal ripristino:
gbak -c -se localhost:service_mgr C:\Data\backup1.fbk C:\data\new33.fdb -user SYSDBA -pass masterkey -SKIP_D "CLIENT"
Si noti che il parametro SKIP_DATA deve essere trasmesso come parametro singolo, quindi deve essere tra virgolette!
Su Linux, le virgolette dovrebbero essere singole, su Windows - doppie.
Si consiglia vivamente di verificare la condizione dell'espressione regolare prima di utilizzarla, con la seguente query: restituirà un elenco di tabelle che corrispondono alla condizione del filtro (nella query le virgolette sono sempre singole)
SQL> SELECT RDB$RELATION_NAME FROM RDB$RELATIONS WHERE TRIM(RDB$RELATION_NAME) SIMILAR TO '(COUNTRY|JOB)'; RDB$RELATION_NAME =============================== COUNTRY JOB
Tieni presente che le tabelle dal backup o dal ripristino verranno escluse indipendentemente dai vincoli esistenti (chiavi esterne), quindi, se non hai pianificato attentamente tale esclusione, è molto facile ricevere l'errore "Impossibile eseguire il commit dell'indice della chiave esterna" durante il processo di ripristino.
Se non sei un grande fan dell'idea di esporre la password a tutti coloro che vedono i tuoi comandi, ti piacerà il seguente interruttore: -fetch passwordfile
Creiamo il file con la password in C: \ Data \ passfile.txt e usiamolo (qui usiamo una variante incorporata molto semplice, ovviamente, lo switch funzionerà anche con Service Manager):
gbak -b c:\Data\test1.fdb c:\Data\backup5.fbk -user SYSDBA -fetch C:\Data\passfile.txt
Ci sono 2 vantaggi pratici:
Spesso l'obiettivo del backup è eseguire il ripristino immediato, al fine di ottenere il nuovo database fresco, ad esempio, per applicare la nuova dimensione di pagina per il database, o per migrare il database esistente da 2.5 a 3.0.
In questo caso è possibile eseguire il backup-restore con il singolo comando, utilizzando input e output standard come sorgenti per i comandi appropriati, bypassare la creazione del file di backup intermedio, ridurre i requisiti di spazio libero e velocizzare il processo .
Il comando è il seguente:
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 sostanza, qui eseguiamo 2 comandi, uniti dal simbolo |,
il primo per il backup su stdout:
gbak -b -se localhost:service_mgr -g -user SYSDBA -password masterkey C:\Data\test1.fdb stdout
e il secondo, per il ripristino da stdin
gbak -c -se localhost:service_mgr -user SYSDBA -password masterkey stdin C:\Data\new10.fdb
Questo comando è il modo più veloce per eseguire il backup-ripristino sulla stessa istanza di Firebird.
Nota: per convertire database con backup-ripristino in un passaggio da 2.5 a 3.0 è necessario utilizzare 2 istanze di Firebird, see details here.
La figura seguente contiene informazioni sulla velocità dei diversi comandi di backup del backup locale del database di prova:
Come puoi vedere, il modo più veloce per eseguire il backup locale è usare Service Manager (switch -se ) e inibire la garbage collection (switch -ig).
Per il backup dal server remoto alla macchina locale, anche Service Manager è l'opzione migliore:
La situazione con le prestazioni di ripristino è simile: Service Manager è il modo più veloce per ripristinare.
Per quanto riguarda il caso piuttosto raro, quando il ripristino viene eseguito dal backup locale al server remoto, l'utilizzo di Service Manager con il trucco stdin è l'unica scelta praticabile:
Why should I use Firebird backup tools, when there are popular backup tools available which promise to backup everything?
Or, I do backup the complete image of Virtual Machine, why should I bother about backup of Firebird database?
The answer is here.
1) Un tentativo di eseguire gbak senza parametri o con l'utente non proprietario del database / non SYSDBA porterà al seguente errore:
gbak: ERROR:Unable to perform operation. You must be either SYSDBA or owner of the database gbak:Exiting before completion due to errors
2) Se specifichi la password sbagliata, si verificherà il seguente errore:
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
3) Si verifica un errore quando il file esistente viene specificato come destinazione del registro dettagliato
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
4) Si verifica un errore se il database esistente viene specificato nel comando gbak restore come destinazione
gbak: ERROR:database C:\data\new1.fdb already exists. To replace it, use the -REP switch gbak:Exiting before completion due to errors
5) Si verifica un errore quando gbak tenta di scrivere un backup nella posizione in cui non dispone di diritti sufficienti per scrivere.
gbak: ERROR:cannot open file /db/test1.fbk gbak:Exiting before completion due to errors
6) Quando gbak tenta di accedere al file senza il permesso di farlo, ad esempio, il file ha un proprietario diverso dall'utente "firebird" su Linux
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
7) Tenta di utilizzare un output dettagliato
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
8) Tentare di eseguire il backup con Service Manager sul server remoto con il verbose abilitato e l'archiviazione nel file di registro.
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
9) Errore nel ripristino del backup in un passaggio quando il backup non riesce per qualche motivo:
gbak: ERROR:No request from user for stdin data gbak:Exiting before completion due to errors
10) Se stai tentando di passare un non-backup a gbak
gbak: ERROR:unavailable database gbak:Exiting before completion due to errors gbak: ERROR:expected backup description record gbak:Exiting before completion due to errors
11) Il backup di un file di database danneggiato con la pagina sbagliata riporterà il seguente errore (il numero e il file di database saranno diversi, ovviamente)
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