Скільки триває відновлення RAID 6 або RAIDZ2 з дисками 20 TB?

Чому максимальна швидкість диска — це лише найкращий випадок?

Бо максимальна швидкість тримається лише на зовнішніх доріжках. У даташиті Western Digital HC560 максимальні 291 MB/s припадають приблизно на 10% усередину диска. Внутрішні доріжки проходять під головкою повільніше, тож у середньому за повний прохід виходить менше.

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

Відбудова ніколи не перевершить один диск, що пише від початку до кінця.

Чому відбудова mdadm іде повільніше за диск?

Бо md її обмежує. У вихідному коді ядра Linux speed_limit_max за замовчуванням дорівнює 200 000 KiB/s, приблизно 204,8 MB/s, а speed_limit_min — 1 000 KiB/s. У посібнику md пояснено цю пару: md сповільнює відновлення, коли є інша активність, і працює на повній швидкості, коли масив простоює.

Тож зайнятий масив може відбудовуватися близько до нижньої межі. При 1 000 KiB/s диск на 20 TB відбудовувався б приблизно 226 днів. Реальні масиви лежать між цими двома межами, залежно від того, скільки трафіку резервного копіювання чи читання конкурує.

Це можна спостерігати й керувати ним:

# progress, speed and time left
cat /proc/mdstat

# current limits, in KiB/s
sysctl dev.raid.speed_limit_min dev.raid.speed_limit_max

# let the rebuild use more of the disks during a quiet period
sysctl -w dev.raid.speed_limit_min=100000
sysctl -w dev.raid.speed_limit_max=500000

Чи ZFS resilver швидший за відбудову RAID 6?

Часто так, якщо пул не заповнений. У посібнику OpenZFS сказано, що resilver перевіряє лише дані, які ZFS вважає застарілими. Пул, заповнений наполовину, відбудовує приблизно половину байтів, які скопіював би mdadm.

Щоправда, читання менш упорядковане. У посібнику OpenZFS з dRAID зазначено, що raidz мусить використовувати лікувальний resilver, який обходить дерево блоків випадковими читаннями. Тож повний пул RAIDZ2 може відбудовуватися довше, ніж підказують байти.

dRAID змінює картину для великих масивів. Його послідовна відбудова на розподілений spare масштабується за кількістю дисків, поділеною на ширину stripe. Потім scrub перевіряє контрольні суми. З десятьма дисками зазвичай обирають простий RAIDZ2; компроміси описано на ZFS чи апаратний RAID.

Спостерігайте за resilver командою zpool status. Параметр zfs_resilver_min_time_ms, за замовчуванням 1 500 ms у поточному посібнику, задає, скільки ZFS працює над ним між групами транзакцій.

Наскільки ризиковане вікно відбудови?

Мале для RAID 6, більше для RAID 5. Під час відбудови RAID 6 у масиві ще лишається одна парність, тож ще одна відмова переживеться.

Backblaze у звіті за Q2 2026 виміряв річну відмовність 1,41% за весь строк служби своїх дисків. За 27-годинну відбудову дев'ять дисків, що лишилися, дають приблизно 0,04% шансу ще однієї відмови. За 111 годин — приблизно 0,16%.

Нечитні сектори важать більше. Seagate оцінює Exos X20 у щонайбільше один на 10^15 прочитаних бітів. Відбудова з дев'яти дисків на 20 TB читає 1,44 × 10^15 бітів, тож специфікація допускає більше ніж один поганий сектор. RAID 6 виправляє його з другої парності; у RAID 5 нічого не лишається. Повне порівняння на RAID 6 чи RAID 10.

З 23 продавців серверів для зберігання, яких Basalthold перевірив на 2 November 2026, 8 пропонували план на 100 TB або більше. За такого розміру відбудова кожного диска займає майже добу навіть на повній швидкості.

Як скоротити відбудову на орендованому сервері?

Запускайте рано і дайте їй диски.

• Швидко замініть диск. Коли диск виходить з ладу, відкрийте тікет: команда замінить його безкоштовно, а перебудувати масив на новому диску — це вже налаштування на вашому боці. Відлік починається, коли новий диск на місці.
• Призупиніть важкі задачі. Виведіть великі прогони резервного копіювання з вікна відбудови або підвищуйте speed_limit_min уночі.
• Тримайте пул незаповненим. ZFS відбудовує лише збережені дані, тож вільне місце скорочує resilver.
• Тримайте другу копію. Відбудова захищає від ще однієї відмови, а не від пожежі чи помилки: Сервер зберігання не є резервною копією самого себе: ми не зберігаємо копію ваших даних деінде, тому друга копія в іншому місці залишається вашим завданням. Ціль для неї описано на offsite backup для NAS.