Снимок файловой системы linux

Простой откат изменений файловой системы с помощью утилиты snapper

Оригинал: How to Easily Roll Back Changes with Snapper
Автор: Jack Wallen
Дата публикации: 23 сентября 2016 г.
Перевод: А.Панин
Дата перевода: 17 января 2017 г.

snapper является утилитой с интерфейсом командной строки, позволяющей создавать, удалять и сравнивать снимки файловой системы.

Хороший системный администратор должен знать, как устранить последствия любых некорректно осуществленных изменений системы. К примеру, вы можете устанавливать, обновлять, настраивать систему или отдельную службу и столкнуться с ошибкой в процессе выполнения соответствующих действий. Что делать в этом случае? Если вы создали копию файла конфигурации, то ничего страшного не произошло. Если в процессе установки программного обеспечения не было установлено большое количество других необходимых для его корректного функционирования программных компонентов (что, в свою очередь, может стать причиной систематических неполадок), вы можете просто удалить его. Но имеют место и такие ситуации, когда гораздо удобнее осуществить откат всех изменений файловой системы.

Если вы используете файловую систему Btrfs , откат ее изменений не будет связан с какими-либо сложностями. Btrfs позволяет использовать крайне полезный инструмент под названием snapper , позволяющий создавать снимки файловой системы и осуществлять откат ее изменений (в случае неполадок). snapper является утилитой с интерфейсом командной строки, спроектированной специально для управления снимками файловой системы и позволяющей создавать, удалять и сравнивать снимки, а также устранять изменения между ними.

В рамках данной статьи я подробно опишу процесс отката изменений файловой системы с помощью инструмента snapper в новейшей версии дистрибутива openSUSE Leap . Также следует упомянуть о том, что в как в комплекте поставки дистрибутива openSUSE, так и в комплекте поставки дистрибутива SUSE имеется плагин для центра управления системой под названием YaST, предназначенный для работы с snapper и максимально упрощающий описанный процесс. Но, перед тем, как знакомиться с графическим интерфейсом для рассматриваемого инструмента, все же стоит разобраться с лежащими в его основе командами.

Первые шаги

В качестве тестовой площадки будет использоваться свежеустановленная система openSUSE Leap. Так как система не находилась в длительной эксплуатации, в ней отсутствуют файлы конфигурации snapper. По этой причине вам придется открыть центр управления системой YaST, осуществить переход Miscellaneous > snapper и ознакомиться с сообщением об ошибке. Для исправления этой ошибки вам придется осуществить обновление системы с помощью инструмента zypper. Таким образом, в результате исполнения команды zypper upgrade будет осуществляться не только обновление системы, но и создание конфигурации snapper для корневой директории (/). Вы также можете создать эту конфигурацию вручную с помощью команды:

Приведенная выше команда создает новый файл конфигурации с именем «root» для корневой директории (/). Файлы конфигурации необходимы для корректной работы snapper; без них вы просто не сможете пользоваться данным инструментом. К счастью, файл конфигурации для корневой файловой системы — это все, что нужно для использования основных функций snapper.

Теперь при выполнении команды snapper list-configs вы увидите запись, соответствующую как минимум одному файлу конфигурации (Рисунок 1).

Рисунок 1: Файл конфигурации для корневой файловой системы, который был создан нами вручную

Если вы выполните команду snapper-list , snapper выведет список всех сохраненных снимков файловых систем. При использовании свежеустановленной системы велика вероятность того, что таких снимков будет не очень много, а возможно, что и вообще не будет. Ну что же, предлагаю создать новый снимок.

Создание снимка файловой системы

Предположим, что вы собираетесь установить веб-сервер Apache и хотите создать снимок файловой системы перед его установкой. Сервер функционирует корректно и ничто не мешает установке Apache. Пришло время создать снимок файловой системы. Это команда, которую следует использовать для его создания:

Давайте разберемся с ее параметрами:

