vsmbackup

Применимость: Linux, OpenVZ

Слова для поиска: резервное копирование, архивирование


Задача:

Как пользоваться автоматическим бэкапом VSMBACKUP?

ПРЕДУПРЕЖДЕНИЕ ОБ ИЗМЕНЕНИЯХ

С 2013.12.01 мы внесли изменения в алгоритм резервного копирования VPS с технологией OpenVZ.

Существенно то, что Во время бэкапа ваш сервер кратковременно переводится в «замороженное» состояние - suspend

Для бэкапа ранее использовалась технология LVM snapshot, что позволяло сливать данные без остановки сервера

За последний год было несколько случаев зависания узла виртуализации из-за ошибок в LVM Ошибки разработчики устраняли (или нам так казалось), но в следующей версии ядра мы снова натыкались на эти «грабли». Воспроизвести и отловить эту ошибку крайне трудно, но мы знаем что она связана с созданием LVM snapshot.

Последний месяц мы не используем этот режим. Для возможности резервного копирования мы сейчас используем кратковременный перевод сервера в режим suspend. Мы считаем, что лучше пусть сервер повисит в suspend несколько секунд в неделю чем упадет на несколько часов.

Сейчас бэкап делается в три фазы:

  1. Основной rsync копирует измененные за неделю и новые файлы с ограничением скорости чтобы не перегружать диск
  2. Быстрый rsync без ограничения скорости для переноса измененных данных за время 1-й фазы
  3. Заморозка системы (suspend) и быстрый перенос изменяемых данных (базы mysql и прочее)

3-я фаза обычно завершается за несколько секунд. Иногда немного дольше. Если это продолжается до 120 сек, то при этом не теряются коннекты и сессии. Учитывая, что бэкап обычно делается в ночное время мы предлагаем считать это приемлемым.

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

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

Используйте mysqldump, mysqlhotcopy или xtrabackup

Лучше использовать xtrabackup, потому что например mysqldump может блокировать вашу базу на время бэкапа.

Инструкция по настройке xtrabackup:

http://www.colobridge.net/wiki/howto/xtrabackup_-_%D1%80%D0%B5%D0%B7%D0%B5%D1%80%D0%B2%D0%BD%D0%BE%D0%B5_%D0%BA%D0%BE%D0%BF%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_mysql

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

Примечание:

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

Для сохранения таких файлов рекомендуем использовать Резервное копирование при помощи SkyCover Duply

VSMBACKUP

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-х архивов, что дает возможность восстановить систему в состояние на дату любого из них. Однако раз в месяц удаляются все и создается один новый полный архив.

Прочие особенности

  • Автоматическое резервное копирование на внешний сервер выполняется один раз в неделю. Если вам нужно более частое резервирование, Вы можете заказать это как дополнительную платную услугу.
  • Сложно сказать когда именно будет копироваться именно ваш сервер. Задания на резервное копирование выполняются с пониженным приоритетом в порядке очереди. Дату резервной копии вы можете узнать по имени архива. Например, имя 146-2012-03-11.tar.gz означает, что архив создан 11 марта 2012 года.
  • Не резервируются файлы архивов с расширениями tar.gz, tar.bz2, tar.lzma, zip, rar.
  • Не резервируются файлы сессий по маске sess_*
  • Место используемое под архивы не учитывается вашей квотой. Другими словами - если у вас квота 5Гб, то из этой квоты не вычитается пространство использованное резервными копиями.
  • Запись в каталог /vsmbackup и изменение данных вам запрещено.
  • Если ваш сервер не изменялся более 60 дней (это определяется по актуализации каталога с системными журналами /var/log), то резервные копии удаляются автоматически.

Восстановление данных

Работы по восстановлению данных из 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

Смотрите также: