Pull to refresh

Comments 8

На больших базах время восстановления gbak-файла неприемлемо большое.
Почему-то ни слова о стандартной утилите nbackup, позволяющей делать бекап-снепшоты, не требующие restore, а также инкрементальные бэкапы.
Эх, этот скрипт лет 5 назад назад бы :).
А так могу порекомендовать делать не 30-дневный архив бекапов, а т.н. циклический бекап, известный еще со времен ленточных накопителей:
— ежедневные бекапы, которые сохраняются 7 дней, далее затираются, кроме недельного и месячного
— недельные бекапы (например, пятничный) хранятся месяц, далее затираются
— месячный бекап (например, за 1 число) хранится полгода/год — по выбору
Таким образом, вы охватываете больший период, при меньшем количестве «носителей». В максимальном случае это 6+4+12 = 22 «носителя».

Также, если вас интересует безопасность, рекомендуется владельцем баз сделать все-таки не sysdba, а специального пользователя
Циклический бекап лучше подходит при использовании инкрементных бекапов с помощью nbackup, о которых спрашивал qw1. В случае gbak-а придется выбирать между возможностю восстановиться (условно) на любой день за последний месяц, либо же на более отдаленные даты, но с «дырами». Тут уже больше от предметной области зависит.

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

А вот что касается владельца базы — опишите, пожалуйста, примерный сценарий, при котором владелец не sysdba обеспечит большую безопасность. Я действительно не понимаю, что это дает.
Это, конечно, скорее защита от дурака, но при владельце, отличном от sysdba, в базе можно создать роль sysdba, которая не имеет никаких прав.
В этом случае sysdba не сможет зайти в базу, а также восстановить украденный бекап. То есть прикрываем того пользователя, который 100% есть на сервере, и на которого скорее всего будет атака.
Хотя, конечно, при физическом доступе к файлу БД/бекапу задача определения хозяина решаемая.
Ну и вообще — зачем светить лишний раз паролем администратора сервера, если нужно всего лишь запускать бекап отдельной базы?

Насчет защиты доступа sysdba — проверено на FB1.5, как на современных версиях не знаю, так как лет 5 уже плотно с fb не работаю.
При наличии утекшего бекапа безопасность firebird-базы равна нулю, т.к. а) база и бекап не шифруются, б) SYSDBA лежит не в базе. Т.е. любой другой сервер, пароль SYSDBA которого вы знаете, любезно пустит вас в неё.
Ну и роль 'SYSDBA' — это защита только от очень юного хакера.
Описанная вами схема реализуется созданием трех заданий в планировщике, каждый со своим периодом запуска и со своей папкой назначения. Т.е. это не вопрос алгоритма, а лишь регламента.
Ваш скрипт тоже реализуется 30 заданиями, но ведь это так неудобно :). Настоящий ленивый администратор, если ему нужно, и циклический бекап сделает 1 командой
Спасибо за интересную статью! Добавил топик в избранное для последующего использования и/или рекомендации клиентам (бывает, на форуме нашего ПО спрашивают про скрипты для Firebird).

Скажите, а у вас нет варианта для такого специфического, но, возможно, не столь редкого у разработчиков случая, когда есть большая папка с кучей разной степени вложенности подпапок, в которой хранятся разные базы, и периодически добавляются новые (или удаляются старые), и задача — делать бэкап своих баз или, скажем, прогнать один раз бэкап-рестор со сборкой мусора с целью уменьшения размера занимаемого на жестком диске пространства (ну заодно много других разработческих проблем решается)? Если готового решения нет, подскажите в какую сторону копать, я не очень силен в языке сценариев.
Sign up to leave a comment.

Articles