Так работают снимки LVM?

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

Из того, что я читал, я думаю, это работает примерно так:

• У вас есть LVM с основным разделом и множеством нераспределенного свободного пространства, не в разделе.
• Затем вы создаете снимок и монтируете его на новый логический том. Снимки, как предполагалось, имеют изменения, поэтому этот первый снимок будет полной копией, правильно?
• На следующий день вы делаете еще один снимок (размер раздела этого снимка не должен быть таким большим) и монтируете его.
• Как-то LVM отслеживает снимки и не хранит неизмененные данные на основном томе.
• Затем вы решаете, что у вас достаточно снимков и удаляете первый. Я не имею понятия, как это работает и как это повлияет на следующий снимок.

Кто-нибудь может исправить меня, где я ошибаюсь. В лучшем случае я гадаю, я не могу найти ничего в Google.

vgdiplay

obu1:/home/jail/home/qps/backup/D# vgdisplay
  --- Volume group ---
  VG Name               fileserverLVM
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               931.51 GB
  PE Size               4.00 MB
  Total PE              238467
  Alloc PE / Size       238336 / 931.00 GB
  Free  PE / Size       131 / 524.00 MB
  VG UUID               qSGaG1-SQYO-D2bm-ohDf-d4eG-oGCY-4jOegU

Почему бы не взглянуть на раздел о снимках в LVM-HOWTO?

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

Снимки LVM “живут” внутри группы томов, содержащей том, который подлежит снимку — не в другом томе. Ваше утверждение “…много нераспределенного свободного пространства не в разделе” звучит так, как будто вы думаете, что снимки “живут” вне группы томов, подлежащей снимку, и это неверно. Ваша группа томов находится в разделе жесткого диска, и том, подлежащий снимку, и любые сделанные вами снимки живут в этой группе томов.

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

Когда вы создаете снимок LVM, вы указываете количество места для хранения любых изменений, сделанных, пока снимок активен. Если вносится больше изменений, чем вы выделили места, снимок становится непригодным для использования и должен быть удален. Вы не хотите оставлять снимки, потому что (а) они заполнятся и станут непригодными, и (б) производительность системы ухудшается, пока снимок активен — все становится медленнее.

Редактировать:

То, что делают службы теневого копирования томов Microsoft и снимки LVM, не слишком сильно отличается. Решение Microsoft немного более комплексное (как это обычно бывает с Microsoft — в лучшую или худшую сторону их инструменты и продукты часто стремятся решать довольно большие задачи вместо того, чтобы сосредотачиваться на чем-то одном).

VSS — это более комплексное решение, которое объединяет поддержку оборудования, поддерживающего снимки, и программных снимков в единый API. Более того, VSS имеет API, позволяющий приложениям быть подготовленными через API снимков, тогда как снимки LVM просто озабочены снимками — любая подготовка приложений — это ваша проблема (перевод баз данных в состояние “резервного копирования” и т.д.).

Снимки LVM являются примером решения на основе копирования при записи, как сказал Эван. Как это работает немного отличается от того, что подразумевал Эван, но не сильно.

Когда у вас есть том LVM без снимков, записи на том происходят так, как вы ожидаете. Блок изменен, и на этом все.

Как только вы создаете снимок, LVM создает пул блоков. Этот пул также содержит полную копию метаданных LVM тома. Когда происходят записи на основной том, например, обновление inode, блок, который будет перезаписан, копируется в этот новый пул, а новый блок записывается на основной том. Это и есть “копирование при записи”. Благодаря этому, чем больше данных изменяется между моментом, когда был сделан снимок, и текущим состоянием основного тома, тем больше места будет потреблять этот пул снимков.

Когда вы монтируете снимок, метаданные, записанные во время создания снимка, позволяют сопоставлять блоки пула снимков с измененными блоками в томе (или на более высоком уровне снимков). Таким образом, когда происходит доступ к определенному блоку, LVM знает, к какому блоку предоставить доступ. Насколько файловая система на этом томе осведомлена, снимков нет.

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

Когда вы удаляете снимок, LVM просто удаляет пул снимков и обновляет дерево снимков по мере необходимости. Если удаляемый снимок является частью дерева снимков, некоторые блоки будут скопированы на более низкий уровень снимка. Если это самый низкий снимок (или единственный), пул просто удаляется, и операция выполняется очень быстро.

Некоторые файловые системы предлагают создание снимков внутри файловой системы, ZFS и BTRFS — это только два из наиболее известных. Они работают аналогично, хотя сама файловая система управляет сопоставлением измененных/неизмененных данных. Это, возможно, лучший способ сделать это, поскольку вы можете проверить целостность всей семьи снимков, чего нельзя сделать с помощью LVM в чистом виде.

Ответы @Evan Anderson и @sysadmin1138, хотя и очень поучительные и точные для своего времени (2009), теперь несколько устарели из-за существования двух различных методов создания снимков LVM:

• первый (назовем его классическим LVM) описан в вышеприведенных ответах. В основном он выделяет определенную часть диска, куда копируются данные, которые должны быть перезаписаны, что приводит к снижению производительности при множественных снимках (например: если один снимок замедляет систему в 3-5 раз, два снимка замедляют ее в 6-10 раз, три снимка в 12-15 раз, и так далее). Это, в свою очередь, делает их неспособными поддерживать политику непрерывных снимков. Кроме того, их хранилище метаданных (простой текст) не было оптимизировано для скорости. Фактически, их основное использование было для резервного копирования: создается один снимок и после резервного копирования удаляется;

• второй (называемый Thin LVM или lvmthin) это совершенно другое дело. Он сильно зависит от оптимизированных для двоичных данных (btree) метаданных для быстрого и эффективного отслеживания участков пространства. Создание снимка не требует изначально никакого дискового пространства (то есть никакой размер снимка не объявляется и никакое пространство не выделяется), за исключением некоторых метаданных. Перезапись уже выделенного участка может снова привести к операции чтение-модификация-запись, но это можно полностью избежать для больших записей (где “большая” запись означает превышающую размер куска данных в тонком пуле). Более важно, что множественные снимки не копируют больше данных, чем один снимок, потому что только метаданные изменяются для сопоставления различных снимков с одним и тем же участком данных. С другой стороны, следует отметить, что тонкие снимки могут “заполнить” весь том, что приводит к остановке всех записей.

Какой тип тома LVM следует использовать? Для корневой файловой системы, я обычно использую классический LVM тома: они очень надежны и их легче восстановить. Более того, корневой раздел часто не содержит много ценных данных сам по себе (и поэтому обычная процедура резервного копирования достаточна). С другой стороны, для томов данных я обычно хочу снимки, которые продолжаются некоторое время/недели в прошлом, поэтому я использую тонкий LVM (или пул ZFS, но это уже другая история…). Для дополнительного контекста, вы можете прочитать здесь

Снимки LVM неэффективны, чем больше снимков, тем медленнее будет работать система.

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

Копирование при записи используется для эффективного использования дискового пространства.

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

Это пример из FAQ

Вы не указываете, используете ли вы Linux или HP-UX. В HP-UX вы создаете логический том и монтируете его как снимок другого логического тома. В Linux вы создаете логический том как том для снимков.

Удаление снимка в HP-UX осуществляется путем размонтирования тома; в Linux это делается с помощью lvremove для удаления логического тома.

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

Скорость доступа к диску на томе снимка медленнее, чем на обычном томе; вы должны учитывать это.