ZFS snapdir=visible: Аудит снапшотів без істерик користувачів

Існує особливий різновид паніки в організації, коли хтось каже: «Потрібно перевірити файли станом на минулий вівторок», а команда зберігання відповідає: «Звісно, але снапшоти бачить тільки root». Це не стільки технічне обмеження, скільки політичне рішення — і, як більшість політик у сфері зберігання, це перетворюється на проблему UX, щойно в процес втягуються користувачі.

snapdir=visible — це один із тих підступно простих перемикачів ZFS, які змінюють спосіб взаємодії людей із файловою системою. Якщо зробити це правильно, форензика снапшотів перетворюється на самообслуговування і зупиняє ваш on-call від перетворення на людський API відновлення файлів. Якщо неправильно — це стає найзаплутанішою «таємничою папкою», ламає очікування в клієнтів SMB/NFS і породжує шквал тікетів, через який починаєш задумуватись про фермерство.

Що snapdir насправді робить (і чого не робить)

Снапшоти ZFS — це не «копії для бекапу» в старому розумінні файлового сервера. Це лише тільки для читання, точкові у часі відображення датасету. Внутрішньо вони — метадані, що посилаються на блоки, які вже існують; ZFS використовує copy-on-write, тому блоки, на які посилаються снапшоти, зберігаються доти, поки жоден снапшот (і жоден живий файл) на них не посилається.

Властивість датасету snapdir контролює, як снапшоти показуються через простір імен файлової системи. Зокрема:

• snapdir=hidden (типово в багатьох середовищах): директорія .zfs існує концептуально, але не видна в списках директорій.
• snapdir=visible: директорія .zfs з’являється в корені точки монтування датасету, зазвичай як /.zfs всередині цього датасету, з піддиректорією snapshot, що містить кожний снапшот у вигляді перегляданого дереву файлів.

Чого воно не робить: не надає прав. Воно не переопреділяє POSIX mode-біти, ACL чи правила шарингу SMB. Воно не робить вміст снапшотів записуваним. Також воно не перетворює снапшоти на незалежні датасети, які можна монтувати де завгодно. Це важливо, бо багато очікувань «користувачі бачать снапшоти тепер!» руйнуються у «користувачі бачать імена снапшотів, але не файли, які вони хочуть», що більше дратує, ніж допомагає.

Дві виробничі мудрості: видимість ≠ доступ та доступ без історії — це хаос. Якщо ви вмикаєте видимість без пояснень, користувачі досліджуватимуть її як малюк у серверній: допитливо і без розуміння наслідків.

Навіщо робити снапшоти видимими взагалі?

Продавальний аргумент простий: швидші аудити і менше відновлень. Реальність нюансована: це змінює характер інцидент-резпонсу і частину складності перекладає з SRE на користувачів. Це може бути вигідно — якщо ви обмежите це розумними налаштуваннями за замовчуванням, навчите користувачів і встановите запобіжники.

Випадки використання, де snapdir=visible корисний

• Аудит і перевірки відповідності: «Покажіть, як ця папка виглядала 1-го числа». Користувачі можуть переглянути снапшоти, щоб перевірити наявність/відсутність артефактів без створення тікета.
• Самообслуговуване відновлення: відновлення видаленого файлу — це копіювання зі снапшота, а не «чекати команду зберігання».
• Форензичне порівняння: порівняння двох точок часу щодо дрейфу конфігурації або підозрілих змін. Снапшоти ZFS дають консистентний вигляд.
• Зменшення радіусу відкатів: користувачі відновлюють лише потрібне, замість запиту на широкий відкат (що рівнозначно використовувати кувалду, щоб починити годинник).

Випадки, де це створює проблеми

• Спільні датасети з заплутаними правами: користувачі бачать дерева снапшотів, але не можуть прочитати більшість через ACL. Це породжує тікети «зламані бекапи».
• Поведінка клієнтів SMB/NFS: деякі клієнти трактують директорії з провідною крапкою як приховані; інші — ні. Індекси та інструменти резервного копіювання можуть непередбачувано рекурсивно заходити в них.
• Багатоарендні середовища: відкриття імен снапшотів може протікати інформацію (імена проєктів, дати інцидентів, політики зберігання), навіть якщо доступ до даних заблокований.

Жарт №1: Робити снапшоти видимими без плану — це як ховати запасний ключ під килимок і дивуватись, що кожен його там перевіряє.

