Главная > Базы данных > Создаём «пуленепробиваемые» бэкапы для MySQL

Создаём «пуленепробиваемые» бэкапы для MySQL


22 февраля 2010, 12:00. Разместил: Mysterious Master
Вы уже запаслись резервной базой данных? Если нет, то очень рекомендуем Вам, ведь на дворе 2010 год. Может, у нас еще и нет летающих машин, но сделать бэкап базы данных точно не составит труда. Мы даже в какой-то степени уверены, что каким-то образом Вы все-таки делаете резервные копии баз. Мы знаем, что Вы спите очень спокойно, зная, что даже если метеорит упадет в серверную Америку, в которой размещено оборудование, на которых хранятся Ваши веб-сайты, то у Вас есть резервные копии и Вы сможете все восстановить в течении пары минут.

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

Но несмотря даже на такое удобное средство – как файлообменники или хранилища информации прямо на просторах сети Интернет, люди все равно ленятся или забывают делать резервные копии документов. Это относится не ко всем, конечно же. Есть компании, которые пользуются блестящими сервисами по созданию резервных копий важных документов.

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

Есть шелл-скрипт (нужно удалить расширение *.txt перед тем, как воспользоваться), который может быть отличным стартом в этом деле, и мы немного расскажем о нем. db-backup.sh.rar [989 b] (cкачиваний: 41)
Но для начала давайте поговорим о бэкапах, о более общем понятии, чтобы мы смогли определить нашу конечную цель.

Типы вещей, которым требуется резервная копия (бэкап – backup)

Существует огромное множество различной информации, которую стоило бы хранить еще в резерве. Самой основной информацией считают:

1. Исходный код
2. Статические файлы (изображения, PDF и т.д.)
3. Информация в базе данных

В наше время есть отличная возможность размещения файлов с исходным кодом в системах «RCS» (перезагружаемое управляющее запоминающее устройство), например, где-нибудь в GitHub. Если Вы пользуетесь таким методом (а Вам следовало бы), и Ваша система RCS располагается на стороннем сервере (от сервера, где размещен Ваш веб-сайт), то у Вас уже есть резервная копия исходного кода. Если с используемым сервером возникнут какие-то неполадки, то Вы просто можете скопировать все на новый сервер. Это одно из преимуществ использования систем RCS.

Статичные файлы (изображения, музыка и т.д.) очень легко поддаются процессу создания бэкапа. Быстрый поиск выдаст Вам огромное количество способов перемещения данных типов файлов куда-нибудь на запасное место, в качестве подстраховки.

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

Более того, это не лучший способ создания резервных баз данных, потому что восстановление из такого типа файлов может вызвать сложности. Вот тот шелл, о котором говорилось выше, как раз может безопасно сделать копию стандартной базы данных MySQL или баз данных с полным шифрованием на стороннее хранилище.

Правда ли у меня теперь есть бэкап?

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

Если в Вашей инструкции нет шага о восстановлении информации, или Вы не пытались протестировать процесс восстановления, то у Вас нет бэкапа!

Все очень просто, но и на самом деле, пока Вы не столкнетесь со всем, что касается восстановления, Вы не сможете узнать – есть ли у Вас этот резерв. Если Вы не пробовали – Вы и не можете знать результата. К примеру, однажды администратор впервые столкнулся с созданием бэкапа некоторых баз данных. Он копировал резервные базы на удаленный компьютер посредством rsync. Он был уверен в том, что у него есть бэкап, но он ошибался, как выяснилось позже.

Как мы уже заметили ранее, если во время процесса rsync будет произведена запись, то гарантированно, что базы будут непригодными. Если бы он когда-нибудь попробовал восстановить эти файлы (а он не сделал этого), то он бы точно разузнал, в чем проблема. И поэтому, мы говорим Вам еще раз – пока Вы не протестируете процесс восстановления, нельзя быть уверенным в наличии бэкапа.

И еще одна вещь, которую нам стоит выделить – всегда сохраняйте резервные копии на сторонние сервисы или компьютеры. Потому что есть вероятность того, что когда Вам потребуется сделать восстановление, проблема может быть именно с Вашей системой.

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

Стандартная процедура настройки создания резервных копий баз данных

Мы пошагово расписали желаемую процедуру создания бэкапа для Virb:

* Создайте временные файлы базы данных
* Сожмите данные
* Зашифруйте данные
* Отошлите эти данные посредством зашифрованного соединения на сторонний сервис
* Автоматизируйте этот процесс с помощью crontab