• snapper : это название утилиты. Да, просто название.
• create : этот параметр сообщает snapper о том, что вы собираетесь создать новый снимок файловой системы.
• —type pre : этот параметр сообщает snapper о том, что вы создаете снимок до внесения изменений в файловую систему.
• —print-number : этот параметр сообщает snapper о необходимости вывода числового идентификатора, ассоциированного с создаваемым снимком файловой системы (он понадобится при создании связанного снимка после внесения изменений в файловую систему). Этот идентификатор является крайне важным.
• —description : это читаемое пользователем описание снимка файловой системы (оно очень поможет при поиске снимков, ассоциированных с определенными изменениями файловой системы или периодами времени).

Теперь, когда вы создали снимок файловой системы до внесения изменений, вы можете выполнять все необходимые действия с сервером (а в нашем примере — устанавливать Apache). После того, как вы закончите работу, вам придется создать ассоциированный снимок файловой системы. Как вы видите, при внесении любых важных изменений в файловую систему вам придется создавать по два ее снимка: снимок перед внесением изменений ( pre ) и снимок после внесения изменений ( post ). Благодаря их наличию вы сможете осуществлять откат изменений файловой системы.

Для создания снимка файловой системы после внесения изменений вы должны выполнить следующую команду:

Здесь вместо X должен использоваться числовой идентификатор, полученный при создании снимка файловой системы до внесения изменений.

Помните, что при создании снимка файловой системы до внесения изменений, snapper должен выводить числовой идентификатор, ассоциированный с этим снимком. и именно для этой цели вы использовали параметр —pre-number . Снова выполните команду snapper list и вы увидите в списке информацию о снимках файловой системы, созданных до и после внесения изменений в нее (Рисунок 2).

Рисунок 2: Числовой идентификатор моего снимка файловой системы до внесения изменений равен 2, а после внесения изменений — 5

Проверка изменений

На этом этапе все становится гораздо проще и удобнее. Вы можете сообщить snapper о необходимости вывода списка всех изменений, внесенных в файловую систему в промежутке времени между созданием ее снимков. При этом мы знаем, что снимок файловой системы до внесения изменений имеет идентификатор 2, а после — идентификатор 5. Но какие файлы были изменены? Выполните команду snapper 2..5 для получения списка всех измененных файлов (Рисунок 3).

Рисунок 3: Список файлов, измененных в процессе установки веб-сервера Apache

Слева от каждой строки несложно обнаружить символ «+» , который обозначает, что файл по приведенному пути был создан. Аналогично символ «c» обозначает, что файл был изменен, а символ «-» — что файл был удален.

Вы также можете ознакомиться со списком изменений определенных файлов. Предположим, что вы обнаружили символ «c» перед путем к файлу «/etc/sysconfig/apache2» и хотите узнать, какие строки этого файла конфигурации были изменены. Вы можете выполнить следующую команду:

В результате будет выведен список изменений файла конфигурации /etc/sysconfig/apache2 на основе его версий до и после установки веб-сервера Apache в формате утилиты diff . Вы также можете выполнить команду snapper diff 2..5 без передачи имени файла для получения информации об изменениях, внесенных в каждый из подвергшихся модификации файлов.

Откат изменений

Предположим, что с помощью команды diff вам удалось найти причину некорректной работы системы и теперь вы хотите осуществить откат этих изменений. На самом деле, это совсем не сложно. Возвращаясь к нашему примеру, предположим, что проблема заключалась в изменениях, внесенных в файл /etc/sysconfig/apache2 . Для отката содержимого этого файла к начальному состоянию достаточно выполнить следующую команду:

Приведенная выше команда позволяет откатить изменения файла /etc/sysconfig/apache2 от состояния из снимка после внесения изменений в файловую систему до состояния из снимка до внесения изменений в файловую систему (в данном случае, перед установкой Apache).

Да, это действительно просто. Даже без плагина snapper для центра управления системой YaST вы смогли откатить изменения, не используя ничего кроме интерфейса командной строки системы.

Истинная сила

