Firebird gbak - варианты командной строки

Как делать правильно, Windows и Linux, замеры скорости.

Что такое gbak?

Gbak - стандартная утилита командной строки СУБД Firebird (см. официальный документ здесь, и статью здесь), предназначенная для 1) создания резервной копии (бэкапа) всей базы данных: Она читает все записи всех таблицы базы данных, и сохраняет (backup) их в файл резервной копии, 2) восстановления данных (restore) из резервной копии в новую базу данных.

Для разработчиков и администраторов с опытом работы с другими СУБД термин "бэкап" может быть неясным, поскольку gbak делает не совсем 100% копию базы данных, а всего-лишь сохраняет данные в файл специфического формата (причем, без содержимого индексов).
Для восстановления базы из резервной копии нужен процесс восстановления также при помощи gbak.

Документация по утилите физического резервного копирования nbackup - здесь.

1. Создание резервных копий с gbak

1.0. Подготовка

Создадим папку C:\data и поместим туда какую-нибудь базы данных. Мы использовали базу нашего теста Firebird OLTP-EMUL test размером 5 гигабайт, но вы можете, конечно, использовать вашу БД. Также вы можете примерно ориентироваться на приведенное время каждой операции для базы размером 5 гигабайт или кратной (10, 20, 100 и т.д.)

Для пользователей Linux – создадим папку /db и поменяем владельца на "firebird", и скопируем туда базу данных (ее владельцем тоже должен быть пользователь firebird).

mkdir /db
chown firebird -R /db

1.1 Простейшая резервная копия командой gbak

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

В этом примере gbak использует доступ к базе данных как embedded.

Firebird 3.0: Embedded-доступ работает по умолчанию для Firebird 3.0, если не указано имя сервера. В режиме SuperServer (в firebird.conf) при такой операции база данных будет заблокирована, и никакой другой коннект не сможет подключиться к БД.

Firebird 2.5: Firebird 2.5 на Windows в этом случае использует протокол XNET. На Linux, Firebird попытается использовать режим embedded, и если он недоступен, автоматически попробует коннект по TCP/IP к локальному серверу. (Если вас интересует что такое XNET, INET, и т.д. - читайте статью Connection Protocols in Firebird 3)

