RAIDZ1 чи RAID 5: що відбувається насправді під час відновлення даних

Коли хтось звертається до фахівця з відновлення даних через збій масиву, відповідь на питання «який це рівень RAID?» визначає весь подальший план дій. RAIDZ1 і RAID 5 базуються на одній і тій же ідеї — розподіл паритету по дисках, щоб втрата одного диска не призводила до втрати даних — проте при навантаженні вони поводяться дуже по-різному. Ці відмінності стають особливо помітними, коли ви маєте справу з деградованим масивом. У цій статті розглянуто, що означають архітектурні відмінності для ймовірності відмови, складності відновлення та того, які інструменти насправді працюють у кожному випадку.

Зміст

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

Як насправді будується кожен масив

RAID 5 розподіляє дані та парність у стрічках фіксованої ширини по всіх дисках учасниках — зазвичай 64 КБ або 128 КБ, встановлених контролером і незмінних. Кожен запис, що зачіпає менше ніж повну стрічку, запускає класичний цикл читання–модифікація–запису: читання старих даних, читання старої парності, обчислення нової парності, запис обох назад.

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

RAIDZ1 — це тип vdev у ZFS: шар пула невіддільний від файлової системи. ZFS групує блоки кожного запису в стрічку змінної ширини, що простягається одночасно по всіх дисках. Часткових записів у межах стрічки не існує; кожен запис завжди покриває повну стрічку. Це цілком усуває цикл читання–модифікація–запис і закриває «діру при записі».

vdev RAIDZ1 неможливо розширити після створення. Ви можете додати новий vdev до пула, але оригінальний залишається фіксованим. RAID 5 у багатьох реалізаціях дозволяє онлайн-розширення — це перевага з погляду гнучкості, яка інколи стає джерелом нових пошкоджень даних.

Write hole і безшумне пошкодження даних

write hole (дірка при записі) — проблема, характерна для RAID 5: якщо живлення вимикається між записом нових даних і записом оновленої парності, блоки даних і парність перестають узгоджуватися. Більшість контролерів при наступному завантаженні тихо приймає цю невідповідність і позначає масив як «здоровий» — парність для цієї смуги (stripe) просто неправильна. Ніхто цього не помічає, поки під час відновлення не вийде з ладу другий диск; у такому випадку смугу неможливо реконструювати й відбувається втрата даних без жодного попередження.

Примітка щодо відновлення: Коли RAID 5 виглядає так, ніби відбулося одночасне відключення двох дисків, але фізично несправний лише один, невідповідність через write-hole — ймовірний винуватець. Спочатку зробіть образи (image) кожного диска та проаналізуйте відповідність парності в підозрілих смугах (stripes), перш ніж робити висновок, що обидва диски вийшли з ладу.

ZFS уникає цього завдяки семантиці copy-on-write (копіювання при записі): дані ніколи не перезаписуються поверх існуючих блоків. Якщо під час запису відбувається відключення живлення, ZFS при наступному монтуванні відкидає незавершену транзакцію. Масив завжди залишається консистентним з моменту, коли він знову стає доступним.

Другою проблемою цілісності є безшумне пошкодження даних (silent data corruption, bitrot). Диски іноді повертають неправильні дані без сигналу про помилку. RAID 5 не має контрольних сум для порівняння і приймає будь-що, що повертає диск. ZFS обчислює контрольну суму для кожного блоку при записі і перевіряє її при читанні — коли блок не проходить перевірку, ZFS реконструює його з парності і перезаписує виправлені дані. У RAID 5 таке саме пошкодження тихо потрапляє до додатка.

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

Ємність і продуктивність

Обидві конфігурації використовують одну й ту саму формулу ємності: (N − 1) × розмір диска, з мінімумом трьох дисків. П’ять дисків по 8 ТБ дають 32 ТБ корисного простору в обох випадках. Різниця полягає в поведінці при записі:

