ZFS проти btrfs: знімки, RAID, відновлення — що болить менше?

January 11, 2026 • February 3, 2026 • Читання: 7 хв • Views: 8

Було корисно?

Є такий тип виклику опівночі, що вчить вас про файлові системи більше, ніж будь-який бенчмарк: «стрибки затримки зберігання», «VM зависають», «вікно бекапу пропущене» і тихий жах, що ваші знімки перетворилися на звалище. ZFS і btrfs обіцяють сучасні можливості файлової системи — copy-on-write, знімки, контрольні суми, самовідновлення. На практиці це виглядає як дві різні філософії управління болем.

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

Теза: що болить менше?

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

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

Мій продакшн-упереджений погляд, здобутий непростим шляхом: ZFS для серйозної багатодискової надлишковості та довготривалих датасетів. btrfs для кореневих файлових систем, знімків ОС на робочих станціях/серверах і простіших дзеркальних конфігурацій, де інтеграція з ядром і зручність інструментів важать більше, ніж максимальна RAID-складність.

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

Цікаві факти та історичний контекст (те, що люди забувають)

ZFS виникла в Sun Microsystems як кінцевий стек зберігання: файловa система + менеджер томів + RAID + контрольні суми, спроектована, щоб усунути «мовчазну корупцію» та операційні здогадки.
btrfs почалася в Oracle як Linux-нативна CoW-файлова система зі знімками і контрольними сумами, мета — конкурувати із ZFS-подібними можливостями, живучи в ядрі.
RAIDZ у ZFS — це не класичний RAID-5/6; він спроектований уникати «write hole» завдяки copy-on-write і групам транзакцій, зменшуючи клас часткової корупції смуг.
Рання репутація btrfs формувалася проблемами RAID5/6. Багато команд болісно вивчили, що паритетний RAID btrfs слід трактувати з обережністю.
Обидві системи контролюють контрольні суми, але ZFS трактує цілісність як основну обіцянку, тоді як btrfs надає цілісність у межах Linux-файлової системи, яка також має уживатися з ширшим екосистемою ядра.
Scrub — це не резервне копіювання. І ZFS scrub, і btrfs scrub — це процеси перевірки цілісності; вони можуть відновлювати лише якщо є надлишкові добрі дані.
ZFS send/receive став шаблоном для дешевої, швидкої реплікації на рівні блоків/записів. btrfs send/receive теж існує і гарний — коли ваша дисципліна по субволюмах/знімках чиста.
Компресія стала мейнстрімом завдяки CoW. ZFS популяризувала «увімкніть — часто швидше»; btrfs зробила компресію доступною і нативною в ядрі з контролем по субволюмах.
«Знімки» — це хитрощі з метаданими, а не магічні додаткові диски. Обидві системи можуть створювати знімки миттєво, але довге зберігання без прибирання перетворюється на операційний борг з відсотками.

Ментальні моделі: у що вірить кожна ФС

ZFS: система зберігання, яка хоче вирішувати всю проблему

ZFS не хоче бути «файловою системою поверх чужого RAID». Вона хоче бути файловою системою, RAID і менеджером томів і шаром цілісності водночас. Тому пула ZFS («zpool») складається з vdev, і ці vdev визначають надлишковість. Файлова система («dataset») лежить зверху і успадковує властивості. Коли ви усвідомите це, ZFS перестає виглядати дивно і починає поводитися як дуже суворий дорослий.

У світі ZFS основна одиниця ризику — це vdev. Втратите vdev — втратите пул. Ви не «додаєте диски до RAIDZ пізніше» без планування. Ви проектуєте ширину vdev і надлишковість на етапі створення (або приймаєте обмеження розширення у вашій версії та операційні обмеження). ZFS винагороджує терпіння і карає імпровізацію.

btrfs: Linux-нативна ФС, що прагне гнучкості

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

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

Знімки та клонування: сила і підводні камені

Як знімки поводяться насправді

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

ZFS знімки: операційно передбачувані

ZFS знімки стабільні, широко використовуються і інтегровані з робочими процесами реплікації. Клони — це знімки, до яких можна писати. ZFS також дає чисті примітиви як holds (щоб заборонити видалення), властивості датасету для рекурсії і потоки send/receive, які добре зрозумілі.

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

btrfs знімки: фантастичні для ОС та дисципліни субволюмів