Замечание 1: Эта команда работает из под пользователя операционной системы (т.е. под вашим аккаунтом), и использует разрешения для доступа к базе данных и файлу резервной копии.
Обычно, служба Firebird на Windows работает под аккаунтом LocalSystem, а на Linux - под пользователем “firebird”, но команды в консоли обычно выполняются под вашим аккаунтом.
Если такой аккаунт не имеет прав для доступа к БД или файлу бэкапа, то будет ошибка “Cannot open backup file” (см. пример в Appendix A. Errors, #5).

Note 2: gbak -b молча перезапишет файл резервной копии. Если у вас есть backup1.fbk, то он будет перезаписан.

Note 3: На Linux эта команда создаст файл бэкапа с владельцем, идентичным пользователю консоли, в которой выполняется gbak.

Время выполнения этой команды: 120 seconds

1.2. Локальный онлайн-бэкап на Windows

Этот раздел только для пользователей Windows! Обычно мы хотим сделать резервную копию БД при активно работающих с базой данных пользователях. Поэтому вместо коннекта embedded лучше использовать локальный протокол, чтобы не блокировать базу даных в режиме SuperServer embedded-соединением. Так что лучше использовать протокол XNET.
Для Firebird 3.0:

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

Для Firebird 2.5 можно использовать локальную строку коннекта, это тоже будет использовать протокол XNET:

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

На Linux Firebird не поддерживает протокол XNET, поэтому вместо локального коннекта нужно использовать TCP/IP (см. раздел 1.3).
Также, протокол XNET работает только для одного экземпляра Firebird, так что, если у вас их несколько, то нужно вместо XNET использовать строку коннекта TCP/INET (с указанием номерома порта, если он отличается от 3050) для конкретного экземпляра Firebird.

Длительность бэкапа: 139 секунд

1.3. Бэкап с использованием строки коннекта TCP/IP

Это самый универсальный вариант команды gbak.
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

В этом случае указываем localhost: перед путем и именем базы данных. Коннект происходит через сетевую подсистему Firebird.
Это несколько медленнее локального доступа, но работает всегда, если сервер запущен и ничто не блокирует коннекты к нему.

Нестандартный порт Firebird

Если у вас Firebird работает на нестандартном порту (например 3051 вместо 3050), то нужно добавлять номер порта в строке коннекта:
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

Длительность бэкапа: 182 секунд

1.4. Более быстрый бэкап через Service Manager

Как можно совместить универсальность соединения по TCP/IP (с указанием нестандартного порта) с высокой скоростью бэкапа? Для этого нужно использовать Service Manager! Service Manager - это способ выполнения задач стандартных утилит с помощью самого Firebird. Обратите внимание, что при использовании Service Manager нет необходимости указывать имя сервера для базы данных - это нужно делать только для параметра -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

Эти команды используют опцию -service для указания использования Service Manager экземпляра Firebird на порту 3050.

В этом случае бэкап производится непосредственно процессом Firebird (в коде Firebird есть копия кода gbak (и не только)), и поскольку коммуникация внутри одного процесса гораздо быстрее, то и процесс бэкапа тоже происходит намного быстрее.
Если Firebird работает на нестанадртном порту (например 3051), то команда будет такой:

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

Замечание : В Firebird 2.5 и Firebird 3.0.0-3.0.5 есть ограничение на длину всей командной строки в 256 символов. Ограничение снято только в 3.0.6.

Если вы достигли такого лимита, например, из-за длинных путей и имени базы и бэкапа, вы можете немного сократить строку, если укажете псевдоним базы данных в databases.conf (3.0 и выше) или aliases.conf (2.5):

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

или

mydb1=/db/test1.fdb  #linux

и затем использовать этот псевдоним в командах:
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

Длительность бэкапа : 115 секунд

1.5. Быстрый бэкап с выключением сборки мусора

Чтобы сделать бэкап еще быстрее, добавьте опцию -g

 -G(ARBAGE_COLLECT)    inhibit garbage collection

В этом случае командная строка будет следующей:
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

Опция -g выключает в Firebird проверку на мусорность версий записей и саму сборку мусора в этом коннекте (опция -se тут ни при чем, ее может и не быть как в предыдущих вариантах).
Это не означает, что при отсутствии опции -g в бэкап "попадет мусор". Никакой "мусор" никогда не попадает в бэкап, потому что gbak в своей транзакции, читающей данные из БД и сохраняющей их в бэкап, видит только последние сохраненные (committed) версии записей. А поскольку с опцией -g проверка более старых версий выключена, процесс бэкапа происходит быстрее.

Мы настоятельно рекомендуем использовать эту опцию, т.к. чистка базы от мусора должна производиться операцией sweep (gfix -sweep или autosweep), так что лучше не возлагать на gbak задачу "сборщика мусора".
Также, если база повреждена, и повредились версии записей, опция -g исключит их проверку, и бэкап такой базы может быть успешным, в отличие от бэкапа без опции -g.

Длительность бэкапа : 105 секунд

1.6. Бэкап на сетевой ресурс

Что если нам нужно сделать бэкап не на локальный диск, а на сетевой ресурс?

На Windows
Частая ошибка пользователей Firebird: выполнение обычного gbak -b с указанием бэкапа на сетевой ресурс работает, а более быстрый вариант -se localhost:service_mgr - не работает.
Причина - служба Firebird на Windows работает под пользователем LocalSystem, который не имеет и не может получить доступ к сетевым ресурсам (разве что если сетевой ресурс выдан группе "Все" ("Everyone"), но это весьма опасно делать в нынешние времена с шифровальщиками и прочим вредоносным ПО).
Решением здесь может быть запуск службы Firebird под явно созданным аккаунтом, которому выданы соответствующие права на нужный сетевой ресурс, локальные базы, и в том числена файлы в C:\ProgramData\Firebird. Также хорошей идеей является настройка параметра DatabaseAccess в firebird.conf.
На Linux
Поскольку на Linux Firebird работает под аккаунтом "firebird", монтируйте сетевые ресурсы с отображением пользователю "firebird", в результате чего служба Firebird будет иметь доступ как к локальному диску, так и к сетевому ресурсу.

1.7. Простой бэкап с удаленного сервера на локальный компьютер

Сделать это достаточно просто.
Вот пример команды для Windows, которая делает резервную копию базы с сервера Linux (с адресом IP 192.168.0.108, но можно использовать и доменное имя сервера, конечно) в локальную папку C:\Data на Windows):

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

