Снимки LVM как стратегия резервного копирования

Насколько жизнеспособной в качестве стратегии резервного копирования будут периодические снимки LVM xen domU? Плюсы, минусы, какие-нибудь ошибки?

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

РЕДАКТИРОВАТЬ:

Вот где я сейчас, когда делаю полное резервное копирование системы.

• lvm снимок диска domU
• новый логический том, размер которого равен размеру снимка.
• дд если = / dev / снимок = = dev / new_lv
• удаление снимка с lvremove
• дополнительная проверка с помощью kpartx / mount / ls

Теперь мне нужно автоматизировать это.

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

Есть несколько шагов для реализации снимка. Во-первых, необходимо выделить новый логический том. Цель этого тома - предоставить область, в которой записаны дельты (изменения) в файловой системе. Это позволяет продолжить исходный том, не нарушая существующий доступ для чтения / записи. Недостатком этого является то, что область снимка имеет конечный размер, что означает, что в системе с занятыми записями она может заполняться довольно быстро. Для томов, которые имеют значительную активность записи, вы захотите увеличить размер снимка, чтобы оставить достаточно места для записи всех изменений. Если ваш снимок переполняется (заполняется), оба снимка останавливаются и помечаются как непригодные для использования. Если это произойдет, вы захотите выпустить свой снимок, чтобы вы могли восстановить исходный том онлайн. Как только релиз будет завершен, вы

Второе, что происходит, - это то, что LVM теперь «меняет» истинные цели рассматриваемых томов. Вы могли бы подумать, что вновь выделенный снимок будет местом для поиска любых изменений в файловой системе, в конце концов, это место, куда собираются все записи, верно? Нет, все наоборот. Файловые системы монтируются на имена томов LVM , поэтому замена имени из-под остальной части системы будет запрещением (поскольку снимок использует другое имя). Поэтому решение здесь простое: при доступе к исходному имени тома оно будет продолжать ссылаться на версию тома, с которой вы сделали снимок, в режиме реального времени (чтение / запись). Том снимка, который вы создадите, будет ссылаться на замороженный(только для чтения) версия тома, для которого вы хотите создать резервную копию. Сначала немного сбивает с толку, но это будет иметь смысл.

Все это происходит менее чем за 2 секунды. Остальная часть системы даже не замечает. Если, конечно, вы не выпустите снимок, пока он не переполнится ...

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

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

Итак, в двух словах:

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

Снимки 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 output). Этот -real LV сопоставляется как с томом снимка, так и с исходным томом, поэтому его можно использовать в обоих местах. Том копирования при записи функционирует как наложение на -real 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)

Что касается howfar, то это хороший метод резервного копирования: может быть, если принять во внимание, что это (1) не поможет для оперативной памяти виртуальных машин, (2) создаст снижение производительности и (3) вам понадобится хранить изображения снимка в другом месте.

VMware VCB также работает со снимками, хотя и не LVM.

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

Если диск тормозит, ваши данные и резервная копия будут потеряны. Даже если вы назначите область снимка другому PE в VG, она будет содержать только данные, измененные с момента снимка.

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

я использую такую ​​настройку для снимков машин сервера vmware и баз данных mysql. пока работает нормально. было пару восстановлений - все без проблем. Стоит учесть одну вещь - при запуске со снимком lvm значительно снижает производительность операций ввода-вывода. смотрите здесь . игнорируйте тот факт, что они говорят о MySQL, операции ввода-вывода являются операциями ввода-вывода ... независимо от того, какие данные хранятся на lvm.

Я использую снимки lvm только для того, чтобы скопировать DomU Lv еще один в отдельную Vg, где каждый домен имеет три резервных «узла», которые находятся в распоряжении.

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

Время от времени резервная копия Lv сбрасывается в файл образа на отдельном сервере.

Все это автоматизировано с помощью скрипта, с резервным копированием каждые два дня и дампом каждую неделю.

Я даже имел в виду режим «паники», когда домен Lv будет восстановлен, но будет запущен из моментального снимка и будет перезагружаться каждые 2 часа, чтобы поддерживать де-сайт в случае серьезных взломов, пока не будет организована надлежащая защита. ,

Что стало с идеей линии защиты «режим паники»?