И здесь не должно быть какой-либо путаницы. Обычно путаница приводит к краху всей процедуры. А ведь последнее, о чем бы Вы хотели беспокоиться, так это о крахе.

Предпосылки

Итак, немного разъясним ситуацию. Допустим, Вы используете новый дистрибутив Линукса по типу Debian (который включает Ubuntu). Вам нужна возможность использовать программу mysqldump, чтобы получить дамп выбранной базы данных. Обычно это приложение идет по умолчанию с инсталлятором MySQL в каждом дистрибутиве Linux.

Будем считать, что у Вас есть установленный в корневом каталоге файл .my.cnf с именем пользователя и паролем, который позволит Вам создать дамп-файл нужных данных. Если Вы никогда раньше не пользовались файлом .my.cnf, то не пугайтесь, все достаточно просто. Создайте файл с названием .my.cnf в корневом каталоге, и внесите туда следующие данные:

[client]
user = dbusername
password = dbpassword

Конечно же, не забудьте указать Ваши данные в строки с именем пользователя и пароля. Затем, задайте права на файл chmod 600 $HOME/.my.cnf (что означает, что другие пользователи не смогут открыть его). Теперь Вы можете использовать все утилиты командной строки mysql*, все время используя атрибуты -u и -p.

Еще следует принять во внимание безопасный запуск mysqldump, который гарантирует, что на Вашем сайте ничего не перепутается. Т.е., ставится запрет на запись на все таблицы в базе, во время дэмпинга базы данных. Говоря точнее, когда производится копирование записей в базе, можно произвести чтение, но невозможно применить процедуры INSERT, UPDATE или DELETE.

Если в Вашей базе несколько сотен мегабайт информации (она обычно размещена в /var/lib/mysql на системах Linux), то у Вас вряд ли возникнут проблемы с дэмпингом базы, так как это займет всего 15 секунд. 15 секунд среди ночи вряд ли возмутят кого-то из посетителей.

Но если у Вас действительно много информации и это может занят длительное время, то лучше всего установить сторонний сервер MySQL, который бы работал исключительно для бэкапов базы данных. Идея заключается в том, что сторонний сервер просто получает те же базы данных и хранит их.

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

К сожалению, объяснение о создании стороннего сервера MySQL не входит в рамки этой статьи.

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

К тому же, нужно взять во внимание, что Вам потребуются установленные stunnel4, rsync и gpg. Это вполне стандартные и бесплатные программы. На свежих дистрибутивах Debian (которые включают в себя Ubuntu), Вы можете установить все эти приложения посредством команд от администратора:

apt-get update && apt-get install stunnel4 rsync gnupg

Настройка шифрования

Нам нужно зашифровать наши резервные базы данных, и передавать зашифрованные файлы мы будем посредством безопасного соединения. С технической стороны, это уже преувеличение возможной опасности, но шифровать очень легко, поэтому мы все равно им воспользуемся. Для начала Вам нужно сгенерировать ключи GPG для дальнейшего использования.

Мы не будем объяснять здесь, как это сделать, так как Вам потребуется не больше 5 минут, чтобы найти материал и изучить, как это сделать. Просто учтите, что Вам следует запомнить кодовое слово, а также можете сделать копии ключей куда-нибудь на свой компьютер, просто ради безопасности.

Теперь Вам нужно настроить ключи GPG, и разобраться с аккаунтом в IBackup. Создайте файл .ibackup в корневой директории. Файл должен состоять из этого:

IBACKUP_USERNAME=username
IBACKUP_PASSWORD=password
GPG_EMAIL=your@email.com

Скоро станет понятно, для чего нужен этот файл. Измените имя пользователя и пароль на свои, которые Вы ввели в аккаунте IBackup, и впишите e-mail адрес, который был использован для создания ключей GPG. Не забудь установить права chmod 600 $HOME/.ibackup, чтобы никто кроме Вас не смог видеть пароль.

Теперь нам нужно немного подстроить stunnel4. Нам не нужно, чтобы он постоянно работал, так что отключите его и убедитесь, что приложение не запускается с каждой загрузкой системы, используя следующие команды:

/etc/init.d/stunnel4 stop
update-rc.d -f stunnel4 remove

Теперь давайте настроим stunnel4 для работы с IBackup. Для начала уберите исходный файл конфигураций.

cd /etc/stunnel
mv stunnel.conf stunnel.conf-orig

Далее, в текстовом редакторе создайте файл под названием ibackup.conf в директории /etc/stunnel. Файл должен состоять из этого:

client = yes
[ibackup]
accept = 8455
connect = rsync4.ibackup.com:5000