Длительность бэкапа : 568 секунд

Эта операция выполняется сильно дольше чем локальный бэкап, потому что gbak пересылает данные по сети с удаленного сервера на локальный компьютер. Для баз размером в сотни гигабайт это будет крайне долго.

1.8. Быстрый бэкап с удаленного сервера на локальный через Service Manager

Следующая команда работает быстрее, чем обычный бэкап с удаленного сервера на локальный компьютер, приведенный в примере выше #1.7

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

Здесь используется Service Manager для создания резервной копии на удаленном сервере, но вывод отправляется в stdout, откуда направляется в локальный файл.
Эта команда примерно на 15-20% быстрее, чем пример в пункте #1.7, потому что:

она производит бэкап на удаленном сервере через Service Manager, в результате чего чтение и сжатие происходят быстрее
по сети пересылается только содержимое файла бэкапа, который обычно меньше чем объем данных в базе данных

Однако, при таком способе нельзя использовать опцию -v утилиты gbak.

Длительность бэкапа : 473 секунд

1.9. Бэкап базы на удаленном компьютере через Service Manager

Используя Service Manager очень просто указать gbak сделать резервную копию базы данных на удаленном сервере, и поместить бэкап там же.

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

Эта команда инициирует бэкап на удаленном сервере через Service Manager, при этом пути и имя базы и бэкапа являются локальными для удаленного сервера.
Разумеется, расположение бэкапа должно быть доступно (по правам доступа) службе Firebird (работающей на Linux под пользователем "firebird", на Windows - под LocalSystem).

1.10. Бэкап до 6 раз быстрее с использованием многопоточности Firebird 5 или HQbird 2.5/3.0/4.0

Если вы всё еще недовольны производительностью бэкапа, рассмотрите возможность миграции на Firebird 5 (или используйте HQbird для версий 2.5, 3.0, 4.0).
Эта версия Firebird поддерживает многопоточный бэкап, который ускоряет обычный бэкап до 6ти раз.

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

Как видите, в командной строке указан новый параметр -par 8, который указывает gbak использовать 8 потоков для создания бэкапа.
С этим параметром Firebird 5 и HQbird (в редакции Enterprise) выполняет sweep, backup и restore гораздо быстрее (результаты приведены на картинке, для другой базы данных):

2. Восстановление базы из резервной копии

! Несмотря на то, что здесь и далее используется термин "восстановление", на самом деле restore это не совсем восстановление. Restore это последовательность операций

создание новой пустой базы данных с параметрами оригинальной базы из бэкапа (размер страницы, forced writes on/off, sweep interval, и т.д.).
Формат этой базы данных будет соответствовать той версии Firebird, на которой вы делаете восстановление из бэкапа.
заливка метаданных из бэкапа (объектов БД - таблиц, процедур, триггеров, view и проч.)
заливка данных из бэкапа
активация индексов

Таким образом, при восстановлении БД из бэкапа вы всегда получите новую БД со старыми данными (теми, которые существовали на момент бэкапа в старой БД).

Допустим, у нас есть резервная копия backup1.fbk, созданная одной из команд выше, и нам нужно из нее восстановить базу данных.

Предположим, что этот файл находится на диске как C:\Data\backup1.fbk в случае Windows, или /db/backup1.fbk в случае Linux.

2.1. Самая простая команда

На 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

Обратите внимание, что параметр -c не перезапишет существующую базу данных, если на диске уже есть C:\data\new1.fdb или /db/new1.fdb. Gbak вернет ошибку, что такая база данных уже есть.

При этом, команда работает по разному на версиях 2.5/3.0+ и Windows/Linux.

На Linux, эта команда будет использовать embedded-доступ для создания базы данных (если вы не меняли порядок провайдеров в firebird.conf), как 3.0 так и 2.5.

На Windows, Firebird 3.0 со стандартным порядком провайдеров будет использовать embedded-доступ, а 2.5 – XNET.

