ZFS copies=2/3: Додаткова надмірність без нового VDEV — розумно чи марнотратно?

January 6, 2026 • February 3, 2026 • Читання: 5 хв • Views: 9

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

ZFS має властивість copies, яка виглядає як чит-код: встановіть її в 2 або 3, і ваші дані отримують додаткову надмірність — без нових дисків, без нових vdev, без перебудови пулу. Це спокусливо, особливо коли закупівлі «ще розглядають» і ваш реєстр ризиків «палає».

На практиці copies не є ні чарівництвом, ні марною штукою. Це гострий інструмент, який може врятувати вам робочий тиждень — або тихо спалити купу ємності й продуктивності, даючи хибне відчуття безпеки. Давайте ставитися до нього по-дорослому: зрозуміти точно, що він дублікує, куди розміщує блоки, як взаємодіє з mirror/RAIDZ/special vdev, і як експлуатувати його, не перетворивши пул на повільний дорогий науковий проєкт.

Зміст

Що copies насправді робить (і чого не робить)
Швидкі факти й історичний контекст
Як це працює в деталях: розміщення блоків, контрольні суми та типи відмов
Розумно чи марнотратно? Рамка для ухвалення рішення
Витрати на продуктивність і ємність (те, що ви реально відчуєте)
Практичні шаблони: де copies виправдовує себе
Три корпоративні міні-історії (з болем)
Практичні завдання: команди, виводи й інтерпретація
План швидкої діагностики
Поширені помилки: симптоми та виправлення
Контрольні списки / покроковий план
Часті запитання
Висновок

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

Властивість набору даних ZFS copies контролює, скільки копій ZFS зберігає для кожного блоку, записаного в цей набір: copies=1 (за замовчуванням), copies=2 або copies=3.
Вона встановлюється на рівні набору даних, наслідувана і застосовується до нових записів (і переписаних блоків), але не до існуючих блоків, якщо ви їх не перепишете.

Що робить

Коли ви записуєте блок, ZFS виділяє простір і записує цей блок. З copies=2 він виділяє два окремі місця для блоку і записує той самий блок двічі. З copies=3 — три місця.
Читання може відбуватися з будь-якої валідної копії; якщо копія не проходить перевірку контрольної суми, ZFS спробує іншу.

Чого не робить

copies не перетворює пул на одному диску на безпечний пул. Воно не захищає від втрати vdev. Воно не виживає втрату диска, якщо надмірність vdev(ів) не може надати щонайменше одну валідну копію.
Це також не заміна для бекапів. Це той самий пул, та сама адміністративна область і такий же радіус ураження при «ой, я видалив».

Корисна ментальна модель: надмірність vdev (mirror/RAIDZ) захищає від відмови пристрою. copies захищає від деяких сценаріїв втрати/корупції на рівні блоків всередині наявної топології та може підвищити шанси на відновлення, коли ви вже працюєте в деградованому режимі або маєте ненадійні сектори.

Жарт #1: Встановити copies=3 на весь пул — це як тричі пакувати продукти в пакети — чудово, допоки не зрозумієш, що більше нічого не вміщається і ти все одно забув яйця.

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

Ось кілька конкретних пунктів контексту, які формують розуміння copies станом на 2025 рік:

ZFS створювався навколо наскрізних контрольних сум: корупція виявляється під час читання, а не припускається за «успішністю» диска. Це робить кілька копій корисними, бо ZFS може вибрати відому хорошу копію.
Ранні розгортання ZFS пропагували «scrub або шкодуй»: періодичні scrubs виявляли латентні помилки секторів і виправляли їх — задовго до того, як споживче сховище навчилося чесно повідомляти про проблеми.
copies старший за багато кар’єр у ZFS: це не модна надбудова; він існує вже роками як прицільний регулятор надмірності.
RAIDZ — це не «просто RAID»: парність ZFS інтегрована з контрольними сумами і самовиліковуванням при читанні, але парність має свої домени відмов (втрата цілого vdev, відсутні пристрої), через які додаткові копії не перейдуть магічно.
Special vdev змінив значення «безпека метаданих»: переміщення метаданих (і опціонально невеликих блоків) на special vdev дає приріст продуктивності — і пастку надійності, якщо цей vdev недоредаундантний. Додаткові копії можуть бути частиною пом’якшення, але не всім вирішенням.
Сучасні диски «ввічливо брешуть»: «успішне» читання може все одно повернути пошкоджені біти. Контрольні суми ловлять це; надмірність виправляє. Додаткові копії можуть дати ще один шанс, коли відновлення парністю важке або неможливе.
Стиснення стало масовим: з compression=lz4 податок по ємності від copies=2 іноді не такий катастрофічний, як ви могли б очікувати — на стиснених даних.
Розмір запису став більшим, а малі файли дивніші: бази даних, образи VM і сховища об’єктів створюють різні патерни блоків; copies взаємодіє з цим так, що не інтуїтивно судити лише «вдвічі більше даних — вдвічі вартість».

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

