Я ищу лучший способ сделать резервную копию моего всепроникающий база данных. Я прочитал документация но еще есть несколько вопросов.
Похоже, что метод непрерывных операций позволяет мне делать резервную копию всей базы данных? Так я бы сделал butil -startbu @filelist, затем сделайте резервную копию всей базы данных (копия, rsync и т. д.), затем запустите butil -endbu @filelist. Просматривая документацию, я не вижу способа получить журналы транзакций с помощью этого метода; как я бы сделал для MSSQL (BACKUP LOG ACCT TO DISK) или Postgres (archive_command). С помощью rsync, возможно, будет возможно делать это каждые 15 минут.
Метод архивного ведения журнала означает, что мне придется время от времени останавливать базу данных, чтобы получить полную резервную копию, что для меня приемлемо. Но могу ли я копировать файлы журналов с сервера каждые 15 минут, то есть доставку журналов?
Спасибо.
После прочтения остальной части этой главы кажется, что ваше предположение верно. Не существует эквивалента доставки журналов MS-SQL.
Восстановление файлов данных при использовании непрерывных операций. Если вы используете непрерывные операции для своей стратегии резервного копирования, у вас нет журнала восстановления, который можно использовать для восстановления изменений, внесенных с момента последнего резервного копирования. Все изменения базы данных с момента создания последней резервной копии теряются, за исключением, возможно, любых транзакций, хранящихся в журнале транзакций. Для любых таких транзакций механизм базы данных автоматически выполняет повтор транзакций при запуске.
Таким образом, существуют журналы транзакций, но не похоже, что система создает какую-либо структуру для их доставки или обеспечения того, чтобы они делали то, что вы ожидаете от них. IOW, я не знаю, как вы подтвердите, что любой данный журнал транзакций соответствует любой заданной полной резервной копии, созданной с помощью непрерывной работы.
Если вы хотите вести архивный журнал каждые 15 минут, вам нужно выключать БД каждые 15 минут. Это не обычный режим работы для большинства производственных баз данных - позволяет ли это ваша среда?
Насколько я понимаю, архивные журналы необходимо удалять вручную после каждого резервного копирования, поскольку они постоянно записываются, поэтому вы потенциально можете создавать резервные копии каждые 15 минут.
Начальный шаг: остановите базу данных, создайте резервную копию, включите архивирование, запустите базу данных. Затем вы можете создавать резервные копии архивов каждые 15 минут в течение ~ 24 часов. Следующее полное резервное копирование: остановите базу данных, создайте резервную копию, удалите / переименуйте архивы, запустите базу данных. Затем вы можете создавать резервные копии архивов каждые 15 минут в течение ~ 24 часов. Следующая полная резервная копия: остановите базу данных, создайте резервную копию, удалите / переименуйте архивы, запустите базу данных .... и т. Д.
Причина, насколько я понимаю, в том, что если вы не удалите / не переименуете архивы, они все равно будут включать все изменения с момента создания вашей первой резервной копии (которые уже находятся в вашей новой резервной копии). Обслуживание архивов ВАШ ответственность ... не похоже, чтобы это было автоматизировано.
Из Расширенного руководства по эксплуатации
"После успешного резервного копирования удалите все существующие архивные журналы.
Внимание! Удалите соответствующие файлы журналов перед возобновлением работы с файлами данных. Синхронизация файлов данных резервного копирования и соответствующих файлов журналов является критическим фактором успешного восстановления ".