ZFS: система іменування знімків, яка робить відкотування безстресовими

Чому іменування — це контроль у виробництві (а не зайва дискусія)

Тема іменування знімків притягує дві категорії людей: тих, хто вважає це питання естетики, і тих, кому вже доводилось відкотити датасет під поглядом віце-президента, який стежить за каналом інциденту. Друга група має рацію.

ZFS-знімок — це погляд у момент часу. Його дешево створювати, швидко перераховувати і він безапеляційний: захоплює блоки, а не ваші наміри. Єдине місце, де наміри зберігаються надійно — це ім’я знімка та метадані навколо нього (властивості, утримання, bookmarks). Саме тому іменування — це операційний контроль — як маркування вимикачів у ЦОДі. Так, ви можете гадати. Але ви також не можете собі цього дозволити.

Ось операційна реальність:

• Ви зробите більше знімків, ніж планували.
• Ви забудете, навіщо взяли принаймні 30% із них.
• Вам знадобиться правильний знімок під тиском.
• У вас буде принаймні один знімок, зроблений під час часткового збою (і він виглядатиме «свіжим»).

Тому мета не «красиві імена». Мета — зробити правильний відкат найпростіший шлях, а неправильний — неприємно складним.

Одна суха істина: якщо ваш список знімків не каже миттєво коли, чому, хто/що і чи безпечно, ви не керуєте системою знімків. Ви ведете папку скріншотів.

Жарт №1: Знімок без схеми іменування — як менеджер паролів, повний «password123» — технічно працездатний, але духовно приречений.

Цікаві факти та історичний контекст

Трохи контексту корисно, бо іменування ZFS лежить на перетині файлових систем, управління томами та операційної культури. Кілька конкретних фактів:

1. ZFS розроблявся як цілісна система: файлова система + менеджер томів + контрольні суми + знімки, спочатку в Sun Microsystems на початку 2000-х.
2. Імена знімків не є глобальними: вони прив’язані до датасету або zvol (наприклад, pool/app@name). Два датасети можуть мати кожен @daily і ZFS це не турбує.
3. Знімки доступні для запису лише через клонування: знімок тільки для читання; ви можете zfs clone його, щоб отримати записуваний датасет. Ця модель формує підхід до іменування «кандидатів для відновлення».
4. Відправлення знімків чутливе до імен: інкрементальний zfs send -i залежить від спільного предка. Мутне іменування робить походження незрозумілим людям, навіть коли ZFS може його обчислити.
5. Знімки недорогі, поки не стануть такими: вони не дублюють блоки одразу, але утримують старі блоки. Політика знімків може тихо стати вашим найбільшим споживачем простору.
6. ZFS підтримує «holds»: можна застосувати тег утримання, щоб знімок не можна було знищити. Це фактично механізм «legal hold» / «не видаляти, серйозно».
7. Існують bookmarks: це легкі посилання на точки знімків для реплікації, вони можуть знизити витрати зберігання, коли потрібні «якорі реплікації» без повного збереження знімків.
8. Імена — частина вашого аудиту: ZFS сам по собі не зберігатиме номер тікета чи причину, якщо ви не покладете їх в ім’я або властивості. Операційні команди зазвичай використовують обидва.
9. Є кілька лінійок ZFS: OpenZFS — це спільнотна реалізація, що використовується на illumos, FreeBSD, Linux і ін. Конвенції іменування — це ваш шар портативності між різними інструментами.

Що дає хороше ім’я знімка в реальному світі

Хороше ім’я знімка — це запис в індексі. Воно має дозволяти відповісти на ці питання без прокрутки:

• Коли його зробили (з таймзоною або неоднозначним UTC)?
• Що його створило (автоматичний таймер, CI job, ручний оператор, runbook оновлення)?
• Чому (перед оновленням, перед міграцією, після бекапу, захоплення інциденту)?
• Який рівень безпеки (можна видалити; слід утримувати; це «золотий»)?
• Якому робочому процесу він належить (реплікація, управління VM, quiesce БД, деплой додатку)?

Система іменування також має бути:

• Сортуваною в хронологічному порядку.
• Стабільною між командами і інструментами автоматизації.
• Безпечною для введення в стресі (без пробілів, без небезпечних для shell символів, без «креативної» пунктуації).
• Сумісною з тим, як ви відбираєте знімки в скриптах (grep, awk або фільтри властивостей ZFS).