Копії — це окремі виділення блоків, а не «RAID всередині RAID»

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

Важлива нюанс: ці виділення зазвичай опиняються в тому ж класі vdev (звичайні data vdev, або special vdev, якщо блок класифіковано туди), і в тому ж пулі.
Це означає, що додаткові копії не є незалежними так, як другий пул, інший шасі або інший сайт.

Контрольні суми — це арбітр

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

іншу копію (з copies>1),
іншу сторону дзеркала (на mirror vdev),
відновлення парністю (на RAIDZ),
або будь-яку комбінацію вищезазначеного.

З якими відмовами допомагає `copies`?

У реальному житті відмови рідко бувають «диск повністю помер і замінений красиво». Зазвичай це:

латентні помилки секторів, що виявляються під час scrub/resilver,
частково несправні пристрої, що повертають переривчасті помилки читання,
помилки прошивки/транспорту, які викликають таймаути та помилки I/O під навантаженням,
пошкоджені блоки в деградованому пулі, де відновлення парністю або варіанти дзеркала вже обмежені.

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

Куди йдуть копії?

Практична відповідь: вони йдуть туди, де аллокатор знаходить місце, підпорядковуючись поведінці виділення блоків та metaslab ZFS.
Неприємна правда: не слід припускати, що копії опиняться на окремих фізичних дисках так, як у дзеркалі.
Вони можуть опинитися на тому ж диску у RAIDZ vdev (але на різних зсувних позиціях), тому що RAIDZ розкладає дані по всіх дисках і парності, і «копія» — це інший логічний блок, який розподіляється за маппінгом RAIDZ. Це все ще корисно: це друга незалежно виділена копія, яка може пережити локалізовану корупцію або нечитаємі області, але це не незалежний домен відмов.

Взаємодія з mirror vs RAIDZ

На mirror vdev у вас уже є дві (або більше) фізичні копії на дисках. Установлення copies=2 поверх двостороннього дзеркала означає, що ви тепер маєте дві логічні копії, кожна з яких дзеркалиться — фактично чотири фізичні екземпляри по двох дисках. Це може допомогти у певних випадках корупції/відновлення, але це велике ампліфікування записів заради маргінального виграшу.

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

Special vdev: місце, де `copies` стає політичним

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

Розумно чи марнотратно? Рамка для ухвалення рішення

Правильне питання не «чи хороший copies=2?» Правильне питання: «Яку відмову я намагаюся пережити і скільки я готовий заплатити за виживання?»

Коли `copies=2` — це розумно

Малі, критично важливі набори даних: конфіги, експорт сховища секретів, малі бази даних, ліцензійні ключі, артефакти CI, які мають бути присутні.
Дерева з великою кількістю метаданих: мільйони малих файлів, де один нечитаємий метаданний блок може бути кошмаром під час відновлення.
Вікна ризику роботи в деградованому режимі: середовища, де ви очікуєте працювати в деградованому стані (віддалені сайти, повільна заміна обладнання), і ви хочете додатковий запас від URE під час scrub/resilver.
Boot-середовища та OS-набори даних: де «не завантажиться» — це операційно дорого, навіть якщо дані деінде цілі.
Набори даних special vdev: деякі команди ставлять copies=2 на метаданих, коли ємність special vdev дозволяє, як підстраховку проти локалізованих помилок медіа.

Коли це марнотратно (або гірше)

