Клони ZFS: миттєві копії з прихованими залежностями (важливо знати)

Клони ZFS — це та особливість, яка змушує інженерів зі сховищ виглядати як фокусники: створити «копію» файлової системи або тому моментально, не переміщаючи дані, і почати в неї писати, ніби вона завжди існувала. Вперше використавши це для шаблону ВМ, CI-середовища або судової копії, здається, що ви обійшли закони фізики.

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

Що насправді таке клон ZFS

Снапшот ZFS — це доступ до датасету (файлової системи) або тому (zvol) у вигляді незаписуваного стану на певний момент часу. Його початкова вартість майже нульова, бо він лише зберігає метадані; блоки спільні, поки не почнуть відрізнятися.

Клон ZFS — це записуваний датасет або zvol, створений із снапшоту. Частина «з снапшоту» — це не дрібниця; це вся суть контракту. Клон починає своє життя, розділяючи блоки з його оригінальним снапшотом. Коли ви пишете в клон, ZFS використовує copy-on-write (CoW): він записує нові блоки в інше місце, оновлює метадані, і клон віддаляється від снапшоту.

У клони є дві властивості, які операторам варто вбити в пам’ять:

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

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

Анатомія клону: dataset проти zvol

ZFS може клонувати обидва типи:

• Файлові системи (datasets): монтуються в точці монтування, містять файли та каталоги.
• Томи (zvols): блочні пристрої, часто використовуються для дисків ВМ, iSCSI LUNів, сирих пристроїв баз даних.

Механізм клонування однаковий. Операційний вплив відрізняється, бо клони zvol часто використовуються у віртуалізаційних стеках, де шаблони та «linked clone» патерни звичні, і де під важкими випадковими записами швидко з’являється write amplification.

Що означає «миттєво» насправді

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

Прихована залежність: «ви не можете видалити цей снапшот»

Класичний сюрприз виглядає так:

• Ви створюєте снапшот pool/prod@app-2025-12-25.
• Ви створюєте клон pool/dev/app-test з цього снапшоту.
• Через тижні ви намагаєтеся видалити старі снапшоти, щоб повернути простір.
• ZFS відмовляється знищити снапшот, бо є залежні клони.

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

Чому це важливо, окрім «не вдається очистити»

У продакшені залежності клонів зазвичай проявляються як:

• Політика збереження снапшотів ламається. Ваше правило «зберігати 14 днів» раптом стає «зберігати 14 днів, якщо немає клонів, інакше зберігати вічно».
• Відновлення простору зупиняється. Команди видаляють файли, але використання пула не падає, бо блоки все ще посилаються снапшотами, які не можна видалити.
• Ускладнення реплікації. Клони можуть заплутати робочі процеси zfs send, якщо ви не спланували топологію датасетів/снапшотів.
• Хаос із промоцією. Хтось «промотує» клон, щоб розірвати залежності, і змінює, який датасет вважати продакшн, — і ваш ментальний образ «що є прод» тепер неправильний.

Промоція: запасний вихід (і потенційна пастка)

zfs promote робить клон «головним» датасетом, а його оригінал стає дочірнім (концептуально). Це спосіб розірвати залежність від оригінального снапшоту, щоб ви могли його видалити. Це також спосіб випадково перевернути родовід і сплутати реплікацію, моніторинг та людей.

Промоція легітимна і часто необхідна. Але вона має бути запланованою дією з явними наслідками, а не відчайдушною командою, скопійованою з форуму, коли пул заповнений на 99%.

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

Шість–десять коротких пунктів, які важливі не як курйоз, а тому, що пояснюють, чому клони поводяться так, як поводяться:

1. Снапшоти ZFS дешеві завдяки CoW. ZFS ніколи не перезаписує на місці; він записує нові блоки й оновлює вказівники, що робить консистентні снапшоти природним наслідком дизайну.
2. Клони створювали для швидкого забезпечення. Ранні користувачі ZFS використовували клони для dev/test і шаблонів ВМ задовго до того, як «інфраструктура як код» стала загальною практикою.
3. Простір ділиться за допомогою лічильників посилань. Блок може посилатися живою файловою системою, одним або кількома снапшотами і одним або кількома клонами; він звільняється лише тоді, коли зникає останнє посилання.
4. «Використано» в ZFS — контекстне. Є «used by dataset», «used by snapshots», «used by children» і «logical used»; ваш пул заповнюється згідно з фізичною реальністю, а не тим числом, на яке ви дивитеся в дашборді.
5. Клони передували багатьом сучасним продуктам з управління копіями даних. Ідея — копіювати миттєво й віддалятися при записі — та сама, що й у багатьох комерційних системах snapshot/clone.
6. Родовід клонів явно зберігається в властивостях. ZFS зберігає властивість origin на клонах; ви можете запитувати й автоматизувати це (і повинні).
7. Промоція змінює походження, а не валідність даних. Вона переставляє, який снапшот вважається «оригіналом» для цілей залежностей; вона не переписує весь датасет.
8. Клони і снапшоти — не резервні копії. Вони чудово працюють для локального відновлення, але поділяють той самий пул, домен відмови і часто ту саму ризик-площу «ой, я знищив пул».
9. Клони ZVOL змінили економіку ВМ. Linked clones дозволяють розгорнути сотні ВМ з одного золотого образу з мінімальним сховищем — доки шаблон записів не перетворить «мінімум» на «сюрприз».

Коли клони — правильний інструмент (а коли ні)

Добре підходить

• Шаблони ВМ / золоті образи: миттєве забезпечення дисків ВМ; платите лише за відхилення від образу.
• CI середовища: швидко піднімайте тестові датасети, видаляйте після завершення прогону.
• Судова експертиза: зробіть записувану копію снапшоту, щоб відтворити проблему, не торкаючись продакшну.
• Пісочниці для аналітики даних: дайте аналітикам записуваний датасет зі стабільного снапшоту без дублювання терабайтів.
• Ризиковані міграції: клон датасету та репетиція змін; якщо щось піде не так — знищіть клон.

Погано підходить (або потребує запобіжних заходів)

• Довгоживучі «тимчасові» середовища, які переживають вікно збереження снапшотів. Так тижневий тестовий клон стає трирічним «якорем простору».
• «Клон як бекап». Якщо пул помирає, і оригінал, і клон помирають разом. Клони зменшують радіус помилок людини, але не апаратних відмов.
• Неврегульований самообслуговуючийся доступ розробників. Розробники створюватимуть клони з креативними іменами, забудуть про них, і ваше прибирання снапшотів перетвориться на терапевтичну сесію.

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

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

1) Інцидент через неправильне припущення: «Видалення снапшоту звільнить простір»

Команда зі сховища в середній компанії експлуатувала кластер віртуалізації на ZFS. У них була акуратна політика: годинні снапшоти протягом 48 годин, щоденні протягом двох тижнів. Це працювало — допоки не перестало. Пул поволі піднімався з 70% до 88% за місяць, потім вийшов на 94% у вихідні, і в понеділок вранці ВМ стали повільними, а дашборди сердитими.

На виклику зробили очікуване: видалити старі снапшоти. Команди destroy почали падати з помилкою «snapshot has dependent clones». Повідомлення здається нешкідливим, поки не зрозумієш, що воно означає «ваша політика збереження — фікція». Припущення було, що лише снапшоти впливають на збереження. Насправді пайплайн створення ВМ тихо перейшов на «linked clones з нічного снапшоту» для пришвидшення створення середовищ. Ніхто не повідомив команду зі сховища, бо з точки зору пайплайну це було покращення продуктивності.

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

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

2) Оптимізація, що відкотилася: «Давайте ще й дедуп»

Інша організація любила ефективність. Вони виявили клони і почали використовувати їх повсюди: бази даних розробників, QA, оновлення стендів. Використання пула впало, забезпечення пришвидшилося, всі вітали одне одного.