І вона має передбачати режими відмов. Велика проблема: у вас буде кілька знімків, зроблених навколо однієї події, але не всі вони рівнозначно придатні для відновлення. Приклад: датасети баз даних. «Crash-consistent» знімок може бути ок або може вимагати відтворення журналів 20 хвилин, що налякає всіх. Іменування повинно відрізняти «quiesced» від «не quiesced», інакше ваш on-call дізнається різницю в реальному часі.

Одна перефразована ідея від Werner Vogels (CTO Amazon): Все постійно ламається; проєктуйте та експлуатуйте так, ніби відмови — норма. (перефразована ідея)

Система іменування знімків: конвенції, що масштабуються

Правило 0: Використовуйте UTC в іменах знімків

Місцевий час для календарів. Операції відновлення — проблема розподілених систем: команди в різних таймзонах, сервери з різними годинниками, і логи вже в UTC. Покладіть UTC в ім’я знімка і ви позбудетеся цілої категорії «чекати, це до деплою чи після?» аргументів.

Рекомендований формат: YYYYMMDDThhmmssZ (ISO-подібний, без двокрапок). Він лексикографічно сортується і очевидний людям.

Правило 1: Розділяйте «розклад» і «напрям»

Багато команд починають з @daily, @hourly, @weekly. Це мило, поки вам не потрібно відновити «знімок прямо перед міграцією схеми». Тепер ви рахуєте денні. Не робіть так.

Замість цього кодуйте:

• cadence (hourly/daily/adhoc)
• intent (predeploy, preupgrade, postbackup, incident)
• creator (auto/manual/ci)

Правило 2: Використовуйте передбачуваний порядок токенів

Виберіть канонічний порядок і ніколи не відступайте. Люди читають зліва направо. Скрипти парсяться зліва направо. Ваш майбутній я буде втомленим і не в захваті від креативності.

Практичний, промисловий шаблон:

<prefix>.<cadence>.<creator>.<intent>.<ts>[.<ticket>][.<flags>]

Приклади імен:

• snap.hourly.auto.base.20260204T010000Z
• snap.daily.auto.base.20260204T000000Z
• snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
• snap.adhoc.ci.predeploy.20260204T015912Z.PR4812
• snap.adhoc.manual.incident.20260204T021100Z.INC7781.hold
• snap.adhoc.auto.quiesced-db.20260204T020000Z

Пояснення:

• Префікс (snap) дозволяє відфільтрувати ваші знімки від інструментів постачальника.
• Крапки нудні й дружні до shell. Уникайте пробілів. Уникайте двокрапок. Уникайте «@prod:good».
• Номери тікетів необов’язкові, але корисні. Не вмикайте конфіденційну інформацію в імена; вони потрапляють у логи, моніторинг і потоки реплікації.
• Флаги — це короткі слова, як-от hold, gold, quiesced. Не перетворюйте їх на прозу.

Правило 3: Розміщуйте «особливість» в кінці, але тримайте часову мітку перед нею

Люди хочуть приробити «-final» або «-good». Якщо це зробити перед часовою міткою, сортування порушиться. Якщо після — сортування залишається хронологічним, і підказка все одно є.

Добре: snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345.gold
Погано: snap.adhoc.manual.gold.preupgrade.CHG12345.20260203T221530Z

Правило 4: Явно кодуйте quiescence для додатків, яким це важливо

Є датасети, де достатньо crash-consistency (статичний контент, більшість дисків VM, якщо гостьова журналізація здорова). А є датасети, де це рулетка (активні БД, деякі черги повідомлень, застарілі додатки). Для них система іменування має містити токен на кшталт:

• quiesced-db (додаток підтвердив flush / fsfreeze / координовану зупинку)
• crash (без координації; відновлення може вимагати реплею журналів)

Це не моральна оцінка. Це маркування ризику.

Правило 5: Використовуйте властивості ZFS для машиночитаних метаданих (а імена для людей)

Імена знімків видно. Властивості доступні для запитів. Використовуйте обидва. Практичний підхід:

• Ім’я несе cadence/intent/timestamp і, можливо, тікет.
• Властивості несуть структуровані метадані, як-от com.company:reason, com.company:owner, com.company:expiry.

Чому обидва? Бо люди вибирають знімки за іменем під час інцидентів, а автоматизації потрібні надійні селектори, які не залежать від парсингу рядка, який ви незмінно «покращите» колись.

Правило 6: Плануйте реплікацію і ретеншн з першого дня

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

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

• Тримайте автоматизовані cadence-знімки за суворим шаблоном: легко збирати, легко видаляти.
• Тримайте «подієві» знімки (preupgrade/incident) на іншому шаблоні та захищайте їх утриманням.
• Використовуйте bookmarks як реплікаційні якорі, коли доречно, але називайте їх із тією ж дисципліною часових міток.

Практичні завдання: команди, виходи та рішення (12+)

Завдання 1: Перерахувати знімки в датасеті, відсортовані за часом створення

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation tank/app
NAME                                   CREATION
tank/app@snap.daily.auto.base.20260203T000000Z   Mon Feb  3 00:00 2026
tank/app@snap.hourly.auto.base.20260203T230000Z Mon Feb  3 23:00 2026
tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345 Tue Feb  3 22:15 2026

Що означає вивід: У вас є часові мітки створення від самого ZFS, а не виведені з імені. Це має значення, коли годинники дріфтять або хтось вручну перейменував шаблони.

Рішення: Якщо час створення ZFS не збігається з часовою міткою в імені, у вас проблема в процесі (або проблема синхронізації часу). Виправте NTP і вашу автоматизацію перед тим, як покладатися на часові мітки під час інцидентів.

Завдання 2: Показати простір, утримуваний знімками (чому «дешево» стає «дорогим»)

cr0x@server:~$ zfs list -o name,used,refer,usedbysnapshots tank/app
NAME      USED  REFER  USEDBYSNAPSHOTS
tank/app  850G  620G   210G

Що означає вивід: USEDBYSNAPSHOTS — це простір, який утримується через посилання знімків на старі блоки.

Рішення: Якщо USEDBYSNAPSHOTS високий і пул має мало вільного місця, слід терміново видаляти знімки за політикою, а не панічно. Якщо це високо на датасеті з великою кількістю змін, негайно перегляньте cadence і ретеншн.

Завдання 3: Знайти найбільші знімки (корисно для цілеспрямованого прибирання)

cr0x@server:~$ zfs list -t snapshot -o name,used,refer -s used tank/app
NAME                                                   USED  REFER
tank/app@snap.hourly.auto.base.20260203T230000Z        18G   620G
tank/app@snap.hourly.auto.base.20260203T220000Z        14G   615G
tank/app@snap.adhoc.manual.incident.20260203T210100Z.INC7781.hold 9G  610G

Що означає вивід: USED знімка — це скільки унікального простору знімок утримує порівняно з живим датасетом.

Рішення: Великі hourly-знімки свідчать про сильний churn. Розгляньте зниження частоти, розділення датасетів для ізоляції churn або змусьте додаток писати в окремий датасет з іншою політикою ретеншн.

Завдання 4: Перевірити існування знімка перед незворотними діями

cr0x@server:~$ zfs list -t snapshot tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
NAME
tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345

Що означає вивід: Якщо він виводить ім’я — знімок існує. Якщо помилка — ваш план відновлення вже неправильний.

Рішення: Якщо ви не можете однозначно ідентифікувати знімок, зупиніться. Не «приблизуйте» з найближчим daily. Так можна відкотити до неправильної схеми.

Завдання 5: Створити «подієвий знімок» з дисциплінованим іменем

cr0x@server:~$ ts=$(date -u +%Y%m%dT%H%M%SZ); zfs snapshot tank/app@snap.adhoc.manual.preupgrade.${ts}.CHG12345

Що означає вивід: Відсутність виводу означає успіх. ZFS такий.

Рішення: Негайно застосуйте hold для високоризикових змін (наступне завдання). Якщо не зробити цього, job очистки може видалити єдиний потрібний знімок.

Завдання 6: Захистити знімок тегом hold (зробити видалення неможливим)

cr0x@server:~$ zfs hold keep tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
cr0x@server:~$ zfs holds tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
NAME                                                    TAG   TIMESTAMP
tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345  keep  Tue Feb  3 22:16 2026

Що означає вивід: Знімок має тег утримання keep. Його не можна знищити, поки утримання не зняті.

Рішення: Для інцидентних і pre-upgrade знімків утримання — це дешева страховка. Використовуйте їх. Потім створіть процес для зняття утримань, коли зміни визнано безпечними.

Завдання 7: Додати структуровані метадані через user properties (для подальших запитів)

