Короткий посібник з резервного копіювання та відновлення Gbak

Що таке gbak?

Gbak - це стандартний інструмент командного рядка Firebird (див. його офіційну документацію тут), призначений для виконання 1) повного резервного копіювання бази даних: він читає кожен запис у базі даних і зберігає їх у файл резервної копії, 2) відновлення резервної копії в нову базу даних.

Для розробників та адміністраторів з досвідом роботи з іншими СКБД термін «резервне копіювання» може бути дещо заплутаним, оскільки gbak створює не точну копію бази даних, а файл у не-базовому форматі, лише з даними (індекси зберігаються як декларації).

Щоб створити базу даних з файлу резервної копії gbak, необхідно виконати процес відновлення за допомогою gbak.

1. Освоюємо резервне копіювання за допомогою Gbak

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

Створімо папку C:\data і покладемо туди якусь базу даних. Ми використаємо базу даних 5 ГБ з Firebird OLTP-EMUL тесту, але ви, звичайно, можете використати власну базу даних.

Для користувачів Linux - створімо папку /db і змініть її власника на «firebird», і скопіюйте туди базу даних (переконайтеся, що її власник також firebird).

Code

mkdir /db
chown firebird -R /db

1.1 Найпростіше резервне копіювання Firebird за допомогою команди gbak

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

У цьому прикладі інструмент gbak отримує доступ до файлу бази даних за допомогою локального або вбудованого доступу.

Firebird 3.0: Вбудований доступ у стандартній конфігурації для Firebird 3.0 (з параметром у firebird.conf ServerMode = SuperServer) спробує встановити ексклюзивне блокування бази даних, тому інші підключення не зможуть отримати доступ до бази даних (або спроба gbak завершиться невдачею через активні підключення).

Firebird 2.5: З Firebird 2.5 на Windows команда працюватиме нормально через протокол XNET (якщо у вас запущено лише один екземпляр Firebird, звичайно). На Linux Firebird спробує використати вбудований доступ; якщо він недоступний, він автоматично (і неявно) спробує підключитися через TCP/IP. (Якщо ви не знаєте, що означає XNET, INET тощо, будь ласка, перегляньте Шпаргалку з рядків підключення Firebird).

Примітка 1: Ця команда виконується від імені користувача ОС (тобто вашого) і використовує його права для доступу до файлів резервної копії та бази даних.

Зазвичай служба Firebird на Windows працює з обліковим записом LocalSystem, а на Linux - від користувача «firebird», але консоль зазвичай запускається від вашого власного облікового запису користувача.