Потім хтось вимовив фразу, яка знищувала тижні гарного настрою: «Якщо клони економлять простір, дедуп збереже ще більше». Вони включили dedup на датасеті з клонованими образами ВМ та баз даних у zvol. Перші дні числа виглядали чудово. Наступні тижні — пам’ять стала під тиском. Механізм ARC частіше пропускав кеш. Латентність стала стрибкоподібною в часи навантаження. Зрештою машина почала іноді «зависати» під навантаженням, ніби вона серйозно задумалася над життям.

Таблиці дедупа вимогливі до пам’яті. Клони вже ефективно ділили блоки, якщо походять з однієї лінії снапшотів; дедуп додає глобальний облік блоків. Для їхнього навантаження — багато подібних, але розходячихся ВМ з випадковими записами — дедуп збільшив метадантичний чаїнж і зробив кожен запис дорожчим. «Заощаджений простір» був реальний, але вони поступилися передбачуваною продуктивністю та оперативною простотою.

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

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

Одна команда платформ у великому підприємстві ставилася до клонів як до продакшн-ресурсів, а не магічних трюків. Їхнє правило було нудним: кожен клон повинен мати власника, номер тикета та дату закінчення. Не в таблиці — ці властивості зберігалися як користувацькі властивості ZFS безпосередньо на датасеті.

Коли пул почав тренд на підйом, вони не гадали. Запустили скрипт: перелічити всі клони, їхні оригінальні снапшоти та дати закінчення. Більшість були легітимними. Кілька — прострочені й невикористовувані. Їх видалили першими, що розблокувало снапшоти, що звільнило простір. Ніякої пожежі не сталося.

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

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

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

Нижче наведені практичні завдання, які ви можете виконати на типовій системі OpenZFS (Linux або illumos). Команди припускають наявність привілеїв. Виводи прикладні; у вас вони будуть іншими.

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

cr0x@server:~$ zfs list -t filesystem,snapshot,volume -o name,type,used,refer,origin -r tank/app
NAME                          TYPE      USED  REFER  ORIGIN
tank/app                      filesystem 12.3G  9.8G  -
tank/app@daily-2025-12-20      snapshot   0B    9.8G  -
tank/app@daily-2025-12-21      snapshot   0B    10.1G -
tank/app@daily-2025-12-22      snapshot   0B    10.1G -
tank/app-clone-qa             filesystem 3.1G  11.0G tank/app@daily-2025-12-21

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

Завдання 2: Створити снапшот (швидко й безпечно)

cr0x@server:~$ zfs snapshot tank/app@pre-change-001
cr0x@server:~$ zfs list -t snapshot -o name,creation -r tank/app | tail -n 3
NAME                          CREATION
tank/app@daily-2025-12-22      Mon Dec 22 01:00 2025
tank/app@pre-change-001        Thu Dec 25 09:14 2025

Інтерпретація: Снапшот миттєвий і консистентний на рівні ZFS.

Завдання 3: Створити клон зі снапшоту

cr0x@server:~$ zfs clone tank/app@pre-change-001 tank/app-clone-dev
cr0x@server:~$ zfs get origin,mountpoint tank/app-clone-dev
NAME               PROPERTY    VALUE                    SOURCE
tank/app-clone-dev  origin      tank/app@pre-change-001  -
tank/app-clone-dev  mountpoint  /tank/app-clone-dev      default

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

Завдання 4: Доведіть залежність: спробуйте знищити оригінальний снапшот

cr0x@server:~$ zfs destroy tank/app@pre-change-001
cannot destroy snapshot tank/app@pre-change-001: snapshot has dependent clones

Інтерпретація: Цей снапшот закріплено. Ваша політика збереження зустріла реальність.

Завдання 5: Знайти залежні клони для снапшоту

cr0x@server:~$ zfs list -t filesystem,volume -o name,origin -r tank | grep 'tank/app@pre-change-001'
tank/app-clone-dev  tank/app@pre-change-001

Інтерпретація: Простий grep працює, але для великих господарств вам знадобляться скриптові запити з zfs get -H.

