Незмінні резервні копії ZFS: readonly і політики снапшотів, що справді працюють

Що означає «незмінність» у світі ZFS (і чого вона не означає)

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

У ZFS у вас немає єдиного магічного вимикача незмінності. Є шари:

• Снапшоти дають вам узгодженість у точці часу та дешеве версіонування.
• Readonly датасети зменшують випадкові записи і усувають цілий клас «ой»-ситуацій.
• Holds і делеговані права можуть запобігти видаленню снапшотів звичайними операторами.
• Топології реплікації дозволяють зробити сервер бекапу «буденнішим» (це добре) і зменшити радіус ураження.
• Офлайн або відкладене видалення (часто поза ZFS) — те, що доводить ransomware до відчаю.

Ось чого ZFS-іммутібільність не є:

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

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

Факти й історичний контекст, що формують реальні проєкти резервного копіювання

• ZFS народився в Sun, щоб вбити поділ «менеджер томів + файловa система». Саме тому снапшоти та контрольні суми — першокласні можливості, а не надбудови.
• Copy-on-write — трюк, що все зробив можливим. Снапшоти ZFS дешеві, бо блоки спільні до моменту зміни.
• ZFS контролює контрольні суми даних і метаданих наскрізь. Це зробило проблему «тихої корупції» розв’язною, а не міфом.
• Снапшоти самі по собі — не резервні копії. Вони зберігаються в тому ж пулі. Втрата пулу = втрата снапшотів. Цю відмінність ігнорували з моменту винайдення снапшотів.
• Ранні користувачі ZFS зрозуміли, що «scrub» — це графік, а не емоція. Регулярні scrubs знаходять биті сектори, поки у вас ще є надмірність.
• Інкрементальний send/receive став робочою конячкою DR на ZFS. Це фактично журнал змінених блоків між снапшотами.
• Конвенції іменування снапшотів стали окремою індустрією. Бо коли панікуєш під час інциденту, ти вибереш не той снапшот, якщо ім’я не очевидне.
• «Незмінні резервні копії» стали популярними після еволюції ransomware. Зловмисники навчилися видаляти бекапи першими, потім шифрувати. Оборонці навчилися не робити видалення простим.

Одна перефразована ідея, яку варто мати на стіні: paraphrased idea «Сподівання — не стратегія», приписують Джеймсу Кемерону; її часто повторюють в операційних колах, бо це болюче правда.

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

Найпростіша надійна архітектура асиметрична:

1. Джерело (production): записувані датасети, часті снапшоти, sender для реплікації.
2. Ціль бекапу (vault): отримує снапшоти, зберігає їх readonly, зберігає їх довше і мінімізує коло тих, хто може їх видаляти.
3. Опціональна друга ціль (offsite): отримує від vault або прямо від source залежно від довірчих кордонів.

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

Модель загроз, прямо

• Випадкове видалення: адміністратор знищує снапшоти або датасети, або скрипт очистки йде враз.
• Ransomware з обліковими даними: нападник отримує SSH-ключі, API-токени або доменного адміністратора і цілить у інфраструктуру бекапу.
• Скомпрометований хост бекапу: нападник отримує root на vault і намагається зруйнувати політику зберігання.
• Корупція: погана RAM, помираючі диски, ненадійні HBA або некоректне прошивання — ZFS може виявити це, але тільки якщо ви запускаєте scrub і моніторите.

Ваші захисти повинні відповідати моделі загроз. Readonly захищає від випадкових записів. Holds і делегація захищають від видалення «звичайними» користувачами.
Для «root на vault» потрібна ізоляція (інша доменна аутентифікація, MFA, обмежені ключі), моніторинг і бажано офлайн/офсайтна копія.

Readonly датасети та снапшоти: різниця, що має значення о 2 годині ночі

Readonly dataset означає, що ви не можете змінювати файли в живому поданні файлової системи цього датасету (mountpoint). Це запобіжний захід.
Він відмінно підходить для цілей бекапу: ви отримуєте репліковані снапшоти і потім тримаєте датасет readonly, щоб хтось не «швидко не відредагував конфіг» всередині бекапу.

Снапшоти — це незмінні знімки датасету в певний момент. Але «незмінний» тут означає, що блоки не зміняться; це не означає, що привілейований користувач не може знищити об’єкт снапшота.
Видалення — справжній ворог у сценаріях з ransomware.