cr0x@server:~$ zfs set com.acme:reason="preupgrade app 7.4" tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
cr0x@server:~$ zfs set com.acme:ticket="CHG12345" tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
cr0x@server:~$ zfs get -H -o property,value com.acme:reason,com.acme:ticket tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
com.acme:reason	preupgrade app 7.4
com.acme:ticket	CHG12345

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

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

Завдання 8: Відкотити датасет (і зрозуміти, що ви перезаписуєте)

cr0x@server:~$ zfs rollback -n tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
would rollback tank/app to tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
would destroy the following snapshots:
  tank/app@snap.hourly.auto.base.20260203T230000Z
  tank/app@snap.daily.auto.base.20260204T000000Z

Що означає вивід: -n — це dry run. Відкотування знищить новіші знімки, якщо ви не використаєте -r обережно або не збережете їх клонуванням.

Рішення: Якщо відкат знищить знімки, які потрібні для реплікації або аудиту, зупиніться і розгляньте клонування (Завдання 9). Dry-run у production — обов’язковий.

Завдання 9: Зробити клон знімка замість відкату (безпечніше для судової експертизи)

cr0x@server:~$ zfs clone tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345 tank/app-restore
cr0x@server:~$ zfs list -o name,used,refer,mountpoint tank/app-restore
NAME            USED  REFER  MOUNTPOINT
tank/app-restore  1G   620G   /tank/app-restore

Що означає вивід: Клон записуваний і спочатку малий (USED), бо ділиться блоками зі знімком.

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

Завдання 10: Send/receive з чітким походженням (реплікація без здогадок)

cr0x@server:~$ zfs send -nvP -i tank/app@snap.daily.auto.base.20260203T000000Z tank/app@snap.daily.auto.base.20260204T000000Z
send from @snap.daily.auto.base.20260203T000000Z to tank/app@snap.daily.auto.base.20260204T000000Z estimated size is 12.3G
total estimated size is 12.3G
TIME        SENT   SNAPSHOT

Що означає вивід: Dry-run send (-n) з прогнозом прогресу (-P). Підтверджує існування базового інкрементального знімка та розмір дельти.

Рішення: Якщо оцінений розмір несподівано великий — це сигнал churn (або зміни в стисненні/шифруванні). Перевірте, що змінилося між знімками, перш ніж наповнювати WAN-лінк.

Завдання 11: Використовувати bookmarks як легкі якорі реплікації

cr0x@server:~$ zfs bookmark tank/app@snap.daily.auto.base.20260204T000000Z tank/app#bmark.daily.20260204T000000Z
cr0x@server:~$ zfs list -t bookmark -o name,creation tank/app
NAME                                   CREATION
tank/app#bmark.daily.20260204T000000Z  Tue Feb  4 00:00 2026

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

Рішення: Якщо тиск на ретеншн високий, bookmarks допоможуть реплікаційним процесам, дозволяючи видаляти старіші знімки. Але не вважайте bookmarks точками відновлення для людей; вони не монтуються.

Завдання 12: Перевірити утримання перед прибиранням (чому destroy іноді «не працює»)

cr0x@server:~$ zfs destroy tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
cannot destroy snapshot tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345: snapshot has holds
cr0x@server:~$ zfs holds tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
NAME                                                    TAG   TIMESTAMP
tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345  keep  Tue Feb  3 22:16 2026

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

Рішення: Якщо цей знімок ще потрібен — залиште його. Якщо його безпечно видалити — явно зніміть утримання з записом зміни (Завдання 13).

Завдання 13: Зняти утримання, а потім знищити (зробити це усвідомлено)

cr0x@server:~$ zfs release keep tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345
cr0x@server:~$ zfs destroy tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345

Що означає вивід: Відсутність виводу: успіх.

Рішення: Зняття утримань має відбуватися рідше, ніж їхнє встановлення. Якщо ви знімаєте їх легко, рано чи пізно видалите потрібний знімок. Ставтеся до утримань як до break-glass контролів.

Завдання 14: Знайти знімки за наміром, використовуючи шаблони імен (людська триаж)

cr0x@server:~$ zfs list -t snapshot -o name -s creation tank/app | grep preupgrade | tail -5
tank/app@snap.adhoc.manual.preupgrade.20260110T210002Z.CHG12111
tank/app@snap.adhoc.manual.preupgrade.20260124T210011Z.CHG12202
tank/app@snap.adhoc.manual.preupgrade.20260203T221530Z.CHG12345

Що означає вивід: Ваша система іменування робить намір пошуковим у стресі.

Рішення: Якщо вам потрібен складний regex, щоб знайти «останній preupgrade-знімок», ваші імена занадто хитрі. Спростіть токени.

