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



    Регулярные бекапы — это верный способ сохранить свои важные данные. Произойти может все, что угодно: от пожара в дата центре до просто неаккуратно написанного и запущенного скрипта в вашей базе данных. К этому нужно быть готовым. Хоть вероятность этого достаточно мала, но потери, которые можно понести, огромны. Поэтому вес этого узла в дереве решений будет значителен, а следовательно, нужно позаботиться о бекапах как можно скорее.
    В этой статье мы расскажем, как организован сбор и хранение бекапов в нашей системе.



    Общий подход



    Наша схема хранения бекапов такова:
    — каждый день в полночь делаем полный бекап базы;
    — каждый день в полдень делаем разностный бекапы;
    — каждые 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;
    — время создания последних бекапов;
    — достаточно ли места на диске с бекапами.

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

    Если бекап будет использован в дальнейшем только разработчиками, то рекомендуется удалять/заменять критичные данные. Мы это делаем с хешами паролей, емейлами и другой личной информацией пользователей.

    Повторюсь, иметь бекапы — это очень важно. Но надеемся, что они вам не пригодятся.
    • –4
    • 14,6k
    • 9
    WORKZILLA
    36,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 9

      +1
      Мы делаем бэкапы через duplicity на Amazon S3 + RackSpace.Cloud File.
        0
        C какой скоростью потом можно получить бэкап?
          0
          731 MB база данных восстанавливается около 5 минут.
          Duplicity создает полные снапшоты каждые несколько дней. Нету необходимости применять патчи с самого первого снапшота.
        0
        По поводу того чтобы скопировать на удаленный сервер — использую точно такую же схему только во время бекапа сохраняю файлы на удаленный сервер.
          +1
          Использую похожую схему, но есть несколько отличий:
          Написал 3 bat-файла
          1 файл. Создает ежедневный бэкап базы и сжимает ее с помощью 7zip (с паролем) и складывает в папку Dropbox
          2 файл. Создает еженедельный бэкап базы со сжатием в 7zip (с паролем) и закачивает ее на Amazon Glacier
          3 файл. Создает еженедельный архив папки с изображениями (с паролем) и закачивает их на Amazon Glacier

          Все bat-ники запускаются с помощью Task Sheduler.
            –1
            это же база данных, какой смысл от бекапов? Разве потеря информации в промежутках между бекапами не является катастрофической?
              0
              Все-таки лучше чем ничего.
              0
              7z
              Не позволяет включать в архивы информацию для восстановления и не поддерживает возможность восстановления данных из поврежденных архивов.(c wiki)
              Поломался один байт по дороге и пропал целый архив. Может посмотреть на FreeArc или другие, со встроенной функцией добавления информации для восстановления.
                0
                Может для Вашего бизнеса это не критично, но для всех остальных, кто захочет делать как тут:
                Бекапы лога каждые 10 минут в 2 разных точки, желательно в разные географические точки!!!
                Тогда можно надеятся на 100% сохранность любых данных.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое