Відповідь одразу: Ext4 стандартно не обчислює контрольні суми вмісту блоків даних. Коли сховище повертає читабельні, але неправильні дані, ext4 не має з чим їх порівняти — файл відкриється, скопіюється й потрапить у резервну копію, тільки в ньому вже не буде оригінальних даних. Btrfs і ZFS контрольні суми даних мають і під час scrub пошкодження виявлять; виправити його вони зможуть лише там, де існує друга справна копія — тобто при резервованому масиві. Жоден із них не замінює окрему резервну копію.
Ext4 — не погана файлова система. Вона швидка, зріла і після зникнення живлення відновлюється надійно. Але для корпоративного NAS має одну конкретну слабкість, яка проявляється саме тоді, коли вже пізно: вона не вміє сказати, що вміст файлу змінився. Цей текст про те, як виникає тиха помилка, чому ext4 її не бачить і що з цього випливає для вибору й налаштування NAS.
Що означає тихе пошкодження даних
Між магнітною поверхнею пластини диска й застосунком, що відкриває файл, стоїть ціла низка проміжних ланок: прошивка диска, його кеш, кабелі SATA чи SAS, контролер NAS, рівень RAID, RAM і нарешті файлова система. Помилка може виникнути будь-де в цьому ланцюжку.
Частина несправностей є «гучною» і видимою. Диск повідомляє про нечитабельний сектор, випадає з масиву, у SMART з’являються Reallocated або Pending сектори. З цим можна працювати — система знає, що щось не спрацювало.
Гірше, коли весь ланцюжок вважає помилковий блок абсолютно справним. Ніде не засвітиться індикатор. На практиці це виглядає так:
- архів ZIP чи 7z повідомляє про помилку CRC, і частину файлів із нього не вдається розпакувати,
- фотографія має посередині зміщену кольорову смугу,
- старіший PDF відкривається з повідомленням про пошкоджену структуру,
- диск віртуальної машини перестає завантажуватися,
- база даних під час читання сторінки виявляє розбіжність власної контрольної суми,
- програма резервного копіювання без верифікації перезаписує досі справну копію пошкодженою версією.
Останній пункт — найпідступніший. Ротація резервних копій у цей момент активно працює проти вас — тиха помилка копіюється так само слухняно, як і правильні дані, і за кілька циклів вже нема звідки взяти справну версію.
Для цього явища зазвичай використовують термін «bit rot», але він оманливий. Він натякає на поступове старіння носія, тоді як причиною так само часто буває несправна RAM, помилка прошивки, проблема з живленням або некоректний запис, який стався ще місяці тому. Масштабні вимірювання на продакшн-масивах описали це явище вже давно — найчастіше цитують дослідження CERN і роботу NetApp/University of Wisconsin над статистикою мільйонів дисків. Конкретні цифри втім відрізняються залежно від типу обладнання, і їх не можна переносити на малий корпоративний NAS як «ймовірність втрати даних».
Важливо інше: SMART на цей тип помилки не відповість. SMART описує стан пристрою та події, які диск сам зафіксував, — а не правильність вмісту вашого договору. Як читати SMART і що з нього насправді можна дізнатися, розбираємо у статті як розпізнати, що HDD помирає.
Чому журналювання ext4 недостатньо
Журнал ext4 вирішує зовсім інше завдання, ніж те, якого від нього очікують люди. Він стежить, щоб після перерваного запису не залишилися напівзавершені зміни метаданих — щоб у каталозі не висів запис про файл, блоки якого ніхто ніколи не виділив. Це узгодженість структури, а не правильність вмісту.
Сучасна ext4 вміє рахувати контрольні суми метаданих і журналу (функція metadata_csum, у сучасних дистрибутивах увімкнена в mkfs за замовчуванням). Це означає, що пошкоджений inode або зламаний блок каталогу система розпізнає. Але це не означає наскрізну контрольну суму користувацьких даних — її ext4 не веде. Коли сховище для певного блока повертає інший, але й далі читабельний вміст, ext4 не має еталона, з яким могла б його звірити. Тож вона просто не має як дізнатися, що щось не так, і мовчить.
Цю прогалину не закриває навіть fsck. Він перевіряє структуру: каталоги, бітові карти розподілу, inode, кількість посилань. Йому байдуже, чи має у файлі стояти сума 120 000 Kč, чи перевернувся всередині один біт.
До того ж його не можна запускати просто так. Перевірка вимагає відключеного тому:
umount /dev/vas_svazek
e2fsck -f /dev/vas_svazekЦе простій і необхідність влучити в правильний пристрій. На NAS з лінуксовим RAID, LVM або пропрієтарним рівнем виробника цю команду не запускайте без знання конкретної архітектури — розшарування пристроїв там виглядає інакше, ніж у вебінтерфейсі.
Що додатково роблять Btrfs і ZFS
Btrfs зберігає контрольні суми даних і метаданих в окремих деревах, відокремлених від блоків, які вони описують. ZFS вбудовує контрольну суму кожного блока в його батьківський покажчик, тому під час читання перевіряє весь ланцюжок від кореня дерева аж до даних. Деталі реалізації різняться, але наслідок однаковий: якщо обчислена сума не збігається зі збереженим значенням, система знає, що прочитаному блоку довіряти не можна, і повідомляє про помилку замість того, щоб передати його застосунку.
Тут варто розділити дві речі, які в маркетингових матеріалах часто зливаються в одне. Виявлення працює навіть на одному диску. Виправлення — ні. Системі потрібно звідкись узяти правильну копію — друге дзеркало, іншого учасника масиву, паритет у RAIDZ. На односковому томі Btrfs точно назве вам пошкоджений файл і відмовиться його видати, але оригінальний вміст з нічого не створить. Що все одно краще, ніж ext4, яка видасть вам його пошкодженим, вдаючи, що все гаразд.
| Характеристика | ext4 | Btrfs | ZFS |
|---|---|---|---|
| Контрольні суми метаданих | Так (metadata_csum) | Так | Так |
| Контрольні суми вмісту файлів | Стандартно ні | Так | Так |
| Онлайн-scrub даних під час роботи | Ні в такому обсязі | Так | Так |
| Самовідновлення даних з резервної копії | Ні на рівні FS | Так, якщо є резервування | Так, якщо є резервування |
| Вбудовані знімки (snapshot) | Ні | Так | Так |
| Де зустрінете в готових NAS | QNAP QTS та інші | Synology DSM, Linux | QuTS hero, TrueNAS |
Scrub: перевірка, яка справді має виконуватися
Контрольні суми самі собою нічого не пильнують. Перевіряється лише той блок, який хтось прочитає. Файл, до якого три роки ніхто не звертався, може бути пошкоджений, а система про це не знає — доки хтось не прочитає його цілком. Саме це й робить scrub: проходить збережені дані, перераховує суми й порівнює їх. Якщо знаходить розбіжність і існує правильна резервна копія, пошкоджений блок перезаписує правильним вмістом і фіксує це.
На Linux з Btrfs:
btrfs scrub start -Bd /data
btrfs scrub status /data
btrfs device stats /dataУ ZFS:
zpool status -v tank
zpool scrub tank
zpool status tank/data і tank — лише приклади: на продакшн-сховищі спершу перевірте реальний mountpoint і назву pool. У Synology DSM те саме сховано в Storage Manager під Data Scrubbing, і це можна поставити за розкладом.
Як відправна точка розумний scrub раз на місяць. Але конкретний графік залежить від ємності, швидкості дисків і робочого навантаження. Врахуйте, що на заповненому масиві він триває від годин до днів і весь цей час навантажує всі диски безперервним читанням.
І одне рішуче попередження: scrub не запускайте в момент, коли масив перебуває в режимі Degraded, Volume Crashed або Read-Only. Безперервне читання всіх дисків — це саме те навантаження, під яким остаточно доб’єте й так ослаблений масив, той самий механізм, через який rebuild часто вбиває RAID-масив. Порядок дій для вже пошкодженого Synology зі статусом Storage Pool Degraded і QNAP з RAID Group Degraded розбираємо окремо.
Чим відрізняються Synology, QNAP і TrueNAS
Synology. Btrfs підтримують передусім орієнтовані на бізнес серії з позначенням Plus — наприклад DS224+ або DS923+. Доступність втім завжди перевіряйте у специфікації конкретної моделі й версії DSM, це не властивість усього бренду. Важлива технічна деталь: Synology не об’єднує диски нативним Btrfs RAID. Btrfs у них лежить над лінуксовим програмним RAID (md) і LVM. Щоб це разом мало сенс, Synology додало шлях, яким Btrfs при розбіжності контрольної суми запитує другу копію з рівня RAID під собою. Це працює лише за увімкнених контрольних сум для конкретної спільної папки й за наявності резервованого масиву — обидві умови потрібно перевірити, а не припускати.
QNAP. Серія TS-464 і чимало інших моделей QTS працюють на ext4. Захисту вмісту файлів там просто немає. ZFS QNAP пропонує в окремій системі QuTS hero, наприклад у серії TVS-h674. Тож недостатньо купити «QNAP на чотири відсіки» — вирішує модель, встановлена операційна система і спосіб, яким створюється pool. Міграція між QTS і QuTS hero — не перемикач; вона означає перенесення даних.
TrueNAS SCALE. Будується на OpenZFS і дає найбільший контроль над проєктуванням дзеркал, RAIDZ, знімків і реплікації. За це платите необхідністю на цьому розумітися. Для малої фірми має сенс там, де є постачальник, який рішення спроєктує, задокументує і стежитиме за його станом — а не як коробка, яку хтось один раз наклацав і закрив.
Скільки коштує цей захист
Контрольні суми безкоштовні — вони вже в файловій системі. Платите за те, що потрібно для виправлення: резервну ємність, достатньо відсіків, RAM, резервне джерело живлення і другу локацію для резервної копії.
У дводискового дзеркала отримаєте приблизно половину повної ємності. RAIDZ1 або масив з одинарною парністю коштує вам ємність одного диска, RAIDZ2 або масив з подвійною парністю — ємність двох. Для корпоративних документів NAS на чотири відсіки зазвичай розумніший вибір, ніж найдешевша модель на два відсіки — дозволяє стійкішу конфігурацію й подальше розширення, а різниця в ціні самого корпусу проти цінності даних мала. Диски, зовнішнє сховище для резервних копій і роботу з міграцією рахуйте окремо.
Для ZFS доречна ECC-пам’ять, особливо для важливих корпоративних даних. Інтернет-легенда про те, що ZFS без ECC нищить дані, не відповідає дійсності — але діє проста логіка: контрольна сума обчислюється в RAM, тож помилка в RAM запишеться в pool як «правильна». ECC цей ризик знижує. І якщо у вас немає конкретної причини й прорахованих вимог до пам’яті, тримайте ZFS-дедуплікацію вимкненою; її навантаження на пам’ять — найчастіша причина того, що малий pool стає непридатно повільним.
Які диски й конфігурації мають сенс
Обирайте диски, призначені для безперервної роботи в масиві — WD Red Plus або Red Pro, Seagate IronWolf та IronWolf Pro, Toshiba N300. Для кожного конкретного позначення моделі перевірте технологію запису; у нижчих ємностях у минулому траплялися диски SMR, які в RAID під час rebuild поводяться проблематично. Різницю між CMR і SMR та порівняння окремих серій маємо у статтях CMR проти SMR і WD Red проти Seagate IronWolf проти Toshiba N300.
WD Purple у NAS для документів не належить, навіть якщо він такого ж розміру й дешевший. Він створений для систем відеоспостереження, і його прошивка оптимізована на безперервний запис відео, де невелика втрата кадру допустима. Для баз даних і віртуальних машин це не заміна.
Що перевіряємо під час проєктування:
- чи система взагалі використовує контрольні суми даних,
- чи захист увімкнено і для конкретних спільних папок, а не лише теоретично на томі,
- яка резервованість дозволить самовідновлення, а не лише переживе відмову диска,
- чи scrub справді планується і доводиться до кінця,
- куди надходять сповіщення і чи хтось їх читає,
- чи NAS підключений до UPS і чи вміє коректно вимикатися,
- чи існує окрема резервна копія і чи проводилося тестове відновлення.
Для нативного Btrfs у випадку важливих даних обирають RAID1 або RAID10. Профілі Btrfs RAID5/6 мають давно відому проблему з write hole, і в upstream-документації позначені як небажані для продакшену — як автоматичний вибір для корпоративного NAS вони не годяться.
RAID, знімок і резервна копія вирішують різні несправності
Це те місце, де найчастіше помиляються в міркуваннях, а не в конфігурації:
- RAID підтримує роботу при відмові певної кількості дисків.
- Контрольні суми виявляють, що вміст змінився.
- Знімок (snapshot) дозволяє повернутися до старішої версії.
- Резервна копія рятує дані, коли зникає або компрометується весь NAS.
Жоден із цих рівнів не замінює інші. Знімок на тому самому NAS — це не резервна копія: він зникає разом із pool, пристроєм і зламаним обліковим записом адміністратора. Навіть Btrfs і ZFS не захистять від ransomware, якщо зловмисник отримає права видаляти знімки й репліки; як виглядає такий перебіг подій, описуємо у статті про ransomware на NAS. Тому поряд із локальними знімками вам потрібна окрема копія: другий NAS, об’єктне сховище з відповідною ретенцією або офлайн-носій — і принципи резервного копіювання 3-2-1 діють і для фірми з NAS. Відновлення тестують, а не припускають, що воно спрацює.
Як розпізнати якісно спроєктований NAS
Постачальник не повинен передавати вам лише коробку з блимаючим RAID. Частиною передавання має бути:
- опис дисків, pool, томів і спільних папок,
- де саме увімкнені контрольні суми,
- графік scrub, SMART-тестів і резервного копіювання,
- сповіщення, налаштовані на конкретну відповідальну особу,
- протокол тестового відновлення кількох файлів,
- документація доступів і можливість передати іншому адміністратору,
- план дій на випадок несправного диска та деградованого масиву.
ITHOPE вміє ще перед купівлею оцінити обсяг даних, потрібний час відновлення, сумісність дисків і необхідний рівень резервування. Результатом має бути задокументоване рішення, про яке ви знаєте, що воно захищає, чого не захищає і скільки коштуватиме його експлуатація.
QUICK ANSWER
Для NAS із важливими корпоративними даними Btrfs має проти ext4 одну принципову перевагу: контрольні суми вмісту файлів і scrub, який виявляє тихе пошкодження раніше, ніж воно встигне поширитися в резервні копії. ZFS забезпечує такий самий захист і значно потужніше керування сховищем, але вимагає продуктивнішого обладнання й досвідченішого адміністрування. Виявлення працює навіть на одному диску, виправлення — лише за наявності резервування. Жодна із систем не замінить окрему резервну копію.
FAQ
Чи розпізнає ext4 пошкоджений файл?
Лише тоді, коли помилка проявляється як нечитабельний блок, або коли її помічає сам застосунок власним контрольним механізмом — наприклад архіватор через CRC чи база даних через контрольну суму сторінки. Ext4 стандартно не звіряє вміст блоків даних зі збереженою контрольною сумою.
Чи виправить Btrfs пошкоджені дані на одному диску?
Виявить їх і відмовиться видавати, але без другої правильної копії їй нема з чого відновлювати. Для самовідновлення даних потрібне резервоване сховище — дзеркало або масив із парністю.
Чи ZFS завжди краща за Btrfs?
Ні. ZFS має досконаліше керування pool, контроль цілісності й реплікацію, але висуває вищі вимоги до проєктування, RAM і адміністрування. Для меншої фірми зазвичай практичніший підтримуваний Synology з Btrfs, якщо в нього правильно налаштовані scrub, сповіщення та резервне копіювання.
Як часто запускати scrub на NAS?
Раз на місяць — розумна відправна точка. Термін коригуйте залежно від розміру сховища, робочого навантаження й рекомендацій виробника. При деградованому масиві не запускайте scrub без попередньої діагностики.
Чи захищають Btrfs або ZFS від ransomware?
Контрольні суми — ні: зашифрований файл із погляду файлової системи є коректно записаним файлом. Знімок може допомогти повернутися до стану перед атакою, але лише якщо зловмисник не може його видалити. Потрібні окремі облікові дані доступу, відповідна ретенція і резервна копія поза межами основного NAS.