Насколько жизнеспособны в качестве стратегии резервного копирования периодические снимки LVM xen domU? Плюсы, минусы, подводные камни?
Мне это кажется идеальным решением для быстрого безмозглого восстановления. Любое расследование может быть проведено на сломанном логическом томе, если domU будет успешно работать без перебоев.
РЕДАКТИРОВАТЬ:
Вот где я сейчас, когда делаю полное резервное копирование системы.
Теперь мне нужно это автоматизировать.
Снимки LVM предназначены для захвата файловой системы в замороженном состоянии. Они не предназначены для использования в качестве резервной копии сами по себе. Однако они полезны для получения согласованных образов резервных копий, поскольку замороженный образ не может и не будет изменяться в процессе резервного копирования. Таким образом, хотя вы не будете использовать их напрямую для создания долгосрочных резервных копий, они будут иметь большое значение в любом процессе резервного копирования, который вы решите использовать.
Чтобы создать снимок, нужно выполнить несколько шагов. Во-первых, необходимо выделить новый логический том. Цель этого тома - предоставить область, в которой записываются дельты (изменения) файловой системы. Это позволяет продолжить работу исходного тома без нарушения существующего доступа для чтения / записи. Обратной стороной этого является то, что область моментального снимка имеет конечный размер, что означает, что в системе с загруженными операциями записи она может заполняться довольно быстро. Для томов, которые имеют значительную активность записи, вы захотите увеличить размер вашего снимка, чтобы оставить достаточно места для записи всех изменений. Если ваш снимок переполнится (заполнится), оба снимка остановятся и будут помечены как непригодные для использования. Если это произойдет, вы захотите выпустить свой снимок, чтобы снова подключить исходный том. После завершения выпуска вы сможете перемонтировать том для чтения / записи и сделать доступной файловую систему на нем.
Второе, что происходит, это то, что LVM теперь «меняет местами» истинные цели рассматриваемых томов. Вы могли бы подумать, что вновь выделенный снимок будет местом для поиска любых изменений в файловой системе, в конце концов, это то место, куда собираются все записи, верно? Нет, все наоборот. Файловые системы смонтированы на том LVM имена, так что замена название из-под остальной системы будет запрещено (потому что снимок использует разные название). Итак, решение здесь простое: когда вы получаете доступ к исходному имени тома, оно будет продолжать ссылаться на жить (чтение / запись) версия тома, для которого вы сделали снимок. Созданный вами моментальный снимок будет относиться к замороженный (доступная только для чтения) версия тома, резервную копию которого вы собираетесь создать. Сначала это немного сбивает с толку, но в этом есть смысл.
Все это происходит менее чем за 2 секунды. Остальная система даже не замечает. Если, конечно, вы не отпустите снимок до того, как он переполнится ...
В какой-то момент вы захотите выпустить снимок, чтобы освободить занимаемое им место. После завершения выпуска том моментального снимка возвращается в том, а оригинал остается.
Я не рекомендую использовать это в качестве долгосрочной стратегии резервного копирования. Вы по-прежнему размещаете данные на том же физическом диске, который может выйти из строя, и восстановление вашей файловой системы с отказавшего диска вообще не является резервной копией.
Итак, в двух словах:
Снимки LVM отлично подходят для резервного копирования вашего сервера, не отключая его. Как указано выше, моментальные снимки LVM являются почти мгновенными копиями. Вы создаете их, используя lvcreate так же, как если бы вы создавали сам LV, только вы даете ему --snapshot вариант и оригинальный LV вместо VG. Например:
lvcreate -L <LV size> -s -n <snapshot name> /dev/<VG name>/<LV name>
Это создаст моментальный снимок данного LV с указанным именем моментального снимка, который затем вы сможете подключить и использовать этот моментальный LV для выполнения резервного копирования, не беспокоясь об активно используемых файлах. Это особенно полезно, если вы пытаетесь создать резервную копию активного сервера базы данных.
После того, как вы закончите резервное копирование из моментального снимка, вы захотите удалить его, чтобы уменьшить любые дополнительные накладные расходы ввода-вывода или другие проблемы с производительностью, как уже упоминалось другими, используя:
lvremove /dev/<VG name>/<snapshot name>
Хотя моментальные снимки LVM могут иметь неоценимое значение для создания надежных резервных копий таких систем, как базы данных, и таких систем, которые обычно требуется выключить для резервного копирования, чтобы избежать конфликтов файлов, они не идеальны для долгосрочной работы в качестве быстрого восстановления.
Плохая идея, ИМО.
Моментальные снимки реализованы в режиме копирования при записи, поэтому вы превращаете каждую запись в чтение и две записи (блок, который вы обновляете, сначала считывается из основного тома и сохраняется в томе моментального снимка, прежде чем вы помещаете новые данные в его место), поэтому вы увидите некоторое снижение производительности, если на виртуальных машинах часто выполняется много записей.
Кроме того, IIRC, если том моментального снимка заполняется, он просто бесцеремонно удаляется. Это не подходит для резервного копирования! Поэтому, если вы все же попробуете это в качестве метода резервного копирования, обязательно сделайте том моментального снимка достаточно большим для обработки всех изменений, которые произойдут в течение срока полезного использования моментального снимка. Конечно, если вы знаете и отслеживаете проблему с размером, а проблема с производительностью не является для вас проблемой, то то, что вы предлагаете, может стать полезным дополнением к другим процессам резервного копирования, которые у вас есть.
Снимки LVM очень полезны как часть процесса резервного копирования (создание снимка, резервное копирование снимка в другое место для обеспечения согласованности резервной копии без необходимости отключать обновления «реального» тома, затем удалите моментальный снимок), среди прочего, но не предназначены для самостоятельного резервного копирования.
Перед созданием снимка необходимо убедиться, что данные на диске находятся в согласованном состоянии. например mysql может иметь данные, кэшированные в памяти, которые необходимо принудительно записать на диск, либо путем сброса базы данных, либо путем ее выключения. См. Подробности в руководствах по приложениям.
Помимо умного внешнего вида, LVM на самом деле является «всего лишь» уловкой с отображением устройств. Создание снимка с помощью lvcreate - это не более чем оболочка для некоторых вещей dmsetup. Оболочка создает новое устройство (том моментального снимка) из одного старого тома (исходный уровень lv) и нового (тома копирования при записи). Вместе с этим исходный LV переименовывается в -real (см. Ниже вывод dmsetup ls --tree). Этот -real LV отображается как на том моментального снимка, так и на исходный том, поэтому его можно использовать в обоих местах. Объем копирования при записи работает как наложение на реальный LV. -Snap LV показывает вам комбинацию тома копирования при записи и реального тома. Это действительно создает некоторые накладные расходы на производительность.
Volume00-snap (253:11)
|-Volume00-snap-cow (253:13)
| `- (104:2)
`-Volume00-LogVol01-real (253:12)
`- (104:2)
Volume00-LogVol01 (253:5)
`-Volume00-LogVol01-real (253:12)
`- (104:2)
При удалении снимка снова происходит некоторое переименование и отображение. После этого ситуация снова будет выглядеть примерно так
Volume00-LogVol01 (253:5)
`- (104:2)
Что касается того, насколько это хороший метод резервного копирования данных: это может быть, если вы примете во внимание, что это (1) не поможет для ОЗУ виртуальных машин, (2) снизит производительность и (3) вам понадобится для хранения изображений снимка в другом месте.
VMware VCB также работает со снимками, но не LVM.
Даже если снимки не повлияли на производительность, вы должны понимать: снимки - это не больше резервная копия, чем копия в другую папку на том же диске.
Если диск тормозит, ваши данные и резервная копия будут потеряны. Даже если вы назначите область снимка другому PE в группе VG, она будет содержать только данные, измененные с момента создания снимка.
Резервное копирование означает как минимум копию на полностью отдельный диск.
Я использую такую установку для снимков серверных машин vmware и баз данных mysql. пока работает нормально. была пара восстановлений - все без проблем. Одна вещь, которую следует учитывать - при работе со снимками lvm значительно снижает производительность операций ввода-вывода. смотрю Вот. игнорируйте тот факт, что они говорят о mysql, операции ввода-вывода - это операции ввода-вывода ... независимо от того, какие данные находятся на lvm.
Я использую снимки lvm только для того, чтобы скопировать еще один DomU Lv в отдельный Vg, где у каждого домена есть три резервных "узла" для удаления.
После этого снимок уничтожается, а резервные уровни остаются до следующего раунда. Если мне нужно выполнить восстановление, мне просто нужно выбрать источник Lv из резервной копии Vg и скопировать его в домен Lv.
Время от времени резервная копия Lv выгружается в файл образа на отдельном сервере.
Все это автоматизировано с помощью скрипта, с резервным копированием каждые два дня и дампом каждую неделю.
У меня даже был в голове режим «паники», в котором домен Lv будет восстанавливаться, но запускаться из моментального снимка и сбрасываться каждые 2 часа, чтобы сайт оставался в сети в случае серьезных взломов, пока не будет организована надлежащая защита .
Что стало с идеей защиты «панического режима»?