Резервное копирование базы данных — это такая штука, которую вечно приходится настраивать для уже работающих проектов прямо на «живых» production-серверах.
Подобная ситуация легко объяснима. В самом начале любой проект еще пуст и там просто нечего копировать. В фазе бурного развития головы немногочисленных разработчиков заняты исключительно прикручиванием фишек и рюшек, а также фиксом критических багов с дедлайном «позавчера». И только когда проект «взлетит», приходит осознание, что главная ценность системы — это накопленная база данных, и её сбой станет катастрофой.
Эта обзорная статья — для тех, чьи проекты уже достигли этой точки, но жареный петух ещё не клюнул.

Последнее время стали популярны посты на тему бекапа. Продолжу и я эстафету под девизом «Много бекапов хороших и разных».

Статья 1 и статья 2, натолкнувшие меня на эту идею.

Сам я давно пользуюсь rsnapshot для бекапа серверов, да и не только. Для тех, кто не в курсе, что оно такое — это базирующаяся на rsync утилита на Perl для создания резервных копий. Особенностью является ориентация на создание полных снапшотов файловой системы через заданный интервал времени, для экономии места на диске, не изменившиеся с момента первого бэкапа файлы линкуются как hard link.

Я работаю на Ubuntu 11.10 на ноутбуке и потому статья будет описывать метод бекапа этого самого ноутбука на внешний USB HDD, который не постоянно подключен, а подключается лишь периодически. В момент подключения и будет запускаться скрипт для бекапирования системы.

Итак, начнем.

Некоторое время назад потребовалось сделать бэкап базы данных на RAC. Задача, на самом деле, вполне тривиальная, если бы не несколько но: у заказчика паранойя по поводу безопасности (не удивительно и понятно), у заказчика нет своего DBA (ну так уж вышло) и у меня есть доступ только к консоли сервера с базой данных. Таким образом, пришлось отказаться от использования красивого и удобного Enterprise Manager и придумать банальные консольные скрипты. И вот тут-то и возникла загвоздка.

Стандартное решение: написать скрипты бэкапа, настроить cron, который будет их вызывать по расписанию, и на этом успокоиться до тех пор, пока база таки не упадёт. Но поскольку мы имеем дело с кластером из нескольких нод, встал вопрос, на которой из них дёргать бэкап. На всех — как-то многовато. На одной — а что, если именно она-то и упадёт, а все остальные останутся в строю? По очереди — а что, если упадёт именно та, чья очередь делать бэкап как раз и наступила? На каком-нибудь третьем сервере — нету лишней железки для дополнительной базы данных.

Тогда вспомнилась одна любопытная штука, которая появилась в версии 11.2 и с которой, кроме прочего, давно хотелось разобраться. А именно, внешние таблицы с возможностью предобработки подключаемого файла.

Понятно, что изобретённое решение — это нецелевое использование любопытной фичи. Но получилось забавно.

Зачем

С ростом количества сетевых узлов и сложности их конфигурации наверняка у многих возникает вопрос — а если железка умрет, смогу ли я быстро восстановить работу на другой? Если смогу сделать это вручную, то как долго я буду потом отлавливать мелочи, которые забыл?

Процесс гугления привел к пониманию того, что конкретно для этого вендора готовых решений подобного рода нет. То, что было найдено в комьюнити мне не понравилось — предлагали размещать скрипты резервного копирования на самой железке и запускать их по расписанию. По сути задачу это решало, но если у меня несколько десятков единиц оборудования, нащелкивать копипасту по каждому экземпляру — это не по Фен-Шую.

Благо есть небольшой навык написания полезняшек на Python и фантазия.

IT-специалистам несложно настроить резервное копирование дома, например, с помощью rsync, созданием rar-архивов планировщиком задач, инкрементальным копированием в интернет (не говоря уже о настройке tar+cron или bacula на работе). Однако неспециалисты (для дома) будут использовать программы резервного копирования, которые много проще. Рассмотрим программу, скрывающей за привычной простотой для домашнего пользователя, гибкий и хорошо продуманный инструмент резервного копирования.

В этой статье речь пойдет о бесплатной версии Genie Timeline — Free (Noncommercial), с незначительными ограничениями и отличиями от платных версий (например, нет бэкапа с телефонов Blackberry). Стоит упомянуть, что Pro-версии используют такие компании, как NASA, Siemens, NEC, ZyXEL и Philips.

Задача:

• Ежедневный backup mysql базы данных для JIRA и Confluence;
• Ежедневный backup директорий с attachments;
• Архивирование всех сделанных backup'ов;
• Удаление старых backup'ов.

Оговорюсь, что мне это нужно было сделать для Windows и я понимаю, что для Linux все делается проще и быстрее. Также если вы являетесь администратором, то данный топик вряд ли будет вам интересен и ничего нового вы не узнаете. Но можете использовать написанное, как готовое и проверенное решение.