Завдання 6: Квантифікувати «що насправді використовує простір» через розкладку used

cr0x@server:~$ zfs list -o name,used,usedbysnapshots,usedbychildren,usedbydataset -r tank/app | head
NAME          USED  USEDBYSNAPSHOTS  USEDBYCHILDREN  USEDBYDATASET
tank/app      12.3G 2.4G             3.1G            6.8G

Інтерпретація: Якщо usedbysnapshots велике, видалення снапшотів допомогло б — якщо тільки клони їм не перешкоджають. Якщо usedbychildren велике, клони (або інші дочірні датасети) споживають простір.

Завдання 7: Перевірити стан пула і запас вільного місця (бо CoW потребує голівки)

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0

errors: No known data errors
cr0x@server:~$ zpool list tank
NAME  SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank  7.25T  6.68T   576G        -         -    41%    92%  1.00x  ONLINE  -

Інтерпретація: 92% заповнення — це зона небезпеки для CoW файлових систем. Середовища з багатьма клонами можуть дрейфувати сюди, бо «ми нічого не копіювали» переростає в «ми записали багато різних даних».

Завдання 8: Ідентифікувати родовід клонів і підготуватися до промоції

cr0x@server:~$ zfs get -r -o name,property,value origin tank/app tank/app-clone-dev
NAME              PROPERTY  VALUE
tank/app           origin    -
tank/app@pre-change-001  origin    -
tank/app-clone-dev  origin    tank/app@pre-change-001

Інтерпретація: Тільки клони мають властивість origin. Снапшоти — ні.

Завдання 9: Акуратно промотуйте клон, щоб розірвати залежність

cr0x@server:~$ zfs promote tank/app-clone-dev
cr0x@server:~$ zfs get origin tank/app-clone-dev tank/app
NAME              PROPERTY  VALUE                   SOURCE
tank/app-clone-dev  origin    -                       -
tank/app            origin    tank/app-clone-dev@pre-change-001  -

Інтерпретація: Після промоції клон стає «основною» лінією; оригінальний датасет може стати клоном залежно від графа снапшотів. Це правильна поведінка, але саме тому промоції повинні відслідковуватися в change management.

Завдання 10: Видалити старий снапшот після промоції (якщо доречно)

cr0x@server:~$ zfs destroy tank/app@pre-change-001
cr0x@server:~$ zfs list -t snapshot -r tank/app | grep pre-change-001
cr0x@server:~$ echo $?
1

Інтерпретація: Снапшот зник. Простір буде звільнено тільки якщо немає інших посилань на ті блоки.

Завдання 11: Створити клон zvol для робочого процесу дисків ВМ

cr0x@server:~$ zfs create -V 80G -o volblocksize=16K tank/vm/golden
cr0x@server:~$ zfs snapshot tank/vm/golden@v1
cr0x@server:~$ zfs clone tank/vm/golden@v1 tank/vm/vm-123-disk0
cr0x@server:~$ ls -l /dev/zvol/tank/vm/vm-123-disk0
brw-rw---- 1 root disk 230, 128 Dec 25 09:33 /dev/zvol/tank/vm/vm-123-disk0

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

Завдання 12: Перевірити стискування та логічний vs фізичний простір

cr0x@server:~$ zfs get compressratio,logicalused,used tank/app-clone-dev
NAME              PROPERTY       VALUE  SOURCE
tank/app-clone-dev  compressratio  1.45x  -
tank/app-clone-dev  logicalused    14.9G  -
tank/app-clone-dev  used           3.1G   -

Інтерпретація: logicalused відображає незжатий логічний розмір; used — фізичний простір, зайнятий цим датасетом і його нащадками. У випадку клонів «used» — не означає «унікально спожитий».

Завдання 13: Показати унікальне vs спільне використання для датасету (швидка оцінка)

