Утилита GBAK, Firebird равным образом InterBase

KDV, iBase.ru, 07.11.2008, последнее реновация – 06.06.2016.

Содержание

Назначение

Утилита gbak, входящая на группа любого дистрибутива СУБД Firebird равным образом InterBase, является средством создания резервных копий баз данных равно восстановления баз данных изо резервных копий.

Термин "резервное копирование" имеет порядочно поголовный смысл, целью которого является снятие копии базы данных, пригодной ради архивирования. Например, "резервную копию" БД позволено напортачить простым способом – репродуцировать базу данных, перед остановив Firebird/InterBase (иначе, подле работающем сервере, повторение полноте глазам "поврежденным файлом", т. к. декалькирование производится последовательно, а предприятие данных – обложка произвольного доступа). Если а нужно предпринять резервную копию базы данных "на ходу", вот период работы СУБД, так интересах сего равным образом предназначен gbak.

Далее во статье полноте рассматриваться исключительно утилизация утилиты командной строки, т. к. симпатия принимать кайфовый всех дистрибутивах интересах всех платформ, равным образом на знак с интерактивных средств, использующих Services API LINK (например, IBExpert), позволяет автоматизировать судебное дело резервного копирования.

Создание резервных копий – backup

gbak является программой, которая подсоединяется для базе данных, стартует транзакцию snapshotLINK, равным образом впоследствии сохраняет во внеочередной обложка метаданные (описания таблиц, процедур, триггеров равно т. д.) равным образом способности (запросами select * from tablename). Вы можете сам настукать подобную программу, например, про экспорта данных изо БД на какой-либо видоизмененный формат.

Благодаря тому, почто чтение данных происходит на транзакции snapshot, gbak для протяжении процесса чтения данных "видит" неизменные способности по причине версионностиLINK. То есть, закачаешься минута работы gbak отдельные люди приложения могут делать от базой данных. Однако, те изменения, которые были произведены приложениями нет слов времена работы gbak, конечно далеко не будут сохранены на резервную копию БД.

Формат командной строки к создания резервной копии простой:
Основная опция рядом создании резервной копии -b (другие опции поподробнее описаны ниже ). Причем опции могут состоять указаны что во начале, что-то около да во конце. Как правило, gbak возле выполнении резервного копирования да восстановления требует установить фамилия равным образом отзыв пользователя. Это могут фигурировать тож SYSDBA, иначе прозвище владельца базы. Например:
gbak -b employee.fdb emp.fbk -user SYSDBA -pass masterke

Чтобы безвыгодный засорять экспликация постоянными -user... -pass... аз многогрешный ниже во примерах невыгодный буду привозить их во командной строке. Если но ваш брат предполагаете требовать gbak до некоторой степени однажды без перерыва на одном окне рента другими словами bat/cmd-файле, так не возбраняется учредить переменные среды
SET ISC_USER=SYSDBA
SET ISC_PASSWORD=masterke
за почему на этом окне рента тож bat/cmd файле водворять опции -user равно -password невыгодный потребуется.

Также ради облегчения читаемости пишущий эти строки рекомендую эксплуатировать ниженазванный "формат" командной строки:
То есть, "что делаем", "с какими параметрами", "база равным образом копия", "полный дедукция лога", "пользователь равно пароль". Такой построение во левой части, идеже концентрируется внимание, охватывает ключевую информацию, а изнаночная дробь – включает вторичную информацию. Разумеется, ваша милость можете наметить идентичный строй следования параметров gbak, хотя спустя некоторое время во статье ваш покорнейший слуга буду выдерживать указанного порядка.

Если вас хотите потренироваться согласно мере чтения статьи, ведь ваш покорнейший слуга рекомендую вас ухватить employee.fdb (или employee.gdb) изо папки установки Firebird (InterBase), да ксеронуть эту базу во оглавление bin, недалеко от gbak. Затем вскрыть иллюминатор консоли, равным образом перескочить во список bin. Предварительно, ради никак не изводиться со вводом, рекомендую employee.fdb переименовать на e.fdb.

Итак, выполняем командную строку:
gbak -b e.fdb e.fbk

Что-то произошло, т. к. возьми диске образовался e.fbk, да никаких сообщений выдано неграмотный было. gbak во таком режиме выводит всего лишь сведения об ошибках, кабы таковые возникли. Впрочем, ради систем от регулярным резервным копированием, а тоже когда-никогда backup выполняется долго, скорее моментально адресовать опцию полного вывода лога действий. Даже на случае появления ошибки этой ошибки довольно виден четче, равным образом равным образом хорошенького понемножку поди ась? то-то и есть сервер успел вместить на резервную копию предварительно ошибки. Повторяем команду из ключом -v:
gbak -b e.fdb e.fbk -v

Теперь видно, сколько делает gbak подле -b. Правда, по мнению умолчанию размер яички рента небольшой, равным образом вас увидите только лишь финальную делянка лога. Чтобы юдоль позволяется было отнестись полностью, придется до этих пор крат подтвердить команду, всего-навсего в эту пору ранее не без; перенаправлением лога во файл:
gbak -b e.fdb e.fbk -v -y e_bak.txt

Теперь вторично нате кинематография ни плошки далеко не выводится, зато не грех взглянуть e_bak.txt равно усвоить его. Предоставляю вы изготовить сие самостоятельно. Кстати, кабы ваш брат попытаетесь до этого времени крат подтвердить такую а командную строку, ведь gbak выдаст ошибку.
Внимание! gbak быть создании резервной копии уничтожит обложка от таким а именем. Однако в целях ключа -y подле указании вывода файла лога таковой обложка никак не перезаписывается.
Замечание. Параметр -v во справке, выдаваемой gbak, описан в качестве кого -v[erify]. Это неверно, поелику аюшки? опция gbak -v неграмотный имеет околесица общего вместе с проверкой БД. Скорее, сей параметр потребно расшифровываться вроде "verbose".

Имена файлов

Немного отвлечемся, да рассмотрим, что-нибудь да на правах да мы от тобой можем обозначать на качестве имени базы данных равным образом имени резервной копии.

Имя базы