btrfs знімки сяють, коли ви розглядаєте субволюми як межі: @ для root, @home, можливо @var або @docker, і знімаєте тільки ті, які хочете відкотити. Тут btrfs відчувається як шахрайство: миттєвий знімок, швидкий відкат, легке експериментування.

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

RAID: що вбудовано, що мається на увазі, що ризиковано

ZFS RAID: дзеркала та RAIDZ по-ZFS

Надлишковість ZFS визначається на рівні vdev: mirrors, RAIDZ1/2/3. Додавайте vdev для розширення. Замінюйте диски для відновлення. Scrub для перевірки. Resilver для реконструкції. Це не «встановив і забув», але воно послідовне.

Ключова операційна істина: IOPS здебільшого залежать від кількості vdev, особливо в дзеркалах. Один широкий RAIDZ vdev може давати вражаючу послідовну пропускну здатність і все одно відчуватися повільним для випадкових IO у порівнянні з кількома mirror vdev. Файлова система не повільна; це геометрія.

btrfs RAID: профілі, а не класичні масиви

btrfs говорить про профілі: профіль даних (single, DUP, RAID1, RAID10, RAID5/6) і профіль метаданих (часто RAID1 навіть якщо дані single). Це потужно: ви можете пріоритезувати безпеку метаданих навіть на одному диску використовуючи DUP (на одному пристрої зберігає два копії — корисно проти деяких моделей поганих секторів, але не заміна надлишковості).

Велика заувага залишається за паритетним RAID. Дзеркальні профілі (RAID1/RAID10) широко використовуються і загалом викликають довіру. Паритетні профілі (RAID5/6) мали довгу історію краєвих випадків і досі з обережністю використовуються у багатьох продакшн-середовищах. Якщо ви будуєте «повинно пережити дивні відмови», lane безпечніший — btrfs RAID1/10.

Жарт #2: «RAID — це не резервна копія» — це еквівалент «не торкайся плити» для зберігання — всі кивають, а потім хтось все одно торкається плити.

Відновлення: що можна полагодити, а що ні

ZFS відновлення: scrubs, resilvers і мистецтво не панікувати

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

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

btrfs відновлення: хороші інструменти, більше нюансів і «знай свій режим»

btrfs має добрий набір інструментів для відновлення: scrub, stats пристроїв, утиліти check/repair і можливість монтування в readonly та рятування даних. Але навантаження на оператора більше, бо результати більше залежать від того, які можливості ви використовували (профілі, компресія, квоти, знімки) і який тип відмови стався (один пристрій, багато пристроїв, пошкодження метаданих).

btrfs може бути надзвичайно надійним у добре витоптаних конфігураціях (один пристрій, RAID1/10, дисципліновані знімки). Воно стає менш «передбачувано нудним», чим далі ви йдете в паритетний RAID і складні операції конвертації під тиском.

Продуктивність: затримки, пропускна здатність і війни кешів

ZFS продуктивність: ARC, recordsize, sync і міф про SLOG

ZFS часто звинувачують у «запиті великої кількості RAM». Точніше: ZFS охоче використовує пам’ять для ARC (adaptive replacement cache), бо кеш робить усе краще, поки ні. На Linux ви повинні розуміти взаємодію між ARC і page cache ядра, і встановлювати розумні ліміти на системах з обмеженою пам’яттю.

Для баз даних і віртуалізації тюнінг ZFS часто зводиться до кількох практичних важелів:

recordsize: великий для послідовного (бекапи), менший для випадкового (VM, БД).
compression: часто покращує ефективну пропускну здатність і затримку.
sync: не «оптимізуйте» це, якщо не любите пояснювати втрату даних.
SLOG: допомагає синхронним записам тільки для певних навантажень; це не універсальна пігулка швидкості.

btrfs продуктивність: CoW, компресія і реалії фрагментації

btrfs може бути швидким, особливо з компресією і NVMe. Але CoW має наслідки для навантажень, що переписують великі файли на місці (образи VM, деякі БД). btrfs надає способи пом’якшити це (наприклад, вимкнення CoW на конкретних файлах/директоріях через chattr +C), але це компроміс: ви відмовляєтесь від деяких переваг CoW.

«balance» в btrfs — і можливість, і пастка: воно може реорганізувати дані під новий профіль або покращити розподіл, але це інтенсивно по IO і може посилити біль, якщо запускати його недбало на завантажених системах.