cr0x@server:~$ zfs list -o name,used,refer,logicalrefer tank/app tank/app-clone-dev
NAME              USED  REFER  LOGICALREFER
tank/app          12.3G  9.8G   13.9G
tank/app-clone-dev 3.1G  11.0G  15.1G

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

Завдання 14: Використовувати holds, щоб навмисно закріпити снапшот (контрольована залежність)

cr0x@server:~$ zfs snapshot tank/app@forensics-keep
cr0x@server:~$ zfs hold case-INC123 tank/app@forensics-keep
cr0x@server:~$ zfs destroy tank/app@forensics-keep
cannot destroy 'tank/app@forensics-keep': snapshot is held
cr0x@server:~$ zfs holds tank/app@forensics-keep
NAME                  TAG           TIMESTAMP
tank/app@forensics-keep  case-INC123  Thu Dec 25 09:41 2025

Інтерпретація: Holds — це свідомий спосіб заборонити видалення. Порівняно з залежностями клонів, holds явні й їх легко аудитувати.

Завдання 15: Зняти hold і знищити снапшот

cr0x@server:~$ zfs release case-INC123 tank/app@forensics-keep
cr0x@server:~$ zfs destroy tank/app@forensics-keep

Інтерпретація: Це шлях прибирання, який ви хочете: явний контроль життєвого циклу.

Завдання 16: Реплікаційна перевірка: перелічити снапшоти для відправки

cr0x@server:~$ zfs list -t snapshot -o name -s creation -r tank/app | tail -n 5
tank/app@daily-2025-12-21
tank/app@daily-2025-12-22
tank/app@pre-change-001
tank/app@daily-2025-12-23
tank/app@daily-2025-12-24

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

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

Це план «повільно і пул заповнюється» для інженерів на виклику. Не ідеальний, але він ставить правильні питання в правильному порядку.

1) Спочатку: підтвердіть, що це не питання здоров’я пула або різкого браку місця

cr0x@server:~$ zpool status -x
all pools are healthy
cr0x@server:~$ zpool list -o name,size,alloc,free,cap,frag,health
NAME  SIZE  ALLOC  FREE  CAP  FRAG  HEALTH
tank  7.25T 6.68T 576G   92%  41%   ONLINE

Інтерпретація: Якщо CAP вище ~85–90%, очікуйте фрагментацію і CoW-накладні витрати, що посилять латентність. Середовища з багатьма клонами частіше дрейфують сюди, бо вони заохочують «швидке провізування» без того самого фокусу на «швидке прибирання».

2) Друге: знайти, що фіксує снапшоти і блокує видалення

cr0x@server:~$ zfs list -t snapshot -o name,used,refer -r tank/app | head
NAME                     USED  REFER
tank/app@daily-2025-12-10 0B   8.9G
tank/app@daily-2025-12-11 0B   9.0G
cr0x@server:~$ zfs destroy tank/app@daily-2025-12-10
cannot destroy snapshot tank/app@daily-2025-12-10: snapshot has dependent clones

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

3) Третє: виміряти, куди йде простір (датасет проти снапшотів проти нащадків)

cr0x@server:~$ zfs list -o name,used,usedbydataset,usedbysnapshots,usedbychildren -r tank/app
NAME      USED  USEDBYDATASET  USEDBYSNAPSHOTS  USEDBYCHILDREN
tank/app  12.3G 6.8G           2.4G             3.1G

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

4) Четверте: ідентифікувати, які клони «активні», а які покинуті

cr0x@server:~$ zfs list -t filesystem,volume -o name,origin,used,creation -r tank | grep -v 'origin\s*-' | head
tank/app-clone-qa     tank/app@daily-2025-12-21  3.1G  Mon Dec 22 02:10 2025
tank/vm/vm-123-disk0  tank/vm/golden@v1          9.4G  Thu Dec 25 09:33 2025

Інтерпретація: Швидко складіть список «хто володіє цим». Якщо у вас немає метаданих про власника, ви робите археологію під тиском.

5) П’яте: якщо симптом — продуктивність, перевірте I/O та тиск TXG