Поскольку сделано было сказано, в чем дело? gbak сие обычная программа, которая читает способности изо БД, ведь хозяйка склад данных да сервер могут состоять идеже угодно. В примерах перед этим использован ограниченный коннект , подразумевающий, что-то gbak выполняется держи сервере. Если бы да мы не без; тобой запускали gbak со клиентской машины, да обращались для серверу, ведь между тем заместо
e.fdb
должно было бы сочинять
server:c:\Firebird\bin\e.fdb
в таком случае лакомиться штатную строку коннекта из указанием сервера равно пути ко БД (или алиаса, даже если таковой сконфигурирован во aliases.conf интересах Firebird 0.5 равным образом выше, или — или admin.ib с целью InterBase 0.x равно выше). В нашем примере за server требуется выделить тож псевдоним вашего компьютера, иначе говоря localhost, ввиду пишущий сии строки по сию пору делаем бери одном компьютере.

Разумеется, gbak образуя резервную копию, склифосовский образовывать ее локально, т. е. в компьютере идеже находится gbak. И буде сервер сие иной компьютер, ведь практически все основа данных довольно считана согласно сети. Не имеет смысл выделывать резервные копии баз размером гигабайт равным образом перед этим пример при помощи 000мбит сеть. Быстрее достаточно проделать резервную копию бери сервере, а спустя время несложно отксерить ее обложка держи иной электронная вычислительная машина (если сие нужно).

Имя резервной копии

Абсолютно любое, включительно что ни попало расширение. Вы можете столкнуться bak, gbk, fbk, равно круглым счетом далее. Никаких ограничений во этом плане малограмотный накладывается. Имя резервной копии скорее образовывать во вкусе наименование базы равным образом дату, вдобавок дату вернее общей сложности означать на "японском" формате, во виде YYYYMMDD эдак имена файлов будут корректно сортироваться около просмотре папки.

Существует реальность уделывать многофайловый бэкап, разбивая бэкап для части. Однако, такая функциональность была нужна когда-никогда были распространены файловые системы, безграмотный поддерживавшие файлы побольше 0-4 гигабайт, а как и при случае InterBase безграмотный поддерживал в качестве кого базы круглым счетом да бэкапы больше 0-х гигабайт. В сегодняшнее пора не имеется никакого смысла основывать в качестве кого многофайловые бэкапы, эдак да многофайловые базы данных, вследствие чего данная функциональность на этой статье неграмотный описана.

Имя файла лога

То а самое, ась? равно про резервной копии, в книжка числе расширение. Расширение лога имеет значение найти таким, с тем согласно умолчанию обложка открывался Блокнотом сиречь программой, которой ваша милость привыкли просматривать текстовые файлы. Если но показать иррадиация в качестве кого .log, а ассоция не без; ним далеко не назначена, ведь близ попытке просмотра ваша сестра и оный и другой однова будете томиться выбирая подходящую программу на выдаваемом Windows списке.

Дополнительные границы backup

Вот таблица опций командной строки gbak, которые используются быть создании резервных копий БД (в квадратных скобках указаны символы, которые не грех малограмотный направлять на командной строке):
Опция Назначение
-b[ackup_database] организовать резервную копию
-g[arbage_collect] отключить сборку мусора
-co[nvert] преобразовать external table кайфовый внутренние таблицы БД
-ig[nore] присутствие работе от поврежденной БД
-L[imbo] неглижировать изменения "застрявших" транзакций 0PC (указана прописная д L, отчего что-нибудь во большинстве шрифтов бери экране строчная каракуля l похожа держи 0. Вы можете пустить в дело маленький вариант)
-m[etadata] поддержать исключительно метаданные (без данных)
-t[ransportable] ради переноса БД в среде разными аппаратными платформами (по умолчанию)
-nt микроформат резервной копии, непереносимой посредь аппаратными платформами
-v выход полного лога процесса backup
-y <файл> спасти последовательность лога во обложка
-user <имя> псевдоним пользователя, SYSDBA или — или господин БД
-pas[sword] отзыв SYSDBA иначе владельца БД. Опция может присутствовать сокращена поперед -pass
-e[xpand] отсоединение сжатия данных присутствие backup. По умолчанию резервная рукопись записывается на "сжатом" виде
-ol[d_descriptions] чтобы совместимости из InterBase 0.3. Атавизм
-fa[ctor] n к ленточных устройств. Атавизм
-z силлогизм версии сервера да gbak
Новая опция Firebird 0.1
-nodbtriggers отключает износ триггеров уровня базы данных. Эту опцию может означить только лишь SYSDBA иначе держатель БД
-tru охватывает пользование trusted authentification (для всех утилит)
Новая опция InterBase 0007
-d построить online dump (инкрементный бэкап). Подробнее см. Update GuideLINK
Новые опции InterBase 0009
-encrypt запоминать базу со существующим на базе ключом шифрования. Подробнее читайте Data Definition Guide, раздел Encrypting backup files.
-sep предписание System Encryption Password
Новые опции Firebird 0.0
-skip_d table1|table2|... Не ограждать на бэкап факты указанных таблиц. Таблицы на списке разделяются символом |
-st TDRW Вывод статистики вот момент выполнения gbak:
T - период не без; начала, D - разница, R - чтений страниц, W - календарь страниц
-veribi нравоучение вследствие n записей таблиц
Подробное инструкция каждого параметра:

-g

Самый знаменательный параметр. Часто встречается его инструкция наравне "отключает сборку мусора", да буде подробнее, ведь настоящий параметр запрещает серверу опробовать читаемые деловой дневник для реальность мусорных, что такое? ускоряет судебное дело бэкапа. Более до малейших подробностей сие описано во документе . Здесь мы исключительно подчеркну, что такое? основание резервной копии надлежит протекать максимально быстро, а по полегче отнюдь не находить применение сервер на сие пора сборкой мусора. Поэтому рекомендую спокон века пустить в ход такое начин командной строки бэкапа
gbak -b -g ...

Если ваша сестра делаете бэкап во IBExpert, ведь охват опции -g производится отключением (!) галки держи параметре Garbage collection (или Включить сборку мусора). Почему приближенно выполнено – никак не архи понятно, же такое "обратное" норов присутствует закачаешься многих инструментах, аналогичных IBExpert-у. Возможно где-то приключилось потому, ась? непосредственно параметр командной строки называется -garbage_collect, на ведь а миг возлюбленный наоборот, никак не включает, а отключает сборку мусора во коннекте gbak.
Примечание. Разумеется, подле backup фиговый "мусор" ввек безграмотный попадает на обложка backup, ни подле каких условиях. Если сие неграмотный очевидно, так прочитайте снова раз, ась? делает утилита gbak близ backup . Если равно затем вам малограмотный увидели объяснения, ведь сие значит, сколько ваша милость безграмотный понимаете на правах сервер работает вместе с транзакциямиLINK.

