Комментарии 8
На больших базах время восстановления gbak-файла неприемлемо большое.
Почему-то ни слова о стандартной утилите nbackup, позволяющей делать бекап-снепшоты, не требующие restore, а также инкрементальные бэкапы.
Почему-то ни слова о стандартной утилите nbackup, позволяющей делать бекап-снепшоты, не требующие restore, а также инкрементальные бэкапы.
Эх, этот скрипт лет 5 назад назад бы :).
А так могу порекомендовать делать не 30-дневный архив бекапов, а т.н. циклический бекап, известный еще со времен ленточных накопителей:
— ежедневные бекапы, которые сохраняются 7 дней, далее затираются, кроме недельного и месячного
— недельные бекапы (например, пятничный) хранятся месяц, далее затираются
— месячный бекап (например, за 1 число) хранится полгода/год — по выбору
Таким образом, вы охватываете больший период, при меньшем количестве «носителей». В максимальном случае это 6+4+12 = 22 «носителя».
Также, если вас интересует безопасность, рекомендуется владельцем баз сделать все-таки не sysdba, а специального пользователя
А так могу порекомендовать делать не 30-дневный архив бекапов, а т.н. циклический бекап, известный еще со времен ленточных накопителей:
— ежедневные бекапы, которые сохраняются 7 дней, далее затираются, кроме недельного и месячного
— недельные бекапы (например, пятничный) хранятся месяц, далее затираются
— месячный бекап (например, за 1 число) хранится полгода/год — по выбору
Таким образом, вы охватываете больший период, при меньшем количестве «носителей». В максимальном случае это 6+4+12 = 22 «носителя».
Также, если вас интересует безопасность, рекомендуется владельцем баз сделать все-таки не sysdba, а специального пользователя
Циклический бекап лучше подходит при использовании инкрементных бекапов с помощью nbackup, о которых спрашивал qw1. В случае gbak-а придется выбирать между возможностю восстановиться (условно) на любой день за последний месяц, либо же на более отдаленные даты, но с «дырами». Тут уже больше от предметной области зависит.
Хотя, если учесть, что скрипт все же ориентирован в первую очередь на начинающих администраторов, будем надеятся, что у них относительно маленькие базы и какого-нибудь терабайтного винчестера/рейда хватит для обеспечения приемлимого уровня надежности.
А вот что касается владельца базы — опишите, пожалуйста, примерный сценарий, при котором владелец не sysdba обеспечит большую безопасность. Я действительно не понимаю, что это дает.
Хотя, если учесть, что скрипт все же ориентирован в первую очередь на начинающих администраторов, будем надеятся, что у них относительно маленькие базы и какого-нибудь терабайтного винчестера/рейда хватит для обеспечения приемлимого уровня надежности.
А вот что касается владельца базы — опишите, пожалуйста, примерный сценарий, при котором владелец не sysdba обеспечит большую безопасность. Я действительно не понимаю, что это дает.
Это, конечно, скорее защита от дурака, но при владельце, отличном от sysdba, в базе можно создать роль sysdba, которая не имеет никаких прав.
В этом случае sysdba не сможет зайти в базу, а также восстановить украденный бекап. То есть прикрываем того пользователя, который 100% есть на сервере, и на которого скорее всего будет атака.
Хотя, конечно, при физическом доступе к файлу БД/бекапу задача определения хозяина решаемая.
Ну и вообще — зачем светить лишний раз паролем администратора сервера, если нужно всего лишь запускать бекап отдельной базы?
Насчет защиты доступа sysdba — проверено на FB1.5, как на современных версиях не знаю, так как лет 5 уже плотно с fb не работаю.
В этом случае sysdba не сможет зайти в базу, а также восстановить украденный бекап. То есть прикрываем того пользователя, который 100% есть на сервере, и на которого скорее всего будет атака.
Хотя, конечно, при физическом доступе к файлу БД/бекапу задача определения хозяина решаемая.
Ну и вообще — зачем светить лишний раз паролем администратора сервера, если нужно всего лишь запускать бекап отдельной базы?
Насчет защиты доступа sysdba — проверено на FB1.5, как на современных версиях не знаю, так как лет 5 уже плотно с fb не работаю.
Описанная вами схема реализуется созданием трех заданий в планировщике, каждый со своим периодом запуска и со своей папкой назначения. Т.е. это не вопрос алгоритма, а лишь регламента.
Спасибо за интересную статью! Добавил топик в избранное для последующего использования и/или рекомендации клиентам (бывает, на форуме нашего ПО спрашивают про скрипты для Firebird).
Скажите, а у вас нет варианта для такого специфического, но, возможно, не столь редкого у разработчиков случая, когда есть большая папка с кучей разной степени вложенности подпапок, в которой хранятся разные базы, и периодически добавляются новые (или удаляются старые), и задача — делать бэкап своих баз или, скажем, прогнать один раз бэкап-рестор со сборкой мусора с целью уменьшения размера занимаемого на жестком диске пространства (ну заодно много других разработческих проблем решается)? Если готового решения нет, подскажите в какую сторону копать, я не очень силен в языке сценариев.
Скажите, а у вас нет варианта для такого специфического, но, возможно, не столь редкого у разработчиков случая, когда есть большая папка с кучей разной степени вложенности подпапок, в которой хранятся разные базы, и периодически добавляются новые (или удаляются старые), и задача — делать бэкап своих баз или, скажем, прогнать один раз бэкап-рестор со сборкой мусора с целью уменьшения размера занимаемого на жестком диске пространства (ну заодно много других разработческих проблем решается)? Если готового решения нет, подскажите в какую сторону копать, я не очень силен в языке сценариев.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Комплексная автоматизация резервного копирования баз данных Firebird/InterBase на Windows-серверах