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

17

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

Мені це здається ідеальним рішенням для швидкого, бездумного відновлення. Будь-яке розслідування може проходити на розбитому логічному томі, а DomU успішно працює без перерви.

Редагувати:

Ось де я зараз, коли роблю повні резервні копії системи.

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

Тепер мені потрібно це автоматизувати.

backup xen lvm

— Кароліс Т.
джерело

32

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

Існує кілька кроків, щоб здійснити знімок. Перший полягає в тому, що потрібно виділити новий логічний обсяг. Мета цього тома - забезпечити область, де записуються дельти (зміни) у файловій системі. Це дозволяє продовжувати вихідний том, не порушуючи жодного наявного доступу для читання / запису. Мінусом цього є те, що область знімків має обмежений розмір, а це означає, що в системі із зайнятими записами вона може заповнюватися досить швидко. Для томів, які мають значну активність в записі, вам потрібно збільшити розмір вашого знімка, щоб забезпечити достатньо місця для всіх змін. Якщо ваш знімок переповнюється (заповнюється), обидва знімки зупиняться та будуть позначені як непридатні. Якщо це станеться, ви захочете випустити знімок, щоб ви могли повернути оригінальний том в Інтернеті. Як тільки випуск завершиться, ви '

Друге, що трапляється, - це те, що LVM зараз "замінює" справжні цілі відповідних томів. Ви можете подумати, що щойно виділений знімок стане місцем для пошуку будь-яких змін у файловій системі, зрештою, саме там збираються всі записи, правда? Ні, це навпаки. Файлові системи змонтовані на імена томів LVM , тому заміна імені з-під решти системи буде ні-ні (оскільки на знімку використовується інша назва). Тож рішення тут просте: Коли ви отримуєте доступ до оригінального імені тома, він продовжуватиме посилатися на живу (читання / запис) версію тома, для якого ви зробили знімок. Обсяг створеного вами знімка стосуватиметься замороженого(лише для читання) версія тома, яку ви маєте намір створити резервну копію. Спочатку трохи заплутано, але це матиме сенс.

Все це відбувається менше ніж за 2 секунди. Решта системи навіть не помічають. Якщо, звичайно, ви не випустите знімок до його переповнення ...

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

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

Отже, коротко:

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

— Евери Пейн
джерело

4

Також продуктивність знімків LVM лінійно погіршується - 8 знімків у 8 разів перевищують IO.

— Стівен

9

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

— Каміль Кісієль

2

В інтересах повноти Каміль Кісієль правильний. Дивіться: tldp.org/HOWTO/LVM-HOWTO/snapshotintro.html

— ktower

1

Після сильного нарікання на себе за те, що я неправильно поінформував, відповідь було змінено на основі безлічі джерел документації та обговорення. Вибачте, мої погані.

— Avery Payne

10

Знімки LVM чудово підходять для створення резервної копії сервера, не відлучаючи його в офлайн. Як зазначалося, знімки LVM - це майже миттєві копії. Ви створюєте їх за допомогою lvcreateкоманди так само, як і для створення самого НН, тільки ви даєте йому --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 можуть бути безцінними при створенні надійної резервної копії систем, таких як бази даних, і таких, які, як правило, ви хочете відключити до резервного копіювання, щоб уникнути суперечок файлів, вони не є ідеальними для тривалої роботи як швидкого відновлення.

— Джеремі Бууз
джерело

9

Не гарна ідея, ІМО.

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

Крім того, IIRC, якщо об'єм знімка заповнюється, його просто безцеремонно відкидають. Це не добре для резервних цілей! Тож якщо ви все-таки спробуйте це як резервне копіювання, обов’язково зробіть обсяг знімка достатньо великим, щоб обробити всі зміни, які відбудуться протягом строку корисного використання знімка. Звичайно, якщо ви знаєте і стежите за проблемою розміру, а проблема продуктивності не є для вас проблемою, то те, що ви пропонуєте, може стати корисним доповненням до інших ваших резервних процесів.

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

— Девід Спіллетт
джерело