Від чого readonly захищає

• Випадкові редагування датасету бекапу цікавими людьми.
• Некоректно налаштовані сервіси, які випадково пишуть у mountpoint бекапу.
• Деякі класи шкідливого ПО, що просто шифрують змонтовані записувані файлові системи.

Від чого readonly не захищає

• zfs destroy снапшотів/датасетів користувачем з привілеями ZFS.
• Знищення пула (zpool destroy), вилучення пристроїв або саботаж імпортованості.
• Потоки реплікації, що перезаписують ваші очікування (наприклад, forced receive, що робить rollback).

Якщо запам’ятати одне: readonly — для записів; holds/делегація — для видалень.

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

Політика снапшотів, яка не гниє: іменування, каденція, збереження

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

Конвенція іменування: оберіть одну і не імпровізуйте

Використовуйте префікс, який кодує «керується політикою», і часову мітку, що сортується лексикографічно. Приклад:
auto-YYYYMMDD-HHMM для частих снапшотів і daily-YYYYMMDD для довшого зберігання.

Ви можете тримати кілька рівнів у тому ж датасеті, якщо ваш інструмент зберігання це розуміє. Якщо робите вручну — спростіть:
hourly протягом 48 годин, daily протягом 30 днів, weekly протягом 12 тижнів, monthly протягом 12 місяців. Налаштуйте під RPO/RTO і реальність ємності.

Каденція: співпадайте з бізнес-ритмами, а не з власними вподобаннями

• Бази даних: часті снапшоти важливі, але узгодженість важливіша. Координуйте з пріоритетами додатків або використовуйте репліки.
• Домашні каталоги: hourly часто достатньо. Люди видаляють файли вдень; вам потрібні легкі відкатні точки.
• VM-образи: робіть снапшоти біля вікон змін і перед патчингом. Також — досить часто, щоб покривати «ой, ми оновили не те».

Retention: те, що ви зберігаєте, — те, що можна відновити

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

Не плутайте кількість снапшотів із безпекою

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

Запобігання видаленню: holds, делегація прав і радіус ураження адміністраторів

Якщо ваша загроза бекапу включає ransomware, треба припустити, що нападник спробує видалити снапшоти. Вам потрібне принаймні одне з: holds,
делегування прав, що забороняє знищення снапшотів звичайним операторам, або окрема система, що примусово реалізує політику зберігання поза ZFS.
Ідеально: усе перераховане шарами.

Holds в ZFS: недооцінений ремінь безпеки

Hold запобігає знищенню снапшота, поки hold не знято. Це не «абсолютна незмінність», але сильний захист від випадкового видалення й від нападників, які не мають відповідного набору привілеїв (або не помічають holds).

Holds зручні в операціях, бо вони явні й інспектовані. Можна маркувати holds іменами, наприклад policy або vault.
Використовуйте їх на стороні vault, щоб примусово дотримувати вікна збереження.

Делегація: менше людей повинні мати можливість знищувати бекапи

Багато організацій запускають ціль бекапу з тією ж групою адміністраторів, що й продакшн. Зручно. Але саме так нападник отримує дві цілі водночас.
Розділіть ролі:

• Користувач реплікації може receive, але не може знищувати старі снапшоти.
• Оператори бекапу можуть перелічувати й відновлювати, але видалення снапшотів під контролем.
• Роль break-glass може знімати holds, із MFA та аудитом.

Readonly на vault все ще корисний

Навіть з holds встановіть отриманий датасет у readonly. Більшість ransomware і випадкових помилок банальні: вони шифрують файли, до яких можуть записуватися.
Ускладніть запис — і ви зменшите кількість постраждалих.

Реплікація правильно: send/receive шаблони і режими відмов

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

Шаблон A: Джерело знімає снапшоти, vault отримує (рекомендований за замовчуванням)

Джерело робить снапшоти за розкладом. Vault тягне або джерело штовхає їх. Vault зберігає снапшоти довше, ніж джерело.
Датасет vault — readonly і захищений від видалення. Це стандарт, і він працює.

Шаблон B: Vault робить снапшоти отриманого датасету (корисно для «історії на боці vault»)