Якщо цей обліковий запис користувача не має доступу до шляху бази даних або шляху резервної копії, gbak завершиться з помилкою «Cannot open backup file» (див. приклад у Додатку A. Помилки, #5).

Примітка 2: gbak -b мовчки перезаписує файл резервної копії. Отже, якщо у вас уже є backup1.fbk, він буде перезаписаний.

Примітка 3: На Linux ця команда gbak створить файл резервної копії з власником, рівним користувачу консолі.

Час резервного копіювання для цієї команди: 120 секунд

1.2. Локальне резервне копіювання за допомогою gbak, яке можна виконувати онлайн на Windows

Цей розділ призначений лише для користувачів Windows! Зазвичай нам потрібно виконувати резервне копіювання, коли є активні підключення до бази даних, тому замість вбудованого підключення краще явно вказати локальний протокол, щоб уникнути встановлення ексклюзивного блокування файлу бази даних самим gbak у Firebird 3, тобто XNET.

Для Firebird 3.0:

Code

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

Для Firebird 2.5 ми можемо використати локальний рядок підключення, і він також використає XNET:

Code

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

На Linux Firebird не підтримує специфічний локальний протокол, як XNET на Windows, тому необхідно використовувати рядок підключення TCP/IP (див. розділ 1.3).

Також XNET працює лише для одного екземпляра Firebird, тому якщо ви запускаєте кілька екземплярів Firebird на Windows, може бути простіше використати рядок підключення у стилі INET, щоб вказати цільовий екземпляр сервера.

Час резервного копіювання: 139 секунд

1.3. Резервне копіювання за допомогою gbak з рядком підключення TCP/IP

Це найуніверсальніша команда gbak для виконання резервного копіювання онлайн.

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

У цьому випадку, вказавши localhost: на початку шляху до бази даних, підключення виконується через мережеву підсистему Firebird.

Це трохи повільніше, ніж локальний доступ, але працює у всіх випадках, коли у нас є запущений сервер, який приймає підключення.

Нестандартний порт для Firebird

Якщо у вас Firebird працює на нестандартному порту (наприклад, 3051 замість 3050), ви можете виконати резервне копіювання таким чином:

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

Час резервного копіювання: 182 секунди

1.4. Швидше резервне копіювання за допомогою gbak із Service Manager

Як досягти універсальності TCP/IP-з’єднання з підтримкою нестандартного порту та швидкого локального резервного копіювання? Скористаймося Service Manager! Service Manager, простими словами, - це спосіб запуску стандартних інструментів через рушій Firebird. Зверніть увагу, що у випадку Service Manager немає потреби вказувати ім’я сервера в шляху до бази даних, лише в параметрі -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

Ця команда використовує перемикач -service, щоб указати, що ми хочемо використати Service Manager екземпляра Firebird на порту 3050 для виконання резервного копіювання.

У цьому випадку резервне копіювання виконуватиметься безпосередньо всередині процесу Firebird (він містить копію коду gbak), а оскільки внутрішньопроцесна комунікація набагато швидша, резервне копіювання в цьому випадку буде значно швидшим.

Якщо Firebird працює на нестандартному порту (наприклад, 3051), команда може виглядати так:

Code

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 (знято лише у 3.0.6): командний рядок (усі параметри та шляхи до бази даних і резервної копії) має бути коротшим за 256 символів.

Якщо ви впираєтеся в це обмеження, наприклад, через довгі шляхи до бази даних і резервної копії, ви можете оголосити псевдонім для бази даних у databases.conf (3.0 і вище) або aliases.conf (2.5):

Code

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

або

Code

mydb1=/db/test1.fdb  #linux

і потім використати його в нашій команді:

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

Час резервного копіювання: 115 секунд

1.5. Найшвидше резервне копіювання за допомогою gbak із вимкненим збиранням сміття

Щоб зробити резервне копіювання ще швидшим, додамо перемикач -g

Code

 -G(ARBAGE_COLLECT)    inhibit garbage collection

Отже, команда резервного копіювання буде такою:

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

Перемикач -g змушує рушій Firebird вимкнути збирання сміття для процесу резервного копіювання у файлі бази даних.

Це не означає, що сміттєві версії записів зберігатимуться у файлі резервної копії; це означає, що сервер не намагатиметься очищати наявне сміття в базі даних під час резервного копіювання, і резервне копіювання буде швидшим.

Ми наполегливо рекомендуємо використовувати цей перемикач, оскільки вважаємо, що збирання сміття та пов’язане з ним очищення має виконуватися за допомогою sweep (gfix -sweep або autosweep), тому краще не розглядати gbak як альтернативу sweep.

Час резервного копіювання: 105 секунд

1.6. Резервне копіювання на мережевий ресурс або мережеве розташування

Що робити, якщо нам потрібно розмістити файл резервної копії на мережевому ресурсі?

У Windows

Часте непорозуміння нових користувачів Firebird: ручне резервне копіювання (коли ви запускаєте команду з командного рядка) за допомогою простого gbak -b на мережевий ресурс працює нормально, але швидка версія gbak із -se localhost:service_mgr не працює.

Причина в тому, що Firebird у Windows працює під обліковим записом LocalSystem, який не має доступу до мережевих розташувань (якщо ці мережеві ресурси не налаштовані на доступ для групи «Everyone», але це дуже і дуже небезпечно в нашу епоху програм-вимагачів).

Рішення - запускати службу Firebird у Windows під обліковим записом із достатніми правами для доступу до мережевого ресурсу та, водночас, достатніми правами для доступу до локальних файлів бази даних і системних файлів у C:\ProgramData\Firebird. Також гарною ідеєю буде налаштувати параметр RestrictAccess у firebird.conf.

У Linux

Оскільки Firebird у Linux працює під обліковим записом «firebird», змонтуйте мережевий ресурс із зіставленням користувача «firebird», щоб служба Firebird могла отримати доступ до мережевого розташування так само, як до локального диска.

1.7. Просте резервне копіювання з віддаленого сервера на локальну машину

Можливо виконати резервне копіювання бази даних з віддаленого сервера на локальну машину.

Приклад команди нижче запускається на комп’ютері з Windows, отримує доступ до бази даних на сервері Linux (з IP-адресою 192.168.0.108, але також можна використовувати ім’я хоста сервера, звісно), а файл резервної копії зберігається в папку C:\Data на Windows:

Code

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

Code

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 на віддаленому сервері, тому всі операції читання та стиснення виконуються найшвидшим способом,
через мережу передається лише результуючий файл резервної копії, розмір якого менший за обсяг даних у базі даних

Однак за допомогою цієї команди неможливо увімкнути докладний режим і зберегти детальний вивід у файл журналу.

Час резервного копіювання: 473 секунди

1.9. Резервне копіювання бази даних Firebird на віддаленому сервері на той самий віддалений сервер за допомогою Service Manager

За допомогою Service Manager можна викликати резервне копіювання gbak бази даних на віддаленому сервері та зберегти його також на тому самому віддаленому сервері.

Code

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. Резервне копіювання бази даних Firebird у 6 разів швидше за допомогою багатопотокового резервного копіювання у Firebird 5 (або HQbird 2.5/3.0/4.0/5.0)

Якщо ви досі не задоволені продуктивністю резервного копіювання Firebird gbak, розгляньте можливість переходу на Firebird 5 (або використання корпоративного дистрибутива Firebird: HQbird для інших версій).

Він підтримує багатопотокове резервне копіювання, що дозволяє пришвидшити операції резервного копіювання з gbak до 6 разів.

Code

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 потоків для створення резервної копії.

HQbird виконує завдання з обслуговування (sweep, резервне копіювання, відновлення) набагато швидше (результати на рисунку нижче, звісно, з іншої бази даних):

2. Відновлення за допомогою інструмента Gbak

У нас є файл резервної копії backup1.fbk, створений однією з команд вище, і нам потрібно відновити його швидко та ефективно.

Припустімо, що файл знаходиться у C:\Data\backup1.fbk у випадку Windows або /db/backup1.fbk у випадку Linux.

2.1. Найпростіша команда відновлення

У Windows

Code

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

У Linux

Code

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

Перш за все, зверніть увагу, що gbak -c не перезаписує файл бази даних, і якщо існує файл C:\data\new1.fdb або /db/new1.fdb, gbak поверне помилку про те, що база даних уже існує.

Тоді ця команда насправді працює зовсім по-різному на 2.5/3.0+ та Windows/Linux.

На Linux ця команда використовуватиме вбудований доступ до створеної бази даних (якщо ви, звісно, не змінили в firebird.conf порядок провайдерів Firebird) як для 3.0, так і для 2.5.

На Windows, на Firebird 3.0 з типовим порядком провайдерів, це буде вбудований доступ, на 2.5 - XNET.

Далі, ця команда створює файл з правами користувача, який запустив gbak, це особливо важливо на Linux - якщо ви запускаєте такий gbak від root, власником файлу бази даних буде root, і процес Firebird, який працює під користувачем “firebird”, не зможе отримати доступ до відновленого файлу.

Примітка для користувачів Linux

Багато людей, щоб “виправити” право власності, надають доступ усім до відновленої бази даних, тобто щось на кшталт “chmod 777 database”, але це дуже небезпечно, правильний спосіб - змінити власника бази даних на firebird за допомогою наступної команди

Code

chown firebird /db/new1.fdb

Загалом, ця команда достатньо хороша для простого відновлення невиробничих баз даних (використовуваних для тестування або розробки).

Час відновлення: 275 секунд

2.2. Відновлення з рядком підключення localhost

Найбільш універсальний, але не найшвидший варіант відновлення:

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

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

Якщо Firebird працює на нестандартному порту, наприклад, 3051, його можна вказати в команді відновлення:

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

Час відновлення: 1225 секунд

2.3. Відновлення з XNET на Windows

Щоб зробити відновлення трохи швидшим, на Windows ми можемо використати XNET (для Firebird 3.0 і вище):

Code

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

На Firebird 2.5 на Windows доступ XNET буде використано з простим рядком команди (якщо запущено лише один екземпляр Firebird):

Code

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

Час відновлення: 585 секунд

2.4. Швидше відновлення з Service Manager

І найшвидший спосіб відновлення - використання 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

З перемикачем -se ми викликаємо Service Manager на адресі localhost і доручаємо йому виконати код відновлення всередині рушія Firebird.

Коли відновлення виконується Service Manager, створений файл бази даних належатиме обліковому запису запущеного екземпляра Firebird (процесу) - це “firebird” на Linux і LocalSystem на Windows.

Час відновлення: 244 секунди

2.5. Не рекомендований перемикач

У якийсь момент у вас може виникнути спокуса використати наступний перемикач:

Code

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

Code

щоб примусово замінити існуючу базу даних новою.

На наш досвід, цей перемикач значно збільшує шанси випадково перезаписати виробничу базу даних.

Ми наполегливо рекомендуємо щоразу відновлювати базу даних з новою назвою та перейменовувати її, а також явно видаляти стару базу даних.

Ми навіть не наводитимемо приклад команди з цим перемикачем.

2.6. Відновлення бази даних за допомогою аліаса

Можливо відновити базу даних, використовуючи аліас, оголошений у databases.conf (або aliases.conf у Firebird 2.5)

Наприклад, ми маємо наступне оголошення

Code

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

restdb=/db/newrest1.fdb  #Linux

Отже, ми можемо виконати наступну команду для відновлення резервної копії до шляху, вказаного аліасом

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. Відновлення локальної резервної копії на віддаленому сервері

Можливо відновити локальний файл резервної копії на віддаленому сервері Firebird.

У цьому прикладі ми відновлюємо файл резервної копії, збережений на Windows, на сервері Linux (його IP-адреса 102.168.0.108):

Code

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:

Code

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

Ця команда викликає відновлення на віддаленому сервері зі стандартним введенням stdin як джерелом резервної копії - і подає введення за допомогою частини команди < C:\Data\backup1.fbk.

Виглядає трохи складно? Але це простий спосіб збільшити продуктивність gbak у 10 разів для відновлення на віддаленому сервері!

Час відновлення: 450 секунд

2.9. Відновлення надзвичайно довгих таблиць

Якщо у вас справді велика база даних із загальною кількістю рядків понад 2 мільярди, необхідно вказати перемикач -o[ne_at_a_time], щоб відновлювати кожну таблицю в окремій транзакції, щоб уникнути внутрішнього переповнення.

Code

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]

