Наскільки мені відомо, LVM дозволяє робити знімки об'єму. Існує також ряд файлових систем (ZFS, Btrfs, reiserfs, ...), які підтримують знімки.
Однак я ніколи не розумів різниці між LVM-знімками та знімками файлової системи. Якщо можливо зробити знімки з LVM, чому хтось потребує свого часу, щоб реалізувати його у файловій системі?
Редагувати: чи бажаний якийсь із них у деяких ситуаціях? Чому?
Відповіді:
Більшість із цих знімків - це знімки, що записуються під час копіювання, які є дуже швидкими та дуже дешевими (для зберігання даних) на рідко оновлюваних системах. Знімки LVM - це знімки COW, обидві ZFS / BTRFS мають режим COW для знімків, у reiserfs не створено знімків, файлова система NSS Novell також COW, а також обсяги Shadow Copy для томів Windows NTFS.
Знімки, що записуються під час копіювання, переносять копію метаданих цільового об'єму в пул знімків. Потім, залежно від того, який режим використання COW вони використовують, вони копіюють дані, які будуть перезаписані новим записом у пул знімків, перш ніж записувати нові дані.
ZFS та (зрештою, якщо вони ще не існують) BTRFS мають повний знімок можливостей, що корисно для оснащення на окремих носіях, що, в свою чергу, дуже зручно для систем резервного копіювання sneakernet із використанням знімних носіїв. ZFS не називає це "знімком", однак вони використовують можливість ZFS використовувати zfs sendта zfs recvкопіювати томи та знімки по мережі на віддалений хост (або локальний масив).
Я віддаю перевагу здібностям знімків на рівні файлової системи над LVM, тому що я краще довіряю самій файловій системі для чистого керування процесом. Однак, за відсутності прямої підтримки файлової системи, у більшості випадків LVM має працювати чудово.
Знімки COW хороші, якщо вам потрібна оперативна резервна копія, зроблена дуже швидко для короткотермінових потреб у відновленні. Наприклад, щодня робити щоденно або 4 рази на день, робити їх слід протягом тижня. Це зручно, якщо вам потрібно відновити файли, які користувачі випадково видаляють, або потрібно відкатати всю систему до конфігурації попереднього оновлення. Вони також можуть бути використані деякими системами резервного копіювання як повністю закрита файлова система, тому резервні копії, взяті з обсягу знімка, не повинні турбуватися про те, що відкриті файли будуть перешкоджати . Ключове, що потрібно пам’ятати, - це те, що обсяги знімків будуть знаходитися на тому самому сховищі, що і основний том, тому не дайте вам нічого у разі відмови масиву.
Повні знімки хороші, якщо вони зроблені на якийсь знімний або віддалений носій інформації. Якщо у вас є мережеве сховище, ціль може бути іншим iSCSI або масивом Fiber Channel, ніж той, в якому розміщено основний сховище. Це дає певний захист від масиву від деяких несправностей. Якщо ви користуєтесь знімними носіями, такими як накопичувач ESATA 3 ТБ, ви навіть можете використовувати його як просту систему резервного копіювання на диск. Ці знімки МОЖУТЬ бути на іншому обладнанні, ніж їхні брати-коровай, тому корисні для стійкості до катастроф.
Знімки на Full - від COW.
Термін "знімок" трохи змінився протягом багатьох років. Цього року я впевнений, що це означає «копіювати-записувати копію оригінальних даних за допомогою блоку-переміщення». За цим визначенням "Повний" знімок, представлений вище, насправді не є знімком, це реплікацією. Деякі постачальники сховищ раніше використовували різні визначення поняття "знімок", щоб описати різні операції на рівні блоків, які вони виконують. Там, де це заплутано, знаходяться системи, які використовують знімки як частину процесу реплікації.
LVM вимагає попереднього планування. Я, як правило, не використовую його, тому що це ще один шар абстракції і він рідко доступний, коли мені це потрібно. Є й інші варіанти клонування на рівні файлової системи (в Linux) без LVM. Ви можете використовувати Hot Copy від R1Soft для цього. Це модуль ядра, але дозволяє додавати цю можливість на ходу.
Дуже чітка проблема: знімки LVM не гарантовано матимуть послідовний FS jue через те, що LVM "не знає" нічого про FS, яким він завантажується
Відредаговано (див. Коментарі): - вірно, якщо ФС не має підтримки .freeze_fs, інакше ФС повинна поводитися витончено.
syncцього знімок є точним дублікатом вже встановленої файлової системи; тож коли ви робите це, воно виглядає як "не чисто вимкнено" (тому що воно не було відключене), і вам доведеться виконати деякі коригувальні дії, перш ніж це буде послідовно. Звичайно, це, як правило, лише повтор журналу, і після цього syncце повинно бути порожнім повтором; тому немає небезпеки втрати даних.
xfs_freeze is intended to be used with volume managers and hardware RAID devices that support the creation of snapshots.) - спеціальна річ для знімків, чи знає LVM-2 про це та вже використовує її? 3) Скажіть мені, де або в користувальницькому просторі ( source.redhat.com/cgi-bin/cvsweb.cgi/LVM2/?cvsroot=lvm2 ), або в джерелах ядра, я можу довести, що ви праві, говорячи нам, що LVM надає FS синхронізація
lock a filesystem and force it into a consistent state. Отже, принаймні, я можу сказати, що я, мабуть, помилявся, сказавши, що "не гарантовано мати послідовний FS", оскільки справа в підтримці методу freeze_fs 'всередині реалізації FS - деякі FSes, безумовно, мають таку підтримку (EXT3, Reiser3, XFS), а деякі ні (EXT2, наприклад). Крім того, він відповідає на 2-е питання - заморожування XFS, швидше за все, буде автоматично оброблено LVM.
Як доповнення до інших відповідей. У знімках FS ви можете скористатися такими функціями FS, як стиснення та дедупликація на всіх знімках.