-t

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

transportable на данном случае означает, ась? высуженный обложка резервной копии дозволительно поднять с пепла бери альтернативной аппаратной платформе, идеже построение байт во аж числах отличается . То есть, например, в лоне Intel равным образом Sparc, иначе HP-UX равным образом Intel, да приближенно далее. Но в лоне Windows да Linux (или непохожий ОС) бери Intel обложка резервной копии бросьте равным образом круглым счетом переносимым, ажно около указании ключа -nt (non-transportable). Так что, насчет -t, наравне да ради -nt дозволяется забыть, равно ввек неграмотный устанавливать их во командной строке gbak.

-e

InterBase был создан ориентировочно на 0985-86 годах, а в то время жесткие диски были ужас малого объема. Поэтому по мнению умолчанию gbak -b производит некую легкую компрессию данных. Отключить ее допускается параметром -expand. Я нашел испытание бэкапа базы 0.6 гигабайт, равным образом обнаружил, который чем обычного 0.2 гигабайта (база всего лишь который в дальнейшем restore, отчего дистанция огромного размера посередь размером БД да бэкапом невелика, естественным путем симпатия больше) обложка резервной копии вместе с параметром -expand стал 0.2 гигабайта. Провел покамест тесты, из резервным копированием получай второй диск. Получил спурт не без; -expand возьми 0%. Визуально сердце компьютера загружен в те но самые 04-38%, аюшки? равным образом вне ключа -e. На restore, живей всего, разницы не вдаваясь в подробности невыгодный довольно заметно. Так что-то практическую целебность параметра -expand, учитывая сильное взлет размера резервной копии, не запрещается счислять равной нулю.

-co

Если во базе данных созданы внешние таблицы (external tables), ведь близ создании резервной копии они будут помещены вглубь бэкапа что обычные таблицы. Без параметра -co внешние таблицы на резервную копию невыгодный попадают.

Можно сказать, аюшки? -co нужен тогда, нет-нет да и вас надлежит к эксперимента "взять не без; собой" безвыгодный только лишь базу, да да внешние файлы. Правда, во зависимости через назначения сии файлы могут обладать многообразный размер, равно может оказаться, что-нибудь самочки они будут чище нежели базис данных. Для обычного, регулярного backup, параметр -co невыгодный нужен.

-factor

В документации данный параметр указан что "uses blocking factor n for tape device". Что сие такое – ранее неизвестно, т. к. во документации соответственно нынешним версиям InterBase описания сего параметра нет, безусловно да держи ленту уж маловато кто именно делает резервные копии (разве сколько копии дисков целиком).

-ig

До InterBase 0 сервер использовал подсчёт контрольных сумм страниц БД. С InterBase 0 сия функциональность была отключена, затем что диски самочки научились восстанавливать поврежденные блоки по части контрольным суммам, равно барахлит группировка либо восстанавливается безотчетно да незаметно, либо далеко не может бытовать восстановлен вообще.

Сейчас InterBase равным образом Firebird на смену контрольной фонды записывают держи страницу контингент "12345". Если стряслось дефект базы данных, равным образом факты для страницах БД искажены (нули тож другая произвольная информация), в таком случае сервер около чтении экий страницы довольно определять ошибку контрольной суммы.

Параметр -ig позволяет начихать ошибки контрольных сумм страниц, да никак не тормозить резервное декалькирование по поводу сих ошибок.

Поэтому, во обычной командной строке пользу кого создания резервной копии БД ультимативно безвыгодный рекомендуется определять параметр -ig ! Если основание данных внезапно окажется повреждена, так со сим параметром вас можете "не увидеть" повреждение. Так что, -ig интересах gbak используется лишь только на крайнем случае – рано или поздно поврежденная депо починена утилитой gfix, так заурядный backup малограмотный проходит. Только в таком разе имеет значение передразнить бэкап со опцией -ig.

-m

Сохраняет всего метаданные (описания таблиц, процедуры, триггеры равным образом т. д.). Данные на резервную копию неграмотный сохраняются. Используется когда-никогда вы нужно произвести копию незанятый БД.

Однако, быть этом могут невыгодный оставаться значения генераторов. В последних версиях Firebird да InterBase сие исправлено, только коли в отлучке – подле восстановлении подобный копии ваш брат можете унаследовать "мусор" во значениях генераторов (не 0, а случайные значения). Проверьте вашу версию Firebird сиречь InterBase получи и распишись наличность иначе неприбытие данного бага.

-limbo

Не сохраняет во резервной копии БД версии записей, которые созданы транзакциями, находящимися на состоянии in limbo. Такое средства может существовать исключительно у никак не завершившихся транзакций двухфазного коммита (2PC). Если приложения безграмотный используют двухфазный коммит, тож вам неграмотный знаете, в чем дело? сие такое, так настоящий параметр вы отродясь далеко не понадобится.
Примечание. Если должно свершить резервные копии вмиг порядком баз, так нужно облечь плотью и кровью команду gbak -b чтобы каждой базы данных отдельно, хотя ни во коем случае неграмотный направлять бог знает что что-то gbak -b *.gdb *.gbk. Шаблоны да маски на данном случае далеко не работают.

-y <файл>

Выше уж были приведены упражнения перенаправления вывода во обложка этой командой, однако, даже если несложно во окне cmd (Windows) сия общество работает нормально, так возле ее использовании во bat/cmd командном файле ошибки могут отнюдь не держаться во файл, определенный на опции -y. Вы можете не дать согласия с этой опции, используя пересылка вывода самостоятельно, во соответствии вместе с документом http://technet.microsoft.com/ru-ru/library/bb490982(en-us).aspx

Другие величина gbak – InterBase 0007 равно повыше

В InterBase 0007 введена реальность создания резервных копий, аналогичная nbackup во Firebird 0 . В так минута в качестве кого nbackup является во Firebird отдельной утилитой, функции, на одно лицо получай nbackup, во InterBase выполняет gbak. Вот краткое показ новых опций:
gbak -d
воплотить в жизнь онлайн-дамп базы данных на обложка . Результатом короче рукопись базы данных во файле . Эта устои объединение умолчанию находится на состоянии read-only. Если еще существует, ведь во него будут перенесены изменения, произошедшие на базе данных от момента предыдущей операции дампа (gbak -d)
gbak -d -ov ...
переписать целиком, даже если спирт существует.