Завдання 15: Підтвердити mountpoint датасету перед діями відновлення

cr0x@server:~$ zfs get -o name,property,value mountpoint,canmount tank/app tank/app-restore
NAME            PROPERTY    VALUE
tank/app        mountpoint  /srv/app
tank/app        canmount    on
tank/app-restore mountpoint /tank/app-restore
tank/app-restore canmount   on

Що означає вивід: Ви бачите, куди змонтується і чи буде автомонт.

Рішення: Перед відкатом перевірте, щоб ви випадково не змонтували клон поверх production-шляхів. Для тестових відновлень встановіть безпечний mountpoint або canmount=noauto.

Завдання 16: Перевірити стан пулу перед тим, як звинувачувати знімки в повільності

cr0x@server:~$ zpool status -x
all pools are healthy

Що означає вивід: ZFS не бачить помилок або деградованих vdev. Це базова умова.

Рішення: Якщо пул нездоровий, операції зі знімками можуть бути повільними, бо система вже бореться. Виправляйте апаратні проблеми або resilver перш ніж намагатися налаштувати систему.

Жарт №2: Єдина річ страшніша за «у нас немає знімків» — «у нас 40 000 знімків і ніхто не знає, які з них реальні».

Три корпоративні міні-історії з практики

Міні-історія 1: Інцидент через неправильне припущення («@daily означає безпечно»)

У середній SaaS-компанії команда зберігання мала просту політику: hourly для критичних датасетів, daily для всього іншого. Імена були короткі: @hourly, @daily. Автоматизація тримала лише тиждень hourly і місяць daily. Команда почувалася відповідальною. Вони й були. Просто не за потрібне.

Бекенд-деплой пройшов не так і пошкодив підмножину метаданих користувачів. Інцидент-командир попросив відновити «вчора опівночі». On-call знайшов @daily знімок, відкотив датасет і спостерігав запуск додатку. Він запустився. Потім почав викидати новий тип помилок: відсутні записи, на які посилаються нові файли. Відкат відновив датасет, але не систему.

Неправильне припущення було в тому, що «daily» означає «відомо хороший». Насправді знімок був crash-consistent і захопив стан під час інгісту. Додаток очікував координованого чекпоінту між двома датасетами: один тримав метадані, інший — блоби. Блоб-датасет мав свій @daily, зроблений за кілька хвилин пізніше. Відкат відновив одну сторону, але не обидві. Вітаємо — ви створили невідповідність даних з відчутною впевненістю.

Виправлення не вимагало героїчного нового інструмента. Це була зміна іменування та політик: знімки для мульти-датасетних додатків бралися в оркестрованому батчі з одним токеном часу, а ім’я містило quiesced лише тоді, коли додаток це підтверджував. Runbook оновили, щоб відновлювати консистентний набір, співставляючи часові мітки між датасетами. Раптом «який знімок?» перестав бути предметом дебатів і став фільтром.

Міні-історія 2: Оптимізація, що дала зворотний ефект (частота знімків як підсилювач латентності)

Фінансова команда тримала ZFS для VM-дисків і мала вимогу зберігати часті точки відновлення. Хтось вирішив: «Якщо знімки дешеві, робитимемо їх кожні 5 хвилин.» Автоматизацію оновили. Працювало. До певного часу.

Через два місяці скарги на продуктивність стали регулярними. Не катастрофа, але постійно: періодичні сплески латентності, особливо в години пікового навантаження. Усі звинувачували «гіпервізор» або «мережу». Графіки показали більш прозаїчне: вибухи метаданих навколо часу знімків, підвищене write amplification через утримані блоки і пули, що ближче до заповнення через розширення ретеншну.

Зворотний ефект був тонким: команда оптимізувала RPO, ігноруючи криву витрат при churn. Часті знімки на датасетах з великою кількістю записів не просто створюють більше записів; вони утримують більше розгалуженої історії блоків. У поєднанні з пулом, що висить біля високого заповнення, це ускладнило алокацію, збільшило фрагментацію і дало системі менше опцій. Політика 5 хвилин не лише додала роботи; вона посилила найгіршу поведінку перенапруженого пулу.

План відновлення був прагматичним: знизити частоту для high-churn датасетів, розділити «OS-диски» і «data-диски» у різні датасети з різним ретеншн, і впровадити мінімум вільного простору. Іменування знімків допомогло: команда могла точно ідентифікувати і видалити cadence 5 хвилин (snap.5min.auto.base...) без торкання подієвих знімків або якорів реплікації.