Іноді хочете, щоб vault робив свої власні снапшоти (наприклад «daily-cold») незалежно від дій джерела.
Це нормально, але ускладнює відновлення: тепер у вас дві простори імен снапшотів, і треба точно знати, що ви відправляєте й що тримаєте.

Режим відмови: forced receives і неочікувані rollbacks

Інструменти реплікації іноді використовують прапорці, які можуть відкотити ціль, щоб вона відповідала потоку від джерела. Це може видалити нові цільові снапшоти
або знищити локальну історію vault, якщо працювати необережно. Ваш vault має бути простим: в основному receive, retain і служити відновленням.
Уникайте «хитрих» двонаправлених схем, якщо вони вам справді не потрібні.

Режим відмови: інкрементальний ланцюг пошкоджено

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

Жарт №2: Інкрементальна реплікація — як офісні плітки: видали один ключовий факт — і всі з нуля починають розповідь заново.

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

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

Завдання 1: Підтвердити readonly датасет на vault

cr0x@server:~$ zfs get -H -o property,value readonly vault/backups/prod
readonly	on

Значення: Живий mount датасету не записується.
Рішення: Якщо воно off, встановіть зараз на датасеті vault (не на продакшн-датасетах, які додатки мають писати).

Завдання 2: Примусити readonly (сторона vault)

cr0x@server:~$ sudo zfs set readonly=on vault/backups/prod
cr0x@server:~$ zfs get -H readonly vault/backups/prod
readonly	on

Значення: Нові записи через mountpoint блокуються.
Рішення: Якщо якийсь процес потребує доступу на запис, він не має використовувати датасет vault. Виправте робочий процес, а не прапорець.

Завдання 3: Переглянути снапшоти з часом створення, щоб перевірити каденцію

cr0x@server:~$ zfs list -t snapshot -o name,creation -s creation -r tank/prod | tail -5
tank/prod@auto-20251226-0100  Fri Dec 26 01:00 2025
tank/prod@auto-20251226-0200  Fri Dec 26 02:00 2025
tank/prod@auto-20251226-0300  Fri Dec 26 03:00 2025
tank/prod@auto-20251226-0400  Fri Dec 26 04:00 2025
tank/prod@auto-20251226-0500  Fri Dec 26 05:00 2025

Значення: Каденція снапшотів стала послідовною; імена сортуються за часом.
Рішення: Якщо є прогалини — перевірте cron/systemd таймери, логи інструменту снапшотів і стан пулу (невдалі снапшоти можуть бути симптомом).

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

cr0x@server:~$ zfs list -t snapshot -o name,used,refer -s used -r tank/prod | head -5
NAME                         USED  REFER
tank/prod@auto-20251220-0100  48G   1.2T
tank/prod@auto-20251218-0300  41G   1.2T
tank/prod@auto-20251222-0900  39G   1.2T
tank/prod@auto-20251224-1800  35G   1.2T

Значення: Деякі снапшоти прив’язують великі обсяги старих блоків (великий USED).
Рішення: Великі USED снапшоти часто — «перед масовою перезаписом». Зберігайте їх, якщо вони в політиці; інакше обрізайте за рівнями, а не на емоціях.

Завдання 5: Перевірити holds на снапшотах vault

cr0x@server:~$ zfs holds vault/backups/prod@daily-20251201
NAME                               TAG     TIMESTAMP
vault/backups/prod@daily-20251201   policy  Fri Dec  1 00:05 2025

Значення: Hold з ім’ям policy запобігає видаленню.
Рішення: Якщо немає holds і ви покладаєтесь на них для незмінності — додайте їх систематично (краще через автоматизацію).

Завдання 6: Застосувати hold до снапшота, який не можна втратити

cr0x@server:~$ sudo zfs hold policy vault/backups/prod@daily-20251201
cr0x@server:~$ zfs holds vault/backups/prod@daily-20251201
NAME                               TAG     TIMESTAMP
vault/backups/prod@daily-20251201   policy  Fri Dec 26 05:40 2025

Значення: Снапшот тепер захищено від zfs destroy доти, доки hold не знято.
Рішення: Використовуйте holds для рівнів збереження, юридичних утримань або заморожень під час інцидентів. Документуйте, хто може їх знімати.