Як директорія .zfs поводиться в реальному житті

Коли ви встановлюєте snapdir=visible на датасеті, ZFS показує спеціальну директорію в корені цього датасету: .zfs. Зазвичай під нею ви отримаєте:

• .zfs/snapshot/ — директорії з іменами кожного снапшота, кожна з яких містить повне файлове дерево, як воно виглядало в момент створення снапшота.

Декілька поведінок, що мають оперативне значення:

• Дерево снапшота доступне тільки для читання. Користувачі можуть копіювати з нього, але не змінювати всередині.
• Права оцінюються так само, як і для живого датасету. Якщо користувач не міг прочитати /data/hr/payroll.xlsx вчора, він також не зможе прочитати його в .zfs/snapshot/yesterday/data/hr/payroll.xlsx.
• Це на рівні датасету. Якщо у вас вкладені датасети, кожен має свій власний огляд .zfs. Це може збити з пантелику, коли користувачі переходять через точки монтування і раптом бачать різні списки снапшотів.
• Це не звичайна директорія. Деякі інструменти поводяться з нею дивно: рекурсія, номери inode і семантика обходу можуть здивувати старі утиліти.

Існує також тонка соціальна поведінка: як тільки користувачі відкривають .zfs/snapshot, вони починають ставитись до нього як до «машини часу». Це нормально — поки не закінчується зберігання і «машина часу» втрачає паливо. Якщо ви хочете менше злих листів, комунікуйте політику зберігання як продуктову фічу («ми зберігаємо 30 щоденних снапшотів»), а не як магічну властивість всесвіту.

Факти й історичний контекст, які варто знати

Трохи контексту допомагає приймати кращі рішення. Ось кілька конкретних фактів, які неодноразово важливі в реальних впровадженнях:

1. Снапшоти ZFS дешево створювати, бо вони здебільшого записують метадані; велика вартість з’являється пізніше, коли снапшоти утримують старі блоки.
2. Copy-on-write — це причина роботи снапшотів: ZFS ніколи не перезаписує на місці; зміни записують нові блоки, а снапшоти зберігають посилання на старі блоки.
3. Директорія .zfs синтетична: вона не зберігається як звичайні файли; це віртуальний вигляд, який надає ZFS.
4. Видимість спочатку була для адмінських робочих процесів, а пізніше стала механізмом самообслуговуваного відновлення у багатьох компаніях — часто без формального UX-плану.
5. «Витік імен снапшотів» — це реальна річ: навіть якщо дані захищені, імена снапшотів можуть видати кодові назви проєктів, дати інцидентів або підказки HR, якщо ви вкладаєте їх у назви.
6. Рекурсивне знімання створює ілюзію повноти: знімання батьківського датасету не означає автоматично, що всі дочірні датасети включені, якщо ви не робите це явно або не використовуєте рекурсивні прапори.
7. SMB «Previous Versions» — окрема фіча від snapdir=visible; можна підтримувати одну, іншу або обидві, і вони поводяться по-різному.
8. Снапшоти — це не бекапи, якщо пул виходить з ладу або рансомвар зашифрує живий датасет і ви реплікуєте зашифровані блоки. Снапшоти — локальна подушка безпеки, а не план відновлення після катастрофи.
9. Політика зберігання — це політика ємності: «зберігати більше снапшотів» нічим не відрізняється від «купити більше дисків», тільки з меншою кількістю зустрічей з відділом закупівель.

Три корпоративні міні-історії (біль, іронія, порятунок)

1) Інцидент через хибне припущення: «Видимо = доступно»

У великому внутрішньому файлохостингу часто траплялися «ой»-видалення. Команда зберігання включила snapdir=visible, щоб скоротити кількість тікетів на відновлення. Протягом дня черга helpdesku покращилася — допоки аналітик з комплаєнсу не спробував дістати файл зі снапшота і не отримав «Permission denied». Вони ескалували, припустивши, що снапшоти — це «архіви бекапу» і тому аудиторам має бути за замовчуванням доступно.

Хибне припущення було тонким: роль аналітика давала доступ до деяких звітів через прикладний шар, а не через файлові права. У живому світі доступ контролював додаток. У світі снапшотів користувач мав справу безпосередньо з POSIX правами і ACL, які були суворішими. Користувач міг бачити імена снапшотів, але не міг пройти в критичні директорії.