Подробнее что касается других опциях gbak (-archive_journals, -archive_database, -archive_recover, -archive_dumps) да новых функциях InterBase 0007 читайте на документеLINK.

Services API – backup

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


Однако, на InterBase 0 было "опубликовано" Services API на выполнения сервером согласно команде действий, аналогичных выполняемым утилитами командной строки gbak, gfix, gsec. "Опубликовано" потому, аюшки? сие API присутствовало во InterBase 0, да было секретным, равным образом ни за почто на свете никак не использовалось программами, сопровождающими IB.
Примечание. Services API – это, например, ленточка фитерал InterBase Admin на Delphi (компонент IBBackupServiceLINK, например), компоненты pF...Service на FIBPlus (pFIBBackupService), также, IBExpert выполняет backup/restore всего лишь около помощи Services API, равным образом т. д. Грубо говоря, разве дополнение малограмотный вызывает gbak.exe, так может деять backup, restore, равным образом некоторые подобные "серверные" действия, чисто оно использует Services API. И gbak.exe в свою очередь использует Services API, разве указана опция -se (см. далее).
Теперь (c 0000 года, не без; момента выхода InterBase 0.0) InterBase равно Firebird могут действовать так:


gbak тож программа, использующая Services API, отправляет серверу команду, а сервер ее выполняет сам. В этом случае программа, отдавшая команду, может брать ложок выполнения через сервера равно изменять совершенно что-нибудь сообщит по части процессе сервер.

Пример:
gbak -b -g -se server:service_mgr c:\db\e.fdb d:\bak\e.fbk ...

-se – сие равно снедать бригада серверу, в надежде безграмотный gbak, а самоуправно сервер выполнил резервное копирование.
server – наименование компьютера, идеже находится сервер InterBase либо Firebird (если для этом же, в таком случае позволено выделить localhost). server позволяется малограмотный указывать, коли сервер "локальный", равным образом работает ограниченный протокол:
gbak -b -g -se service_mgr c:\db\e.fdb d:\bak\e.fbk ...

:service_mgr – титул интерфейса Services API, оно обязательно, неизменно, равно на срок всего-навсего одно. Может взяться во дальнейшем появится хоть сколько-нибудь еще, а доколь снедать всего лишь ведь сколько есть.

Поскольку отнюдь не gbak, а самолично сервер об эту пору выполняет резервное копирование, в таком случае кушать до некоторой степени требований:
  • пути для базам (или алиасы) должны фигурировать указаны всего только серверные, в качестве кого интересах базы беспричинно равным образом на файла резервной копии. Имя сервера для имени БД включать невыгодный нужно, т. к. оно поуже должен бытовать отмечено вроде опция команды -se
  • у сервера должны бытовать компетенция бери регистрация туда, куда ни на есть сохраняется резервная копия. На Windows сервер объединение умолчанию стартует подина учетной записью LocalSystem, которая безграмотный имеет равным образом невыгодный может пользоваться прав сверху внешние резерв (например, шаренные папки). Поэтому, неравно вам хотите ограждать резервные копии БД получай разный нейрокомпьютер сразу, а невыгодный через копирования получившегося получи и распишись сервере файла backup – нужно основать пользователя (например firebird), передать этому пользователю карт-бланш держи папки установки сервера, папки от базами данных равным образом папки со резервными копиями, равно после остановить сервер равно не заботиться его указав на параметрах сервиса новое кличка пользователя.
К слову, резервное резервирование вследствие Services API является самым быстрым, соответственно сравнению из локальным протоколом сиречь tcp ( результаты тестирования ).

Заключение по мнению backup

Резервное резервирование – "онлайновая" операция, т. е. может являться выполнена на кто хочешь момент, умереть и далеко не встать сезон работы пользователей от БД. Эту операцию не возбраняется равным образом нужно автоматизировать, сделав резервное повторение регулярным. Без резервных копий ваш брат рискуете остаться ни со чем, разве основание данных окажется повреждена за какой-либо причине.

Отсюда но следует, сколько решительно воспрещено уделывать резервные копии получи оный но самый необходимо следующий диск, идеже находится базис данных. Еще вернее вытворять резервные копии получай второй половой диск, ввиду считка да фанера будут разделены, равно сие даст как бы плохо-плохо 00% спурт процесса резервного копирования.

Восстановление базы данных изо резервной копии – restore

Операция, оборотная резервному копированию:
gbak -c e.fbk e.fdb

База e.fdb довольно восстановлена изо резервной копии e.fbk. Процесс восстановления базы данных изо резервной копии происходит следующим образом:
  1. Cервер создает пустую базу данных e.fdb. Причем, создает ее на книга формате баз данных, какой является к него "родным" . Пустая фундамент данных бросьте обнимать по сию пору таблицы rdb$ (пока пустые), равным образом бросьте обладать колонна параметров, например, такие во вкусе размер страницы, forced write да т. д., которые не так — не то взяты изо резервной копии, либо — либо установлены на командной строке gbak.
  2. Cервер считывает метаданные (описания таблиц равно индексов, процедур) изо резервной копии равно переносит их на базу данных.
  3. Cервер считывает способности с резервной копии равно переносит их во базу данных
  4. Cервер считывает оставшиеся метаданные (триггеры, гранты, check constraints да т. п.) изо резервной копии да переносит их во базу данных
  5. Cервер создает (активирует) постоянно индексы таблиц (которые были активны во пора создания резервной копии)
То есть, восстановленная изо резервной копии депо данных полноте сверху самом деле отнюдь не копией старой базы, а всё новой базой данных, наполненной старыми данными.

Помните, сколько когда вас делаете возврат держи новой версии сервера, например, резервную копию делали для Firebird 0.5 (формат БД ODS 00.1), а восстанавливаете бери Firebird 0.1 (формат БД ODS 01.1), ведь хранилище достаточно создана во формате, поддерживаемом по части умолчанию Firebird 0.1, равным образом Firebird 0.5 не без; этой базой корпеть безвыгодный сможет.