Вони й далі відповідали на вимоги, просто перестали вважати підсистему зберігання чарівною скринькою бажань.

Міні-історія 3: Нудна, але правильна практика, яка врятувала день (dry runs + holds)

Платформа охорони здоров’я мала культуру «роби нудні речі першими». Їхні runbook-и ZFS вимагали двох кроків перед будь-яким відкатом: zfs rollback -n dry run, і підтвердження утримань на будь-якому знімку, пов’язаному з тікетом зміни. Інженери бурчали. Здавалося, це зайва бюрократія з додатковим набором команд.

Під час планового вікна оновлення інженеру довелося відновити датасет після того, як інструмент міграції записав несподівані значення. Вони вибрали знімок, що здавався правильним: того ж дня, близька часова мітка. Dry-run попередив, що відкат знищить кілька новіших знімків, які використовувалися як інкрементали для реплікації. Це не лише втрата даних; це реплікаційний беклог, що перетвориться на вихідні дані на вихідні дні.

Інженер зупинився. Вони клонували, перевірили стан додатку в клоні, і тоді обрали інший знімок, який зберігав ланцюг реплікації. Нудний крок уникнув другого інциденту: провалену реплікацію і панічне повторне насіння.

Пізніше автоматизація прибирання намагалася обрізати «adhoc» знімки старше порогу. Вона не змогла видалити pre-upgrade, бо утримання були встановлені зі стандартним тегом. Нікому не потрібно було пам’ятати. Система пам’ятала. Оновлення пройшло успішно, утримання зняли після перевірки, а інцидент закрили без драми.

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

План швидкої діагностики: знайти вузьке місце швидко

Коли операції зі знімками повільні — або реплікація повзе — люди схильні звалювати все на «ZFS snapshots», ніби це демон. Не робіть цього. Проводьте триаж. Ось швидка, високосигнальна послідовність.

Перш за все: чи хворий пул?

• Перевірка: zpool status -x
• Чому: деградовані vdev, resilvers, помилки checksum або офлайн-пристрої домінуватимуть над усім іншим.
• Рішення: Якщо не здоровий — виправляйте це в першу чергу. Налаштування марне, поки ваш пул кульгає.

По-друге: чи пул занадто заповнений?

• Перевірка: zpool list та usedbysnapshots по датасетах
• Чому: висока завантаженість зменшує гнучкість алокації; знімки утримують блоки; обидва фактори можуть спричинити сплески латентності.
• Рішення: Якщо ви наближаєтесь до операційного порогу вільного місця — видаліть знімки безпечно, додайте ємність або зменшіть churn. Оберіть принаймні один крок сьогодні.

По-третє: чи churn походить з одного датасету?

• Перевірка: zfs list -o name,used,usedbysnapshots по датасетах; знайдіть «погорільців».
• Чому: один лог-датасет може домінувати в дельтах знімків і обсягах реплікації.
• Рішення: Розділіть датасети за профілем записів. Припиніть знімкувати тимчасові логи з високою частотою, якщо вам не подобається оплачувати збережену мотлох.

По-четверте: чи повільна реплікація через великі дельти?

• Перевірка: zfs send -nvP -i між знімками.
• Чому: Ви не зможете оптимізувати 10x дельту без зміни того, що пише.
• Рішення: Якщо дельти несподівано великі — досліджуйте поведінку додатку, невідповідність recordsize, зміни стиснення та частоту знімків.

По-п’яте: чи страждаєте від «накопичення знімків»?

• Перевірка: кількість знімків: zfs list -t snapshot | wc -l (грубо, але швидко)
• Чому: дуже велика кількість знімків підвищує операційне навантаження і імовірність людської помилки.
• Рішення: Якщо кількість вийшла з-під контролю — виправте автоматизацію ретеншну і шаблони імен, щоб ви могли безпечно видаляти без регекс-лотереї.

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

Помилка 1: «Ми не можемо сказати, який знімок безпечний для відновлення»

Симптоми: Довгі нитки інцидентів, суперечки про часові мітки; кілька часткових відкатів; страх робити rollback.

Корінна причина: Імена кодують лише cadence (@daily), але не intent, quiescence чи групування робочих процесів.

Виправлення: Впровадьте токенізовану схему імен з UTC-часовими мітками і маркерами наміру (preupgrade, predeploy, incident, quiesced-db). Для мульти-датасетних додатків робіть координовані знімки з однаковим часовим токеном по всіх датасетах.

