Це так, як працюють знімки LVM?

Я намагаюся з'ясувати, як працюють знімки LVM, щоб я міг реалізувати його на своєму файловому сервері, але у мене виникають труднощі знайти що-небудь в Google, яке пояснює, як це працює, а не як використовувати його для базової системи резервного копіювання.

З того, що я прочитав, я думаю, що це працює приблизно так:

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

Чи може хтось виправити мене там, де я помиляюся. У кращому випадку, я здогадуюсь, я нічого не можу знайти в Google.

vgdiplay

obu1: / home / тюрма / home / qps / резервне копіювання / D # vgdisplay
  --- Група томів ---
  VG Ім’я файлового сервераLVM
  Ідентифікатор системи
  Формат lvm2
  Області метаданих 1
  Послідовність метаданих №3
  VG Access читання / запис
  Статус VG може змінюватись
  MAX LV 0
  Кур НН 2
  Відкрийте LV 2
  Макс PV 0
  Кур PV 1
  Дія ПВ 1
  VG Розмір 931,51 ГБ
  Розмір PE 4,00 Мб
  Всього PE 238467
  Alloc PE / Розмір 238336 / 931,00 ГБ
  Безкоштовно PE / Розмір 131 / 524,00 Мб
  VG UUID qSGaG1-SQYO-D2bm-ohDf-d4eG-oGCY-4jOegU

Ви не подивитеся на розділ знімків LVM-HOWTO ?

Знімки LVM - це ваше основне рішення "копію при записі". Знімок насправді є не що інше, як попросити LVM дати вам "покажчик" на поточний стан файлової системи та записати зміни, зроблені після знімка, на вказану область.

Знімки LVM "живуть" всередині групи томів, що розміщує томи, що підлягають знімку - не інший том. Ваше твердження "... багато і багато нерозподіленого вільного простору, а не розділу", звучить так, що ваше мислення полягає в тому, що знімки "живуть" поза групою томів, що підлягає знімку, і це не точно. Ваша група томів живе у розділі жорсткого диска, а том - під час знімка та будь-яких знімків, зроблених у прямому ефірі.

Нормальний спосіб використання знімків LVM - це не для довготривалого зберігання, а для отримання послідовної «картини» файлової системи таким чином, щоб можна було зробити резервну копію. Після резервного копіювання знімок знімається.

Коли ви створюєте знімок LVM, ви визначаєте кількість місця для проведення будь-яких змін, здійснених під час активного знімка. Якщо буде внесено більше змін, ніж ви вказали, простір для знімка стає непридатним і його потрібно викинути. Ви не хочете залишати знімки прокладками, оскільки (а) вони заповняться і стають непридатними; і (b) продуктивність системи впливає під час активного знімка - все стає повільніше.

Редагувати:

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

VSS - це більш комплексне рішення, яке об'єднує підтримку апаратних пристроїв, що підтримують знімки та знімки на основі програмного забезпечення в єдиний API. Крім того, VSS має API, які дозволяють додаткам перетворюватися в режим спокою через API знімків, тоді як знімки LVM стосуються лише знімків - будь-яка програма, яка зупиняється, є вашою проблемою (розміщення баз даних у станах резервного копіювання тощо).

Знімки LVM - це приклад рішення знімка під час копіювання під час запису, як сказав Еван. Те, як це працює, трохи відрізняється від того, що передбачає Еван, але зовсім не багато.

Коли у вас є об'єм LVM без знімків, запис у том виходить так, як ви очікували. Блок змінено, і все.

Як тільки ви створюєте знімок, LVM створює пул блоків. Цей пул також містить повну копію метаданих LVM обсягу. Коли записи відбуваються з основним томом, таким як оновлення inode, блок, що перезаписується, копіюється в цей новий пул, а новий блок записується в основний том. Це "копіювати на запис". Через це, чим більше даних, які змінюються між тим, як зроблено знімок, і поточним станом основного обсягу, тим більше місця буде витрачено цим пулом знімків.

Коли ви монтуєте знімок, метадані, записані під час зйомки, дозволяють відображати блоки пулу знімків на змінені блоки в обсязі (або знімок вищого рівня). Таким чином, коли доступ приходить для певного блоку, LVM знає, до якого блоку доступ. Що стосується файлової системи на цьому томі, знімків немає.

Джеймс вказав на один з недоліків цієї системи. Коли у вас є кілька знімків одного і того ж обсягу, кожен раз, коли ви пишете в блок основного тома, ви потенційно запускаєте запис у кожному знімку. Це тому, що кожен знімок підтримує власний пул змінних блоків. Крім того, для довгих дерев знімків доступ до знімка може спричинити небагато обчислень на сервері, щоб визначити, який саме блок потрібно подати для доступу.

Коли ви знімаєте знімок, LVM просто скидає пул знімків та оновляє дерево знімків за потребою. Якщо опущений знімок є частиною дерева знімків, деякі блоки будуть скопійовані на знімок нижчого рівня. Якщо це найменший знімок (або єдиний), пул просто опускається, і операція дуже швидка.

Деякі файлові системи пропонують знімки у файловій системі, ZFS та BTRFS - це лише два найбільш відомих. Вони працюють аналогічно, хоча сама файлова система управляє зміненим / незмінним відображенням. Це, мабуть, кращий спосіб зробити це, оскільки ви можете збити цілу сім'ю знімків для послідовності, що ви не можете зробити прямо з LVM.

Ви не вказуєте, чи використовуєте ви Linux або HP-UX. У HP-UX ви створюєте логічний том і монтуєте його як знімок іншого логічного тома. У Linux ви створюєте логічний том як об'єм знімка.

Видалення знімка в HP-UX здійснюється шляхом підрахунку гучності; в Linux це робиться за допомогою lvremove для видалення логічного обсягу.

У будь-якому випадку зміни - це єдине, що зберігається на вашому знімку. Чим довше знімок залишається доступним, тим більше змін він накопичує - і є шанс, який він міг би заповнити, якщо не мати належного розміру чи випустити.

Швидкість доступу до диска на гучність знімка повільніше, ніж до нормальної гучності; ви повинні це врахувати.

Знімки LVM неефективні, чим більше знімків, тим повільніше буде йти система.

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

Використовується функція Copy on Write , щоб дисковий простір використовувався ефективно.

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

Це приклад із FAQ