Эти данные предназначены специально для IBackup, но и другие приложения также имеют схожие данные. Опция "accept" определяет локальный порт, который будет использовать stunnel4, и поэтому Вам не следует указывать порт, который возможно используется.

Выполняем процедуру создания бэкапа

Так как мы уже обеспечили безопасность, можно приступать к созданию резервных копий. Открывайте шелл (о котором говорилось в самом начале статьи) в текстовом редакторе так, чтобы можно было в нем разобраться. Первые 14 строк содержат имена баз данных, которые мы собираемся копировать, и определяют приложения, которые будут использованы для этого.

#!/bin/bash

# ibackup.com destination
IBACKUP_DEST=$1

# database names
DB_NAMES=$2

# binaries we need
MYSQLDUMP=/usr/bin/mysqldump
GZIP=/bin/gzip
GPG=/usr/bin/gpg
RSYNC=/usr/bin/rsync
STUNNEL=/usr/bin/stunnel4

Если Вы никогда раньше не работали с шеллами, то все равно не должно возникнуть сложностей. Данные типа $1 и $2 определяют команду, которая будет проводиться посредством скрипта. Итак, здесь $1 – это то, что мы будем использовать в качестве имени полученного файла с резервными базами, а $2 содержит имена баз данных, которые мы будем копировать.

Самое интересное идет с 23 до 39 строки.

DOTIBACKUP="$HOME/.ibackup"

if [ ! -r $DOTIBACKUP ]; then
    echo "Need $DOTIBACKUP file for username and password!"
    exit 1
else
    PERMS=`/bin/ls -l $DOTIBACKUP | /usr/bin/awk '{print $1}'`
fi

if [ $PERMS != "-rw-------" ]; then
    echo "Permissions on $DOTIBACKUP are wrong!"
    echo "Should be -rw-------, actually is $PERMS"
    exit 1
fi

. $DOTIBACKUP
export RSYNC_PASSWORD=$IBACKUP_PASSWORD

Эти команды проверяют наличие файла .ibackup и выставленные права. Если все нормально, то исходный файл, можно сказать, впитывает в себя все что проходит через скрипт. Затем устанавливается, что переменная RSYNC_PASSWORD будет значением строки IBACKUP_PASSWORD, которое Вы использовали для доступа к сервису.

Строки 41 и 42 устанавливают связь с локальным портом, необходимым для работы с stunnel4.

# local stunnel4 port
STUNNEL_PORT=`/bin/grep 'accept' /etc/stunnel/ibackup.conf | awk '{print $3}'`

Далее, между линиями 44 и 49 мы убеждаемся в том, что директория, нужная для хранения всей информации, существует.

# place to dump everything
DUMPDIR="$HOME/.ibackup_data"

if [ ! -d $DUMPDIR ]; then
    mkdir $DUMPDIR
fi

Мы собираемся настроить систему на создание резерва каждый день. И было бы очень кстати, если бы хранились данные за несколько последних дней. Просто для подстраховки. В строках 51-56 мы используем очень удобный механизм дат *NIX, который выставляет даты за текущий день, вчерашний и день перед вчерашним.

# today, for tagging the dumpfile
DATE=`/bin/date +%Y-%m-%d`

# yesterday, and the day before that
ONEDAYAGO=`/bin/date -d '1 day ago' +%Y-%m-%d`
TWODAYSAGO=`/bin/date -d '2 days ago' +%Y-%m-%d`

Мы уже почти готовы сделать копию. С 58 по 86 строки все на самом деле очень скучно. Просто проверьте, выставлены ли параметры конечной папки и программы, необходимые для работы. Есть важный момент в строках 88 и 92 – в них находится информации о запуске mysqldump.

cd $DUMPDIR

echo -n "dumping $DB_NAMES to $DUMPDIR/$IBACKUP_DEST-$DATE.mysql... "
$MYSQLDUMP --opt --databases $DB_NAMES > $IBACKUP_DEST-$DATE.mysql
echo "done!"

Давайте взглянем на команду дэмпинга, чтобы быть уверенными в том, что мы все там понимаем. Переменная $DB_NAMES была ранее установлена в скрипте. Это второй параметр командной линии, проходящий через скрипт, и он сообщает mysqldump о базах, которые относятся к нему. Переменная $IBACKUP_DEST отвечает за часть имени нашего дамп-файла. И наконец, переменная $DATE – о нем мы говорили совсем недавно. Он определяет дату создания.

Далее, между строками 94 и 105 дамп файл подвергается шифрованию и сжатию. Также там проверяется состояние шифрования.