Великі медіа, бекапи та холодні архіви: якщо ви можете відновити дані, додаткові копії часто марні; використовуйте реплікацію в інший пул/сайт замість цього.
Бази даних з високою швидкістю запису: ампліфікація записів вдарить двічі: по затримці і по витривалості SSD (або IOPS HDD). Ви це відчуєте і за це заплатите.
Встановлювати весь пул у copies=2 «на всяк випадок»: це еквівалент того, щоб поставити всю компанію в груповий чат, бо хтось пропускає повідомлення.
Спроба компенсувати погану топологію: якщо ваш дизайн — «один великий RAIDZ1 з величезними дисками», copies не виправить це. Виправлення — дизайн vdev, гарячі спейри, моніторинг і реалістичний план resilver.

Практична рубрика для рішення

Я використовую три питання в продакшні:

Який шлях відновлення, якщо кілька блоків стануть непрочитуваними? Якщо відповідь «відновлення з бекапу за години» або «відбудувати об’єкт», вам, ймовірно, не потрібен copies.
Який профіль записів? Якщо це інтенсивні випадкові записи, copies може перетворити стабільну систему в генератор скарг на затримки.
Чи можу я обмежити радіус ураження? Якщо ви можете ізолювати критичні дані в окремий набір даних і встановити там copies, функція стає життєздатною. Масове використання — це коли ви змушені пояснювати фінансам математику зберігання.

Витрати на продуктивність і ємність (те, що ви реально відчуєте)

Ємність: зазвичай близько лінійної, іноді ні

Наївне очікування правильне в більшості випадків: copies=2 приблизно подвоює використаний простір для цього набору даних; copies=3 приблизно потроює його.
Стиснення і recordsize можуть зменшити абсолютні числа, але ефект множника залишається: кожний блок, який ви зберігаєте, ви зберігаєте в кількох екземплярах.

Де люди дивуються, так це не в множнику; а в взаємодії зі снапшотами і патернами переписування. ZFS — copy-on-write. Якщо у вас є снапшоти і ви переписуєте блоки, то ви отримаєте:

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

Ампліфікація записів: реальний цінник

Кожна додаткова копія — це додаткове виділення, додаткові I/O, додаткові операції контрольних сум і додаткові оновлення метаданих. На HDD RAIDZ більшість болю проявляється як:

зростання затримки запису і довші часи txg sync,
більше фрагментації (більше виділень на логічний запис),
гірші IOPS для малих записів.

На SSD/NVMe пулах це теж може боліти, але симптоми часто — знос носія та поведінка garbage collection, плюс іноді сплески затримок під час навантаження пам’яті.

Поведіка читання: інколи краще, інколи гірше

Читання може виграти, якщо одна копія повільна або переривчасто падає; ZFS може вибрати іншу. Але ви також можете погіршити читання, створивши більш фрагментовані розкладки і додаткове метаданте навантаження з часом.
В умовах чистої системи читання зазвичай не стають магічно швидшими від copies.

Жарт #2: copies=3 — це трохи як взяти три парасольки, щоб не промокнути — ви все одно намокнете, якщо дах провалиться, а тепер у вас ще й три парасольки щоб сушити.

Практичні шаблони: де `copies` виправдовує себе

Шаблон 1: «Маленький, але страшний» набір даних

Малий набір даних, що містить, наприклад, експорт Terraform state, артефакти для завантаження кластеру або сертифікатні довірчі дерева, може бути екзистенційним.
Зберігання його з copies=2 дає додатковий запас проти локалізованих помилок медіа без перебудови всього пулу.

Шаблон 2: Дерева файлів з великою кількістю метаданих

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

Шаблон 3: Крайній сайт, де «деградований режим — норма»

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

Шаблон 4: Захист special vdev, обережно визначений

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

Три корпоративні міні-історії (з болем)

Міні-історія #1: Інцидент, спричинений хибним припущенням

Середня компанія тримала один пул для «всього», побудований на великому RAIDZ2. Лід прочитав про copies=2 і вирішив ввімкнути його на наборі даних з образами VM, аргументуючи: «RAIDZ2 плюс copies=2 = фактично RAIDZ4, так?» Зміна пройшла, бо звучала як безкоштовна безпека.

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

Розбір поломки був принизливим: набір даних мав великий обсяг записів, і copies=2 подвоїв тиск на виділення та синхронізацію. Пул не був переповнений, але в нього закінчилося терпіння — часи txg sync зросли, а синхронні записи (і все, що вдає себе синхронним) почали ставати в чергу.