Эта команда создаст базу данных с правами того, кто стартовал gbak, и это особенно важно для Linux – если вы запускаете такую команду под рутом (root), владельцем файла базы данных будет root, и далее Firebird, работающий под пользователем "firebird", не сможет получить доступ к этой базе данных (речь именно о владельце файла БД, а не об имени владельца БД в смысле SQL).

Замечание для пользователей Linux
Многие, с целью "исправить" владельца файла, применяют права всех для созданной базы данных, например "chmod 777 database", но это небезопасно. Правильно будет поменять владельца файла именно на пользователя "firebird"

chown firebird /db/new1.fdb

В целом, команда простая и достаточная для баз, находящихся в разработке или тестировании.

Длительность : 275 секунд

2.2. Восстановление базы с localhost

Наиболее универсальной, но не быстрой, является команда:
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

Нестандартный порт

Если Firebird работает на нестандартном порту, например 3051, порт можно указать так же как и для бэкапа:
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

Длительность команды : 1225 секунд

2.3. Восстановление базы через XNET на Windows

Чтобы восстановление шло побыстрее, на Windows мы можем использовать явное указание протокола XNET (для Firebird 3.0 и выше):

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

В Firebird 2.5 на Windows протокол XNET и так будет использован, если указано имя базы без имени сервера:

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

Длительность команды : 585 секунд

2.4. Быстрое восстановление через Service Manager

Самый быстрый способ восстановления - использовать 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

С опцией -se, мы командуем через Service Manager серверу на localhost выполнить восстановление БД. Пути к базе и бэкапу должны быть локальными, как и в случае бэкапа.