Інцидент став політичним, бо виглядав так, ніби storage «зламав процес аудиту». Насправді storage відкрив реальність: роль аудиту ніколи не мала прямого файлового доступу. Виправлення спочатку не було технічним — а лексичним. Команда написала коротку внутрішню ноту: «Снапшоти відображають історію файлової системи; вони не підвищують привілеї». Потім вони додали контрольовану «групу аудиторів» з правом тільки читання на конкретні датасети і створили документований процес тимчасових дозволів.

Після цього виграш став реальним: аудити прискорилися, і on-call перестав робити майстерні відновлення о 2:00 ранку. Але ключовий урок залишився: перемикач фічі — це не процес.

2) Оптимізація, що обернулась проти: «Зробимо все видимим скрізь»

Платформна команда вирішила стандартизувати: всі датасети отримують snapdir=visible. Метою була консистентність і менше винятків. Вони розгорнули це в п’ятницю ввечері, бо зміна була «просто властивістю». (Якщо ви шукаєте знак від всесвіту: це був знак.)

Понеділок ранком приніс веселість. Сукупність індексувальних агентів — спочатку розгорнутих для прискорення корпоративного пошуку — почала обходити дерева .zfs/snapshot. Кожний снапшот виглядав як ціла нова всесвіт файлів. Індексери не розуміли, що це історичні вигляди, і радо переіндексували той самий контент десятки разів у різних снапшотах. CPU на фермі індексерів підскочив, мережевий трафік зріс, і кластер зберігання побачив набагато більше метаданихних читань, ніж зазвичай.

Ще гірше — деякі команди використовували інструменти, що трактують будь-яку директорію як кандидат для бекапу. Декілька «домашніх скриптів резервного копіювання» (типу: написані раз, ніколи не тестовані знову, підтримувані забобоном) пішли за .zfs і роздули вікна бекапу. Ніхто не хотів цього визнавати, але «оптимізація» створила податок на кілька систем.

Відкат був швидким: сховати видимість на широких шарінгах, потім ввімкнути вибірково там, де самообслуговування важливе і клієнти добре поводяться. Довгострокове виправлення — налаштувати індексери й інструменти бекапу виключати /.zfs і створити датасети з чітким призначенням: користувацькі шари отримали кураторську політику видимості снапшотів, а машинні датасети залишились прихованими.

Жарт №2: Найшвидший спосіб знайти забутого павука (crawler) — дати йому нескінченний лабіринт і подивитись, як він мчить.

3) Нудна, але правильна практика, що врятувала день: «Малий межовий датасет і передбачувані імена»

Інженерна організація зберігала артефакти збірки і релізні пакети на ZFS. Вони були суворі щодо макету датасетів: кожна продуктова лінія мала свій власний датасет, і права були консистентні. Імена снапшотів були нудними за стандартом: auto-YYYYMMDD-HHMM, створювались щогодини і видалялися щодня.

Одного дня менеджер релізу виявив, що підписаний бінарник зник з директорії «final». Миттєвий страх — компрометація. Потрібно було відповісти на два питання: коли він зник і хто мав доступ? Оскільки snapdir=visible був увімкнений на тому датасеті, команда релізу могла негайно переглянути снапшоти, знайти останній снапшот, де файл існував, і звузити вікно до конкретної години.

Команда зберігання все одно долучилась, але тепер питання не було «будь ласка, відновіть усе». Це було «ми визначили вікно зникнення; чи можете ви зіставити це з SMB логами аудиту і підтвердити, що проблем з пулом не було?» Це той тип тікета, який хочеться отримувати: обмежений, з доказовою базою і швидкий.

Остаточний результат був буденний: автоматизація мала занадто широкий патерн чистки. Але розслідування уникло драми, бо межі датасету були чисті, імена снапшотів передбачувані, а експозиція снапшотів була навмисною. Це не героїчна інженерія; це хороша гігієна, що приносить дивіденди.

Практичні задачі: команди, виводи та інтерпретація

Нижче реальні задачі, які можна виконати в продакшні, щоб впровадити, перевірити та усунути проблеми з snapdir=visible. Кожна містить, на що звертати увагу, щоб це не було просто спамом команд.

Задача 1: Перевірити поточну настройку snapdir на датасеті

cr0x@server:~$ zfs get -H -o name,property,value,source snapdir tank/projects
tank/projects	snapdir	hidden	default

Інтерпретація: Використовується значення за замовчуванням (hidden). Якщо source — local, хтось явно його встановив; якщо inherited, то батьківський датасет його контролює.