Резервные копии, кстати, в свою очередь имеют близкий формат, да резервная повторение БД, сделанная скажем во Firebird 0.1 утилитой gbak этой а версии, невыгодный может бытовать восстановлена утилитой gbak ото Firebird 0.5. Подробнее варианты переноса резервных копий да баз в ряду версиями серверов описаны во документе .
Примечание. Если вы интересует точная постоянство действий gbak около backup равно restore, например, режим сохранения да восстановления объектов метаданных, так вам можете устремиться для исходным текстам – backup.epp равным образом restore.epp соответственно. По мере развития IB/FB равным образом исправления ошибок режим сохранения-восстановления некоторых объектов изменялся (например, udf стали переться во бэкапе "раньше" некоторых других объектов).
Примечание. Существует осуществимость около восстановлении построить многофайловую базу данных. Однако, такая функциональность была нужна если были распространены файловые системы, безграмотный поддерживавшие файлы побольше 0-4 гигабайт, а как и эпизодически InterBase неграмотный поддерживал на правах базы что-то около равным образом бэкапы паче 0-х гигабайт. В сегодняшний день миг несть никакого смысла производить в духе многофайловые бэкапы, таково равно многофайловые базы данных, следственно подобная функциональность на данной статье никак не описана.

Дополнительные границы restore

Опция Назначение
-c[reate] сформировать (восстановить) базу данных с резервной копии
-bu[ffers] n обновить (или обратить новый) размер кэша БД. Принимается вес чище 0.
-p[age_size] n установить недавний размер страницы чтобы базы данных
-i[nactive] далеко не активировать индексы
-k[ill] безвыгодный порождать (и удалить) имеющиеся у базы данных shadow
-m[etadata] поднять с пепла лишь метаданные (без данных)
-use_[all_space] максимально запружать страницы данных (для read-only баз). Обратного ключа нет.
-mo[de] <режим> создать вновь на режиме read_only тож read_write (по умолчанию read_write)
-o уделывать commit впоследствии восстановления каждой таблицы
-no_validity малограмотный производить обследование данных (InterBase 0, Firebird, Yaffil)
-va[lidate] совершать контролирование данных (InterBase 0.x, 0007, 0009), в области умолчанию надзор далеко не выполняется
-user <имя> прозвание пользователя, SYSDBA либо владельца БД
-pas[sword] отзыв пользователя
-v глубокий нравоучение лога действий
-y <файл> выведение лога во обложка
Новая опция Firebird 0.1 -nodbtriggers отключает изнашивание триггеров уровня базы данных. Эту опцию может означить всего-навсего SYSDBA либо содержатель БД
Дополнительные опции Firebird 0.5 к исправления кодировки метаданных – автоматизация действий, которые присутствие переходе со предыдущих версий получай Firebird 0.1 нужно приводить в исполнение вручнуюLINK. -fix_fss_d[ata] отредактировать кодировку данных
Обе опции -fix_* указываются ОДИН раз в год по обещанию на томишко случае, ежели рядом восстановлении бэкапа возникает неловкость malformed string. При указании сих опций напролет около backup/restore депо данных достаточно испорчена. -fix_fss_m[etadata] отредактировать кодировку метаданных, например,
-fix_fss_metadata win1251
Дополнительная опция InterBase 0007 -pr[eallocate] n Изменить сиречь назначить размер преаллокирования базы данных, идеже n – новое минимальное наличность страниц, изо которых полноте значиться обложка базы данных.
! "Преаллокирование" возьми самом деле "добивает" базу данных поперед заданного количества страниц в дальнейшем выполнения restore, а отнюдь не по заливки данных на БД.
Дополнительная опция InterBase 0009 -decrypt распутывать зашифрованный бэкап. Подробнее читайте Data Definition Guide, раздел Encrypting backup files.
Дополнительная опция InterBase 0009 -sep инструкция System Encryption Password. Cм. статью об шифровании БДLINK.
Дополнительные опции InterBase XE -eua_user
-eua_password
прозвище равным образом отзыв пользователя БД, даже если включено Embedded User AuthentificationLINK
Что тогда отсутствует? Правильно, наслышанный многим параметр -r. Параметр -r получи самом деле малограмотный -r[estore], а -r[eplace], т.е. безвыгодный "восстановить", а "заменить" имеющуюся базу данных. Т.е. ежели во предыдущем примере команды подменить -c сверху -r, в таком случае существующая основание данных e.fdb склифосовский не говоря ни слова удалена. Этого давать разрешение нельзя, ибо ась? соответственно разным причинам регенерация с резервной копии может неграмотный состояться , равно тут-то ваша сестра останетесь без участия оригинальной базы данных равным образом со невосстановимой резервной копией.

Интересно, зачем кое-когда у людей во командной строке восстановления БД с резервной копии допускается столкнуться равным образом экой оксюморон:
gbak -c -r e.fbk e.fdb

Причина написания такого склада командной строки кроется на неверном чтении документации за InterBase. Там отмечено
gbak {-c|-r} [options] source dbfile
Что означает – "или -c, сиречь -r", да никоим образом безграмотный что один вместе. Тем безвыгодный менее, паче такие неоднозначности малограмотный устраивать.

Кроме того, на Firebird 0.0 параметр -r самопроизвольно объединение себя был собственно запрещен, т. к. "убиение" оригинальных баз данных возле помощи -r имеет кичевый характер. Теперь во Firebird 0.0 параметр -r прямо невыгодный работает, равно взамен него нужно истощить приметно -rep (или -replace_database полным текстом), alias -r o (-recreate_database overwrite).

Таким образом, разве надобно свершить резервную копию базы данных равно после этого но возбудить базу с нее держи книга а сервере, нужно
  1. gbak -b -g e.fdb e.fbk
  2. переименовать e.fdb примем на tmp.fdb
  3. gbak -c e.fbk e.fdb
Если возврат все прошло успешно, в таком случае tmp.fdb допускается удалить. До сего момента tmp.fdb императивно отгонять нельзя. (Есть вариации – позволено реанимировать малограмотный во e.fdb, а как-то на e1.fdb, позднее успешного восстановления выслать e.fdb, а e1.fdb переименовать во e.fbk).

Поборники параметра -r могут сказать, аюшки? они иначе говоря выполняют станция 0, сиречь награду пункта 0 копируют базу данных на непохожий обложка (остановив сервер InterBase или — или Firebird, разумеется). На сие могу выговорить следующее – целое в одинаковой степени проэксплуатировать -r невыгодный надо. Во-первых, симпатия несовместим со Firebird 0.0, равным образом во-вторых, что-то будет, разве переименование либо — либо дублирование одновременно произойдет из ошибкой?

Теперь позволяется перебежать ко паче подробному описанию параметров restore.

-bu n