cr0x@server:~$ zpool iostat -v tank 1 5
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        6.68T   576G    820   2400   65.2M  210M
  mirror-0                  6.68T   576G    820   2400   65.2M  210M
    sda                         -      -    410   1200   32.6M  105M
    sdb                         -      -    410   1200   32.6M  105M
--------------------------  -----  -----  -----  -----  -----  -----

Інтерпретація: Клони самі по собі не роблять I/O повільним, але середовища з багатьма клонами часто означають більше снапшотів, більше метаданих і більше випадкових записів (особливо з zvol для ВМ). Якщо пул майже повний, те саме навантаження працюватиме повільніше.

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

Помилка 1: Ставитися до клонів як до незалежних копій

Симптом: Ви видаляєте снапшот і ZFS відмовляється: «snapshot has dependent clones». Або гірше: ви боїтеся видаляти щось, бо «це може зламати клон».

Виправлення: Зробіть інвентар клонів і їхніх оригіналів. Вирішіть, чи клон одноразовий. Якщо так — знищіть його. Якщо ні — розгляньте zfs promote (планово) або міграцію в незалежний датасет (send/receive або повна копія), а потім видаліть залежність.

Помилка 2: Розростання клонів без TTL

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

Виправлення: Впровадьте термін придатності через користувацькі властивості (owner, ticket, expires). Звітуйте про клони щотижня. Автоматично видаляйте прострочені клони після повідомлення відповідального.

Помилка 3: Промоція клона в середині інциденту без розуміння родоводу

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

Виправлення: Перед промоцією: зафіксуйте zfs get origin для всіх задіяних датасетів, документуйте очікувані наслідки й координуйте з власниками реплікації. Після промоції: оновіть операційну документацію і будь-яку автоматизацію, яка припускає ролі датасетів.

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

Симптом: Ви знищуєте снапшоти, а пул залишається повним. Або видаляєте файли, і нічого не змінюється.

Виправлення: Перевірте залежні клони, holds на снапшотах і інші датасети, що посилаються на блоки. Використовуйте usedbysnapshots і usedbychildren, щоб зрозуміти, хто насправді фіксує простір.

Помилка 5: Використовувати клони для довгоживучих баз даних без контролю write amplification

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

Виправлення: Для write-heavy навантажень клони все ще підходять, але ставтеся до них як до реальних датасетів з реальним зростанням. Застосуйте квоти, моніторьте used і запас пула, і періодично оновлюйте клони зі свіжих снапшотів замість того, щоб зберігати їх назавжди.

Помилка 6: Плутати «refer» з «унікальним споживанням простору»

Симптом: Клон показує refer=10T, і хтось панікує, вважаючи, що він займає 10T.

Виправлення: Навчіть команду, що refer — це доступний обсяг, а не унікальне фізичне виділення. Використовуйте розкладку used і загальне виділення пула, щоб оцінити реальний ризик ємності.

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

Чекліст A: Безпечний робочий процес створення клонів у продакшні

1. Створіть іменований снапшот з часовою міткою і метою (наприклад, @template-v3 або @pre-change-INC123).
2. Створіть клон з іменем, що кодує власника/сервіс.
3. Встановіть користувацькі властивості на клоні: owner, ticket, expiry.
4. Застосуйте квоти/резервації там, де потрібно, щоб клони не могли непомітно з’їдати пул.
5. Задокументуйте оригінальний снапшот у тікеті; трактуйте його як залежність, як версію схеми бази даних.

cr0x@server:~$ zfs snapshot tank/app@template-v3
cr0x@server:~$ zfs clone tank/app@template-v3 tank/app-clone-ci-4512
cr0x@server:~$ zfs set org.owner=ci-team tank/app-clone-ci-4512
cr0x@server:~$ zfs set org.ticket=CI-4512 tank/app-clone-ci-4512
cr0x@server:~$ zfs set org.expires=2026-01-05 tank/app-clone-ci-4512
cr0x@server:~$ zfs set quota=200G tank/app-clone-ci-4512

