Насколько я знаю, LVM позволяет делать снимки тома. Существует также ряд файловых систем (ZFS, Btrfs, reiserfs, ...), которые поддерживают моментальные снимки.
Однако я никогда не понимал разницу между снимками LVM и снимками файловой системы. Если есть возможность делать снимки с помощью LVM, почему кто-то тратит время на его внедрение в файловую систему?
Изменить: какой-либо из них предпочтительнее в некоторых ситуациях? Зачем?
Большинство из этих моментальных снимков являются копиями при копировании при записи, которые являются действительно быстрыми и действительно дешевыми (с точки зрения хранения) в редко обновляемых системах. Снимки LVM являются снимками COW, ZFS / BTRFS имеют COW-режим для снимков, reiserfs не имеет снимков изначально, файловая система Novell NSS также COW, как и тома теневого копирования для томов Windows NTFS.
Копии при записи моментальных снимков принимают копию метаданных целевого тома в пул моментальных снимков. Затем, в зависимости от того, какой режим COW они используют, они копируют данные, которые будут перезаписаны новыми записями, в пул моментальных снимков перед записью новых данных.
ZFS и (в конечном итоге, если еще не существует) BTRFS имеют возможности полного снимка, которые полезны для привязки к отдельным носителям, что, в свою очередь, очень удобно для систем резервного копирования sneakernet, использующих съемные носители. ZFS не называет это «моментальным снимком», тем не менее, они используют возможность ZFS использовать zfs sendи zfs recvкопировать тома и моментальные снимки по сети на удаленный хост (или локальный массив).
Я предпочитаю возможности снэпшотов на уровне файловой системы, а не LVM, потому что я лучше доверяю самой файловой системе для аккуратного управления процессом. Однако из-за отсутствия прямой поддержки файловой системы LVM в большинстве случаев работает нормально.
Снимки COW хороши, если вам нужно выполнить резервное копирование на определенный момент времени для очень быстрого восстановления. Например, делать ежедневно или 4 раза в день, хватая на неделю. Это удобно, если вам нужно восстановить файлы, которые пользователи случайно удалили, или откатить всю систему до конфигурации перед обновлением. Они также могут использоваться некоторыми системами резервного копирования в качестве полностью приостановленной файловой системы, поэтому резервные копии, взятые с тома моментальных снимков, не должны беспокоиться о мешающих работе открытых файлах. Главное, что нужно помнить - тома моментальных снимков будут находиться в том же хранилище, что и основной том, поэтому ничего не выдайте в случае сбоя массива.
ПОЛНЫЕ снимки хороши, если они переносятся на съемные или удаленные носители. Если у вас есть сетевое хранилище, целью может быть другой массив iSCSI или Fibre Channel, чем тот, в котором размещено основное хранилище. Это дает вам некоторую защиту вне массива для некоторых типов сбоев. При использовании съемных носителей, таких как диск ESATA емкостью 3 ТБ, вы даже можете использовать его в качестве простой системы резервного копирования на диск. Эти снимки МОГУТ быть на другом оборудовании, чем их братья COW, поэтому полезны для устойчивости к бедствиям.
На Full vs COW снимки.
Термин «снимок» немного изменился за эти годы. В этом году я почти уверен, что это означает «копирование исходных данных с копированием при записи с использованием блочного перемещения». По этому определению «полный» снимок, представленный выше, на самом деле не является снимком, это репликация. В прошлом некоторые производители хранилищ использовали разные определения «снимка» для описания различных операций на уровне блоков, которые они выполняют. Там, где это сбивает с толку, находятся системы, которые используют моментальные снимки в процессе репликации.
LVM требует предварительного планирования. Я не использую его, потому что это еще один уровень абстракции и он редко доступен, когда мне это нужно. Есть и другие варианты клонирования на уровне файловой системы (в Linux) без LVM. Для этого вы можете использовать Hot Copy от R1Soft . Это модуль ядра, но он позволяет добавлять эту возможность на лету.
источник
Совершенно ясная проблема: снимки LVM не гарантируют, что они будут иметь одинаковую FS, потому что LVM ничего не знает о FS, с которой он загружается
Отредактировано (см. Комментарии): - верно, если FS не поддерживает
.freeze_fs, в противном случае оно должно обрабатываться 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) Скажите мне, где в пользовательском пространстве ( sources.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 - некоторые FS, безусловно, имеют такую поддержку (EXT3, Reiser3, XFS), а некоторые нет (EXT2, например). Кроме того, он отвечает на второй вопрос - вполне вероятно, что замораживание XFS будет автоматически выполнено с помощью LVM.Как дополнение к другим ответам. В снимках FS вы можете воспользоваться такими функциями FS, как сжатие и дедупликация во всех снимках.
источник