Задача 2: Увімкнути snapdir=visible (для одного датасету)

cr0x@server:~$ sudo zfs set snapdir=visible tank/projects
cr0x@server:~$ zfs get -H snapdir tank/projects
tank/projects	snapdir	visible	local

Інтерпретація: Тепер датасет показуватиме директорію .zfs у своїй точці монтування. Це не змінює зберігання снапшотів, не створює снапшотів і не змінює права.

Задача 3: Підтвердити, що .zfs існує та видима в точці монтування

cr0x@server:~$ ls -la /tank/projects | head
total 12
drwxr-xr-x  6 root root    6 Dec 24 10:01 .
drwxr-xr-x  4 root root    4 Dec 24 09:58 ..
drwxr-xr-x  2 root root    2 Dec 24 10:01 .zfs
drwxr-xr-x 18 root root   18 Dec 24 09:59 engineering
drwxr-xr-x 11 root root   11 Dec 24 10:00 finance

Інтерпретація: Якщо .zfs відсутня, переконайтесь, що ви перелічуєте точку монтування датасету (а не батьківську директорію) і що датасет змонтований.

Задача 4: Перелік снапшотів через CLI ZFS (істинне джерело)

cr0x@server:~$ zfs list -t snapshot -o name,creation,used,refer,mountpoint -r tank/projects | head
NAME                                   CREATION                USED  REFER  MOUNTPOINT
tank/projects@auto-20251224-0900        Wed Dec 24 09:00 2025   12M   1.20T  -
tank/projects@auto-20251224-1000        Wed Dec 24 10:00 2025   18M   1.21T  -

Інтерпретація: Поле USED показує, скільки унікального простору утримує цей снапшот (блоки, не посилаються більше ніде). Якщо USED росте, політика зберігання має прямий вплив на ємність.

Задача 5: Перелік снапшотів через перегляд .zfs

cr0x@server:~$ ls -1 /tank/projects/.zfs/snapshot | head
auto-20251224-0900
auto-20251224-1000

Інтерпретація: Якщо CLI ZFS показує снапшоти, але .zfs/snapshot порожня, ймовірно ви не в тому датасеті, який думаєте (плутанина з вкладеними датасетами), або шлях клієнта перетинає межу монтування.

Задача 6: Скопіювати видалений файл зі снапшота назад (безпечне самообслуговування)

cr0x@server:~$ cp -av /tank/projects/.zfs/snapshot/auto-20251224-0900/engineering/readme.txt \
> /tank/projects/engineering/readme.txt
'/tank/projects/.zfs/snapshot/auto-20251224-0900/engineering/readme.txt' -> '/tank/projects/engineering/readme.txt'

Інтерпретація: Використовуйте cp (або rsync) для відновлення в живе дерево. Не намагайтесь писати всередині дерева снапшота; воно тільки для читання і операція завершиться помилкою.

Задача 7: Підтвердити здатність користувача проходити по директоріях снапшота

cr0x@server:~$ sudo -u alice ls -la /tank/projects/.zfs/snapshot/auto-20251224-0900/finance
ls: cannot open directory '/tank/projects/.zfs/snapshot/auto-20251224-0900/finance': Permission denied

Інтерпретація: Зазвичай це очікувана поведінка. Це означає, що снапшот поважає ті самі права, що й живе дерево. Якщо користувачі очікують доступу, потрібно обговорення ACL/прав, а не перемикач зберігання.

Задача 8: Знайти, що споживає місце через снапшоти (на загальному рівні)

cr0x@server:~$ zfs list -o name,used,avail,refer,ratio,mountpoint tank/projects
NAME          USED  AVAIL  REFER  RATIO  MOUNTPOINT
tank/projects 3.41T 2.12T  1.21T  1.68x  /tank/projects

Інтерпретація: USED включає блоки, утримувані снапшотами. Якщо REFER стабільний, але USED зростає, снапшоти (або клони) утримують старі дані.

Задача 9: Побачити споживання простору по снапшотах

cr0x@server:~$ zfs list -t snapshot -o name,used,refer -s used -r tank/projects | tail -5
tank/projects@auto-20251220-0900  1.9G  1.08T
tank/projects@auto-20251221-0900  2.3G  1.10T
tank/projects@auto-20251222-0900  3.1G  1.14T
tank/projects@auto-20251223-0900  4.8G  1.18T
tank/projects@auto-20251224-0900   12M  1.20T