Практичні завдання з командами (і що означає їхній вивід)

Найшвидший спосіб вивчити ці системи — робити реальні речі: створювати пули, знімки, scrub, симулювати відмови і практикувати шляхи відновлення. Нижче завдання, які ви можете виконати на тестових системах. Команди припускають Linux з інструментами ZFS (OpenZFS) і btrfs-progs для btrfs.

Завдання 1 (ZFS): Створити дзеркальний пул і перевірити топологію

cr0x@server:~$ sudo zpool create -o ashift=12 tank mirror /dev/disk/by-id/ata-diskA /dev/disk/by-id/ata-diskB
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         ONLINE       0     0     0
          mirror-0                   ONLINE       0     0     0
            ata-diskA                ONLINE       0     0     0
            ata-diskB                ONLINE       0     0     0

errors: No known data errors

Інтерпретація: mirror-0 — ваша одиниця надлишковості. Якщо втрачаєте один диск, пул лишається онлайн. Якщо втрачаєте весь mirror vdev (обидва диски), пул загинув.

Завдання 2 (ZFS): Створити датасети з розумними властивостями для VM і бекапів

cr0x@server:~$ sudo zfs create -o compression=zstd -o atime=off tank/vm
cr0x@server:~$ sudo zfs set recordsize=16K tank/vm
cr0x@server:~$ sudo zfs create -o compression=zstd -o recordsize=1M tank/backup
cr0x@server:~$ sudo zfs get -o name,property,value compression,recordsize,atime tank/vm tank/backup
NAME         PROPERTY    VALUE
tank/vm      compression zstd
tank/vm      recordsize  16K
tank/vm      atime       off
tank/backup  compression zstd
tank/backup  recordsize  1M
tank/backup  atime       on

Інтерпретація: Ви підбираєте recordsize під модель IO. VMs: менші записи зменшують read-modify-write ампліфікацію. Бекапи: великі записи підвищують послідовну ефективність.

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

cr0x@server:~$ sudo zfs snapshot -r tank@pre-upgrade
cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer,creation | head
NAME                    USED  REFER  CREATION
tank@pre-upgrade          0B   128K  Tue Dec 24 00:10 2025
tank/backup@pre-upgrade   0B    96K  Tue Dec 24 00:10 2025
tank/vm@pre-upgrade       0B   256K  Tue Dec 24 00:10 2025

Інтерпретація: USED знімка зростає, коли жива ФС відходить від знімка. Не ігноруйте це; це «місце, яке ви не можете повернути, поки не видалите знімки».

Завдання 4 (ZFS): Відправити інкрементальний знімок на інший пул (реплікація)

cr0x@server:~$ sudo zfs snapshot tank/vm@replica-001
cr0x@server:~$ sudo zfs send -w tank/vm@replica-001 | sudo zfs receive -u backup-pool/vm
cr0x@server:~$ sudo zfs snapshot tank/vm@replica-002
cr0x@server:~$ sudo zfs send -w -i tank/vm@replica-001 tank/vm@replica-002 | sudo zfs receive -u backup-pool/vm

Інтерпретація: Перший send — повний; другий — інкрементальний. -w посилає raw-потік, зберігаючи властивості і (коли підтримується) характеристики шифрування.

Завдання 5 (ZFS): Scrub і читання результатів

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Tue Dec 24 00:14:02 2025
        2.31G scanned at 410M/s, 812M issued at 144M/s, 120G total
        0B repaired, 0.66% done, 0:13:50 to go
config:

        NAME         STATE     READ WRITE CKSUM
        tank         ONLINE       0     0     0
          mirror-0   ONLINE       0     0     0
            diskA    ONLINE       0     0     0
            diskB    ONLINE       0     0     0

errors: No known data errors

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

Завдання 6 (ZFS): Симулювати відмову диска й замінити його

cr0x@server:~$ sudo zpool offline tank /dev/disk/by-id/ata-diskB
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         DEGRADED     0     0     0
          mirror-0                   DEGRADED     0     0     0
            ata-diskA                ONLINE       0     0     0
            ata-diskB                OFFLINE      0     0     0

errors: No known data errors
cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-diskB /dev/disk/by-id/ata-diskC
cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: DEGRADED
  scan: resilver in progress since Tue Dec 24 00:20:11 2025
        8.02G scanned, 1.94G issued, 120G total
        1.93G resilvered, 1.62% done, 0:18:10 to go