Неправильне припущення полягало не в тому, що ZFS може зберігати кілька копій. Неправильне припущення — що надмірність безкоштовна, якщо не купувати диски. Вони відкотили copies для образів VM, виокремили невеликий «критичний конфіг» з copies=2 і повернулися до теми редизайну: vdev, спейри і реплікація.

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

Інша організація вирішила «оптимізувати» використання special vdev. У них були NVMe як special vdev для метаданих і малих блоків, і хтось хотів максимум продуктивності для кешу збірки монорепозиторію: багато малих файлів, багато метаданих, дуже гарячо.
Вони встановили special_small_blocks на велике значення, щоб більше даних попадало на special vdev, а потім додали copies=2 «для безпеки».

Спочатку продуктивність виглядала чудово. Збірки прискорилися, операції з інодами літали, і всі дякували команді зберігання за «інновації». Потім special vdev почав заповнюватися швидше, ніж очікувалося. Оскільки він тепер хостив не тільки метадані, а велику кількість малих даних, copies=2 подвоїв там споживання. Пул в цілому мав достатньо місця; special vdev — ні.

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

Рішенням не було оголосити special vdev «поганими». Його почали трактувати як окремий рівень з власним плануванням ємності. Зменшили special_small_blocks, залишили special vdev редундантним, і використовували copies=2 тільки на дуже невеликому наборі даних, що цього справді вимагав. Кеш збірки налаштували інакше — бо зберігання не замінює видалення старих кешів.

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

Команда фінпослуг мала звичку, що виглядала болісно консервативною: щомісячні вікна scrub, алерти на помилки контрольних сум і політику, що будь-який набір даних з «ключі, auth, bootstrap» отримує copies=2 — але тільки ці набори і тільки після перевірки ємності.
Ніхто не хизувався цим. Це не було гламурно. Це була паперова робота з CLI командами.

Під час планового scrub ZFS зареєстрував невелику кількість помилок контрольних сум на одному диску. Диск не перевищив пороги SMART; він не випав. Просто іноді почав повертати сміття. Scrub виявив погані блоки, ZFS вилікував їх за допомогою надмірності, і спрацювали алерти. Команда замінила диск у робочий час без драми.

Тиждень потому вони зафіксували другу проблему: окремий пристрій мав кілька непрочитуваних секторів. Цього разу постраждав набір даних із «ключами та bootstrap». Оскільки він мав copies=2, ZFS зміг прочитати альтернативну копію без повного покладання на відновлення парністю під навантаженням.

Нічого не вибухнуло. Немає war room. Немає «відновлення з стрічки». Лише кілька тікетів і апаратна заміна. Нудна практика не в тому, що вони використовували copies; а в тому, що використовували його вузько, спостерігали за пулами як дорослі і запускали scrub на розкладі навіть коли нічого не горіло. Нудне — недооцінене в зберіганні.

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

Команди нижче припускають інструменти в стилі OpenZFS на Linux. Налаштуйте імена пулу/наборів даних. Мета не в запам’ятовуванні прапорів; мета — набути м’язової пам’яті для перевірки поведінки до і після зміни copies.

Завдання 1: Перевірити поточні налаштування `copies` і наслідування

cr0x@server:~$ zfs get -r copies tank
NAME              PROPERTY  VALUE    SOURCE
tank              copies    1        default
tank/critical      copies    2        local
tank/critical/ca   copies    2        inherited from tank/critical
tank/vm           copies    1        inherited from tank

Інтерпретація: ви хочете бачити SOURCE як local лише там, де ви це мали на увазі. Випадкове наслідування — це як «невелика міра безпеки» перетворюється на «чому пул заповнений?»

Завдання 2: Змінити `copies` для одного набору даних

cr0x@server:~$ sudo zfs set copies=2 tank/critical

Інтерпретація: це впливає на нові записи (нові блоки). Існуючі блоки залишаються як були, поки їх не перепишуть.

Завдання 3: Підтвердити, чи існуючі дані переписалися (ні)

cr0x@server:~$ zfs get copies tank/critical
NAME           PROPERTY  VALUE  SOURCE
tank/critical  copies    2      local

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

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

cr0x@server:~$ sudo rsync -a --inplace --checksum /tank/critical/ /tank/critical/.rewrite-pass/