При восстановлении БД через Service Manager у созданного файла БД будут права пользователя Firebird - "firebird" на Linux, и LocalSystem на Windows (если на Windows Firebird работает не под специально созданным пользователем.

Длительность команды : 244 секунды

2.5. Не рекомендуемые опции

В какой-то момент вы можете захотеть использовать опции:

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

или

   -REP(LACE_DATABASE)						replace database from backup file (restore)

с целью принудительной замены существующей базы данных на восстанавливаемую из бэкапа.

По нашему опыту, эти опции весьма увеличивают шанс перезаписать вашу рабочую БД (особенно, если -r или -rep вы привыкли использовать при тестировании или разработке БД. Такая привычка - плохая).

Мы крайне рекомендуем восстанавливать БД из бэкапа в базу с новым именем, или вначале переименовывать существующую БД, а уже потом удалять "старую БД", если это необходимо (на Linux переименование БД с существующими коннектами ничего не изменит, и эти коннекты продолжат работу со старой БД).

Так что, мы не будем давать примеров использования этих опций.

2.6. Восстановление базы с использованием псевдонима

При восстановлении БД можно использовать псевдоним, объявленный в databases.conf (или в aliases.conf для Firebird 2.5)

Например, у нас есть такое определение:

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

restdb=/db/newrest1.fdb  #Linux

Значит, мы можем использовать следующие команды для восстановления БД
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

2.7. Восстановление локального бэкапа на удаленный сервер

Есть возможность восстановить локальный бэкап на удаленный сервер Firebird.

В этом примере мы восстанавливаем бэкап, хранимый на Windows, в базу данных на сервере Linux (с адресом IP 102.168.0.108):

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

Длительность восстановления : 7009 секунд

Как вы можете заметить, такое восстановление очень медленное, его можно ускорить с помощью Service Manager.

2.8. Восстановление локального бэкапа на удаленный сервер через Service Manager

Для восстановления локального бэкапа на удаленный сервер через Service Manager необходимо использовать трюк с входным потоком stdin:

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

Эта команда перенаправляет файл бэкапа в stdin на удаленном сервере.

Выглядит странновато, но позволяет ускорить восстановление БД почти в 15 раз.
Длительность восстановления : 450 секунд

2.9. Восстановление очень больших таблиц

Если у вас действительно большая база данных с более чем 2 миллиардов записей в таблицах необходимо указать опцию -o[ne_at_a_time] для восстановления каждой таблицы в отдельной транзакции (для исключения переполнения некоторых внутренних структур).

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

3. Логирование бэкапа и рестора

3.1. Gbak с подробным выводом

По умолчанию gbak достаточно молчаливая утилита, даже не выводит сообщения об успешном завершении процесса. Чтобы получить детальный вывод, нужно добавить опцию -v[erify]

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

В результате вы увидите массу подробностей. Минусом здесь является некоторое замедление процесса, в отличие от работы gbak без вывода, так что лучше подробный вывод направлять не на консоль, а в файл опцией -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

Note: gbak не будет перезаписывать существующий лог! Если у вас уже есть C:\data\backuplog1.txt, как в этом примере, то будет выдана ошибка (см. #3 в Приложении А).
Note 2: есть дополнительная опция -verbint n для сокращения вывода о количестве сохраняемых или восстанавливаемых записей. Например, ... -verbint 1000000.

3.2. Добавляем статистику производительности к подробному выводу

В случае подробного вывода при бэкапе или восстановлении мы видим сообщения вроде:

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

для каждой таблицы и других объектов базы даных.
Гораздо интереснее получать информацию, сколько времени заняло сохранение или восстановление конкретного объекта.

Для этого используйте опцию -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

Когда указана эта опция, в логе появятся столбцы:

gbak: time   delta  reads  writes

По которым можно понять длительность и объем ввода-вывода для каждого объекта.

3.3. Исключение таблиц из бэкапа или при восстановлении

В базе данных могут быть таблицы типа логов, которые вам не нужно сохранять в бэкап или восстанавливать в новую БД. Так что можно указать опцию -SK[IP_DATA] с параметром в виде регулярного выражения.

В примере ниже мы исключаем таблицы COUNTRY и JOB из бэкапа::

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

В следующем примере мы исключаем таблицу CLIENT при восстановлении из бэкапа:

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

Обратите внимание, что параметры для SKIP_DATA должны быть переданы как единое целое, поэтому должны быть обрамлены кавычками!
Причем, на Linux, кавычки должны быть одинарными, а на Windows –двойными.

Осторожность при исключении таблиц из бэкапа или восстановления

Мы настоятельно рекомендуем проверять регулярное выражение исключения таблиц перед его использованием. Сделать это можно следующим запросом – он вернет список таблиц в соответствии с условием фильтра(в запросе нужно использовать одинарные кавычки независимо от Windows или Linux)

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

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

Обратите внимание, что таблицы будут исключены из бэкапа или восстановления независимо от существующих ограничений целостности (Foreign Keys), поэтому есть риск получить ошибку “Cannot commit foreign key index” во время восстановления из бэкапа.

3.4. Получение пароля из файла

Иногда нужно прятать пароль пользователя в командах при бэкапе и восстановлении. Для этого есть опция -fetch passwordfile

Создадим файл с паролем SYSDBA в файле C:\Data\passfile.txt и используем его в простом варианте бэкапа (опция работает и с использованием Service Manager):

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

Есть 2 преимущества у такого способа:

Мы храним пароль в одном файле, и можем быть уверены что все команды будут использовать актуальный пароль
Мы не показываем пароль в каждой командной строке

4. Потоковый backup-restore

Часто после бэкапа нужно сразу сделать восстановление, чтобы получить новую базу данных, или чтобы убедиться, что бэкап восстанавливается без проблем. Например, нужно изменить размер страницы БД, или мигрировать с одной версии Firebird на другую (допустим, с 2.5 на 3.0).

В этом случае есть возможность сделать бэкап-рестор одной командой, используя потоки ввода-вывода без создания промежуточного файла бэкапа. В этом случае не требуется дисковое пространство для файла бэкапа, а также сокращается время бэкапа-рестора.
Пример команды:

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

Как видите, здесь две команды, объединенные символом |,
сначала идет бэкап в stdout:

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

а затем идет восстановление из stdin

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

Эта команда является самой быстрой для бэкапа-рестора на одном экземпляре Firebird.

Для конвертации баз из одной версии Firebird в другую, например из 2.5 в 3.0, необходимо использовать два экземпляра Firebird, более подробно метод описан в статье.

5. Итог по производительности

На картинке приведена информация о разной скорости бэкапа тестовой базы данных разными командами:

Как видите, самый быстрый способ сделать бэкап, это использовать Service Manager (опция -se[rvice]) и выключить сборку мусора (опция -g).

Для бэкапа с удаленного сервера на локальный компьютер Service Manager также является лучшим вариантом:

С восстановлением ситуация аналогична - Service Manager самый быстрый способ.

В редких случаях, когда восстановление делается из локального файла на удаленный сервер, использование Service Manager с stdin является единственным вариантом по скорости:

Ответ на очень частый вопрос про VM (виртуальные машины) и бэкапы баз Firebird

Зачем мне использовать утилиты gbak или nbackup, если есть куча инструментов для файлового бэкапа чего угодно?

или

Я делаю бэкап образа диска виртуальной машины, зачем мне думать еще и про бэкап базы Firebird?

Краткий ответ: база данных Firebird это файл случайного доступа (random-access file), поэтому он может быть корректно скопирован внешними средствами только если служба Firebird остановлена (т.е. файл БД не открыт службой Firebird). А бэкапы дисков виртуальных машин сохраняют копию БД в состоянии, аналогичном после нажатия кнопки Reset. Поэтому для бэкапа дисков виртуальных машин для БД Firebird нужно выполнять дополнительные действия (см. описание утилиты nbackup).

Приложение А . Ошибки при бэкапе/восстановлении

1) Запуск gbak без параметров, или с некорректным именем пользователя:

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

2) Неверный пароль:

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) Указан существующий файл для подробного вывода

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) При восстановлении указано имя существующего файла БД

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