Завдання 7: Доведіть, що снапшот не можна знищити через holds

cr0x@server:~$ sudo zfs destroy vault/backups/prod@daily-20251201
cannot destroy snapshot vault/backups/prod@daily-20251201: snapshot has holds

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

Завдання 8: Перевірити, хто може знищувати снапшоти (делегація)

cr0x@server:~$ sudo zfs allow vault/backups/prod
---- Permissions on vault/backups/prod --------------------------------
Local+Descendent permissions:
user repl-user create,mount,receive
user backup-ops mount,snapshot,send
user breakglass destroy,hold,release

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

Завдання 9: Перевірити стан пулу (бо реплікація не виправить биті диски)

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

Значення: Наразі явних проблем немає.
Рішення: Якщо бачите degraded/faulted пристрої — спочатку ремонтуйте апаратне забезпечення. Бекапи на хворому пулі — це просто повільна доставка корупції.

Завдання 10: Перевірити недавні результати scrub

cr0x@server:~$ zpool status vault
  pool: vault
 state: ONLINE
  scan: scrub repaired 0B in 03:12:44 with 0 errors on Sun Dec 22 03:30:12 2025
config:

        NAME        STATE     READ WRITE CKSUM
        vault       ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Значення: Scrub пройшов, нічого не відремонтовано, не знайдено помилок контрольних сум.
Рішення: Якщо scrubs не заплановано — заплануйте. Якщо scrub повторно знаходить помилки — дослідіть диски, кабелі та RAM.

Завдання 11: Підтвердити, що реплікаційні снапшоти існують на обох сторонах

cr0x@server:~$ zfs list -t snapshot -o name -r tank/prod | grep auto-20251226-0500
tank/prod@auto-20251226-0500
cr0x@server:~$ zfs list -t snapshot -o name -r vault/backups/prod | grep auto-20251226-0500
vault/backups/prod@auto-20251226-0500

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

Завдання 12: Запустити інкрементальний send/receive (ручний, явний)

cr0x@server:~$ sudo zfs send -I tank/prod@auto-20251226-0400 tank/prod@auto-20251226-0500 | ssh backup-vault sudo zfs receive -u -F vault/backups/prod
cr0x@server:~$ ssh backup-vault zfs list -t snapshot -o name -r vault/backups/prod | tail -2
vault/backups/prod@auto-20251226-0400
vault/backups/prod@auto-20251226-0500

Значення: Інкрементальна реплікація вдалася; vault має новий снапшот. Прапорці важливі:
-u отримує без монтування; -F може зробити rollback — використовуйте лише коли повністю розумієте наслідки на цілі.
Рішення: Якщо вам регулярно потрібен -F, у вас ймовірно проблема з гігієною ланцюжків снапшотів. Виправте видалення снапшотів і іменування.

Завдання 13: Виміряти пропускну здатність реплікації й побачити виграші від стиснення

cr0x@server:~$ sudo zfs send -nvP tank/prod@auto-20251226-0500 2>&1 | tail -3
send from @auto-20251226-0400 to tank/prod@auto-20251226-0500 estimated size is 17.2G
total estimated size is 17.2G
time        sent   snapshot

Значення: Оцінка dry-run показує, наскільки великий інкремент.
Рішення: Якщо оцінки постійно величезні, робоче навантаження інтенсивно перезаписуване. Жодне налаштування не перетворить «17G на годину» в «200M на годину».
Налаштовуйте частоту снапшотів, виключайте швидко мінливі датасети або приймайте реальність мережі/ємності.

Завдання 14: Виявити «снапшоти, що прив’язують простір», які спричинюють мало вільного місця

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint vault/backups/prod
NAME               USED  AVAIL  REFER  MOUNTPOINT
vault/backups/prod  38T   1.2T  1.4T   /vault/backups/prod

Значення: Датасет майже заповнений (AVAIL малий). Продуктивність і виділення можуть страждати.
Рішення: Не «вирішуйте» це видаленням випадкових снапшотів. Застосуйте політику зберігання, додайте ємності або перемістіть довготривалі рівні в інший пул.

Завдання 15: Перевірити неприємні reservation і refreservation

cr0x@server:~$ zfs get -H -o property,value reservation,refreservation vault/backups/prod
reservation	none
refreservation	none

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