RAID 5 з апаратним кешем із батарейним резервуванням добре справляється з комбінованими навантаженнями — кеш поглинає сплески й виносить виконання циклу читання‑модифікації‑запису за межі критичного шляху. Без такого кеша затримка запису помітно зростає для дрібних випадкових записів.
RAIDZ1 показує добру продуктивність для послідовних навантажень із великими розмірами записів — зберігання медіа, резервні копії, образи віртуальних машин. Слабке місце — дрібні випадкові записи: кожен запис формує повну смугу (stripe), тож навантаження, інтенсивні за IOPS, як‑от бази даних, підходять погано без L2ARC і SLOG на швидких NVMe.
Пропускна здатність при послідовному читанні приблизно порівнянна — масив читає дані з кількох дисків паралельно, тому в цьому відношенні жодна конфігурація не має суттєвої переваги.

cURL error: Operation timed out after 180003 milliseconds with 0 bytes received

Ризик відновлення на великих дисках

На дисках більшого, ніж приблизно 4–8 ТБ, захист з одною парністю стає серйозним експлуатаційним ризиком. Процес відновлення читає кожен сектор усіх живих дисків — на диску об’ємом 16–20 ТБ це займає багато годин під підвищеним навантаженням вводу/виводу. У корпоративних дисків зазначається рівень URE ≈ 1 помилка на 10¹⁵ біт (URE — помилка непоправного читання); у споживчих дисків він приблизно в 10 разів вищий (~1 помилка на 10¹⁴ біт). Для масиву з чотирьох дисків по 12 ТБ процес відновлення читає ≈36 ТБ — натрапити на URE цілком правдоподібно, а не рідкість.

ZFS має невелику, але важливу перевагу: resilvering читає лише виділені блоки. Масив, заповнений на 40%, при відновленні читає приблизно 40% даних. Ребілд у RAID 5 завжди читає повну ємність диска незалежно від того, скільки даних фактично записано — істотна відмінність і по часу, і по ризику для частково заповнених масивів.

Практична порада: Для дисків більш ніж 8 ТБ переходьте на RAIDZ2 або RAID 6 (подвійна парність). Конфігурації з одною парністю залишаються прийнятними для менших масивів, де час відновлення не перевищує кількох годин.

Відновлення даних із RAID 5

Складність відновлення RAID 5 сильно варіюється, оскільки параметри масиву не зберігаються в універсально читабельному форматі. Апаратні контролери фіксують порядок дисків, розмір стріпу, алгоритм паритету та зсув блоку в пропрієтарних метаданих або на вбудованому NVRAM. Якщо контролер виходить з ладу, вам потрібен або ідентичний замінник (іноді з точною версією прошивки), або програмне забезпечення, яке здатне відновити конфігурацію з «сирих» даних дисків. Програмний RAID 5 через mdadm є більш портативним — суперблок на кожному диску-члені містить параметри масиву. Сам суперблок, однак, є вразливістю: його перезапис робить збирання масиву повністю ручним процесом.

Критичні кроки при відновленні RAID 5, у такій послідовності:

Перед будь-якими діями створіть сектор за сектором образи кожного диска. Робота з образами замість «живих» дисків дозволяє повторити будь-яку помилку, повернувшись до початкового стану. Це — найважливіший крок.
Не дозволяйте контролеру автоматично ініціювати відновлення (rebuild). Якщо під час цього процесу на будь-якому з живих дисків з’явиться URE (Unrecoverable Read Error — непоправна помилка читання), стріп буде втрачено назавжди. Вимкніть автоматичний ребілд, поки не отримаєте образи.
Відновіть порядок дисків — неправильний порядок дає на вигляд валідний, але корумпований масив. Схема ротації паритету у стандартному left-symmetric RAID 5 дозволяє це перевірити без гадань.
Визначте розмір стріпу — поширені значення: 64 KB, 128 KB і 256 KB. Правильний розмір дає впізнавані сигнатури файлової системи на очікуваних зміщеннях. Інструменти для відновлення автоматизують цей крок повністю.