Інтерпретація: «Resilver» — це реконструкція. У дзеркалах це просто; у RAIDZ це складніше. Слідкуйте за повільними resilver — це часто вказує на прихований IO-контент або другий хворий диск.

Завдання 7 (btrfs): Створити ФС на одному пристрої і монтувати її

cr0x@server:~$ sudo mkfs.btrfs -L data /dev/nvme0n1p3
btrfs-progs v6.6
Label:              data
UUID:               4b1a0c7e-1d2a-4a6f-9e3c-2e3a3a4e6b2f
Node size:          16384
Sector size:        4096
Filesystem size:    400.00GiB
Block group profiles:
  Data:             single
  Metadata:         DUP
  System:           DUP
cr0x@server:~$ sudo mount -o compress=zstd,space_cache=v2 /dev/nvme0n1p3 /mnt/data
cr0x@server:~$ sudo btrfs filesystem df /mnt/data
Data, single: total=1.00GiB, used=256.00MiB
Metadata, DUP: total=1.00GiB, used=112.00MiB
System, DUP: total=8.00MiB, used=16.00KiB

Інтерпретація: Metadata DUP на одному диску — прагматичне підвищення цілісності. Це не надлишковість проти смерті диска, але може допомогти проти деяких локальних корупцій.

Завдання 8 (btrfs): Створити субволюми і знімки (OS-стиль)

cr0x@server:~$ sudo btrfs subvolume create /mnt/data/@
Create subvolume '/mnt/data/@'
cr0x@server:~$ sudo btrfs subvolume create /mnt/data/@home
Create subvolume '/mnt/data/@home'
cr0x@server:~$ sudo btrfs subvolume snapshot -r /mnt/data/@ /mnt/data/@-snap-pre-upgrade
Create a readonly snapshot of '/mnt/data/@' in '/mnt/data/@-snap-pre-upgrade'
cr0x@server:~$ sudo btrfs subvolume list /mnt/data | head
ID 256 gen 12 top level 5 path @
ID 257 gen 13 top level 5 path @home
ID 258 gen 14 top level 5 path @-snap-pre-upgrade

Інтерпретація: Read-only знімки безпечніші для відкату і send/receive. Трактуйте межі субволюмів як межі радіусу ураження.

Завдання 9 (btrfs): Використати send/receive для інкрементальної реплікації

cr0x@server:~$ sudo btrfs subvolume snapshot -r /mnt/data/@ /mnt/data/@-snap-001
cr0x@server:~$ sudo btrfs send /mnt/data/@-snap-001 | sudo btrfs receive /mnt/backup
At subvol /mnt/backup/@-snap-001
cr0x@server:~$ sudo btrfs subvolume snapshot -r /mnt/data/@ /mnt/data/@-snap-002
cr0x@server:~$ sudo btrfs send -p /mnt/data/@-snap-001 /mnt/data/@-snap-002 | sudo btrfs receive /mnt/backup
At subvol /mnt/backup/@-snap-002

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

Завдання 10 (btrfs): Scrub і читання статистик пристроїв

cr0x@server:~$ sudo btrfs scrub start -Bd /mnt/data
Starting scrub on devid 1
Scrub device /dev/nvme0n1p3 (id 1) done
Scrub started:    Tue Dec 24 00:35:12 2025
Status:           finished
Duration:         0:01:07
Total to scrub:   18.00GiB
Rate:             274.62MiB/s
Error summary:    read=0 write=0 csum=0 verify=0 no_csum=0 csum_discards=0 super=0 malloc=0 uncorrectable=0 corrected=0
cr0x@server:~$ sudo btrfs device stats /mnt/data
[/dev/nvme0n1p3].write_io_errs   0
[/dev/nvme0n1p3].read_io_errs    0
[/dev/nvme0n1p3].flush_io_errs   0
[/dev/nvme0n1p3].corruption_errs 0
[/dev/nvme0n1p3].generation_errs 0

Інтерпретація: Scrub перевіряє контрольні суми і намагається відремонтувати, коли є надлишковість. Статистика пристроїв допомагає ідентифікувати хиткий пристрій раніше, ніж він повністю відмовить.

Завдання 11 (btrfs): Конвертувати в RAID1 з другим пристроєм (поведінка схожа на дзеркало)