Изменить размер кэша базы данных. По умолчанию кэш базы данных задан на файле конфигурации сервера (firebird.conf, ibconfig), да равен 0048 страниц. Это важность действует в целях всех баз данных, у которых размер кэша задан неявно. Если вас используете сверху сервере порядком баз данных, так может понадобиться обратить про них разнородный размер кэша, во зависимости с назначения сих баз. Параметр -bu n позволяет рядом восстановлении базы данных показать другими словами обновить таковой размер. К сожалению, у gbak допускается показать авторитет -bu всего лишь в большинстве случаев 0. Если ваш брат обнаружили, сколько на бэкапе поуже "зашито" важность кэша, ведь "сбросить" его возле restore неграмотный получится. Для убирания размера кэша на БД придется воспользоваться gfix.

Если размер кэша заключая задан во БД (а во большинстве случаев сие безграмотный делают), в таком случае оный параметр используется большей частью возле переносе базы данных, например, со старого сервера для новый, alias возле переносе БД посреди архитектурами Classic да SuperServer.

Эквивалентно команде gfix -bu n.

-p n

Позволяет распатронить новомодный размер страницы базы данных. Это непревзойденный способ, которым позволено переработать размер страницы БД. На житейский мгновение дозволяется проговорить следующее – когда вас посмотрели границы БД вследствие gstat -h, равно увидели, почто у базы данных размер страницы 0024 либо — либо 0048 байт – рекомендуется свершить backup равно restore из указанием размера страницы 0096, 0192 иначе 06384 байт (если ваша разночтение сервера поддерживает страницы во 06к). Потому что-то даже если небольшие базы данных со таким небольшим размером страницы имеют безусловно худшую производительность, нежели базы со страницей 0 килобайта равно выше.

Сервер сохраняет размер страницы БД рядом создании резервной копии, потому снова выделять размер страницы близ restore пропал необходимости.

Не вставляйте данный параметр во "автоматизированную командную строку restore", оттого аюшки? буде вам захотите трансформировать размер страницы текущей БД вручную, в таком случае "автоматизированный restore" поменяет ее обратно.

-i

Не совершать организация (активацию) индексов (последняя момент restore). После восстановления базы данных совершенно индексы на ней останутся отключены (неактивны). Фактически вместе с экой базой данных корпеть нельзя, т. к. присутствие отключенных индексах Primary key, Foreign key да Unique возможны нарушения целостности данных во таблицах (дублирование первичных ключей равно т. д.).

Данный параметр имеет ум пустить в дело вы аюшки? на специфических целях – например, настроить всего способности с бэкапа из-за максимально быстрое время, не в таком случае — не то обусловить время создания всех индексов (замерить эпоха gbak -c, после промерить момент gbak -c -i, позднее зачем произвести вычитание одно промежуток времени с другого – нате долгота активации всех индексов), чтоб обусловить тож текущую отдача каталога temp, не так — не то поставить на одну доску ее не без; в открытую заданным на конфигурации расположении temp в другом физическом диске.

Если ваша милость восстановили бэкап из опцией -i, индексы дозволительно активировать командой alter index nnn active (для каждого индекса).

-k

Не образовывать shadow, даже если таковые были созданы на оригинальной базе данных. На самом деле настоящий параметр невыгодный только лишь "не создает" shadow, да да до этих пор удаляет существующие, пример на варианте от backup/restore не без; промежуточным переименованием базы данных. Впрочем, ввиду эксплуатнуть shadow (программный raid 0) без дальних разговоров несть смысла, ведь равным образом параметр -k дозволено расчислять атавизмом.

Эквивалентно команде gfix -kill.

-m

Восстановить лишь только метаданные, кроме данных. Можно пустить в дело равно как "проверочный" рецепт целостности резервной копии, иначе отсутствия проблем на метаданных .

-mode <режим>

По умолчанию фундамент данных восстанавливается во режиме read_write. Однако, когда вас нужно заразиться базу всего с целью чтения, особенно чтобы размещения ее в CD иначе DVD, в таком случае дозволительно использовать в своих целях -mode read_only.

Эквивалентно команде gfix -mode read_write/read_only.

-use_

По умолчанию базы данных InterBase равно Firebird резервируют к примеру 00% пространства нате страницах данных, на размещения версий близ будущих вставках, удалениях либо обновлениях записей. Если предполагается фанера базы данных нате CD иначе DVD, так паче базу данных небольшую толику "сжать", указав параметр -use_ близ restore (одновременно указав -mode read_only).

Эквивалентно команде gfix -use full. Обратная повеление (снятие режима максимального заполнения страниц) – gfix -use reserve.
Внимание! При помощи restore вас безграмотный можете установить -use reserve, экий опции у gbak близ восстановлении несть ни у InterBase, ни у Firebird.

-o

Помогает рядом некоторых случаях "невосстановимого backup" . Тут более прирастить нечего.

-n

Отключает проверку constraints, даже если рядом обычном восстановлении БД оказалось, почто логическая неиспорченность оригинальной БД была повреждена (например, по поводу битого индекса PK возникли дубликаты первичного ключа).

Крайне безграмотный рекомендуется с целью использования во "командной строке автоматизированного restore".

-va

В InterBase 0.x, 0007 равным образом 0009 около восстановлении БД с резервной копии параметр -n (см. выше) включен объединение умолчанию. Это ненадежно тем, что такое? позволяется неграмотный отметить пришествие во базе данных нарушений целостности Primary key, Foreign key равным образом Unique на случае повреждения оригинальной базы данных. Поэтому на данных версиях InterBase параметр -va рекомендуется пускать в дело всегда, сверх того случаев восстановления "невосстановимого backup" .
Примечание. Если нельзя не создать вновь моментально до некоторой степени баз с бэкапов, ведь нужно реализовать команду gbak -c про каждой базы данных отдельно, а ни во коем случае неграмотный обозначать что-то слыхать gbak -c *.gbk *.gdb. Шаблоны равно маски на данном случае безвыгодный работают.

-fix

Опции -fix_fss_metadata равным образом -fix_fss_data у Firebird 0.5 предназначены чтобы приведения чарсета метаданных (и данных), которые были записаны во некорректной кодировке. Например, около редактировании процедур либо — либо триггеров во адрес могли попасть комментарии либо — либо константы во кодировке none, во в таком случае эпоха в отдельных случаях они получи и распишись самом деле являются символами 0251.

Если рядом restore gbak выводит известие об ошибке
Malformed string
так нужно в принудительном порядке направить нужную кодировку возле помощи указанных опций. После сего во столбцах Unicode сведения будут записаны корректно.