Інтерпретація: перепис може бути дорогим і створює нові дані. На практиці ви робите контрольований перепис (іноді через тимчасовий набір даних) і перевіряєте запас вільного місця спочатку. Обережно: «ретрофіт copies» — це не безкоштовна операція.

Завдання 5: Відслідкувати referenced space і logical used space

cr0x@server:~$ zfs list -o name,used,refer,logicalused,logicalrefer,compressratio tank/critical
NAME           USED  REFER  LUSED  LREFER  RATIO
tank/critical  18G   18G    11G    11G     1.60x

Інтерпретація: logical* показує логічний розмір до стиснення; USED/REFER — на диску. З copies=2 ви очікуєте, що on-disk зросте відносно logical — якщо тільки стиснення не компенсує це.

Завдання 6: Стежити за здоров’ям пулу і лічильниками помилок

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:11:19 with 0 errors on Sun Dec 22 03:10:05 2025
config:

        NAME                         STATE     READ WRITE CKSUM
        tank                         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
            sde                      ONLINE       0     0     0
            sdf                      ONLINE       0     0     0

errors: No known data errors

Інтерпретація: CKSUM помилки кажуть «диск повернув погані дані». Саме тут надмірність і додаткові копії мають значення.

Завдання 7: Запустити scrub (і знати, на що підписуєтесь)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub in progress since Mon Dec 23 02:00:02 2025
        1.02T scanned at 1.40G/s, 210G issued at 290M/s, 6.20T total
        0B repaired, 3.39% done, 06:40:12 to go

Інтерпретація: scrubs знаходять латентні помилки, поки ще є надмірність. Якщо copies — ваш страховий килимок, scrubs підтверджують, що килимок є.

Завдання 8: Виміряти поведінку txg sync (показник «записи кусають»)

cr0x@server:~$ sudo zpool get -H -o name,property,value,source autotrim,ashift,autoreplace tank
tank	autotrim	off	default
tank	ashift	12	local
tank	autoreplace	off	default

Інтерпретація: ще не txg, але ви перевіряєте фундаментальні налаштування. Помилки в ashift і trim можуть домінувати в продуктивності, і люди звинувачують copies, коли реальна проблема — невідповідне вирівнювання або поведінка пристрою.

Завдання 9: Спостерігати реальний I/O за пулом і vdev

cr0x@server:~$ zpool iostat -v tank 2
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        5.20T  1.00T    120    980  12.3M  210M
  raidz2-0                  5.20T  1.00T    120    980  12.3M  210M
    sda                         -      -     20    170  2.1M   35.0M
    sdb                         -      -     21    165  2.1M   34.1M
    sdc                         -      -     18    162  2.0M   33.8M
    sdd                         -      -     19    161  2.1M   34.6M
    sde                         -      -     21    160  2.0M   35.2M
    sdf                         -      -     21    162  2.0M   36.1M
--------------------------  -----  -----  -----  -----  -----  -----

Інтерпретація: після ввімкнення copies=2 на наборі даних з високою кількістю записів ви часто побачите зростання операцій запису і ширини смуги при тій самій пропускній здатності на рівні додатку. Це ампліфікація записів, що виходить на світло.

Завдання 10: Перевірити властивості набору даних, що взаємодіють з `copies`

cr0x@server:~$ zfs get -o name,property,value -s local,inherited,default recordsize,compression,sync,copies,logbias tank/critical
NAME           PROPERTY     VALUE     SOURCE
tank/critical  recordsize   128K      default
tank/critical  compression  lz4       inherited from tank
tank/critical  sync         standard  default
tank/critical  copies       2         local
tank/critical  logbias      latency   default

Інтерпретація: sync, recordsize і compression часто визначають, чи терпимо copies. Невеликий recordsize з sync-навантаженням і додатковими копіями — і ви отримуєте чергу підтримки від команди зберігання.

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

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,creation -s creation tank/critical | tail -n 5
tank/critical@auto-2025-12-23-0100   220M   18G  Mon Dec 23 01:00 2025
tank/critical@auto-2025-12-23-0200   110M   18G  Mon Dec 23 02:00 2025
tank/critical@auto-2025-12-23-0300   190M   18G  Mon Dec 23 03:00 2025
tank/critical@auto-2025-12-23-0400   140M   18G  Mon Dec 23 04:00 2025
tank/critical@auto-2025-12-23-0500   160M   18G  Mon Dec 23 05:00 2025

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