cr0x@server:~$ sudo btrfs device add /dev/nvme1n1p3 /mnt/data
cr0x@server:~$ sudo btrfs balance start -dconvert=raid1 -mconvert=raid1 /mnt/data
Done, had to relocate 12 out of 12 chunks
cr0x@server:~$ sudo btrfs filesystem df /mnt/data
Data, RAID1: total=16.00GiB, used=12.00GiB
Metadata, RAID1: total=2.00GiB, used=512.00MiB
System, RAID1: total=32.00MiB, used=64.00KiB

Інтерпретація: btrfs використовує профілі та чанки. Після конвертації ваші дані й метадані віддзеркалені по пристроях. Операція balance — ціна за цю гнучкість — плануйте вікна обслуговування.

Завдання 12 (btrfs): Вимкнути CoW для директорії VM (з компромісами)

cr0x@server:~$ sudo mkdir -p /mnt/data/vmimages
cr0x@server:~$ sudo chattr +C /mnt/data/vmimages
cr0x@server:~$ lsattr -d /mnt/data/vmimages
---------------C------ /mnt/data/vmimages

Інтерпретація: Нові файли в цій директорії будуть NOCOW, що часто зменшує фрагментацію і покращує шаблони записів VM. Компроміс: ви відмовляєтесь від CoW-гарантій для цих файлів (і поведінка контрольних сум може залежати від ядра/функцій).

Завдання 13 (ZFS): Перевірити поведінку ARC і тиск пам’яті (Linux)

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|hit|miss)'
size                            4    17179869184
c_max                           4    25769803776
hit                             4    1402382231
miss                            4    32988312

Інтерпретація: Розмір ARC і hit/miss дають вам швидкий сигнал: чи вистачає кешу. Якщо машина свапить, ліміти ARC потребують уваги, але не реагуйте імпульсивно — спочатку знайдіть реальних споживачів пам’яті.

Завдання 14 (ZFS): Визначити, що їсть простір (знімки проти живих даних)

cr0x@server:~$ sudo zfs list -o name,used,avail,refer,usedbysnapshots,usedbydataset -r tank
NAME        USED  AVAIL  REFER  USEDBYSNAPSHOTS  USEDBYDATASET
tank        420G   1.2T   128K              0B          128K
tank/vm     300G   1.2T   250G            80G          250G
tank/backup 120G   1.2T   110G            10G          110G

Інтерпретація: Якщо USEDBYSNAPSHOTS великий — важіль для очищення старих знімків. Якщо USEDBYDATASET великий — живі дані зросли і вам потрібна ємність або політика стрижки.

План швидкої діагностики (знайдіть вузьке місце, перш ніж воно знайде вас)

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

1) Встановіть: це диск, CPU, пам’ять чи галасливий орендар?

cr0x@server:~$ uptime
 00:41:03 up 12 days,  4:22,  2 users,  load average: 18.12, 17.90, 16.55
cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            128G         92G         3.1G        2.2G         33G         29G
Swap:             0B          0B          0B
cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
18  3      0 3211232 120000 28000000    0    0  1200  3400 9000 22000 25 15 30 30  0

Інтерпретація: Високий wa натякає на IO wait. Високий load з низьким IO wait — про CPU. Тиск пам’яті проявляється як зменшення available і можливий свап (якщо увімкнено).

2) Спочатку перевірте стан файлової системи/пулу; потім продуктивність

Бо деградований пул часто виглядає як «випадкова повільність».

cr0x@server:~$ sudo zpool status
cr0x@server:~$ sudo btrfs device stats /mountpoint
cr0x@server:~$ dmesg | tail -n 50

Інтерпретація: Будь-які read/write/cksum помилки, скиди або таймаути змінюють ваш план: ви не налаштовуєте, ви тріажите апарат.

3) Ідентифікуйте топ-споживачів IO (по процесу й по пристрою)

cr0x@server:~$ iostat -xz 1 5
cr0x@server:~$ pidstat -d 1 5

Інтерпретація: Шукайте пристрої з високою завантаженістю і ростом await, і процеси, що генерують непропорційні записи. Тут ви знайдете «одну задачу бекапу», що випадково робить випадковий IO на пулі VM.

4) Для ZFS: перевірте ARC і поведінку sync-записів

cr0x@server:~$ cat /proc/spl/kstat/zfs/arcstats | egrep '^(size|c_max|mru_size|mfus|hits|miss)'
cr0x@server:~$ sudo zfs get -o name,property,value sync,logbias,primarycache,recordsize -r tank/vm

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