Благодаря инструменту snapper, вы приобретаете истинную силу. С помощью нескольких несложных команд вы можете создавать и сравнивать снимки файловых систем, а также откатывать изменения, появившиеся в новых снимках. После того, как вы научитесь работать с утилитой snapper, вам непременно следует обратить внимание на плагин snapper для центра управления системой YaST; он является настолько же мощным, но более простым в использовании благодаря наличию графического интерфейса.

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

Источник

Файловые системы Linux следующего поколения: NiLFS(2) и exofs

Краткое содержание:

В системе Linux продолжаются инновации в области файловых систем. В ней поддерживаются разнообразные файловые системы для различных операционных систем. В Linux также поддерживаются самые современные технологии, относящиеся к файловым системам. К числу таких, которые внедряются в Linux, относятся две новые файловые системы: журнально-структурированная файловая система NiLFS(2) и система хранения объектов exofs. Давайте изучим назначение этих двух новых файловых систем и преимущества, которые они дадут.

Анонс новых файловых систем для Linux одновременно как вдохновляет, так и пугает. Вдохновляет, поскольку файловые системы предоставляют новую территорию для интересных улучшений. Пугает, поскольку файловая система на ранних стадиях разработки является, как правило, экспериментальной, и не совсем готова для полноценного использования. Но иногда это анонсы об инвестициях в будущее Linux и, действительно, в недавнем анонсе о ядре 2.6.30-rc1 много интересного. В конце 2008 года было объявлено о Btrfs (B-Tree File System – файловая система на основе бинарных деревьев), а совсем недавно были представлены две другие уникальные файловые системы: NiLFS(2) и exofs.

Основы файловых систем

Давайте начнем с краткого введения в такие нетрадиционные файловые системы, а затем исследуем конкретные особенности систем NiLFS(2) и exofs.

Журнально-структурированные файловые системы

Журнально-структурированные файловые системы и твердотельные диски SSD

Журнально-структурированные файловые системы являются идеальными для твердотельных дисков (дисков SSD), которые изготавливаются из флеш памяти NAND. Основная проблема с флеш памятью в том, что есть ограничения на число циклов записи и стирания данных. Поскольку журнальная структура задается для всего устройства, операции записи выполняются равномерно по всему диску и количество записей становится одинаковым по всему устройству и, следовательно, число циклов стирания уменьшается. Поэтому журнально-структурированные файловые системы работают очень хорошо на дисках SSD (последовательная запись) и также обеспечивают лучшую их сохранность.

Журнально-структурированные файловые системы имеют богатую историю в современных компьютерных системах. Первая журнально-структурированная файловая система была предложена в 1988 году Джоном Остераутом (John Ousterhout) и Фредом Дуглисом (Fred Douglis) и позже в 1992 году была реализована в операционной системе Sprite. Как следует из названия, журнально-структурированная файловая система рассматривает файловую систему как закольцованный журнал, в котором новые данные и метаданные файловой системы записываются в начало журнала, а свободное пространство берется с конца журнала (смотрите рис.1). Это означает, что данные в журнале могут быть записаны два и большее число раз, но поскольку журнал хронологически растет вперед, самые последние данные всегда рассматриваются как активные. Наличие нескольких копий данных в журнале дает несколько интересных преимуществ, которые мы более подробно рассмотрим ниже.

Рис.1: Общий вид журнально-структурированной файловой системы

Хотя журнально-структурированный подход является только архитектурной особенностью, он дает несколько явных преимуществ. Одно из них – восстановление системы после ее краха, которое проще при использовании журнально-структурированного подхода.

Еще одним преимуществом является более производительное использование системы хранения, на базе которой реализована файловая система. Можно напомнить, что последовательная запись на диски происходит значительно быстрее, чем прямой ввод/вывод. Поскольку запись осуществляется последовательно, накладные расходы уменьшаются, результат на диске оказывается быстрее и, следовательно, файловая система работает быстрее.

Объектный подход к системам хранения

Системы и стандарты хранения объектов