Можливо, я не розумію, як працюють знімки. У посібнику сказано, що знімок - це майже миттєва копія логічного тома, що дозволяє уникнути необхідності приймати систему, яка використовує її в автономному режимі. З вашого опису, здавалося б, що знімок - це більше гілка, копія, а не заморожена копія. Чи оновлюється знімок усіх змін, внесених у оригінальну систему після його внесення? Якщо так, мені потрібно негайно зняти дані та знищити знімок, оскільки це не призначено як механізм зберігання резервних копій? Спасибі!

— Karolis T.

2

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

— Девід Спіллетт

Але якщо він змінений (знімок), звідки це "застиглий"? Скажімо, у мене такий сценарій, робоча система якось зіпсується з часом. У мене є знімок, коли він працював правильно. Чи буде знімок представляти систему, поки вона все ще працювала коректно, чи зміни, які призвели до пошкодження оригінальної системи в першу чергу? Сподіваюся, я досить зрозумілий, просто хочу бути впевненим, що я його справді розумію.

— Кароліс Т.

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

— Евері Пейн

1

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

— Martijn Heemels

6

Перед тим, як зробити знімок, вам потрібно буде переконатися, що дані на диску знаходяться у постійному стані. наприклад, mysql може мати дані, кешовані в пам’яті, які потрібно змусити диск, відкидаючи базу даних або закриваючи її. Докладніше перегляньте посібники зі своїх додатків.

— pgs
джерело

5

Під розумними на вигляд матеріалами, LVM - це насправді "лише" хитрість картографування пристроїв. Створення знімка з lvcreate - це не набагато більше, ніж обгортка деяких матеріалів dmsetup. Обгортка створює новий пристрій (об'єм знімка) з одного старого тома (оригінальний lv) та нового (обсягу копіювання на запис). Разом з цим оригінальний LV перейменований у -real (див. Нижче, що є dmsetup ls --tree output). Цей -реальний LV відображається як на об'єм знімка, так і на початковий об'єм, тому його можна використовувати в обох місцях. Гучність копіювання при записі функціонує як накладення на LV -real. LV -snap показує поєднання обсягу копіювання на запис та -реальної кількості. Це справді створює деяку ефективність роботи.

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 також працює з моментальними знімками, btw, хоча і не LVM.

— wzzrd
джерело

4

Навіть якщо знімки не мали жодного впливу на продуктивність, ви повинні розуміти: знімки - це не більше резервної копії, ніж копія в іншу папку на тому ж диску.

Якщо диск гальмується, ваші дані та резервна копія втрачаються. Навіть якщо ви присвоїли область знімка іншому PE в VG, він містить лише дані, змінені з моменту зйомки.

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

— Свен
джерело

Так, я це розумію. RAID 1 створений для захисту від збоїв пристрою зберігання даних, резервного копіювання у віддалене місце - від пошкодження програмного забезпечення. Я розглядаю знімки LVM як інструмент для дійсно швидкого відновлення, коли ви не знаєте, що сталося, і вам зараз потрібна система в Інтернеті. Будь-які інші варіанти, швидше відновлення domU з резервної копії LVM?

— Кароліс Т.

3

Я використовую таку настройку для знімків серверних машин vmware та баз даних mysql. працює добре до цих пір. було пару реставрацій - все без проблем. одне, що слід врахувати - під час роботи зі знімком lvm отримує значну ефективність для операцій вводу / виводу. дивіться тут . ігноруйте той факт, що вони говорять про mysql, i / o ops - це i / o ops ... незалежно від того, який тип даних знаходиться на lvm.

— pQd
джерело

1

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

— pQd

2

Я використовую знімки lvm лише для того, щоб скопіювати DomU Lv ще один в окремий Vg, де кожен Домен має три резервні "вузли", які є у розпорядженні.

Після цього знімок знищується, а резервні копії Lv залишаються до наступного раунду. Якщо у мене є відновлення, я просто повинен вибрати джерело Lv з резервної копії Vg і скопіювати його в домен Lv.

Час від часу резервний файл Lv скидається у файл зображення на окремому сервері.

Все це автоматизовано за допомогою скрипту, із резервною копією кожні два дні та скиданням кожного тижня.

Я навіть мав на увазі режим "паніки", коли домен Lv буде відновлено, але запускається зі знімка та скидається кожні 2 години для збереження сайту в Інтернеті у разі серйозних злому, доки не вдасться організувати належну захист .

— Берземус
джерело

1

Що стало з лінії захисту ідеї "режиму паніки"?

— NginUS
джерело