Завдання 12: Перевірити наявність і стан special vdev (якщо використовується)

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

        NAME                               STATE     READ WRITE CKSUM
        tank                               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
            sde                            ONLINE       0     0     0
            sdf                            ONLINE       0     0     0
          special
            mirror-1                       ONLINE       0     0     0
              nvme0n1p1                    ONLINE       0     0     0
              nvme1n1p1                    ONLINE       0     0     0

Інтерпретація: якщо у вас є special vdev, ставтеся до нього як до першокласного громадянина. Додаткові копії не врятують дизайн special vdev без надмірності.

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

cr0x@server:~$ zpool get fragmentation tank
NAME  PROPERTY       VALUE  SOURCE
tank  fragmentation  38%    -

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

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

cr0x@server:~$ zfs get copies tank
NAME  PROPERTY  VALUE  SOURCE
tank  copies    1      default

Інтерпретація: якщо тут показано local на корені пулу, ви, ймовірно, тільки що подвоїли вартість кожного набору даних, якщо його не було перевизначено. Це те відкриття, яке краще мати о 10:00, а не о 02:00.

План швидкої діагностики

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

Крок 1: Пул здоровий, чи ми маскуємо відмову?

Перевірте zpool status -v на наявність read/write/CKSUM помилок, деградованих vdev або поточного resilver/scrub.
Якщо бачите помилки контрольних сум, припускайте проблеми з пристроєм або шляхом перш за все. Додаткові копії можуть допомогти вам тимчасово йти далі, але вони не вирішують корінь.

Крок 2: Тиск ємності або тиск special vdev?

Перевірте zfs list і zpool list на наявність вільного простору; ZFS не любить бути дуже заповненим.
Якщо ви використовуєте special vdev, перевірте його алокацію і чи не він біля повноти. «Нормальний» пул зі «переповненим» special vdev може поводитися погано.

Крок 3: Ампліфікація записів і txg contention?

Спостерігайте zpool iostat -v 2 під час уповільнення. Якщо операції запису і ширина смуги зросли, а пропускна здатність додатку залишилася незмінною, ви платите податок ампліфікації.
Перевірте залучені набори даних: zfs get copies,sync,recordsize,compression. Sync-важкий набір з copies=2 — головний підозрюваний.

Крок 4: Один поганий диск (або повільний диск) тягне vdev?

У дзеркалах повільна сторона може створювати дивні латентні патерни залежно від політик читання і чергування.
У RAIDZ один хворий диск може дуже затримувати відновлення і scrubs/resilvers.

Крок 5: Підтвердьте, що ви не випадково не розширили радіус ураження

zfs get -r copies tank і шукайте несподіване наслідування.
Перевірте, чи тимчасовий набір з copies=3 не став батьком для всього через чиїсь скорочення.

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

Помилка 1: Встановлення `copies=2` в корені пулу

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

Виправлення: поверніть назад на корені і явно встановіть тільки на потрібні набори даних.

cr0x@server:~$ sudo zfs inherit copies tank
cr0x@server:~$ sudo zfs set copies=2 tank/critical

Помилка 2: Очікування ретроспективного захисту без переписування даних

Симптом: ви встановили copies=2, але scrubs все ще повідомляють невідновлювані помилки на старих блоках (або ви не бачите зростання ємності, як очікували).

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

Помилка 3: Використання `copies` щоб «виправити» ризиковий дизайн vdev

Симптом: ви все одно не витримуєте другої втрати диска в RAIDZ1; деградований resilver все ще лякає.

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

Помилка 4: Увімкнення `copies=2` на набори даних з великими записами (VM або БД)

Симптом: раптові сплески затримок після «покращення безпеки», збільшення txg sync times, більше IO wait і незадоволені власники застосунків.

Виправлення: поверніть copies=1 для таких наборів; використовуйте належну надмірність і розгляньте SLOG/sync тонке налаштування лише якщо ви повністю розумієте вимоги до надійності.

cr0x@server:~$ sudo zfs set copies=1 tank/vm

Помилка 5: Непомітне заповнення простору special vdev

Симптом: пул має вільне місце, але метаданні операції уповільнюються; завантаження special vdev високе; сплески затримок під час масових операцій.

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