Інтерпретація: Старіші снапшоти часто утримують більше унікальних блоків, особливо якщо датасет зазнає великого churn (образи VM, артефакти збірки, бази даних). Декілька «важких» снапшотів можуть домінувати у витратах.

Задача 10: Виявити «сканери директорій снапшотів» за симптомами активності файлової системи

cr0x@server:~$ sudo zpool iostat -v tank 2 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        8.10T  2.12T    980    210   118M  22.1M
  raidz2    8.10T  2.12T    980    210   118M  22.1M
    sda         -      -    160     35  19.7M  3.6M
    sdb         -      -    165     36  19.4M  3.7M
    sdc         -      -    162     34  19.6M  3.5M

Інтерпретація: Раптове зростання read IOPS і read bandwidth після увімкнення видимості часто вказує на сканери (індексери, AV, скрипти бекапу), що обходять дерева снапшотів.

Задача 11: Перевірити точки монтування датасетів і межі вкладених датасетів (щоб уникнути плутанини)

cr0x@server:~$ zfs list -o name,mountpoint -r tank/projects
NAME                     MOUNTPOINT
tank/projects            /tank/projects
tank/projects/engineering /tank/projects/engineering
tank/projects/finance    /tank/projects/finance

Інтерпретація: Кожен дочірній датасет має свій простір імен снапшотів і потенційно свою настройку snapdir. Користувачі, що переходять у /tank/projects/engineering, побачать .zfs для цього датасету, а не снапшоти батька.

Задача 12: Встановити snapdir через спадкування (застосувати до піддерева)

cr0x@server:~$ sudo zfs set snapdir=visible tank/projects
cr0x@server:~$ zfs get -H -o name,value,source snapdir tank/projects/engineering
tank/projects/engineering	visible	inherited from tank/projects

Інтерпретація: Спадкування — ваш друг для консистентності, але воно також збільшує радіус ураження. Для шарів, орієнтованих на користувача, розгляньте явні локальні налаштування і документуйте наміри.

Задача 13: Вимкнути видимість (кнопка «зупинити кровотечу»)

cr0x@server:~$ sudo zfs set snapdir=hidden tank/projects
cr0x@server:~$ zfs get -H snapdir tank/projects
tank/projects	snapdir	hidden	local

Інтерпретація: Це приховує .zfs з переліків директорій знову. Це не видаляє снапшоти; лише знімає UX-видимість.

Задача 14: Перевірити політику збереження снапшотів і обрізати свідомо

cr0x@server:~$ zfs destroy tank/projects@auto-20251220-0900
cr0x@server:~$ zfs list -t snapshot -r tank/projects | grep auto-20251220-0900
cr0x@server:~$ echo $?
1

Інтерпретація: Видалення снапшота вивільняє місце тільки якщо ці блоки більше ніде не посилаються (інші снапшоти чи клони). Якщо місце не зменшилось, ймовірно інші снапшоти тримають той самий churn або клони «прикріпили» блоки.

Задача 15: Дослідити клони, які прикріплюють простір снапшота

cr0x@server:~$ zfs get -H -o name,value origin -r tank/projects | grep -v '^-$'
tank/projects/engineering/testclone	tank/projects@auto-20251222-0900

Інтерпретація: Якщо датасети клоновані зі снапшотів, ці снапшоти (або їх блоки) можуть бути фактично незнищуваними, поки клон не буде видалений або не піднятий. Видимість цьому не сприяє напряму, але часто виявляється під час аудитів снапшотів.

Модель контролю доступу: що користувачі реально бачать і можуть робити

snapdir=visible змінює лише знаходжуваність, а не авторизацію. У більшості POSIX-настроєнь користувачу потрібне:

• Права execute (traverse) на кожній директорії в шляху, щоб дістатися до файлу у снапшоті.
• Право read на файл, щоб скопіювати його назовні.
• Відповідні права ACL, якщо ви використовуєте NFSv4 ACLs або POSIX ACLs.

Це означає, що ви можете використовувати видимість без передачі нових повноважень, але це також означає, що користувачі можуть відчувати «піддраження» через імена снапшотів, якими вони не можуть скористатися. Практичний шаблон — розділяти датасети за аудиторією:

• Користувацькі шари (домашні директорії, командні шарінги): розгляньте snapdir=visible плюс явні інструкції з самообслуговування, з виключеннями для сканерів.
• Машинні датасети (бази даних, образи VM, кеші CI): тримайте snapdir=hidden, якщо немає вагомої причини; ці дерева притягують сканери і часто мають великий churn.
• Аудиторські датасети: якщо аудиторам потрібен доступ, надайте його навмисно через ACL групи тільки для читання; не розраховуйте на «бо вони бачать — значить мають доступ».

Примітка щодо імен: імена снапшотів стають UI, коли ви їх відкриваєте. Якщо в іменах є пробіли, жарти або кодові назви інцидентів — ви фактично пишете свій внутрішній щоденник на вхідних дверях. Використовуйте передбачувані, нудні імена. Нудні — масштабуються.

Продуктивність та операційний вплив

У теорії, відкриття .zfs/snapshot — це лише перелік директорій. На практиці, це змінює те, що роблять користувачі та програми, а отже змінює навантаження. Більшість «проблем продуктивності», звинувачених у snapdir=visible, фактично спричинені одним із наступного:

• Рекурсивне сканування індексерами, антивірусом, агентами резервного копіювання або скриптами «find / -type f», які тепер включають снапшоти.
• Огляд, навантажений метаданими, коли користувачі трактують дерева снапшотів як архіви і запускають багато переліків директорій по багатьом снапшотам.
• Плутанина меж монтування, коли користувачі заходять у дочірні датасети і викликають показники різних наборів снапшотів, множачи свої перегляди.

Операційно, плануйте:

• Більше читань метаданих (особливо якщо користувачі переглядають старі снапшоти з великими деревами директорій).
• Більше тиску на кеш (ARC), якщо дерева снапшотів часто обходяться і не вміщаються в пам’ять.
• Питання підтримки про «що це за папка .zfs?» і «чому тут так багато копій?»

Один прагматичний трюк: ставтеся до snapdir=visible як до продукту для користувача. Впроваджуйте його з виключеннями (індексери/бекапи), зі зрозумілою політикою зберігання і з фрагментом «як відновити свій файл». Ви заощадите більше годин, ніж будь-яка мікрооптимізація recordsize.

Швидкий план діагностики

Коли хтось каже «снапшоти гальмують» або «увімкнення snapdir спричинило затримки», у вас немає часу на філософські дебати. Ось швидкий порядок дій, що швидко знаходить вузькі місця.

Перш за все: підтвердьте, що змінилось і де

1. Підтвердьте датасет і точку монтування, до яких звертаються користувачі (вкладені датасети мають значення).
2. Підтвердьте, що snapdir справді visible на цьому датасеті (і чи це успадковано).
3. Підтвердьте, чи скарга стосується переліку імен снапшотів, чи обходу вмісту снапшотів.

cr0x@server:~$ zfs list -o name,mountpoint -r tank/projects
cr0x@server:~$ zfs get -H -o name,value,source snapdir tank/projects tank/projects/engineering

По-друге: перевірте стан пулу та явне насичення

1. Стан пулу (помилки, resilvering) — перш за все. Деградований пул робить винною будь-яку фічу.
2. IOPS і пропускну здатність на пулі в час вікна скарги.
3. Підказки по затримках: багато читань при низькій пропускній здатності часто вказує на метаданний шторм.

cr0x@server:~$ zpool status -x
all pools are healthy
cr0x@server:~$ zpool iostat -v tank 1 5

По-третє: шукайте сканери дерева снапшотів і метаданний шторм

1. Чи є процеси, що роблять широкі обходи директорій?
2. Чи індексер/AV/агент бекапу нещодавно не оновив конфіг?
3. Чи датасет експортується через SMB/NFS і його обходять клієнти?

cr0x@server:~$ ps auxww | egrep 'find |updatedb|locate|rsync|backup|index' | head
cr0x@server:~$ sudo lsof +D /tank/projects/.zfs/snapshot 2>/dev/null | head

Інтерпретація: lsof +D може бути дорогим на великих деревах; використовуйте його обережно. Якщо воно занадто повільне, обмежте перевірку одним снапшотом або використайте цілеспрямовані перевірки на відомі агенти.

По-четверте: перевірте тиск на ARC і конфлікти по пам’яті

1. Якщо ARC стрибає, метадані значно впливають.
2. Переконайтесь, що ви не увійшли в своп; свопінг перетворює ZFS на перформанс-арт-проєкт.

cr0x@server:~$ free -h
cr0x@server:~$ vmstat 1 5

По-п’яте: вирішіть пом’якшення