Завдання 16: Підтвердити, що ви справді можете відновити (клонування снапшота)

cr0x@server:~$ sudo zfs clone vault/backups/prod@auto-20251226-0500 vault/restore/prod-test
cr0x@server:~$ zfs list -o name,mountpoint,readonly vault/restore/prod-test
NAME                    MOUNTPOINT              READONLY
vault/restore/prod-test  /vault/restore/prod-test  off

Значення: Ви можете матеріалізувати точку в часі для тестування відновлення. Клони за замовчуванням записувані.
Рішення: Робочі процеси відновлення повинні працювати на клонax, а не на незмінному датасеті. Тримайте датасет vault readonly; робіть відновлення окремо.

Хвора діагностика: знайдіть вузьке місце спочатку, не в кінці

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

Перш за все: чи пул здоровий і не вмирає?

• Запустіть zpool status. Якщо є READ/WRITE/CKSUM помилки — це інцидент надійності, а не питання налаштувань.
• Перевірте, чи запущений scrub. Scrub + реплікація можуть навантажити I/O на малих пулах.

Друге: чи є приховане обмеження в ємності?

• Перевірте zfs list і вільне місце пула. Дуже заповнені пули фрагментуються і уповільнюють роботу, а видалення снапшотів може стати «єдиним вирішенням», до якого звертаються люди.
• Подивіться, які снапшоти тримають місце (zfs list -t snapshot -o used).

Третє: чи реплікація блокується станом ланцюжка снапшотів?

• Підтвердіть, що базові снапшоти є на обох сторонах.
• Шукайте помилки «cannot receive incremental stream» у логах завдань; зазвичай це означає відсутні снапшоти або розбіжну історію.

Четверте: чи це I/O, CPU або мережа?

• Якщо оцінки send великі — навантаження на перезаписи високе. Жодна оптимізація не зробить «17G» малим.
• Якщо ви шифруєте або стиснюєте потік — CPU може бути вузьким місцем. Профілюйте перед зміною налаштувань.
• Якщо vault на повільніших дисках, ніж продакшн (часто), receives будуть відставати. Це не баг; це архітектура, що просить терпіння.

П’яте: чи ви самі стріляєте собі у властивості?

• Перевірте sync, recordsize і compression на датасетах vault. Не копіюйте сліпо production-настройки на бекапи.
• Будьте обережні з atime на датасетах бекапу; він може створювати марні записи метаданих, якщо щось сканує дерево.

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

Помилка 1: «Readonly означає незмінність»

Симптоми: Снапшоти зникають під час інциденту; датасет досі readonly.

Корінна причина: Хтось з привілеями ZFS знищив снапшоти/датасети; readonly цього не зупиняє.

Виправлення: Використовуйте holds для рівнів збереження, приберіть destroy із ролей реплікації/операторів і ізолюйте адміністративні межі vault.

Помилка 2: Реплікація «успішна», але відновлення втрачає дані

Симптоми: На таргеті є снапшоти, але дані додатка непослідовні або відсутні очікувані файли.

Корінна причина: Часування снапшотів не узгоджене з консистентністю додатка, або ви реплікували невірне піддерево датасетів.

Виправлення: Знімайте снапшоти у правильних датасетах, координуйте з quiesce на рівні додатка за потреби, валідируйте відновлення автоматично й тримайте тестовий датасет для відновлень.

Помилка 3: Повні повторні відправлення щотижня

Симптоми: Інкрементальний receive падає; завдання повертаються до full send; мережа перевантажується.

Корінна причина: Базовий снапшот видалено на одній із сторін або таргет розійшовся через локальні снапшоти/зміни і примусові відкатні дії.

Виправлення: Захистіть базові снапшоти через holds, стандартизуйте іменування, уникайте локальних записів на отриманому датасеті і перестаньте використовувати -F як спосіб життя.

Помилка 4: Пул досягає 95% і все стає «повільним ZFS»

Симптоми: Реплікація відстає, висока затримка, випадкові ENOSPC, видалення снапшотів триває вічно.

Корінна причина: Ігноровано планування ємності для росту снапшотів; ретеншен занадто агресивний для пулу.

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

Помилка 5: Датасет бекапу змонтований і просканований антивірусом/індексаторами