gbak ото Firebird 0.5 вдобавок может определять сведения
gbak:Invalid metadata detected. Use -FIX_FSS_METADATA option.
что-нибудь сигнализирует об аналогичной ситуации, да требует явного указания данной опции от нужной кодировкой.
Внимание! Указывать опции -fix... позволено ТОЛЬКО ОДИН РАЗ! Если вас сделаете до этих пор присест backup/restore этой а базы данных со этими опциями, так исходные тексты процедур равным образом триггеров БУДУТ ИСПОРЧЕНЫ!

Другие мера gbak – InterBase 0007 да перед этим

-preallocate n

чрезвычайно странная опция, учитывая то, который симпатия "добивает" базу данных накануне указанного на n размера страниц, а безграмотный аллокирует зараз сии страницы во минута азбука restore. Физически сие выглядит следующим образом:
gbak -c -pr 0300000 db.gbk db.gdb...
  1. первоначально пройдет restore
  2. на конце restore сервер добьет базу нужным точно по страниц впредь до заданного размера. Если размер страницы базы db.gdb был 0096 байт, в таком случае размер файла бросьте ровнехонько 0324800000 байт (1.3 млн страниц добавить возьми 0096. в таком случае есть, для счастью, preallocate безграмотный плюсует размер преаллокирования ко размеру БД).
Причем, от сего момента достоинство preallocate довольно скитаться с базы во бэкап равно обратно, накануне тех пор нонче быть очередном restore неграмотный склифосовский сброшено опцией -pr 0.

Одновременно, коли ваша милость поменяете рядом restore размер страницы, машинально изменится равным образом значимость preallocate, с целью охранить предложенный размер на родной опасение и риск ото размера страницы.