Системы хранения объектов базируются на стандарте T-10 Object Storage Devices (OSD). В его спецификациях уточняется набор команд стандарта SCSI с тем, чтобы можно было поддерживать операции на уровне объектов. В дополнение к определениям объектных методов доступа, в этих спецификациях освещаются вопросы безопасности и управления метаданными.

В традиционных системах хранения при работе с дисковыми устройствами для запоминания данных обычно используется нативный интерфейс дисков. Этот интерфейс основывается на семантике блочного хранения, когда действия осуществляются с небольшими блоками данных фиксированного размера и с данными об их отображении (метаданные файловой системы). В системах хранения объектов используется совсем другой подход: вместо управления блоками фиксированного размера в этих системах управление осуществляется объектами, имеющими различные размеры, и связанными с ними метаданными (в которых на системном уровне представлена информация об объекте).

Системы хранения объектов – это уникальный путь к очень масштабируемым системам хранения, при этом подразумевается как многовариантность хранения, так и безопасность. Стандарт OSD можно реализовывать различными способами. Вы можете использовать компоненты, соответствующие стандарту OSD (такие, как драйверы и инициаторы OSD), либо высокоуровневые компоненты (целевые системы, которые создают функциональность OSD на баз традиционных драйверов). Но фундаментальное различие между блочными и объектными системами хранения в том, что в блочных системах вы, используя протокол, которые работает на уровне блоков данных, и создаете объекты из коллекций блоков, которые содержат как данные, так и метаданные. В объектных системах вы, вместо этого, взаимодействуете с объектами и связанными с ними метаданными (смотрите рис.2). Тогда устройства хранения объектов становятся одноуровневыми пространствами имен объектов, где иерархия объектов (если она нужна) создается с использованием стека системы хранения.

Рис.2: Сравнение систем хранения, использующих блоки, и систем хранения, использующих объекты

В настоящей статье описывается одна из реализаций файловой системы над объектной системой хранения.

Новая реализация журнально-структурированной файловой системы: NiLFS(2)

NiLFS(2) является второй итерацией журнально-структурированной файловой системой, разработанной в Японии фирмой Nippon Telegraph and Telephone (NTT). Файловая система находится в стадии активной разработки, недавно введена в основное ядро Linux (в добавок к вводу в ядро NetBSD). Первая версия NILFS (version 1) появилась в 2005 году, но в ней отсутствовал какой-либо вариант сборки мусора. В середине 2007 года была реализована вторая версия, в которой имелась сборка мусора, а также возможность создавать множественные копии данных и поддерживать с ними работу. В этом году (2009г.) файловая система NiLFS(2) была введена в основное ядро и ее можно просто подключить, инсталлировав загрузочный модуль.

Интересной особенностью NiLFS(2) является создание моментальных снимков. Поскольку файловая система NILFS является журнально-структурированной, новые данные записываются в начало журнала, а старые данные все еще продолжают существовать (до тех пор, пока не потребуется утилизировать память). Поскольку старые данные существуют, вы можете вернуться по времени назад и проверить предыдущие состояния файловой системы. Предыдущие состояния называются в NiLFS(2) контрольными точками и являются интегральной частью файловой системы. NiLFS(2) создает эти контрольные точки в тот момент, когда делаются изменения, но их можно создать и принудительно.

Файловые системы с моментальными снимками состояния

Система NiLFS(2) – одна из множества файловых систем, в которых есть возможности делать моментальные снимки состояния системы. Другими системами, имеющими средства создания моментальных снимков, являются ZFS, LFS и Ext3cow.

Как будет показано далее, контрольные точки (точки восстановления) можно просматривать, а также можно преобразовывать в моментальные снимки состояния. Моментальные снимки состояний можно монтировать в пространстве файловых систем Linux точно также как и другие файловые системы, но в настоящее время они доступны только для чтения. Это очень полезно, поскольку вы можете смонтировать моментальный снимок и восстановить файлы, которые ранее были удалены, либо просмотреть предыдущие версии файлов.