Помилка 6: Сприйняття `copies` як плану бекапу

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

Виправлення: використовуйте снапшоти, іммутованість де доступна, і реплікацію/офсайтні бекапи. Додаткові копії все ще «в середині радіуса ураження».

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

Контрольний список A: Перед увімкненням `copies=2`

Визначтеся з охопленням: підтвердьте, що ви можете ізолювати критичні дані в окремий набір даних (або невелике піддерево).
Заміри базових показників: зафіксуйте zpool iostat -v, zpool status і показники набору даних used/refer/logicalused.
Підтвердьте запас вільного місця: не робіть цього на пулі, який вже близький до повноти; навантаження алокатора скриє реальні результати.
Перевірте політику збереження снапшотів: зрозумійте, як довго старі одно-копійні блоки будуть зафіксовані.
Перевірте здоров’я vdev: якщо вже є помилки контрольних сум, спочатку виправте апаратне забезпечення; не приховуйте це додатковими копіями.

Контрольний список B: Ввімкнення і безпечна валідація

Встановіть copies=2 тільки на цільовий набір даних.
Запишіть невеликий тестовий обсяг і перевірте поведінку через зміну обліку простору (очікуйте більше on-disk зростання на логічний запис).
Моніторте затримки і симптоми txg під час звичайного пікового навантаження.
Запустіть scrub у звичайному вікні технічного обслуговування і підтвердіть, що «0 errors» залишається істинним.

Контрольний список C: Якщо потрібно дублювати існуючі дані

Плануйте простір: вам може тимчасово знадобитися додатковий вільний простір для перепису.
Виберіть метод перепису: контрольована копія в новий набір даних (бажано), або in-place перепис (ризиковіше).
Валідуйте через контрольні суми: використовуйте ZFS send/receive де доречно, щоб змусити семантику перепису збереження снапшотів, але тільки якщо це відповідає вашому операційному моделю.
Виводьте снапшоти: переконайтеся, що старі блоки нарешті зникнуть, інакше ви довго платитимете за обидва стани.

Часті запитання

1) Чи означає `copies=2`, що я переживу дві відмови дисків?

Ні. Стійкість до відмов дисків визначається вашим макетом vdev (mirror/рівень RAIDZ). copies додає додаткові інстанси блоків в межах цієї топології; воно не створює новий незалежний домен відмов.

2) Чи захищає `copies` від мовчазної корупції даних?

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

3) Чи корисний `copies=2` на mirror пулі?

Іноді, для невеликих критичних наборів даних. Але дзеркала вже дають кілька фізичних копій. На завантажених дзеркальних навантаженнях copies може бути дорогим способом купити невеликий додатковий надійний запас.

4) Чи корисний `copies=2` на RAIDZ?

Частіше ніж на дзеркалах — коли використовується вузько. Парність RAIDZ може реконструювати, але в періоди деградації і при URE додаткові незалежно виділені копії можуть покращити відновлюваність для окремих цінних даних.

5) Чи дублює встановлення `copies=2` існуючі дані автоматично?

Ні. Це впливає на нові записи. Щоб застосувати до існуючих блоків, потрібно їх переписати/перемістити.

6) Як `copies` взаємодіє зі стисканням?

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

7) Чи колись доречно використовувати `copies=3`?

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

8) Чи краще `copies` за реплікацію?

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

9) Чи можна встановити `copies` тільки для метаданих?

Непряма опція «тільки для метаданих» на рівні набору даних відсутня. Ви можете, проте, таргетувати набори даних, що важать метаданти, і проектувати з special vdev та вибором recordsize, щоб впливати на те, що вважається «малим». Але не плутайте вплив з гарантіями.

10) Який найбільший операційний ризик від увімкнення `copies`?

Випадкове розширення області дії й регрес продуктивності. Зустрічані відмови зазвичай не «ZFS зламався»; вони «хтось подвоїв записи на найгарячішому наборі і не виміряв».

Висновок

copies=2 і copies=3 не є гімміком, і не є універсальним оновленням. Це прицільні важелі надмірності, які працюють найкраще, коли ви можете вказати невеликий набір даних і сказати: «Якщо цей набір отримає поганий блок у невдалий момент, ми втрачаємо день (або компанію).»

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