echo -n "gzipping $DUMPDIR/$IBACKUP_DEST-$DATE.mysql... "
$GZIP $DUMPDIR/$IBACKUP_DEST-$DATE.mysql
echo "done!"

echo -n "encrypting $DUMPDIR/$IBACKUP_DEST-$DATE.mysql... "
$GPG -e -r $GPG_EMAIL $DUMPDIR/$IBACKUP_DEST-$DATE.mysql.gz
echo "done!"

if [ $? -ne 0 ]; then
    echo "encryption failed!"
    exit 7
fi

Дальше проводится небольшая чистка и в строках 107-112 запускается stunnel4.

echo -n "removing $DUMPDIR/$IBACKUP_DEST-$DATE.mysql.gz... "
/bin/rm -fv $DUMPDIR/$IBACKUP_DEST-$DATE.mysql.gz
echo "done!"

echo "Starting stunnel for rsync..."
/etc/init.d/stunnel4 start

И теперь, в строке 114, мы наконец-то отсылаем наш свежеиспеченный резервный файл на удаленные серверы посредством IBackup.

$RSYNC -r -v -z -t --delete-after --exclude $IBACKUP_DEST-$ONEDAYAGO* --exclude $IBACKUP_DEST-$TWODAYSAGO* $DUMPDIR/ $IBACKUP_USERNAME@localhost::ibackup/$IBACKUP_DEST --port $STUNNEL_PORT

Все это представляет собой несколько разных свойств RSYNC, так что давайте подробнее ознакомимся с этим термином. Окончания командной строки -r -v -z -t представляют собой параметры синхронизации в IBackup. Параметр --delete-after говорит rsync о том, что все файлы, которые были синхронизированы и которых нет в локальной директории, должны быть удалены. Но у нас здесь также есть два параметра --exclude.

Это нечто вроде оповещения о том, что нам нужны переданные файлы, а к тому же и один со вчерашнего дня и позавчерашнего тоже, но все остальное надо удалить. Это значит, что у нас будут резервные копии за последние три дня. И еще один интересный момент – мы указали rsync об использовании, $STUNNEL_PORT, что означает, что вся связь осуществляется посредством stunnel4 и поэтому все файлы шифруются.

Последние строки 116-121 просто останавливают работу stunnel4 и удаляют временную директорию.

echo "Stopping stunnel for rsync..."
/etc/init.d/stunnel4 stop

echo -n "Cleaning up... "
/bin/rm -rfv $DUMPDIR
echo "done!"

Так что, все должно быть примерно так. Чтобы выяснить это, скопируйте и запустите скрипт db-backup.sh с выставленными правами CHMOD 755 - chmod 755 db-backup.sh. Не забудьте протестировать его, чтобы убедиться в том, что он работает. Если Вы хотите, чтобы цель называлась «mybackup» и Вам нужно сделать резервные копии баз с именами «db1», «db2» и «db3», то Вам нужно запускать скрипт таким образом.

/path/to/db-backup.sh mybackup "db1 db2 db3"

Если это сработает, то мы уже почти в конце пути! Нам просто нужно автоматизировать процедуру, что можно сделать посредством cron. В шелл, которым Вы тестировали скрипт, впишите следующее:

crontab -e

Это перенесет Вас в режим редактирования работы cron. Предположим, что Вы хотели бы, чтобы бэкап делался в 12:40 каждый день. Внесите следующие данные в Ваш файл crontab:

0 40 * * * /path/to/db-backup.sh mybackup "db1 db2 db3" >/dev/null 2>&1

Сохраните файл, и затем внесите строку «crontab -l» в список задач crontab, и убедитесь, что строка там присутствует. Если все нормально, то нам остается сделать лишь следующее.

Тестируем восстановление баз

В начале статьи мы говорили, что если у Вас не получается восстановить файлы, то можно считать, что у Вас и нет бэкапа. На самом деле, мы имели в виду как раз это. Ну что же, если Вы уже зашли так далеко, то следует сделать и последний шаг – восстановление баз. Через день, после того, как Вы проделали все эти действия, идите в аккаунт IBackup, скачивайте дамп-файл, расшифровывайте его посредством ключей GPG, которые Вы сделали, и восстанавливайте базы через запущенный MySQL.

Убедитесь, что у Вас получилось сделать последний шаг правильно, и тогда не может быть и речи об утрате данных из баз.

В заключение

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

Если Вы хотите использовать другие приложения, то Вам нужно будет просто заменить некоторые команды, которые проводятся через rsync. Хотя, основная задача и процесс реализации вряд ли поменяются в ближайшее время.

Удачи Вам!
Вернуться назад