Помилка 2: «Під час прибирання видалили потрібний знімок»

Симптоми: Подієві знімки зникають; у постмортемі — «ми думали, що він там».

Корінна причина: Немає утримань; скрипти прибирання широко підходять до «adhoc»; немає розділення класів ретеншн.

Виправлення: За замовчуванням встановлюйте утримання для змін/інцидентів. Розділяйте ретеншн: snap.hourly.auto.base видаляються агресивно; snap.adhoc.manual.preupgrade утримуються до явного релізу.

Помилка 3: «Відкат знищить новіші знімки і реплікація ламається»

Симптоми: Dry-run показує видалення знімків; після відкату ланцюги реплікації падають; потрібно заново налаштовувати seed.

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

Виправлення: Завжди використовуйте zfs rollback -n. Віддавайте перевагу клонуванню для валідації і судової експертизи. Якщо необхідно відкотити — плануйте реакліматизацію реплікації і зберігайте необхідні знімки.

Помилка 4: «Використання простору знімків росте, хоча файли видалені»

Симптоми: USED датасету не падає; пул залишається заповненим; видалення даних не повертає простір.

Корінна причина: Знімки утримують старі блоки, тож видалення у живому датасеті не звільняє простір, поки знімки не знищені.

Виправлення: Знайдіть великі знімки (zfs list -t snapshot -s used). Зменшіть ретеншн на high-churn датасетах. Розгляньте зміну макету датасетів, щоб ізолювати джерела churn.

Помилка 5: «Імена несумісні між інструментами; скрипти пропускають знімки»

Симптоми: Деякі імена знижують підкреслення, деякі — дефіси; часові формати різні; скрипти ретеншн пропускають частину; інцидентні знімки не знаходяться grep-ом.

Корінна причина: Багато творців знімків (cron, CI, адміністратори) без загальної конвенції.

Виправлення: Визначте один канонічний порядок токенів і роздільників; застосуйте через wrapper-скрипти або політику. Додайте властивості для структурованих метаданих, щоб автоматизація могла відбирати за властивістю, а не рядком.

Помилка 6: «Ми робимо знімки надто часто і продуктивність стрибає»

Симптоми: Сплески латентності в часи знімків; великі інкрементальні дельти для реплікації; зростання заповнення пулу.

Корінна причина: Часті знімки на high-churn датасетах; невідрегульований ретеншн; пул занадто повний.

Виправлення: Зменшіть частоту для датасетів з високим churn; розділіть датасети за профілем записів; встановіть мінімум вільного місця; перевіряйте дельти через zfs send -nvP перед глобальним поштовхом змін.

Контрольні списки / покроковий план

Контрольний список A: Впровадити систему іменування без руйнування всього

1. Перелік творців знімків: cron jobs, CI pipelines, інструменти постачальника, люди. Якщо ви не знаєте, хто створює знімки — ви не контролюєте іменування.
2. Виберіть канонічний шаблон імен: наприклад, snap.<cadence>.<creator>.<intent>.<ts>.
3. Стандартизувати формат UTC-часової мітки: YYYYMMDDThhmmssZ. Ніяких винятків.
4. Визначте класи ретеншн:
   • hourly.auto.base (короткий)
   • daily.auto.base (середній)
   • adhoc.*.preupgrade та adhoc.*.incident (утримуються)
5. Вирішіть щодо токенів quiescence: мінімум quiesced-db проти crash.
6. Додайте властивості для метаданих: reason, ticket, expiry, owner.
7. Оновіть runbook-и: відновлення за групою часових міток для мульти-датасетних додатків; політика «клонувати спочатку» для відновлень з високим ризиком.
8. Впроваджуйте поступово: почніть з нових знімків. Не перейменовуйте старі на місці, якщо не впевнені, що інструменти не зламаються.

Контрольний список B: «Потрібно відновити зараз» (кроки оператора)