Детальний розбір сценаріїв відмов, включно з діями на випадок, коли контролер неправильно переконфігурує масив після заміни диска, див. Як відновити дані з RAID 5.

Що обрати — і коли це має значення для відновлення

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

Обирайте RAIDZ1, якщо у вас уже працює ZFS (TrueNAS, Proxmox, кастомний Linux). Вбудовані контрольні суми, забезпечення цілісності даних за механізмом copy-on-write та портативність незалежно від контролера зменшують ймовірність безвихідної ситуації. Вихід з ладу контролера не є проблемою для пулу ZFS.
Обирайте RAID 5, якщо ваше середовище використовує апаратний RAID-контролер і не має інфраструктури ZFS. Виконуйте регулярні перевірки цілісності, перевіряйте SMART-дані на всіх дисках перед будь-яким відновленням і підтримуйте актуальну резервну копію — підтвердіть її придатність до відновлення перед початком операції з відновлення (rebuild).

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

RAIDZ1 і RAID 5 мають спільний фундаментальний ризик: друга відмова диска під час відновлення призводить до втрати даних. Для дисків понад 8 ТБ або для по-справжньому незамінних даних двопаритетні конфігурації — RAIDZ2 або RAID 6 — забезпечують запас безпеки, якого не дає одиночна парність.

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

Ні — не безпосередньо. Мітки пулу ZFS зберігаються безпосередньо на дисках і є самодостатніми, але для їхнього читання потрібна система з підтримкою ZFS. Хороша новина: ZFS працює на Linux, FreeBSD, macOS (через OpenZFS) і Windows (через WSL2 або драйвери від сторонніх розробників), тому зазвичай встановити ZFS на цільовій машині досить просто. Коли ZFS доступний, zpool import автоматично знайде пул. Оригінальне обладнання, контролер або операційна система не потрібні.

Це не теоретична, а реальна відмова, але для її виникнення потрібна певна послідовність подій: частковий запис (partial write), потім неочікувана втрата живлення (unclean power loss), а далі — друга відмова диска до того, як невідповідність буде виявлена й виправлена. На практиці це означає, що ризик при окремому інциденті низький, але він накопичується протягом років експлуатації системи без джерела безперебійного живлення (UPS). Найвразливіші масиви — ті, що працюють без кешу запису з батарейним живленням (battery-backed write cache) і без регулярних перевірок консистентності. Коли така подія відбувається, втрата є «тихою» — помилка не фіксується в момент виникнення початкової неконсистентності.

Жодна конфігурація сама по собі не захищає від програм-вимагачів — обидві представляють операційній системі змонтовану файлову систему, а програми-вимагачі шифрують усе, що ОС може записати. Практична перевага ZFS полягає в знімках: знімки ZFS створюються на рівні блоків, майже миттєві й не можуть бути змінені чи видалені процесом зі звичайними правами користувача за правильно налаштованих політик захисту знімків. Пул RAIDZ1 із знімками щоразу за годину і політикою обмеженого видалення дає точку відкату, до якої програми-вимагачі зазвичай не дістаються. RAID 5 не має еквівалентного механізму на рівні сховища.

Так, і це більш помітно в RAIDZ1, ніж у RAID 5. Оскільки кожен запис у RAIDZ1 — це повноширинний стріп (stripe), який одночасно зачіпає всі диски, операція запису не може завершитися, доки найповільніший диск у vdev не підтвердить її. Один старіючий диск із підвищеною затримкою — навіть якщо SMART‑метрики ще не показують відмови — обмежить загальну пропускну здатність запису vdev до своєї швидкості. Це іноді перший помітний симптом перед тим, як диск почне видавати помилки читання. Якщо один диск у vdev RAIDZ1 систематично показує вищу затримку вводу/виводу в zpool iostat -v, розглядайте його як кандидата на заміну до подальшого погіршення.