• Якщо винуватці — сканери: виключіть /.zfs на рівні інструментів, потім повторно протестуйте.
• Якщо користувачі роблять легітимний важкий огляд: розгляньте надання спеціального «хоста відновлення» або документованого робочого процесу, або залишайте видимість лише на вибраних датасетах.
• Якщо пул насичений: ви можете бути обмежені ємністю або IOPS незалежно від видимості — виправляйте пул, а не симптом.

Поширені помилки: симптоми та виправлення

Помилка 1: Увімкнення видимості на широких шарінгах без виключення сканерів

Симптоми: раптовий стрибок read IOPS, повільні переліки директорій, зростання CPU індексерів/AV, вибух вікон бекапу.

Виправлення: знову сховайте snapdir, щоб зупинити кровотечу, потім налаштуйте виключення у сканерах для /.zfs. Потім ввімкніть вибірково на датасетах, де це корисно.

cr0x@server:~$ sudo zfs set snapdir=hidden tank/projects
cr0x@server:~$ zpool iostat -v tank 2 3

Помилка 2: Припущення, що снапшоти читаються аудиторами, бо вони видимі

Симптоми: скарги «Permission denied», ескалація аудиту, звинувачення, що storage «приховав» дані.

Виправлення: вирівняйте файлові права/ACL з вимогами аудиту або забезпечте опосередкований робочий процес. Документуйте, що видимість не підвищує привілеї.

cr0x@server:~$ getfacl -p /tank/projects/finance | head -40

Помилка 3: Плутати снапшоти батьківського датасету з дочірнім

Симптоми: користувачі кажуть «потрібного снапшота немає», хоча він існує в іншому місці; непослідовні списки снапшотів по шляхах.

Виправлення: відобразіть межі датасетів і точки монтування; переконайтесь, що автоматизація снапшотів покриває дочірні датасети як передбачено.

cr0x@server:~$ zfs list -o name,mountpoint -r tank/projects
cr0x@server:~$ zfs list -t snapshot -r tank/projects/engineering | head

Помилка 4: Імена снапшотів, що стають проблемою безпеки або HR

Симптоми: користувачі можуть вивести чутливі події з імен снапшотів; незручні питання на аудитах; «чому снапшот називається layoff-plan?»

Виправлення: стандартизувати нейтральні імена (мітка часу + політика), тримайте «значення» в системі змін, а не в іменах снапшотів.

cr0x@server:~$ zfs list -t snapshot -o name -r tank/projects | head

Помилка 5: Вважати снапшоти заміною бекапів

Симптоми: відсутні копії поза коробкою, рансомвар шифрує живі дані і снапшоти старіють або реплікуються в зашифрованому стані, втрата пулу критична.

Виправлення: тримайте снапшоти як локальний відкат; використовуйте реплікацію і окремі домени зберігання для реальних бекапів (і тестуйте відновлення).

cr0x@server:~$ zfs list -t snapshot -r tank | wc -l

Помилка 6: Дозволяти політиці зберігання дрейфувати до заповнення пулу

Симптоми: пул досягає високої заповненості, продуктивність падає, видалення не звільняє місце «як раніше», аварійне очищення снапшотів.

Виправлення: моніторити зростання снапшотів, підчищати свідомо і розуміти клони. Розгляньте quota/refquota, щоб обмежити шкоду по датасету.

cr0x@server:~$ zpool list
cr0x@server:~$ zfs list -o name,used,refer,avail -r tank/projects

Чеклісти / покроковий план

Чекліст A: Безпечне розгортання snapdir=visible на користувацькому шарі

1. Оберіть датасет(и) свідомо. Віддавайте перевагу командним шарам або домашнім директоріям зі стабільними правами.
2. Переконайтесь у наявності автоматики створення снапшотів (щогодини/щодня) і документованої політики зберігання.
3. Стандартизujte імена снапшотів, щоб вони були передбачувані і нудні.
4. Перелічіть сканери: індексери, AV, агенти резервного копіювання, аналітика файлів, інструменти пошуку. Заплануйте виключення для /.zfs.
5. Увімкніть видимість у пілоті (один датасет, одна команда).
6. Вимірюйте вплив: pool iostat, досвід клієнтів, типи тікетів.
7. Опублікуйте двохвилинний гайд з самообслуговування («копіюйте з .zfs/snapshot/<snap>/path»).
8. Розширюйте поступово, з планом відкату (snapdir=hidden).