Симптоми: Неочікуваний метаданний I/O, receives уповільнюються, навантаження хоста бекапу стрибає.

Корінна причина: Датасети vault змонтовані й поводяться як живі файлові системи; сканери чіпають усе підряд.

Виправлення: Receive з -u, тримайте датасети vault не змонтованими за замовчуванням, монтуйте лише для відновлень і ізолюйте клоновані відновлювальні середовища.

Помилка 6: Holds є, але ретеншен не працює

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

Корінна причина: Holds застосовані без життєвого циклу; немає автоматичного зняття після закінчення вікна збереження.

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

Помилка 7: «Ми реплікували, отже в безпеці»

Симптоми: І джерело, і vault містять зашифровані/пошкоджені дані після компрометації.

Корінна причина: Реплікація вірно скопіювала погані зміни швидко; немає затримки, детекції або офлайн-рівня.

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

Три корпоративні міні-історії з полі боїв резервного копіювання

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

Середньорозмірний SaaS запустив ZFS і на продакшн, і на сервері бекапу. Датасети бекапу були встановлені readonly=on, і всі були впевнені.
Вони навіть мали слайд у квартальному ризик-огляді: «незмінні резервні копії ввімкнено».

Потім було скомпрометовано привілейоване облікове. Нападник не став шифрувати датасет vault. Він просто видалив снапшоти, бо видалити швидше, ніж шифрувати.
Продакшн потім теж постраждав, і команда виявила, що їхнє вікно збереження тепер «з моменту прибуття нападника».

Післямортем був корисний: ніхто не брехав, але кілька людей визнали, що припускали — readonly означає незмінність.
Так не є. ZFS точний; люди — ні.

Виправлення було також точним: holds на снапшоти vault по рівнях ретеншену, делеговані права, щоб реплікаційні користувачі не могли нічого знищити,
і окремий break-glass обліковий запис з аудитом і MFA. Також вирішили, що хости бекапу не приєднуються до того самого доменного простору, що продакшн.

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

Велика команда підприємства була під тиском зменшити витрати на сховище. Вони різко скоротили ретеншен на vault і ввімкнули скрипт
«cleanup», що видаляв снапшоти за кількістю, а не за віком. Скрипт був швидкий і графіки виглядали добре. Та недовго.

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

Цікаво: ZFS не винен. Їхня оптимізація знищила єдине, що могло врятувати від тихого збою — час.
Ransomware голосне. Корупція й погана логіка тихі.

Вони відкотили зміну ретеншену, але не до старих чисел. Зробили зріле рішення: шарова політика з невеликою кількістю довготривалих «gold» снапшотів, що тримаються через holds,
плюс періодичне тестове відновлення. Витрати на сховище трохи зросли. Впевненість у відновленні зросла значно.

3) Нудна, але правильна практика, що врятувала день: регулярні тренування з відновлення

Фінансова команда щотижня проводила тренування з відновлення. Щоп’ятниці хтось клонував снапшот з vault у restore sandbox і запускав набір перевірок:
кількість файлів, sanity на рівні додатка і швидкий integrity read на кількох репрезентативних файлах.

Це було не гламурно. Люди скаржилися, що це займає час. Керівництво все одно фінансувало це, бо створювалося просте артефакт: тікет «відновлення протестовано з снапшота X».
Той тікет був нудним, але повторюваним доказом.

Коли їх вразили крадійством облікових даних, нападник спробував видалити снапшоти і натрапив на holds. Потім спробував змінити змонтований датасет і натрапив на readonly.
Тим часом команда вже знала, який снапшот відновлювати, бо тестували його недавно. Вони відновили чисто і пішли далі.

Урок не в «кращій техніці». Урок у тому, що вони виконували нудну роботу. В операціях нудна робота — це те, що купує вам сон.

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

Крок за кроком: побудуйте «майже незмінний» ZFS vault з розумними налаштуваннями

1. Визначте датасети та межі.
   Продакшн-датасети записувані; vault-датиасети — receive-only і readonly.
2. Реалізуйте каденцію снапшотів на source.
   Тримайте імена консистентними. Забезпечте, щоб снапшоти покривали ваш RPO.