5) Для btrfs: перевірте чи не йде balance/scrub і патерни фрагментації

cr0x@server:~$ sudo btrfs balance status /mountpoint
cr0x@server:~$ sudo btrfs scrub status /mountpoint
cr0x@server:~$ sudo btrfs filesystem usage /mountpoint | head -n 30

Інтерпретація: Запущений balance у пікові години може пояснити «раптовий IO-податок». Також слідкуйте за використанням метаданих; дефіцит метаданих може викликати дивні затримки.

Звичайні помилки (симптоми & виправлення)

Помилка 1: Трактування знімків як бекапів

Симптом: «У нас є знімки, чому не можемо відновити після втрати пулу?» і довга пауза.

Виправлення: Знімки захищають від логічних помилок (rm -rf, невдала оновлення) на тому ж сховищі. Бекапи потребують незалежного носія або віддаленої системи. Використовуйте ZFS send/receive або btrfs send/receive на інший хост/пул або окрему систему резервного копіювання. Тестуйте відновлення, а не тільки відправки.

Помилка 2: ZFS пул спроєктований як один величезний RAIDZ vdev для VM

Симптом: Чудові послідовні бенчмарки, жахлива латентність VM, скарги що «IOPS прокляті».

Виправлення: Для випадкового IO використовуйте кілька mirror vdev або кілька RAIDZ vdev щоб збільшити паралелізм. Також встановіть відповідний recordsize (наприклад, 16K) для VM датасетів і вмикайте компресію.

Помилка 3: btrfs паритетний RAID використовується як mdadm RAID6

Симптом: Несподівана поведінка під час відмови пристрою/перебудови, заплутані стани помилок, відновлення схоже на археологію.

Виправлення: Віддавайте перевагу btrfs RAID1/10 для надійності в продакшні, якщо немає перевірених процедур для паритетних режимів. Якщо потрібен паритет, розгляньте mdadm під btrfs або оберіть ZFS RAIDZ.

Помилка 4: Запуск btrfs balance недбало на живому продакшні

Симптом: Спайки IO-латентності, тайм-аути додатків, «нічого не змінилося», окрім того, що «хтось запустив обслуговування».

Виправлення: Використовуйте фільтрований balance (-dusage= / -musage=) і плануйте його. Моніторте. Трактуйте balance як задачy міграції зберігання, а не скрипт для прибирання.

Помилка 5: «Оптимізація» sync-настроювань ZFS, щоб зробити бенчмарки гарними

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

Виправлення: Тримайте sync=standard, якщо не розумієте до кінця вимоги до стійкості додатка. Якщо потрібен швидший sync, розгляньте SLOG-пристрої з захистом від втрати живлення і валідуйте поліпшення затримки на реальних навантаженнях.

Помилка 6: Ігнорування scrub, бо «пул онлайн»

Симптом: Перший scrub за рік знаходить помилки; тепер ви дебажите історію корупції замість її попередження.

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

Помилка 7: Розростання знімків без політики утримання

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

Виправлення: Впровадьте політику утримання знімків (щогодини/щодня/щотижня) і автоматизуйте прибирання. Відслідковуйте простір, зайнятий знімками (ZFS: usedbysnapshots; btrfs: використання субволюма і qgroups, якщо застосовано).

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

Чекліст A: Вибір між ZFS і btrfs (рішення для продакшну)

Визначте модель відмов: один диск? два диски? контролер бреше? битова корупція? помилка оператора? радіус ураження при ransomware?
Визначте навантаження: VMs, БД, об’єктне сховище, бекапи, домашні каталоги розробників, root ОС.
Вирішіть підхід до надлишковості: ZFS mirror/RAIDZ vs btrfs RAID1/10 (або mdadm + btrfs).
Вирішіть стратегію знімків: які datasets/subvolumes отримують знімки; утримання; ланцюг реплікації; захист від видалення.
Плануйте спостережливість: графіки scrub, алерти по помилках пристроїв, прогноз ємності, тривоги по росту знімків.
Репетируйте відновлення: заміна диска; відкат знімка; відновлення реплікованого датасету на чистий хост.

Чекліст B: План розгортання ZFS (нудно, правильно, повторювано)