Чекліст B: Безпечне прибирання, коли снапшоти не видаляються

1. Спробуйте знищити снапшот і підтвердіть помилку — залежні клони (а не holds).
2. Перелічіть клони з відповідним origin.
3. Класифікуйте клони: одноразові, збережені, невідомий власник.
4. Для одноразових клонів: знищіть їх першими.
5. Для важливих клонів: вирішіть між промоцією або міграцією в нову лінію.
6. Після видалення залежності: знищіть снапшот, підтвердіть тренд звільнення простору.

cr0x@server:~$ zfs destroy tank/app@daily-2025-12-10
cannot destroy snapshot tank/app@daily-2025-12-10: snapshot has dependent clones
cr0x@server:~$ zfs list -t filesystem,volume -o name,origin -r tank | grep 'tank/app@daily-2025-12-10'
tank/app-clone-sandbox  tank/app@daily-2025-12-10
cr0x@server:~$ zfs get org.owner,org.expires tank/app-clone-sandbox
NAME                 PROPERTY    VALUE        SOURCE
tank/app-clone-sandbox  org.owner   alice        local
tank/app-clone-sandbox  org.expires 2025-12-01  local
cr0x@server:~$ zfs destroy tank/app-clone-sandbox
cr0x@server:~$ zfs destroy tank/app@daily-2025-12-10

Чекліст C: Дерево рішень про промоцію (зробіть це явним)

1. Чи хочете, щоб клон став основною лінією? Якщо так — промоція виправдана.
2. Чи припускає реплікація або автоматизація, що оригінал — основний? Якщо так — спочатку оновіть автоматизацію або оберіть міграцію.
3. Чи потрібно зберегти історію снапшотів на оригіналі? Якщо так — ретельно перегляньте набори снапшотів і протестуйте send/receive у стейджингу.
4. Чи маєте достатньо вільного місця? Промоція — метаданова операція, але прибирання, яке ви намагаєтесь зробити, може потребувати запасу місця щоб завершитися безпечно.

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

1) У чому різниця між снапшотом і клоном у ZFS?

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

2) Чому я не можу видалити снапшот, хоча він мені не потрібен?

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

3) Як знайти, який клон блокує видалення снапшоту?

Перелічіть датасети і томи з властивістю origin і зіставте ім’я снапшоту.

cr0x@server:~$ zfs list -t filesystem,volume -o name,origin -r tank | grep 'tank/app@daily-2025-12-10'

4) Чи споживають клони простір?

Вони споживають простір у міру віддалення від оригінального снапшоту. На початку вони ділять блоки, тому створення дешеве. З часом записи виділяють нові блоки, і ці блоки унікальні для клону (хіба що ще хтось посилається на них).

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

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

6) Чи варто використовувати клони для баз даних?

Часто так для швидких оновлень, але встановіть квоти й моніторте зростання. Бази даних багато пишуть; клон може швидко стати «майже повним розміром» щодо оригіналу в залежності від churn. Перевага — швидкість провізування й зручність відкату, а не гарантована довгострокова економія простору.

7) Що насправді робить zfs promote?

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

8) Чи безпечні клони ZFS у продакшні?

Так — якщо ви управляєте життєвим циклом і залежностями. Ризик не в цілісності даних; ZFS виконує те, що обіцяє. Ризик — операційний: приховане збереження, закріплення простору і несподівані промоції. Ставтеся до клонів як до ресурсів першого класу з власником і терміном дії.

9) Чому видалення файлів не звільнило простір пула?

Тому що видалені блоки все ще посилаються снапшотами і/або клонами. Перевірте usedbysnapshots, залежні клони і holds на снапшотах. Простір звільняється тільки коли зникає останнє посилання.

10) Чи є безпечніша альтернатива клонам для «копіювання» даних?

Якщо вам потрібна незалежна копія без залежностей, робіть повну копію або використовуйте zfs send | zfs receive в окремий датасет/пул. Це не миттєво, але видаляє ланцюжок спільних блоків, який вводять клони.

Висновок

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

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