3. Реплікуйте на vault.
   Віддавайте перевагу явній реплікації на основі снапшотів. Уникайте робочих схем, що вимагають частого використання -F.
4. Встановіть vault датасети readonly і бажано не змонтованими за замовчуванням.
   Монтуйте клоновані відновлення.
5. Накладайте holds на снапшоти vault за рівнями ретеншену.
   Використовуйте тег на кшталт policy, щоб це було доступно для пошуку і послідовно.
6. Делегуйте права ZFS.
   Обліковий запис реплікації: receive, не destroy. Оператори: дії відновлення, не перезаписування політики ретеншену.
7. Заплануйте scrubs і моніторинг помилок.
   Scrub націлений на виявлення латентних помилок перед тим, як вони стануть відсутніми блоками під час відновлення.
8. Плануйте ємність з запасом.
   Не тримайте vault пул практично наповненим. Ретеншен снапшотів потребує резерву місця.
9. Регулярно тестуйте відновлення.
   Клонувати снапшот, змонтувати, провалідувати і записати результат.
10. Практикуйте break-glass.
    Визначте, хто може знімати holds, як це аудитується і як уникнути культури «всі — root» на vault.

Операційний чекліст: перед тим як заявити «незмінні резервні копії»

• Чи може акаунт без breakglass знищити снапшоти vault? Якщо так — ви не незмінні.
• Чи застосовані і видимі holds? Якщо ні — ви покладаєтесь на людей у стресі.
• Чи змонтовано і деінде записується vault? Якщо так — очікуйте, що шифрування вдасться.
• Чи маєте принаймні одну копію поза головним доменом довіри? Якщо ні — ви в одному скомпрометованому доменному адміністраторі від проблем.
• Чи відновлювали з vault за останні 30 днів? Якщо ні — у вас вірування, а не бекапи.

FAQ

Чи дійсно снапшот ZFS незмінний?

Його вміст незмінний (copy-on-write), але об’єкт снапшота може бути знищений кимось із потрібними привілеями.
Якщо потрібне «не можна видалити» — використовуйте holds і обмежте destroy.

Чи зупиняє readonly=on ransomware?

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

Де краще брати снапшоти — на vault чи на source?

За замовчуванням — робіть снапшоти на source і тримайте ретеншен на vault. Снапшоти на стороні vault корисні для додаткових рівнів, але додають складності і можуть заплутати відновлення.

Який найнадійніший спосіб відновлювати без ослаблення незмінності?

Клонуйте снапшот у окремий датасет для відновлення і змонтуйте його. Тримайте отриманий датасет vault readonly і бажано не змонтованим.

Як holds взаємодіють з політиками збереження?

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

Чи можна обмежити користувачів реплікації лише receive?

Так. Використовуйте zfs allow для делегування лише необхідного (зазвичай receive, можливо create), і уникайте надання destroy.
Потім перевіряйте це за допомогою zfs allow.

Чому інкрементальна реплікація іноді вимагає повного повторного відправлення?

Інкрементальні потоки вимагають спільного базового снапшота. Якщо базовий снапшот відсутній на одній із сторін — або історія на цілі розійшлася — інкрементальний receive падає і потрібен full send.
Захищайте базові снапшоти і припиніть видаляти снапшоти ad hoc.

Скільки снапшотів — «занадто багато»?

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

Який найкращий індикатор, що мій vault нездоровий?

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

Чи потрібен офсайт, якщо мій vault «незмінний»?

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

Висновок: наступні кроки, які ви можете зробити цього тижня

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

1. На vault встановіть отримані датасети readonly=on і отримуйте з -u, щоб вони випадково не монтувалися.
2. Реалізуйте holds для снапшотів у вашому вікні ретеншену і доведіть, що не можна знищити захищені снапшоти.
3. Приберіть destroy у акаунтів реплікації й операторів; залиште його для break-glass ролі з аудитом.
4. Проведіть тренування з відновлення: клонувати снапшот, змонтувати і валідовано щось значуще (не лише «монтується»).
5. Перевірте стан пулу і розклад scrub на source і vault. Якщо цілісність нестабільна — незмінність стає академічною.

Виконайте ці п’ять кроків, і ваша позиція з бекапів зміниться з «надій і скриншотів» на «вимірну і придатну для виживання». Оце й є суть.