Виберіть геометрію vdev: дзеркала для IOPS/латентності; RAIDZ2 для ємності + стійкості; уникайте одного широкого vdev для змішаних навантажень.
Встановіть ashift правильно (зазвичай 12) при створенні пулу; не хочете «відкривати» розмір сектора пізніше.
Визначте datasets по робочим навантаженням; встановіть recordsize, compression, atime.
Налаштуйте політику знімків і реплікацію; перевірте інкрементальні send.
Плануйте scrubs і алерти на зміни zpool status і checksum помилки.
Документуйте процедуру заміни дисків і тримайте резервну ємність для resilver.

Чекліст C: План розгортання btrfs (почніть із безпечних шляхів)

Вирішіть: один диск, RAID1 чи RAID10. Трактуйте паритетний RAID як спеціальний проєкт, а не за замовчуванням.
Використовуйте subvolumes як межі; знімайте ті, які реально можете відкотити.
Увімкніть компресію (zstd — популярний вибір) і узгоджені монтальні опції.
Плануйте операції balance: фільтрований, за розкладом, моніторинг.
Scrub регулярно; слідкуйте за stats пристроїв; розслідуйте IO помилки раніше.
Тестуйте відновлення send/receive; тримайте батьківські знімки поки діти не репліковані безпечно.

Три корпоративні міні-історії (правдоподібні, технічно точні й болючі)

Міні-історія 1: Інцидент через неправильне припущення

У них був акуратний сетап: btrfs на парі SSD, знімки щогодини і гордий дашборд, що показував «кількість знімків: в нормі». Молодший інженер поставив очевидне питання — «Ми робимо бекап кудись поза хостом?» — і отримав відмашку «знімки фактично як бекапи; ми можемо відкотити що завгодно». Це речення — еквівалент залишити ключі в машині, бо маєте страховку.

Інцидент спочатку був не драматичний. Помилка прошивки SSD почала давати періодичні помилки читання, потім диск почав відвалюватися від шини. Система працювала; надлишковість покрила відмову. Команда замінила диск. Тиждень потому другий SSD почав вести себе подібно — та сама партія, та сама прошивка, різний час. Раптом машина впала і файлова система стала недоступною.

Незручна зустріч була не про саму відмову. Диски ламаються; тому ми дзеркалимо. Зустріч була про виявлення, що їх «план бекапу» жив на тому ж шасі. Знімки були бездоганні й марні. Шлях відновлення — «надіятися, що вендор зможе відновити NAND» — це не план, а молитва з P.O.

Після цього вони зробили нудні, але правильні речі: оф-хост реплікація send/receive на окрему систему і щомісячні тести відновлення. Команда перестала сперечатися, чи знімки — це бекапи, бо в календарі з’явився доказ: відновлення працює.

Міні-історія 2: Оптимізація, що вдарила в спину

Кластер віртуалізації перевели на ZFS на Linux, бо команда хотіла чисті знімки і реплікацію. Ранні тести показували пристойну продуктивність. Потім хтось помітив, що sync-важкі навантаження «трохи повільні», і добронамеренний ентузіаст запропонував фікс: вимкнути sync-семантику на датасеті VM. Графіки стали чудовими.

Декілька днів всі були щасливі. Латентність впала, пропускна здатність зросла, команда виглядала як чаклуни. Єдиний скептик постійно питав: «Що думає база даних про fsync?» — його не любили, поки він не виявився правий.

Потім стався незапланований відключення живлення — нічого екзотичного, просто збій об’єкта й UPS, що виконував роль декоративної коробки. Декілька VM перезавантажилися, але частина мала пошкоджений стан додатків. Одна база відновилася, інша — ні. Причина була проста: датасет мав конфігурацію, яка дозволяла «випаровування» підтверджених записів при краху. ZFS зробила саме те, що їй наказали. Файлова система не кусала їх — конфігурація вкусила.

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

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Одна команда використовувала ZFS для файлового сервісу, про який всі забули, доки він не зламався — найвища похвала для сховища. У них були дві звички, що здавалися занадто старомодними: щомісячні scrubs і регулярні огляди алертів пулу. Не «коли згадаємо», а справді за розкладом, з on-call runbook.

Під час одного scrub ZFS повідомила невелику кількість checksum помилок на одному диску. Продуктивність була нормальна; користувачі не скаржилися. Спокусливо було ігнорувати. Але контрольні суми не брешуть заради веселощів, і ZFS не схильна до театральності. Вони перевірили SMART і виявили зростання reallocated sector count, замінили диск в робочий час.

