Регулярные бекапы — это верный способ сохранить свои важные данные. Произойти может все, что угодно: от пожара в дата центре до просто неаккуратно написанного и запущенного скрипта в вашей базе данных. К этому нужно быть готовым. Хоть вероятность этого достаточно мала, но потери, которые можно понести, огромны. Поэтому вес этого узла в дереве решений будет значителен, а следовательно, нужно позаботиться о бекапах как можно скорее.
В этой статье мы расскажем, как организован сбор и хранение бекапов в нашей системе.
Общий подход
Наша схема хранения бекапов такова:
— каждый день в полночь делаем полный бекап базы;
— каждый день в полдень делаем разностный бекапы;
— каждые 30 минут делаем бекап транзакционного лога.
Таким образом, теоретически, в худшем случае Воркзилла может потерять данные за 30 минут, а в среднем за 15 минут. Что очень неприятно, но все-таки лучше, чем потерять больше или вообще все. Конечно, есть более надежные схемы, но то, что используем мы, думаю, подойдет многим.
Бекапы мы делаем на один из специально для этого предназначенных дисков и выгружаем данные на Amazon S3, который гарантирует, что данныe не пропадут.
Автоматические бекапы в MS SQL Server
MS SQL Server позволяет легко организовать схему создания бекапов, которая подойдет для вашей системы. Мы для этого используем “Планы обслуживания” (Maintanance Plans). Новый план можно создать при помощи встроенного помощника или интуитивно понятного конструктора планов. Подробнее о создании “Планов Обслуживания” можно почитать тут.
Кроме создания самого бекапа, можно запускать дополнительные скрипты по очистке базы, проверить ее на целостность данных, удалить старые бекапы, чтобы не переполнялся диск, и т.д.
Пример готового плана для создания полных бекапов показан на картинке
"
После того как план создан, необходимо настроить соответствующую работу в SQL Server Agent.
Для этого нужно убедиться, что сервис установлен и запущен. В окне инспектора объектов выбрать SQL Server Agent -> Jobs -> кликнуть правой кнопкой по вашей работе и выбрать Изменить (Modify) в контекстном меню.
В открывшемся окне вы сможете посмотреть всю информацию о вашей работе и изменить ее при необходимости. Ниже показан пример формы для изменения расписания, по которому будет запускаться выбранная работа.
Загружаем в Amazon S3
Теперь резервные копии вашей базы будут создаваться по тому сценарию, который вы описали. На следующем шаге важно позаботиться о том, чтобы бекапы не пропали, если что-то случится с вашим сервером, например, испортится жесткий диск. Безопаснее всего скопировать бекап в другое место. Это может быть сервер в другом дата центре, какое-либо облачное хранилище либо что-то еще.
Мы используем для этого Amazon S3. Он гарантирует, что данные не пропадут, к тому же этот сервис достаточно дешевый.
Для синхронизации диска с нашими бекапами и S3 мы используем простую самописную утилиту на python. Она запускается при помощи Task Scheduler — встроенной утилиты Windows. Скрипт запускается каждые 30 минут и, благодаря небольшому объему бекапов транзакционного лога, эта процедура не потребляет много ресурсов.
Если вы решите использовать Amazon S3, то следует помнить о лимите в 5 Гб при загрузке файла. Если требуется загружать файлы большего размера, то придется загружать файлы по частям.
Нужно ли сжатие?
Размеры файлов резервных копий баз данных могут иметь существенные объемы, и при выгрузке на другой сервер может возникать несколько проблем:
— резко возрастает исходящий траффик;
— забивается сетевой канал;
— возрастает число операций ввода/вывода у текущего диска.
Бекапы можно сжимать, используя различные архиваторы (мы рекомендуем 7z).
Таким образом, решаются проблемы, описанные выше, но возникает другая: для сжатия файла требуются существенные затраты процессорного времени.
Вам предстоит решить, какой вариант для вас более предпочтителен. В случае Воркзиллы мы не сжимаем бекапы.
О чем нужно помнить
Мы рекомендуем настроить систему, которая будет периодически проверять, корректно ли работают все ваши процессы по созданию бекапов. Мы в Воркзилле используем Nagios. Его лучше настраивать на отдельном сервере внутри локальной сети. Из того, что нужно проверять, я выделяю следующее:
— запущен ли SQL Agent;
— появляются ли новые файлы на S3;
— время создания последних бекапов;
— достаточно ли места на диске с бекапами.
Для тех, кто очень беспокоится о безопасности своих данных, можно архивировать бекапы с паролем. Теперь, если бекап каким-то образом попадет в руки злоумышленников, им будет проблематично получить данные.
Если бекап будет использован в дальнейшем только разработчиками, то рекомендуется удалять/заменять критичные данные. Мы это делаем с хешами паролей, емейлами и другой личной информацией пользователей.
Повторюсь, иметь бекапы — это очень важно. Но надеемся, что они вам не пригодятся.
Автор: serproc