Кроме постоянного создания моментальных снимков система NiLFS(2) имеет ряд других преимуществ. Одна из наиболее важных возможностей из возможных в перспективе – быстрый рестарт. Если текущая контрольная точка оказалась неработоспособной, то для того, чтобы перейти к работоспособному варианту файловой системы, нужно переместиться назад к последней хорошей контрольной точке. Это, безусловно, лучше процесса восстановления ошибок с помощью fsck.

Проблемы с NiLFS(2)

Хотя непрерывное создание моментальных снимков отличное свойство, за это приходится платить. Как упоминалось ранее, эта система – журнально-структурированная, так что в ней операции записи, по своей природе, последовательные (минимизация операций поиска на уровне физического диска) и, следовательно, очень быстрые. Если рассматривать ее подробнее, то из-за того, что она журнально-структурированная, требуется использовать сборщик мусора, который удается старые данные и метаданные. Обычно система работает очень быстро, но когда требуется сборка мусора, производительность системы снижается.

Исследуем NiLFS(2)

Версия NiLFS(2) и ядро

Приведенный здесь пример работы NiLFS(2) был сделан с использованием ядра Linux 2.6.27. В состав основного ядра файловая система NiLFS(2) была включена в версии 2.6.30-rc1, но для нашего случая модули и инструментальные средства файловой системы NILFS устанавливались из исходных кодов. О том, как установить NiLFS(2) в ядро смотрите в ссылках, приведенных в оригинале статьи.

Давайте взглянем на файловую систему NiLFS(2) в действии. Мы покажем, как создать файловую систему NiLFS(2) на псевдоустройстве loop device (простейший способ протестировать файловую систему), а затем рассмотрим некоторые возможности NiLFS(2). Начнем с установки модуля ядра:

Затем создадим файл, в котором будет находиться файловая система (область на хостовой операционной системе, в которой мы смонтируем свою собственную файловую систему для псевдоустройства loop device), и после этого с помощью команды mkfs создадим в нем файловую систему NiLFS(2) (смотрите листинг 1).

Листинг 1: Подготовка файловой системы NiLFS(2)

Теперь мы имеем образ диска, инициализированного в формате файловой системы NiLFS(2). Затем, используя псевдоустройство loop device, монтируем файловую систему (смотрите листинг 2). Обратите внимание, что когда файловая система будет смонтирована, будет также запущена пользовательская программа nilfs_cleanerd, реализующая сервис сборки мусора.

Листинг 2. Монтирование NiLFS(2) на псевдоустройстве loop device

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

Листинг 3: Список контрольных точек и создание мгновенного снимка

Теперь у нас имеется мгновенный снимок и снова с помощью команды touch добавим в нашу текущую файловую систему несколько новых файлов (смотрите листинг 4).

Листинг 4: Добавляем в нашу файловую систему NiLFS(2) еще несколько файлов

Теперь смонтируем наш мгновенный снимок как файловую систему, позволяющую только чтение. Сделайте это точно так, как и при предыдущем монтировании, но в этом случае нужно указать для монтирования мгновенный снимок. Сделайте это с помощью опции cp. Обратите внимание, что по результатам использования команды lscp видно, что мгновенный снимок был CNO=2. Используйте это значение CNO в команде mount для того, чтобы смонтировать файловую систему с доступом только для чтения. Если смонтировать систему на чтение и запись, то вы с помощью команды ls увидите все файлы. В случае монтирования в режиме только для чтения, вы увидите только два файла, которые были сделаны в момент создания мгновенного снимка (смотрите листинг 5).

Листинг 5: Монтирование мгновенного снимка NiLFS(2) в режиме только для чтения.

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

В этом примере показаны две утилиты командной строки файловой системы NiLFS(2): lscp (список контрольных точек и мгновенных снимков) и mkcp (создать контрольную точку или мгновенный снимок). Имеется также утилита, называемая chcp, предназначенная для конвертации контрольной точки в мгновенный снимок и обратно, и утилита rmcp – для аннулирования контрольной точки или мгновенного снимка.

