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

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

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

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

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

vgdiplay

obu1: / home / jail / home / qps / backup / D # vgdisplay
  --- Объемная группа ---
  Имя VG fileserverLVM
  Идентификатор системы
  Формат lvm2
  Метаданные Области 1
  Последовательность метаданных № 3
  VG Access чтение / запись
  VG Status изменяемого размера
  MAX LV 0
  Cur LV 2
  Open LV 2
  Макс PV 0
  Cur PV 1
  Акт PV 1
  Размер VG 931,51 ГБ
  Размер PE 4,00 МБ
  Всего ЧП 238467
  Alloc PE / Размер 238336 / 931,00 ГБ
  Free PE / Размер 131 / 524,00 МБ
  VG UUID qSGaG1-SQYO-D2bm-ohDf-d4eG-oGCY-4jOegU

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

Снимки LVM - это ваше базовое решение для копирования снимков при записи. Снимок на самом деле представляет собой не что иное, как запрос LVM дать вам «указатель» на текущее состояние файловой системы и записать изменения, сделанные после снимка, в назначенную область.

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

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

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

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

То, что делают Microsoft Volume Shadow Copy Services и снимки LVM, не слишком сильно отличается. Решение Microsoft немного более всеобъемлющее (как обычно в случае с Microsoft - к лучшему или к худшему, их инструменты и продукты часто стремятся решить довольно большие проблемы, вместо того, чтобы сосредоточиться на чем-то одном).

VSS - это более комплексное решение, которое объединяет поддержку аппаратных устройств, поддерживающих снимки и программные снимки, в единый API. Кроме того, в VSS есть API-интерфейсы, которые позволяют приложениям работать в режиме покоя с помощью API-интерфейсов моментальных снимков, тогда как моментальные снимки LVM касаются только моментальных снимков - любые приложения, работающие в режиме ожидания, являются вашей проблемой (перевод баз данных в состояние «резервного копирования» и т. Д.).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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