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

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

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

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

Какие папки rSync необходимо сохранить для выполнения вышеперечисленных действий?

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

Спасибо

1 ответ

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

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

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

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

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

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

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

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

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

Другие вопросы по тегам