С учетом непостоянной природы файловой системы фирма NTT рассмотрела некоторые другие весьма новаторские инструменты для использования в будущем – например, команды tls (temporal ls – временное ls), tdiff (temporal diff- временное diff) и tgrep (temporal grep – временное grep).

Расширенная файловая система хранения объектов (exofs)

Расширенная файловая система хранения объектов (exofs) является традиционной файловой системой Linux, построенной над системой хранения объектов. Exofs была первоначально разработана Эвнишаем Трегером (Avnishay Traeger) из IBM и в тот момент называлась файловой системой OSD. После этого компания Panasas, которая строит объектные системы хранения, забрала проект себе и переименовала его в exofs (поскольку истоки идут от файловой системы ext2).

Файловая система над системой хранения объектов

Концептуально система хранения объектов может рассматриваться как одноуровневое пространство имен объектов и связанных с этими объектами метаданных. Сравните это с традиционными системами хранения, использующими блоки, где некоторые блоки заняты метаданными, обеспечивающими семантическую связку. Общая схема exofs такая, как показано на рис.3. Виртуальный переключатель файловых систем VFS (Virtual File System Switch) дает доступ к exofs, а exofs взаимодействует с системой хранения объектов через локальный инициатор OSD. Инициатор OSD реализует набор SCSI команд стандарта OSD T-10.

Рис.3: Общая схема экосистемы exofs/OSD

Идея, лежащая за exofs, это — реализовать традиционную файловую систему над хранилищем OSD. В этом случае будет проще переходить на объектный уровень хранения, поскольку представленная файловая система будет традиционной файловой системой.

Отображение, используемое в файловой системе

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

Файлы внутри файловой системы представлены уникальным образом как айноды (inodes). Exofs в объектной системе отображает айноды в идентификаторы объектов (OIDs). Из этого следует, что объекты используются для представления всех элементов файловой системы. Файлы отображаются непосредственно в объекты, а директории являются просто файлами, которые ссылаются на файлы, содержащиеся в директории (как имя файла и пары inode-OID). Иллюстрация этого приведена в простой форме на рис.4. Для поддержки таких вещей, как побитовые карты размещения айнодов, существуют другие объекты.

Рис.4: Обобщенная схема представлений OSD

Размер идентификаторов OID, используемых для представления объектов в объектном пространстве, равен 64 битам, поэтому поддерживается работа с огромным пространством объектов.

Почему хранение объектов?

Хранение объектов является интересной идеей и позволяет создавать значительно более масштабируемую систему. Некоторые части файловой системы можно изъять из хостовой системы и перенести на уровень реализации подсистемы хранения. Происходит перераспределение, а за счет того, что эти части можно распределить по нескольким устройствам (или системам) реализации объектных систем, вы можете распределить рабочую нагрузку, что упрощает масштабирование методов, базирующийся на объектах, и позволяет создавать существенно большие системы хранения. Вместо того, чтобы требовать от хостовой операционной системы заботиться об отображении блоков и файлов, устройство хранения само обеспечивает это отображение, позволяя хостовой системе оперировать на уровне файлов.

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

Идея хранения объектов недавно возродилась как механизм хранения, используемый в облачных системах. Провайдеры облачных систем хранения (которые продают хранилища как сервис) представляют свои хранилища как средство работы с объектами вместо традиционных блочных API. Эти провайдеры реализуют API для передачи объектов, управления объектами и управления метаданными.

Что дальше?

Хотя NiLFS(2) и exofs будут хорошим дополнением в составе файловых систем Linux, они еще в разработке. Недавно была представлена файловая система Btrfs (фирмы Oracle), которая предлагает для Linux альтернативу файловой системы Zettabyte File System (ZFS) фирмы Sun Microsystems. Еще одной совсем недавно разработанной системой является Ceph, которая представляет собой надежную распределенную файловую систему на основе POSIX, устойчивой к единичным отказам. Сегодня мы рассмотрели новую журнально-структурированную файловую систему и привели с файловой системой на базе хранилища объектов. Linux продолжает доказывать, что это исследовательская платформа и, одновременно, промышленная операционная система.

Источник