Применимость: Linux, OpenVZ
Слова для поиска: резервное копирование, архивирование
Как пользоваться автоматическим бэкапом VSMBACKUP?
С 2013.12.01 мы внесли изменения в алгоритм резервного копирования VPS с технологией OpenVZ.
Существенно то, что Во время бэкапа ваш сервер кратковременно переводится в «замороженное» состояние - suspend
Для бэкапа ранее использовалась технология LVM snapshot, что позволяло сливать данные без остановки сервера
За последний год было несколько случаев зависания узла виртуализации из-за ошибок в LVM Ошибки разработчики устраняли (или нам так казалось), но в следующей версии ядра мы снова натыкались на эти «грабли». Воспроизвести и отловить эту ошибку крайне трудно, но мы знаем что она связана с созданием LVM snapshot.
Последний месяц мы не используем этот режим. Для возможности резервного копирования мы сейчас используем кратковременный перевод сервера в режим suspend. Мы считаем, что лучше пусть сервер повисит в suspend несколько секунд в неделю чем упадет на несколько часов.
Сейчас бэкап делается в три фазы:
3-я фаза обычно завершается за несколько секунд. Иногда немного дольше. Если это продолжается до 120 сек, то при этом не теряются коннекты и сессии. Учитывая, что бэкап обычно делается в ночное время мы предлагаем считать это приемлемым.
Если вы замечаете более длительные перерывы в работе или кратковременная приостановка сервера не является приемлемой, мы можем исключить ваш сервер из стандартной схемы бэкапа.
В этом случае ваш сервер будет бэкапится без 3-й фазы. То есть без заморозки. При таком подходе остановок не будет вообще, но восстановление сервера может оказаться невозможным. В этом случае вам необходимо делать бэкап важных данных собственными средствами с сохранением архива внутри вашего сервера. Это позволит всегда иметь гарантированно исправную версию данных для восстановления. В этом случае вам придется самостоятельно настроить это.
Используйте mysqldump, mysqlhotcopy или xtrabackup
Лучше использовать xtrabackup, потому что например mysqldump может блокировать вашу базу на время бэкапа.
Инструкция по настройке xtrabackup:
Если ваш сервер будет бэкапиться по этой схеме, то не забудьте предупредить об этом техподдержку в случае необходимости восстановления сервера.
Примечание:
Если на вашем сервере есть другие файлы, которые постоянно открыты на запись и непрерывно подвергаются изменениям, регулярно делайте архивную копию внутри вашей системы для возможности восстановления. Ниже вы можете найти ссылки на подробные инструкции. В случае затруднений создайте запрос на техническую поддержку.
Для сохранения таких файлов рекомендуем использовать Резервное копирование при помощи SkyCover Duply
VSMBACKUP разработан для автоматического резервного копирования с условием обеспечить минимальную нагрузку на узлы виртуализации.
Архивные копии хранятся на специальном сервере хранения с обеспечением отказоустойчивости.
Если с момента создания сервера прошло больше недели, то на вашем сервере в каталоге /vsmbackup должны быть доступны резервные копии вашего сервера.
Если все же там пусто попробуйте сделать перезагрузку вашего сервера для перемонтирования сервера резервного копирования.
Содержимое /vsmbackup будет вам доступно и после переустановки операционной системы.
Инкрементные архивы
/vsmbackup: 146-2012-03-11.tar.gz 146-2012-03-23.tar.gz 146-2012-03-29.tar.gz 146-2012-04-05.tar.gz 146-2012-04-10.tar.gz 146-2012-04-12.tar.gz 146.snar
Для хранения данных используется алгоритм инкрементного архивирования. Сперва создается полный архив, потом каждую неделю добавляются инкрементные архивы которые хранят лишь изменения, которые появились с момента предыдущего архивирования.
Потому развертывается архив через распаковку всех составляющих архивов по очереди, от самых старых к самым новым.
Каждые 30 дней инкрементные архивы автоматически удаляются и после удаления начинается новый цикл с создания нового полного архива. То есть - архивы делаются каждую неделю, накапливается до 4-х архивов, что дает возможность восстановить систему в состояние на дату любого из них. Однако раз в месяц удаляются все и создается один новый полный архив.
Работы по восстановлению данных из VSMBACKUP должны производиться в консоли виртуального сервера при подключении по SSH. Можете использовать программу PuTTY, например.
Рекомендуем без особой необходимости не восстанавливать систему полностью, это может быть довольно долго и будут сообщения об ошибках связанные с тем, что запущенные службы могут не дать вам перезаписать некоторые файлы.
Например если у вас запущен mysql, то пока он работает вы не сможете перезаписать файлы баз данных файлами из архива.
Пример команд для восстановления каталога баз данных Mysql:
Сперва надо остановить демон Mysql:
/etc/init.d/mysqld stop Stopping MySQL: [ OK ]
Проверить какие архивы доступны:
ls -1 /vsmbackup/ 123-2012-03-27.tar.gz 123-2012-04-04.tar.gz 123-2012-04-11.tar.gz 123.snar
На моем сервере есть архивы за 23-е марта, 4-е апреля, 11-е апреля и файл 123.snar который содержит данные об инкрементном бэкапе.
Если я хочу восстановить данные по состоянию на 4- апреля, то я должен использовать архивы 123-2012-03-27.tar.gz и 123-2012-04-04.tar.gz
Базы данных mysql обычно хранятся в директории /var/lib/mysql/
Последовательно восстанавливаю данные из двух архивов:
tar -xzgf /vsmbackup/123-2012-03-27.tar.gz ./var/lib/mysql tar -xzgf /vsmbackup/123-2012-04-04.tar.gz ./var/lib/mysql
Не пропустите точку перед /var/lib/mysql
Должно быть именно так: ./var/lib/mysql
Пример команд для полного восстановления системы:
Сперва нужно остановить все службы кроме демона SSHD чтобы не потерять связь с сервером.
Например:
/etc/init.d/httpd stop /etc/init.d/nginx stop /etc/init.d/mysqld stop /etc/init.d/postfix stop /etc/init.d/sendmail stop /etc/init.d/exim stop /etc/init.d/syslog stop /etc/init.d/rsyslog stop /etc/init.d/syslog-ng stop
Я не знаю какие службы у вас запущены, писал команды наугад. У вас они могут быть другими. Например, mysql вместо mysqld.
Нужно убедиться, что службы остановлены:
Проверяем какие порты открыты на сервере командой netstat -atunp:
netstat -atunp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:42222 0.0.0.0:* LISTEN 7616/sshd tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 7700/mysqld
Упс, у меня запущен демон mysqld Забыл выполнить /etc/init.d/mysqld stop, выполняю.
Смотрим список активных процессов командой ps -ax:
ps -ax
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.7/FAQ
PID TTY STAT TIME COMMAND
1 ? Ss 0:03 init [3]
1100 ? S<s 0:00 /sbin/udevd -d
1266 ? Rs 0:00 vzctl: pts/0
1267 pts/0 Ss 0:00 -bash
7600 ? Ss 0:00 syslog-ng -p /var/run/syslog-ng.pid
7616 ? Ss 0:00 /usr/sbin/sshd
7760 ? Ss 0:00 crond
7837 pts/0 R+ 0:00 ps -ax
Еще мне нужно остановить демоны crond и syslog-ng
/etc/init.d/syslog-ng stop /etc/init.d/crond stop
Теперь команда восстановления системы из архива
tar -xzgf /vsmbackup/123-2012-03-27.tar.gz --exclude ./dev \ --exclude ./proc --exclude ./sys --exclude ./vsmbackup
Актуальность: 2012/05/21 14:48