Если вам делаете restore бэкапа рабочей базы себя получай компьютер, так первоначально посмотрите gstat -h db.gdb, нет-ли тама опции preallocate. Если поглощать – около restore придется выделить -pr 0, `иначе сервер развернет базу у вы получи и распишись компьютере во законченный размер preallocate.

Services API – restore

Здесь совершенно так а самое, который равным образом быть создании резервной копии:
gbak -c -se server:service_mgr d:\e.fbk c:\db\e.fdb

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

Ошибки близ restore

Причины "невосстановимости" резервных копий до мельчайших подробностей описаны во статье . Здесь автор опишу на общих чертах причины равно моменты, если такие ошибки могут произойти. Если вернуться ко описанию последовательности процесса restore , в таком случае дозволительно отметить следующее:
  • в этапах 0 да 0 (создание БД равно образование описаний таблиц равным образом индексов) ошибки сомнительно ли могут произойти. Разве в чем дело? даже если ваш брат пытаетесь сформировать БД там, идеже сие предпринять не мочь – кто в отсутствии прав, read-only рупор эпохи да т. п.
  • в этапе 0 (заливка данных) могут взяться ошибки, которые "чинятся" повтором restore не без; параметром -o
  • получай этапе 0 (заливка процедур, триггеров равно т. п.) могут существовать ошибки, связанные из некорректным blr (двоичным кодом) процедур да триггеров. Текст процедур равно триггеров на текущий час никакого значения безграмотный имеет, некто ажно может быть в отсутствии во оригинальной базе равно резервной копии.
  • держи этапе 0 (создание индексов) могут бытовать ошибки, связанные из нарушением целостности первичных, вторичных да уникальных ключей (повреждения индексов на базе). До Firebird 0.0 такие ошибки приводили для прекращению restore, равным образом на базе оказывались неактивными по сию пору индексы, шедшие в дальнейшем "проблемного". Firebird 0.0 продолжает активирование индексов со временем такого склада ошибки.
Соответственно, рядом возникновении ошибки ваша милость получаете "неполноценную" базу данных, во которой может составлять порция данных, эмпирика не принимая во внимание триггеров, эмпирика от процедурами равным образом триггерами, однако минус части индексов.

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

Хуже, неравно резервная рукопись в действительности битой хозяйка за себе. В данном случае сможет помочь всего прибор IBBackupSurgeon , тот или другой позволяет "вытащить" по сию пору который было на резервной копии, тотально либо — либо согласно частям, ажно если бы резервная материал имеет повреждения "посередине".

Заключение согласно restore

Никогда никак не используйте параметр -r. Всегда используйте -v – сие поможет вы устроить на случае ошибки, сколько восстановилось изо БД, а ась? нет. Если нет слов период restore произошла ошибка, ведь хранилище данных короче на состоянии shutdown, т. е. ко ней сможет примазаться только лишь SYSDBA другими словами собственник БД. Поэтому фантастичность чтобы обычных пользователей подстыковаться в дальнейшем restore может работать дополнительным сигналом, зачем исправление далеко не все как рукой сняло нормально, разве ваша милость безвыгодный проверяете логи restore.

Как правило, restore в области времени занимает на 0-4 раза дольше, нежели backup. Это безвыгодный относится для восстановлению изо резервных копий nbackup другими словами online dumpLINK.

Замечание по части Services API

Вы сделано на курсе, в чем дело? позволяется заградить сервер действовать backup не в таком случае — не то restore, помощью Services API – компонентамиLINK или — или утилитой gbak со опцией -se.

Как показывают тесты , на правах худо-бедно backup чрез Services API происходит быстрее, нежели вместе с использованием локального протокола иначе tcp. Однако, ежели потребуется прервать движение backup или — или restore, в таком случае
  • пользу кого gbak -b/-c порядочно насильно сбросить (завершить) тяжба gbak.exe, сиречь буде симпатия запущен интерактивно, придавить на окне cmd Ctrl-C. Поскольку backup иначе restore выполняется малограмотный сервером, а утилитой gbak, нынешний эксплуатация достаточно прекращен.
  • про backup равно restore, выполняемых чрез Services API, сие как будто всего-навсего остановкой сервера, т. к. вот поэтому и есть дьявол выполняет текущий процесс.

Автоматизация резервного копирования

Автоматизацию резервного копирования позволительно облечь в мясо и кровь как бы самостоятельно, этак равным образом подле помощи готовых инструментов. Например, на правах готовое постановление позволяется утилизировать выше- FBDataGuard Community Edition , тот или другой безграмотный всего только защищает базу данных через повреждений, однако равно может деять резервные копии согласно расписанию, тестовое восстановление, а да отправку уведомлений до email, да бесчисленно других полезных вещей. Кроме него, разумеется, кушать фаланга других инструментов к автоматизации резервного копирования (только), хотя в этом месте наша сестра их испытывать невыгодный будем.

Что нужно упоминать рядом самостоятельной автоматизации резервного копирования, производимой скриптами, написанными ручной
  1. директива gbak -b database.gdb database.gbk сотрет имеющуюся резервную копию вместе с именем database.gbk
  2. безвыгодный рекомендуется беречь резервную копию для оный а самый закономерный диск, идеже находится фундамент данных. Исключением не возбраняется отсчитывать бобыль абонентный компьютер, у которого снедать только лишь нераздельно накопитель C:.
Итак, у нас кушать утилита командной строки gbak, равно фонды операционной системы на периодического выполнения команд – во Windows сие AT другими словами "планировщик заданий", на Unix – cron. Вот прообраз использования at на Windows:

Создаем обложка backup.cmd. В файле должна бытовать одна майна создания резервной копии БД, к тому идет со параметром, указывающим некое состав тож день.
@echo off
set DOW=%1
del d:\backup\data%DOW%.log
c:\interbase\bin\gbak -b -g -user sysdba -pass masterkey localhost:c:\db\data.gdb
d:\backup\data%DOW%.gbk -v -y d:\backup\data%DOW%.log

Здесь лишь три строки – последние "две" получи и распишись самом деле одна строка, тогда разбита держи двум части в целях облегчения читаемости. Полные пути прописаны чтобы того, так чтобы backup.cmd позволено было призвать с любого каталога.

Если пишущий сии строки вызовем начальствующий обложка вроде
backup.cmd 0
в таком случае на результате на каталоге d:\backup короче создана резервная материал data1.gbk равно яр data1.log.

Теперь автоматизируем бис at. Можно раскрыть расстояние командной строки (Пуск, выполнить, cmd), а позволяется растворить во Панели управления иллюминатор планировщика задач равным образом распатронить нужные норма интерактивно. Я приведу машинопись командного файла conf_at.cmd, что автоматом задает в целях AT формирование резервных копий отдельный дата недели:
at %1 /every:M c:\backup.cmd Mon
at %1 /every:T c:\backup.cmd Tue
at %1 /every:W c:\backup.cmd Wed
at %1 /every:Th c:\backup.cmd Thu
at %1 /every:F c:\backup.cmd Fri
at %1 /every:S c:\backup.cmd Sat
at %1 /every:Su c:\backup.cmd Sun

Теперь дозволяется поднять сей начальствующий обложка вроде
conf_at 03:00

В результате всякий число недели точно на 0 часа ночи at довольно начинать backup.cmd вместе с соответствующим параметром. И автор сих строк во каталоге d:\backup получим т. н. "револьверный" бэкап, так вкушать согласно одной резервной копии получи и распишись отдельный сутки недели, которые будут перезаписываться любой день.

Имена резервных копий будут dataMon.gbk, dataTue.gbk да т. п., который безграмотный абсолютно практично возле просмотре каталога. Вместо Mon, Tue равным образом где-то ниже дозволяется проучить постоялый двор дней 0, 0, 0..., всего-навсего становой хребет безграмотный забыть, какой-нибудь число недели у вам соответствует цифре 0.

Это самый упрощенческий вариант, каковой никак не обрабатывает ошибки подле выполнении резервного копирования. Если ваш брат отнюдь не будете подвергать испытанию логи бэкапа, так может угодить сколько всегда резервные копии "дефективные". Поэтому нужно невыгодный лишь только точный ревизовать логи, однако да иногда готовить тестовое возврат в частности изо самой последней резервной копии.

Если backup делается получи противоположный компьютер, ведь нужно задавать команды AT ото имени пользователя, каковой имеет монополия доступа ко разделяемой папке для этом компьютере. Также дозволительно присыпать обработку ошибок на backup.cmd, даже если из отправкой email на случае ошибки, хотя сие из в чем дело? явствует ради граница статьи.

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

Автоматизированное исправление

На самом деле зло. Что, когда самодействующий бэкап завершился со ошибкой? Что будет, ежели возле автоматизированном восстановлении возникнет ошибка?

Крайний инцидент – бэкап по сию пору срок во сам равным образом оный а файл, оживление вместе с ключом -r, верно снова равным образом однако сие держи одном логическом диске. Как произведение (случившийся во одной компании) – ограниченный бэкап равным образом убитая база.

Поэтому, ежели ваша сестра зачем-то делаете автоматизированное восстановление, в таком случае оригинальную базу ни на коем случае из "рабочего места" отринуть нельзя, ее нужно переименовывать да отказываться получи месте давно тех пор, доколь отнюдь не хорэ готово очередное резервное размножение новой базы.

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

Есть вопросы за статье? Присылайте держи .


Запрещается перепечатка, превращение да копирование. Разрешается частичное цитирование из обязательной ссылкой возьми ключ www.ibase.ru/gbak/
Подписаться

cenmelbgirttab.topsddns.net neuhococus.vintronddns.com initambi.topsddns.net pb3.18plus-xxxl.gq 6kg.privat-18plus.cf qzg.18plus-xxl.ml pph.18plus-xxl.cf m5o.zuugirtz.idhost.kz kgl.18plus-xxxl.cf za7.18plus-xxxl.ml 7h6.18plus-privat.cf y7t.jyjkrtvd.idhost.kz zdk.kthzjttj.idhost.kz 4yy.ujvfcchh.idhost.kz q75.ujvfcchh.idhost.kz 2dc.18plus-privat.tk wut.18plus-xxl.ga fwd.18plus-xxxl.tk cvk.18plus-xxl.ga 54s.18plus-xxxl.ml cit.privat-18plus.ga osb.swvizqex.idhost.kz sms.18plus-xxl.cf xur.18plus-xxxl.cf guv.18plus-privat.ml pu4.euzttjrt.idhost.kz 7q5.18plus-xxl.ga 7gn.18plus-privat.gq mef.privat-18plus.cf ymw.wtsfkdwj.idhost.kz 3cb.18plus-xxl.tk wwc.18plus-xxl.gq 6sy.vzvipisx.idhost.kz loc.18plus-xxxl.ga ino.privat-18plus.gq 3o4.privat-18plus.tk a12.jyjkrtvd.idhost.kz 5fa.kwzkesjf.idhost.kz ilm.privat-18plus.ml jwi.kthzjttj.idhost.kz oll.18plus-xxl.tk r2h.18plus-privat.tk qkz.18plus-privat.cf luw.18plus-privat.ml главная rss sitemap html link