Code

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

У результаті буде більше деталей. Незначна, але дратівлива проблема полягає в тому, що виведення на консоль може зробити докладне резервне копіювання значно повільнішим, ніж мовчазний варіант, тому гарною ідеєю буде зберегти журнал у файл за допомогою перемикача - 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

Примітка: gbak не перезаписуватиме існуючий файл журналу! Якщо у вас уже є C:\data\backuplog1.txt у цьому прикладі, резервне копіювання видасть помилку (див. #3 у Додатку A).

Примітка 2: існує опція -verbint для керування інтервалом звітування про кількість оброблених записів під час резервного копіювання або відновлення.

3.2. Додавання статистики продуктивності до докладного виводу

У докладному виводі gbak для резервного копіювання та відновлення ми можемо бачити повідомлення, як-от:

Code

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

для кожної таблиці та інших об’єктів бази даних.

Цікаво з’ясувати, які таблиці/об’єкти займають найбільше часу, чи не так?

Для цього необхідно використати перемикач -st(atistics):

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

Після застосування до журналу буде додано наступні стовпці:

Code

gbak: time   delta  reads  writes

тож ми зможемо бачити час та операції введення/виведення, витрачені на кожен рядок.

3.3. Виключення таблиць із резервного копіювання та/або з відновлення

Якщо ви вважаєте, що деякі таблиці можна виключити з резервного копіювання (гарний приклад - дуже довга таблиця журналу), ви можете вказати їх у параметрі SK[IP_DATA], використовуючи регулярний вираз як параметр.

У наведеному нижче прикладі ми виключаємо дані з таблиць COUNTRY та JOB з резервної копії:

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

А в наведеному нижче прикладі ми виключаємо таблицю CLIENT з відновлення:

Code

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

Зверніть увагу, що параметр для SKIP_DATA має передаватися як єдиний параметр, тому він має бути в лапках!

У Linux лапки мають бути одинарними, у Windows - подвійними.

Запобіжні заходи щодо виключення таблиць з резервної копії та/або відновлення

Ми наполегливо рекомендуємо перевірити умову регулярного виразу перед її використанням за допомогою наступного запиту - він поверне список таблиць, які відповідають умові фільтра (у запиті лапки завжди одинарні):

Code

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

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

Зверніть увагу, що таблиці будуть виключені з резервної копії або відновлення незалежно від наявних обмежень (зовнішніх ключів), тому, якщо ви не спланували таке виключення ретельно, дуже легко отримати помилку “Cannot commit foreign key index” під час процесу відновлення.

3.4. Отримання пароля для резервної копії або відновлення з файлу

Якщо вам не подобається ідея показувати пароль усім, хто бачить ваші команди, вам сподобається наступний перемикач: -fetch passwordfile

Створімо файл з паролем у C:\Data\passfile.txt і використаємо його (тут ми використовуємо дуже простий вбудований варіант; звичайно, перемикач також працюватиме з Service Manager):

Code

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

Є 2 практичні переваги:

Якщо ми зберігаємо пароль в одному файлі, ми можемо гарантувати, що всі наші командні файли завжди використовуватимуть актуальний пароль.
Ми не показуємо пароль у кожному командному файлі.

4. Резервне копіювання-відновлення за один крок

Часто метою резервної копії є негайне відновлення, щоб отримати нову свіжу базу даних, наприклад, для застосування нового розміру сторінки для бази даних або для міграції існуючої бази даних з версії 2.5 на 3.0.

У цьому випадку можна виконати резервне копіювання-відновлення однією командою, використовуючи стандартне введення та виведення як джерела для відповідних команд, щоб обійти створення проміжного файлу резервної копії, зменшити вимоги до вільного місця та прискорити процес.

Команда виглядає наступним чином:

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

По суті, тут ми виконуємо 2 команди, об’єднані символом |,

перша - для резервного копіювання у stdout:

Code

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

а друга - для відновлення з stdin:

Code

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

Ця команда є найшвидшим способом виконати резервне копіювання-відновлення на тому самому екземплярі Firebird.

Зверніть увагу: для конвертації баз даних за допомогою резервного копіювання-відновлення за один крок з версії 2.5 на 3.0 необхідно використовувати 2 екземпляри Firebird, деталі дивіться тут.

5. Підсумок щодо продуктивності

На наступному малюнку міститься інформація про швидкість різних команд резервного копіювання локальної резервної копії тестової бази даних:

Як ви можете бачити, найшвидший спосіб виконати локальне резервне копіювання - це використовувати Service Manager (перемикач -se[rvice]) та заборонити збір сміття (перемикач -ig).

Для резервного копіювання з віддаленого сервера на локальну машину Service Manager також є найкращим варіантом:

Ситуація з продуктивністю відновлення аналогічна: Service Manager є найшвидшим способом відновлення.

Що стосується досить рідкісного випадку, коли відновлення виконується з локальної резервної копії на віддалений сервер, використання Service Manager з трюком stdin є єдиним життєздатним варіантом:

Дуже часто задаване питання про віртуальні машини та резервні копії Firebird

Чому я повинен використовувати інструменти резервного копіювання Firebird, коли існують популярні інструменти резервного копіювання, які обіцяють створити резервну копію всього?

Або: я створюю повний образ віртуальної машини, чому я повинен турбуватися про резервне копіювання бази даних Firebird?

Відповідь знаходиться тут.

Додаток A. Помилки під час резервного копіювання/відновлення

Спроба запустити gbak без параметрів або з користувачем, який не є власником бази даних/не є SYSDBA, призведе до наступної помилки:

Code

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

Якщо ви вкажете неправильний пароль, виникне наступна помилка:

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

Помилка виникає, коли існуючий файл вказано як призначення докладного журналу:

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

Помилка виникає, якщо існуюча база даних вказана в команді відновлення gbak як призначення:

Code

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

Помилка виникає, коли gbak намагається записати резервну копію в місце, де він не має достатніх прав для запису.

Code

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

Коли gbak намагається отримати доступ до файлу без дозволу на це - наприклад, файл має іншого власника, ніж користувач “firebird” у 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

Спроба використати докладний вивід:

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

Спроба виконати резервне копіювання з Service Manager на віддаленому сервері з увімкненим докладним режимом та збереженням у файл журналу.

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

Помилка в резервному копіюванні-відновленні за один крок, коли резервне копіювання з якоїсь причини не вдається:

Code

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

Якщо ви намагаєтеся передати gbak нерезервну копію:

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

Резервне копіювання пошкодженого файлу бази даних з неправильною сторінкою повідомить про наступну помилку (номер і файл бази даних, звичайно, відрізнятимуться):

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:Завершення до завершення через помилки

Code


## Контакти

Будь ласка, не соромтеся звертатися до нас з будь-якими питаннями або повідомляти про будь-які помилки чи друкарські помилки: [email protected]