1. Підтвердити стан пулу: zpool status -x. Якщо нездоровий — очікуйте затримок і ризиків.
2. Визначити точні датасети, які постраждали. Не відкатуйте батька, якщо постраждала лише дитина.
3. Перелічити знімки, відсортовані за створенням і знайти токен наміру (predeploy/preupgrade/incident).
4. Перевірити quiescence для БД-подібних датасетів. Обирайте quiesced-db, коли доступно.
5. Dry-run відкат: zfs rollback -n. Прочитайте, що буде знищено.
6. Віддавайте перевагу клонуванню для валідації. Замонтуйте безпечно і перевірте додаток.
7. Відкатуйте лише коли розумієте blast radius і повідомили зацікавлених (реплікація, новіші знімки, залежні сервіси).
8. Після відновлення: зробіть новий знімок з наміром postrestore і утримайте його коротко. Це дає стабільний «відомий стан», якщо подальші зміни підуть не так.

Контрольний список C: Гігієна знімків (тижневе прибирання)

1. Перегляньте використання простору знімками: знайдіть датасети з найбільшим usedbysnapshots.
2. Помітити runaway cadence: надто багато знімків на датасеті зазвичай означає дріфт автоматизації.
3. Видаляти по класу: спочатку видаляйте старі hourly.auto.base; не чіпайте утримувані подієві знімки.
4. Аудит утримань: якщо утримання ніколи не знімають, ваш «тимчасовий» стане постійним. Додайте властивість expiry і цикл перегляду.
5. Тестуйте відновлення: не тільки «можемо перерахувати знімки?» — дублюйте і перевіряйте дані. Ваша система іменування доведена, коли вона допомагає відновленню.

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

1) Чи повинні імена знімків включати ім’я датасету?

Ні. Датасет вже є частиною повного імені знімка (tank/app@...). Дублювання робить імена довшими і гірше зчитуваними. Кодуйте намір і час замість цього.

2) Чи можна перейменувати ZFS-знімок?

Так, ZFS підтримує перейменування знімків у багатьох реалізаціях, але це може мати операційні наслідки (очікування реплікації, скрипти, моніторинг). Розглядайте перейменування як міграційне завдання з тестуванням, а не як звичайне прибирання.

3) Чому не просто використовувати @hourly і спростити?

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

4) Як групувати знімки між кількома датасетами для консистентного відновлення?

Використовуйте спільний токен часової мітки для всіх датасетів, задіяних у координованому знімку. Потім відновлюйте, підбираючи цю часову мітку. Приклад: кожний датасет отримує ...20260204T020000Z.... Тут дисципліна UTC виплачує дивіденди.

5) Чи використовують імена знімків zfs send для правильності?

Правильність ZFS залежить від походження знімків, а не від людського значення імені. Але люди керують системою. Хороше іменування запобігає тому, щоб ви відправили неправильні інкрементали або вибрали неправильну базу під час стресу.

6) Чи варто додавати номери тікетів в імена знімків?

Зазвичай так, для змін і інцидентів. Це легка трасованість. Тримайте їх короткими і не конфіденційними. Якщо ідентифікатори тікетів «брудні», зберігайте їх у властивостях і тримайте імена чистими.

7) Скільки знімків — це «занадто багато»?

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

8) У чому різниця між hold знімка і просто «не видаляти»?

Утримання робить видалення неможливим на рівні файлової системи, навіть якщо скрипт прибирання запуститься з добрими намірами. «Не видаляти» — це надія. Утримання — це контроль.

9) Чи варто зберігати «золоті» знімки назавжди?

Рідко. Довготривалі знімки накопичують утримані блоки і підвищують тиск на простір, особливо на high-churn датасетах. Якщо потрібне довгострокове зберігання — реплікуйте на ціль бекапу і тримайте менше локальних знімків, або перемістіть архівні дані в датасет, спроектований для цього.

10) Чи мають імена знімків бути ідентичними між середовищами (dev/stage/prod)?

Шаблон має бути ідентичним. Шляхи датасетів відрізнятимуться. Послідовні шаблони імен допомагають повторно використовувати runbook-и і автоматизацію та зменшують «працює в staging» сюрпризи.

Висновок: наступні кроки, які дійсно знижують стрес

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

Практичні наступні кроки:

1. Виберіть порядок токенів (snap.cadence.creator.intent.ts) і вимагайте UTC-мітки.
2. Розділіть класи ретеншн: базова cadence проти подієвих знімків. Для подій використовуйте утримання.
3. Додайте властивості для reason/ticket/expiry, щоб автоматизація була надійною.
4. Оновіть runbook відновлення до: list → dry-run → clone-first → validate → rollback лише коли зрозуміло.
5. Проведіть одну репетицію відновлення цього місяця з новими іменами. Якщо репетиція плутає — система іменує вас неправдою.

Знімки — одна з суперсил ZFS. Іменування — це приціл.