Алексей Федорчук
В прошлом очерке про Antergos и ZFS мы с котом Manual’ом описали процесс создания и настройки файловых систем ZFS. позаботились о сохранности наиболее важных из них путём удвоения числа контрольных сумм. Что, однако, обеспечивает поддержку целостности ФС, но никак не сохранность размещённых на них данных. Каковая осуществляется с помощью механизма снапшотов.
Снапшот — моментальный снимок файловой системы ZFS. Он представляет собой одну из разновидностей её наборов данных (dataset), и не требует излишнего места на носителей, поскольку в него записываются только дельты между текущим состоянием файловой системы и его предыдущей версией. В связи с этим снапшоты могут использоваться для резервного копирования отдельных файловых систем пула ZFS.
Для создания снапшота используется команда zfs snapshot с аргументом в виде имени создаваемого снапшота, которое образуется по такой модели:
filesystem@snapshot_name
Покончив с настройкой системы и её рекомплектацией прикладными пакетами, как мы с котом Manual’ом решили увековечить результаты наших трудов в виде снапшотов. И для начала, получив права администратора на неопределённое время командой
$ sudo -s
поглядели на текущие наши файловые системы:
# zfs list NAME USED AVAIL REFER MOUNTPOINT zant 20,1G 87,4G 6,84G / zant/home 6,00G 87,4G 104K /home zant/home/alv 643M 87,8G 616M /home/alv zant/home/kot 692K 87,4G 684K /home/kot zant/home/media 112K 87,4G 112K /home/media zant/home/proj 152M 92,3G 152M /home/proj zant/swap 7,22G 94,6G 232K -
После чего немедленно сделали «снимок» корня файловой иерархии:
# zfs snapshot zant@14-05-02
Результатом команды в такой форме было создание снапшота именно и только корня, без ветвей zant/home, zant/home/alv и всех прочих. Можно было бы окучить и их с помощью опции -r (то есть рекурсивно):
# zfs snapshot -r zant@14-05-02
Но мы решили, что нам такой хоккей не нужен, так как корень, теоретически, особо часто изменяться не будет, и потому его снапшот окажется «долгоиграющим». Домашние и особенно рабочие же наши каталоги будут модифицироваться постоянно, и потому «снапшотить» их придётся гораздо чаще.
Так что следующими на очереди были снапшоты «хомяков» (аккаунт для кота Manual’а был создан заранее):
# zfs snapshot zant/home/alv@14-05-02 # zfs snapshot zant/home/kot@14-05-02
А затем дело дошло и до каталога с текущими проектами:
# zfs snapshot zant/home/proj@14-05-02
На результаты нашей работы можно было полюбоваться такой командой:
# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT zant@14-05-02 47,5M - 6,81G - zant/home/alv@14-05-02 27,0M - 612M - zant/home/kot@14-05-02 8K - 684K - zant/home/proj@14-05-02 108K - 152M -
Сами снапшоты сохраняются в корней «родной» файловой системы в виде скрытых каталогов с именем .zfs, которые, однако, не будут присутствовать в выводе команды ls -a. Чтобы сделать их видимыми, потребуется дать специальную команду, которая для корневой файловой системы будет выглядеть так:
-# zfs set snapdir=visible zant
В результате в корне файловой иерархии появится каталог /.zfs такого содержания:
# # ls -a /.zfs/snapshot/14-05-02 ./ boot/ etc/ mnt/ proc/ run/ sys/ usr/ bin@ lib64@ ../ dev/ home/ opt/ root/ srv/ tmp/ var/ lib@ sbin@
Тут же можно убедиться, что ветви её, образованные отдельными файловыми системами ZFS, пусты:
# ls -a /.zfs/snapshot/14-05-02/home/alv ./ ../
Однако действие команды установки «свойства видимости» для корневой файловой системы распространится и на все дочерние файловые системы:
# ls -a /home/proj/.zfs/snapshot/14-05-02 ./ ../ antergos/ manuals/ romans/ zfs/
Однако более эффективным способом посмотреть на наличные снапшоты буде приведённая ранее команда
# zfs list -t snapshot
Разумеется, мы решили тут же смоделировать ситуацию восстановления файловой системы из снапшота, дабы аварийная ситуация не застала нас врасплох. Для чего кот Manual, скрепя сердцем, удалил из своего домашнего каталога пару «скелетных» каталогов и файлов. После чего мы дали такую команду:
# zfs rollback zant/home/kot@14-05-02
И — о чудо! Всё удалённое немедленно вернулось взад.
Таким образом мы подготовились к неприятностям типа развала Иксов при неудачном обновлении или случайного стирания рабочих материалов. А, как известно, неприятности, к которым ты готов, никогда не происходят. Потому что происходят совсем другие неприятности. Например, отказ диска (в нашем сдучае — SDD). И от этого сами по себе снапшоты никакой страховки не дают, ибо хранятся внутри пула, созданного на том же носителе (или носителях), что и породившие их файловые системы.
Однако и эта задача решаема с помощью механизма репликации снапшотов в другой пул, созданный на отдельном носителе, или даже на другой машине. Однако об этом мы с котом расскажем, когда (и если — или если и когда) обзаведёмся диском, на котором сможем создать независимый пул ZFS.