Назад | Перейти на главную страницу

Virtualizor + Резервное копирование VPS (с возможностью восстановления Bare Metal) с использованием rSync 3

Я использую виртуализатор для управления 3 XEN VPS. Аппаратный узел и каждый VPS работают под управлением CentOS 5.x. Мои потребности в резервном копировании следующие:

1) Мне нужно иметь возможность восстановить весь аппаратный узел без покрытия, за исключением VPS (которые будут восстановлены с помощью # 2 ниже)

2) Мне нужно иметь полную резервную копию каждого VPS, в идеале резервную копию, которую можно развернуть на любом другом хосте, использующем Xen, если возникнет необходимость. Естественно, мне также нужно будет использовать эту резервную копию для восстановления всего VPS до более раннего состояния на том же хосте.

Резервные копии каких папок необходимо сохранить в rSync, чтобы выполнить вышеуказанное?

Специалисты rSync в этом тоже не уверены.

Спасибо

Когда вы говорите "rSync", вы имеете в виду rsync, как в http://rsync.samba.org/ ? Если это так, то я не понимаю, как можно добиться гарантированного восстановления с нуля, используя только rsync.

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

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

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

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

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

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

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

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