5) У gbak/Service Manager нет прав доступа в целевую папку

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

6) У gbak нет прав доступа к файлу БД

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) Попытка использовать подробный вывод при бэкапе в stdout

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -b -g -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) Попытка бэкапа через Service Manager в stdout с подробным выводом.

C:\HQbird\Firebird30>gbak -se 192.168.0.108:service_mgr -b -g -v -st tdrw -y lg1.txt  -user SYSDBA -pass masterkey /db/test1.fdb 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) Ошибка в процессе потокового бэкапа-рестора:

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

10) Бэкап некорректного формата (или не бэкап вообще)

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) Бэкап поврежденной БД (с повреждением какой-либо страницы БД)

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

12) восстановление бэкапа Firebird 5 в Firebird 3

gbak: ERROR:Expected backup version 1..10.  Found 11
gbak:Exiting before completion due to errors

Дополнительно

Контакты

Остались вопросы, или заметили ошибку в тексте? Пишите на support@ibase.ru

Как делать правильно, Windows и Linux, замеры скорости.

Что такое gbak?

1. Создание резервных копий с gbak

1.0. Подготовка

1.1 Простейшая резервная копия командой gbak

1.2. Локальный онлайн-бэкап на Windows

1.3. Бэкап с использованием строки коннекта TCP/IP

Нестандартный порт Firebird

1.4. Более быстрый бэкап через Service Manager

1.5. Быстрый бэкап с выключением сборки мусора

1.6. Бэкап на сетевой ресурс

1.7. Простой бэкап с удаленного сервера на локальный компьютер

1.8. Быстрый бэкап с удаленного сервера на локальный через Service Manager

1.9. Бэкап базы на удаленном компьютере через Service Manager

1.10. Бэкап до 6 раз быстрее с использованием многопоточности Firebird 5 или HQbird 2.5/3.0/4.0

2. Восстановление базы из резервной копии

2.1. Самая простая команда

2.2. Восстановление базы с localhost

Нестандартный порт

2.3. Восстановление базы через XNET на Windows

2.4. Быстрое восстановление через Service Manager

2.5. Не рекомендуемые опции

2.6. Восстановление базы с использованием псевдонима

2.7. Восстановление локального бэкапа на удаленный сервер

2.8. Восстановление локального бэкапа на удаленный сервер через Service Manager

2.9. Восстановление очень больших таблиц

3. Логирование бэкапа и рестора

3.1. Gbak с подробным выводом

3.2. Добавляем статистику производительности к подробному выводу

3.3. Исключение таблиц из бэкапа или при восстановлении

Осторожность при исключении таблиц из бэкапа или восстановления

3.4. Получение пароля из файла

4. Потоковый backup-restore

5. Итог по производительности

Ответ на очень частый вопрос про VM (виртуальные машины) и бэкапы баз Firebird

Приложение А . Ошибки при бэкапе/восстановлении

Дополнительно

Контакты

Подпишитесь на новости Firebird в России