Через кілька тижнів інший диск в тому ж шасі раптово відмовив. Якби вони не замінили перший проактивно, друга відмова стала бся під час вікна деградації. Натомість пул продовжив працювати. Тікет інциденту був нудним: «Диск відмовив; замінили; resilver; без втрати даних.»

Це секрет надійного зберігання: геройське відновлення рідко є ознакою досконалості. Найкраща історія зі зберігання — та, яку ніхто не розповідає, бо нічого цікавого не сталося.

Поширені питання

1) Чи ZFS «безпечніша» за btrfs?

У багатьох продакшн-конфігураціях ZFS має більш послідовно передбачувану історію цілісності і відновлення, особливо з багатодисковими RAIDZ/mirror налаштуваннями. btrfs теж може бути дуже безпечним — особливо в однодискових або RAID1/10 конфігураціях з дисциплінованими операціями — але її профіль ризику більше залежить від того, які можливості ви використовуєте.

2) Чи можу я використовувати btrfs як ZFS зі знімками і реплікацією?

Так: btrfs subvolume snapshots плюс btrfs send/receive можуть надати ефективний робочий процес реплікації. Умова — операційна дисципліна: потрібно керувати ланцюжками знімків і утриманням, і регулярно тестувати відновлення.

3) У чому практична різниця між ZFS RAIDZ і профілями RAID btrfs?

ZFS RAIDZ — частина уніфікованого дизайну пулу, де надлишковість визначається vdev і є центральною для ідентичності пулу. btrfs використовує профілі по чанках для даних і метаданих, які можна конвертувати через balance. ZFS більш жорстка, але детермінована; btrfs гнучкіша, але вимагає ретельніших операційних виборів.

4) Чи обов’язкові scrubs?

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

5) Коли слід використовувати компресію?

Часто за замовчуванням в обох файлових системах, особливо з zstd. Компресія часто покращує продуктивність, бо менше байт лягає на диск. Винятки — вже стислі медіа і системи з обмеженим CPU; навіть тоді тестуйте, а не припускайте.

6) Чи потрібна ECC RAM для ZFS?

ECC настійно рекомендовано для будь-якої серйозної системи зберігання, незалежно від файлової системи. ZFS виграє від ECC, бо активно кешує і піклується про цілісність. Але «без ECC» не означає «не використовувати ZFS» автоматично; це означає розуміти ризики і посилити моніторинг.

7) Чому видалення не звільняє простір, коли є знімки?

Тому що знімки утримують посилання на старі блоки. Видалення файлів прибирає їх з живого вигляду, але блоки залишаються посиланнями в знімках. В ZFS перевіряйте usedbysnapshots. В btrfs перевіряйте використання субволюмів/знімків і розгляньте квоти (qgroups), якщо треба примусово обмежувати.

8) Чи слід ставити ZFS поверх апаратного RAID?

Зазвичай ні. ZFS хоче прямого доступу до дисків, щоб правильно керувати надлишковістю і звітністю про помилки. Якщо змушені використовувати RAID-контролер, налаштуйте його в режимі HBA/JBOD, якщо можливо. «Подвійний RAID» часто призводить до гіршої видимості помилок і заплутанішого відновлення.

9) Яка найпростіша безпечна multi-disk конфігурація btrfs?

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

10) Яка найпростіша безпечна конфігурація ZFS?

Дзеркала. Пул з mirror vdev масштабовано передбачувано для випадкового IO і тримає відновлення простим. RAIDZ2 теж поширений, коли важлива ефективність по ємності, але проектуйте його уважно з урахуванням навантаження і ризику перебудови.

Висновок

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

Якщо ви хочете нативну інтеграцію в ядро, елегантні робочі процеси знімків субволюмів і файлову систему, що відмінно підходить для відкату на рівні ОС та досить безпечне дзеркальне зберігання — btrfs сильний вибір — за умови, що ви лишаєтесь на добре освітлених шляхах (single/RAID1/RAID10) і трактуєте операції обслуговування як справжні продакшн-події.

У будь-якому разі, файлова система не врятує вас від відсутності практики. Проводьте scrubs. Тестуйте відновлення. Тримайте політику знімків нудною. І пам’ятайте: найкраща система зберігання — та, яка перетворює катастрофи на рутину обслуговування.

Схожі статті

ZFS проти btrfs: де btrfs зручний, а де підводить