Чекліст B: Робочий процес самообслуговуваного відновлення (зручний для користувача, низький ризик)

1. Знайдіть правильну точку монтування датасету (уникати плутанини з вкладеними датасетами).
2. Перегляньте .zfs/snapshot за часовим вікном.
3. Знайдіть файл у дереві снапшота.
4. Скопіюйте його назад у живий простір під новим іменем (безпека).
5. Перевірте вміст, потім замініть оригінал за потреби.

cr0x@server:~$ ls /tank/projects/.zfs/snapshot | tail -5
cr0x@server:~$ cp -av /tank/projects/.zfs/snapshot/auto-20251224-0900/engineering/spec.docx \
> /tank/projects/engineering/spec.docx.restored
cr0x@server:~$ ls -l /tank/projects/engineering/spec.docx*

Чекліст C: Робочий процес аудиту (доказ «що існувало коли»)

1. Визначте датасет і відповідний шлях.
2. Знайдіть снапшот, найближчий до часу інтересу (zfs list -t snapshot).
3. Перевірте наявність і метадані у вигляді снапшота.
4. За потреби, захешуйте файл у снапшоті і відновлену копію для доказовості (хешування — операційне рішення; це може бути важким).
5. Запишіть ім’я снапшота і час створення як основу доказу.

cr0x@server:~$ zfs list -t snapshot -o name,creation -r tank/projects | tail -5
cr0x@server:~$ ls -l /tank/projects/.zfs/snapshot/auto-20251224-0900/finance/ledger.csv
cr0x@server:~$ sha256sum /tank/projects/.zfs/snapshot/auto-20251224-0900/finance/ledger.csv

Питання та відповіді

1) Чи робить snapdir=visible снапшоти доступними для всіх?

Ні. Воно робить директорію снапшотів видимою в переліках. Доступ до вмісту снапшотів все ще залежить від файлових прав і ACL.

2) Чи вплине увімкнення на швидкодію пулу?

Прямо — ні. Ризик у поведінці: як тільки снапшоти видимі, інструменти і користувачі можуть обходити їх, спричиняючи читання метаданих і підвищене навантаження. Якщо виключити сканери і застосовувати вибірково, вплив зазвичай помірний.

3) Чому користувачі можуть перерахувати імена снапшотів, але не відкрити папки всередині?

Тому що перелік .zfs/snapshot може бути дозволеним, тоді як прохід у захищені директорії блокується правами execute на директорії або ACL. Це поширене в змішаних середовищах прав.

4) Як знову сховати снапшоти без видалення чогось?

Встановіть snapdir=hidden на датасеті. Снапшоти залишаються; вони просто перестають показуватись через .zfs.

cr0x@server:~$ sudo zfs set snapdir=hidden tank/projects

5) Чи присутній .zfs також у дочірніх датасетах?

Так, кожен датасет має свій простір імен снапшотів і правила спадкування властивостей. Вкладені датасети — часта причина плутанини зі «зниклим» списком снапшотів.

6) Чи можуть користувачі видаляти або змінювати файли всередині снапшотів?

Ні. Вміст снапшотів доступний тільки для читання. Користувачі можуть копіювати дані в живу файлову систему, якщо мають право запису туди.

7) Чи те саме це, що «Previous Versions» у Windows?

Ні. «Previous Versions» у Windows зазвичай реалізується сервером SMB, який мапить снапшоти в цей інтерфейс. snapdir=visible відкриває снапшоти через директорію файлової системи. Можна використовувати одне, інше або обидва; ретельно тестуйте поведінку клієнтів.

8) Якщо я видалю снапшот, чи відразу звільнюся місце?

Не завжди. Місце звільняється тільки коли блоки більше не посилаються жодним снапшотом, клоном чи живою файловою системою. Клони — часта причина, чому видалення снапшота не повертає простір.

9) Який найбезпечніший спосіб дозволити користувачам відновлювати файли, не даючи їм надто багато свободи?

Увімкніть видимість лише на датасетах, призначених для перегляду користувачами, тримайте імена снапшотів передбачуваними, опублікуйте робочий процес відновлення і переконайтесь, що сканери виключають /.zfs. Комбінуйте з quota/refquota, щоб обмежити найгірший випадок.

Висновок

snapdir=visible — це класичний рух ZFS: одна властивість перетворює примітив зберігання на функцію для користувача. Інженерія надійна, але результат залежить від того, як поводяться люди й програми, коли двері відкриті.

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