Дзвінок зазвичай надходить, коли панель керування зелена, а дані зникли. Масив «здоровий». База даних «працює».
І все ж фінансовий директор дивиться на пустий звіт, продуктова команда дивиться на порожнє сховище, а ви дивитесь на ту одну фразу,
яку хотіли б витатуювати в замовленні на купівлю: RAID — не резервна копія.
RAID добре робить одну річ: тримає систему в мережі під час певних видів відмов диска. Він не призначений для захисту від
видалення, корупції, ransomware, пожежі, помилкових дій людини, пошкодженого прошивання або вічного і дивного людського бажання запустити rm -rf
у неправильному вікні.
Що RAID насправді робить (і що він ніколи не обіцяв)
RAID — це схема надмірності для доступності сховища. Це все. Це спосіб продовжувати обслуговувати читання й запис, коли один диск
(а іноді й два) перестає співпрацювати. RAID про безперервність сервісу, а не про безперервність істини.
У виробничих термінах: RAID купує вам час. Він зменшує ймовірність того, що поодинокий відмов диска перетвориться на простій. Він може
покращити продуктивність залежно від рівня та навантаження. Він може спростити управління ємністю. Але він не створює окрему, незалежну,
версійну копію ваших даних. А незалежність — це слово, що рятує вашу роботу.
Доступність vs довговічність vs відновлюваність
Люди звикли кластеризувати це в одне під «безпека даних». Це не одне й те саме:
- Доступність: чи може система продовжувати працювати прямо зараз? Тут допомагає RAID.
- Довговічність: чи залишаться біти правильними з часом? RAID іноді допомагає, іноді вводить в оману.
- Відновлюваність: чи можете ви відновити відомо-правильний стан після інциденту? Це — резервні копії, знімки, реплікація та процеси.
RAID може продовжувати віддавати пошкоджені дані. RAID може точно віддзеркалити ваше випадкове видалення. RAID може з надзвичайним ентузіазмом
реплікувати блоки, зашифровані ransomware. RAID — вірний працівник. Вірний не означає розумний.
Що означає «резервна копія» в системі, яку можна захистити
Резервна копія — це окрема копія даних, яка:
- Незалежна від первинної доменної зони відмови (інші диски, інший хост, бажано інший обліковий запис/повноваження).
- Версійна, щоб ви могли повернутися до стану до події.
- Відновлювана протягом прийнятного часу (RTO) та до контрольної точки часу (RPO), яку ви можете прийняти.
- Протестована, бо «у нас є бекапи» — це не факт, поки ви не відновили з них.
Знімки та реплікація — чудові інструменти. Вони не стають автоматично резервними копіями. Вони перетворюються на резервні копії, коли є
незалежними, захищеними від тих самих адмін-помилок і ви можете відновити їх під тиском.
Жарт №1: RAID — це ремінь безпеки. Резервна копія — це швидка допомога. Якщо ви розраховуєте на ремінь безпеки, щоб зробити операцію, у вас буде довгий день.
Чому RAID не підходить як резервна копія: режими відмов, що мають значення
Причина, чому фраза «RAID — не резервна копія» повторюється, полягає в тому, що режими відмов неінтуїтивні. Відмова диска — лише один вид втрати даних.
Сучасні системи частіше втрачають дані через програмне забезпечення, людей і зловмисників, а не через одиночний диск.
1) Видалення та перезапис миттєво реплікуються
Видаліть директорію. RAID віддзеркалить видалення. Перезапишіть таблицю. RAID розподілить цю нову правду через набір. Немає «відкоту», бо робота RAID —
робити копії консистентними, а не історичними.
2) Тиха корупція, bit rot і пастка «виглядає нормально»
Диски, контролери, кабелі та прошивки можуть повертати неправильні дані без помилки. Файлові системи з контрольними сумами (як ZFS, btrfs) можуть
виявляти корупцію і, з надмірністю, часто самовідновлюватися. Традиційний RAID під файловою системою без контрольних сум на рівні блоків
може охоче повертати пошкоджені блоки і вважати це успіхом.
Навіть з контрольними сумами «від кінця до кінця», ви все ще можете пошкодити дані на вищому рівні: неправильні записі додатку, баг у процесі компактування, напівзастосовані міграції.
RAID збережe корупцію бездоганно.
3) Ransomware не цікавиться вашою парністю
Ransomware шифрує те, до чого має доступ. Якщо він має доступ до змонтованої файлової системи, він може зашифрувати ваші дані на RAID1, RAID10, RAID6,
ZFS mirrors тощо. Надмірність не зупиняє шифрування. Вона просто робить шифрування доступним.
4) Відмови контролера та прошивки тягнуть за собою масив
Аппаратний RAID додає власну домену відмов: контролер, його кеш-модуль, прошивка, батарея/суперконденсатор і формат метаданих.
Якщо контролер помирає, вам може знадобитися ідентична модель контролера та рівень прошивки, щоб коректно зібрати масив.
Програмний RAID також має домени відмов (ядро, md метадані, утиліти користувацького простору), але вони зазвичай прозоріші й портативніші.
Прозорий не означає безпечний. Це просто означає, що ви бачите ніж перш ніж на нього наступити.
5) Відновлення (rebuild) стресує систему і погіршується із збільшенням дисків
Rebuild — це зустріч математики з фізикою. Під час відновлення кожен залишковий диск читається сильно, часто майже на повну пропускну здатність, протягом годин або днів.
Це ідеальна буря для виявлення прихованих помилок на залишкових дисках. Якщо ви втратите ще один диск у RAID5 під час відновлення, масив буде втрачено.
RAID6 дає більше запасу, але відновлення все одно підвищує ризик і знижує продуктивність.
6) Людська помилка: найпоширеніший і найменш шанований режим відмови
Втомлений інженер замінює неправильний диск, витягує невірний лоток або виконує правильну команду на неправильному хості. RAID не захищає від людей. Він їх підсилює.
Одна неправильна дія реплікується з лінійною швидкістю.
7) Катастрофи на сайті та радіус ураження
RAID — локальний. Пожежа теж локальна. Як і крадіжка, проблеми з електропостачанням і «ой, ми видалили весь обліковий запис у хмарі». Реальна стратегія резервного копіювання передбачає
що ви втратите цілу домену відмови: хост, стійку, регіон або обліковий запис.
Цікаві факти та трохи історії (корисні)
Кілька конкретних фактів допомагають засвоїти тему, бо вони показують, як RAID почали сприймати як чарівну паличку.
Ось дев’ять фактів — всі доречні, жоден не романтизований.
- RAID було названо й популяризовано в статті UC Berkeley 1987 року, яка представила «надмірні масиви недорогих дисків» як альтернативу великим дорогим дискам.
- Рання маркетингова кампанія RAID сильно наголошувала на «стійкості до відмов», і багато хто тихо переклав це як «захист даних», що не є тим самим контрактом.
- Рівні RAID ніколи не були єдиним офіційним стандартом. Вендори реалізовували «RAID5» з різною поведінкою та політиками кешу, а потім сперечалися про семантику в вашому вікні простою.
- Аппаратні RAID-контролери історично використовували пропрієтарні формати метаданих на диску, тому відмова контролера може перетворитися на археологію.
- Зростання багатотерабайтних дисків зробило відновлення RAID5 надзвичайно ризиковим, бо час відновлення зростав, а ймовірність зустріти непридатний сектор під час відновлення зростала.
- URE (unrecoverable read error) широко обговорювали в 2000-х роках як практичну причину віддавати перевагу подвійній парності для великих масивів, особливо під час великих відновлень.
- ZFS (вперше випущений у середині 2000-х) ввів контрольні суми від кінця до кінця в звичайну експлуатацію, і зробив термін «bit rot» придатним для керівництва, бо це нарешті можна було виявити.
- Знімки стали звичними в корпоративних сховищах у 1990-х роках, але часто зберігалися на тому ж масиві — швидкий відкат, але не відновлення після катастрофи.
- Ransomware змінив розмову про резервні копії з «стрічка проти диска» на «іммутабельність проти повноважень», бо зловмисники навчилися спочатку видаляти резервні копії.
Три корпоративні міні-історії з реального життя
Міні-історія 1: Інцидент, спричинений хибним припущенням
Середня SaaS-компанія запустила свій первинний кластер PostgreSQL на парі висококласних серверів з аппаратним RAID10. Презентація вендора звучала
заспокійливо: надмірні диски, кеш із батарейним живленням, гарячі резерви. Команда почула «немає втрати даних» і ментально віднесла бекапи до «приємних, але необов’язкових».
Одного дня розробник запустив скрипт очищення проти production. Він мав працювати зі staging-схемою; він потрапив у живу.
За секунди були видалені мільйони рядків. База продовжувала обслуговувати трафік, і графіки моніторингу виглядали нормально — запити навіть стали швидшими,
бо даних стало менше.
Вони намагалися відновитися за допомогою «знімка» RAID-контролера, який не був знімком у файловому сенсі. Це був профіль конфігурації для поведінки кешу.
Постачальник сховища, на їхню честь, не сміявся. Просто поставив питання, що руйнує кар’єри:
«Які ваші останні відомі добрі резервні копії?»
Їх не було. Було налаштовано нічне логічне дампування місяці тому, але воно писалося на той самий RAID-том, і скрипт очищення теж видалив каталог дампів.
Компанія відновлювалася з логів застосунку і сторонніх потоків подій. Відновили більшість, але не все, і витратили тижні на виправлення тонких пошкоджень посилань.
Хибне припущення було не в «RAID безпечний». Воно було в «доступність означає відновлюваність». Вони мали високий аптайм і низьку правдивість.
Міні-історія 2: Оптимізація, що обернулася проти
Медіаплатформа була одержима продуктивністю. Вони перемістили метадані об’єктного сховища з консервативної конфігурації на широкий RAID5, щоб отримати
більше корисної ємності та кращу пропускну здатність запису в тестах. Вони також увімкнули агресивний кеш контролера для збільшення швидкості прийому.
У нормальній роботі все виглядало чудово. Глибина черг була низькою. Латентність знизилась. Керівництво отримало слайд «ефективність зберігання» для квартального звіту.
Вони спокійно спали приблизно місяць.
Потім один диск почав видавати періодичні помилки читання. Масив помітив це як «передбачувану відмову», але тримав диск онлайн. Розпочалося відновлення на гарячий резерв
у години піку, бо система була «надмірною». Це відновлення наситило залишкові диски. Латентність різко зросла, таймаути підскочили,
а повторні запити додатку створили зворотний цикл.
Посеред відновлення ще один диск натрапив на непридатний сектор. RAID5 не витримав цього під час відновлення. Контролер оголосив віртуальний диск зламаним.
Результатом була не просто відмова. Це була часткова корупція метаданих, що ускладнило та уповільнило відновлення більше, ніж чистий збій.
Оптимізація не була злою; вона була необмеженою. Вони оптимізували під ємність і бенчмарк-показники, а заплатили ризиком відновлення і більшим радіусом ураження.
Вони замінили конфігурацію на подвійну парність, перенесли вікна відновлення на непіковий час і — найважливіше — побудували позамасивний конвеєр резервного копіювання,
щоб наступна відмова була нудною.
Міні-історія 3: Нудна, але правильна практика, що врятувала ситуацію
Фінансова компанія керувала файловим сервісом для внутрішніх команд. Сховище було ZFS mirror: просте, консервативне, нецікаве.
Цікавою була їхня гігієна резервного копіювання: нічні знімки, реплікація поза сайтом в іншу адміністраторську домену та місячні тести відновлення.
Усі скаржилися на тести відновлення, бо «вони марнують час». Менеджер SRE зробив їх обов’язковими.
Ноутбук підрядника було скомпрометовано. Зловмисник отримав доступ до VPN, а потім привілейовані облікові дані для запису на мережеву шару.
Протягом ночі ransomware почав шифрувати користувацькі директорії. Оскільки шар був онлайн і записуваний, шифрування швидко поширилося.
ZFS зробив саме те, що від нього чекали: зберіг нові зашифровані блоки з цілісністю. RAID-дзеркала забезпечили, що шифрування стало довговічним.
Наступного ранку користувачі знайшли файли перейменованими та непридатними для читання. Дзеркало було «здоровим». Бізнес — ні.
Компанія відключила мережеву шару, замінила облікові дані та перевірила іммутабельну ціль резервного копіювання. Резервні копії зберігалися в окремому
середовищі з обмеженими правами на видалення і блокуванням збереження. Зловмисник не міг до них дістатися.
Відновлення не було магічним; воно було відпрацьованим. Вони відновили найважливіші директорії першими згідно з попередньо погодженим пріоритетним списком, а решту — наступного дня.
Постмортем був нудним у найкращому сенсі. Мораль теж нудна: нудні процеси перемагають красиву надмірність.
Швидкий план діагностики: знайти вузьке місце та радіус ураження
Коли щось іде не так із сховищем, команди витрачають час на суперечки щодо того, чи це «диски», чи «мережа», чи «база даних».
Правильний підхід — встановити: (1) що змінилося, (2) що сповільнилося, (3) що небезпечно, і (4) чому ви ще довіряєте.
Перш за все: перестаньте робити гірше
- Якщо підозрюєте корупцію або ransomware, заморозьте запис там, де можете: перемонтуйте в режим read-only, зупиніть сервіси, відкличте повноваження.
- Якщо масив деградований і відновлюється, розгляньте варіант зменшення навантаження, щоб уникнути другої відмови під час відновлення.
- Почніть журнал інциденту: виконані команди, часові мітки, зроблені зміни. Пам’ять — не доказ.
По-друге: визначте, чи це продуктивність, цілісність чи доступність
- Продуктивність: висока латентність, таймаути, глибина черги, iowait. Дані можуть бути ще коректними.
- Цілісність: помилки контрольних сум, корупція на рівні застосунку, несподівані зміни файлів. Продуктивність може виглядати нормальною.
- Доступність: відсутні пристрої, масиви деградовані/відмовили, файлові системи не монтуються. Система кричить.
По-третє: швидко локалізуйте домен відмови
- Хост: логи ядра, помилки диска, стан контролера.
- Стек сховища: RAID/mdadm/ZFS, стан файлової системи, стан scrub.
- Шлях IO: multipath, HBA, SAS expander, NIC, комутатори якщо використовується мережеве сховище.
- Застосунок: плани запитів, конкуренція за блокування, шторм повторів.
- Положення щодо бекапів/відновлення: чи є у вас чиста точка відновлення і чи вона доступна?
По-четверте: визначте мету
В інциденті ви повинні обрати одну провідну мету:
- Тримати сервіс працюючим (доступність): стабілізуватися, прийняти деградований режим.
- Захистити дані (цілісність): заморозити записи, зробити форензічні копії, відновити з відомо-добрих копій.
- Відновити сервіс (відновлюваність): переключитися на інший ресурс, відновити деінде, відновити з бекапів.
Ці цілі конфліктують. Вдавати, що цього немає, — як отримати працюючу систему, яка віддає неправильні дані.
Практичні завдання з командами: що виконати, що це означає, які рішення прийняти
Нижче — практичні завдання, які можна виконати на Linux-системах, щоб зрозуміти вашу надмірність і реальну відновлюваність.
Кожне завдання містить: команду, приклад виводу, що це означає і яке рішення з цього випливає.
Завдання 1: Переглянути блокові пристрої та членство в RAID
cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT,MODEL,SERIAL
NAME SIZE TYPE FSTYPE MOUNTPOINT MODEL SERIAL
sda 3.6T disk HGST_HUS726T4TAL K8H1ABCD
├─sda1 512M part vfat /boot/efi
└─sda2 3.6T part
sdb 3.6T disk HGST_HUS726T4TAL K8H1EFGH
└─sdb1 3.6T part
md0 3.6T raid1 ext4 /data
Що це означає: У вас є програмний RAID1-пристрій md0, змонтований в /data, побудований з розділів.
Рішення: Якщо ви думали, що маєте «резервні копії», то ні. Це лише надмірність. Підтвердіть, що резервні копії зберігаються окремо.
Завдання 2: Перевірити стан mdadm RAID та статус відновлення
cr0x@server:~$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdb1[1] sda2[0]
3906886464 blocks super 1.2 [2/2] [UU]
unused devices: <none>
Що це означає: [UU] означає, що обидва члени в мережі. Під час відновлення ви б бачили [U_] і рядок прогресу.
Рішення: Якщо деградовано, зменшіть навантаження і сплануйте заміну диска. Також: зробіть знімок/бекап зараз, якщо у вас немає оф-хостової копії.
Завдання 3: Отримати деталі mdadm, включно з лічильниками подій
cr0x@server:~$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Mon Oct 2 11:22:09 2023
Raid Level : raid1
Array Size : 3906886464 (3726.02 GiB 4000.79 GB)
Used Dev Size : 3906886464 (3726.02 GiB 4000.79 GB)
Raid Devices : 2
Total Devices : 2
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
Name : server:0
UUID : 1a2b3c4d:5e6f:7890:abcd:ef0123456789
Events : 12891
Number Major Minor RaidDevice State
0 8 2 0 active sync /dev/sda2
1 8 17 1 active sync /dev/sdb1
Що це означає: «clean» — добре, але це нічого не каже про те, чи файли коректні, послідовні або відновлювані.
Рішення: Використайте це, щоб підтвердити топологію та визначити, який фізичний диск відповідає якому члену перед роботою з апаратурою.
Завдання 4: Переглянути логи ядра на предмет помилок IO та скидань
cr0x@server:~$ sudo journalctl -k -S "1 hour ago" | egrep -i "ata|sas|scsi|i/o error|reset|timeout" | tail -n 8
Jan 22 10:11:41 server kernel: ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Jan 22 10:11:41 server kernel: ata3.00: failed command: READ DMA EXT
Jan 22 10:11:41 server kernel: blk_update_request: I/O error, dev sdb, sector 9175040 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
Jan 22 10:11:42 server kernel: ata3: hard resetting link
Jan 22 10:11:47 server kernel: ata3: link is slow to respond, please be patient
Jan 22 10:11:52 server kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
Що це означає: Скидання лінку та помилки IO — ранні сигнали попередження. Може бути диск, кабель, backplane або контролер.
Рішення: Розглядайте як «ризик для цілісності». Почніть свіжу резервну копію, якщо можливо; сплануйте обслуговування та ізоляцію апаратури.
Завдання 5: Запитати SMART-стан та ключові лічильники
cr0x@server:~$ sudo smartctl -a /dev/sdb | egrep -i "SMART overall|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable|Power_On_Hours"
SMART overall-health self-assessment test result: PASSED
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 12
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 2
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 2
9 Power_On_Hours 0x0032 089 089 000 Old_age Always - 41231
Що це означає: «PASSED» — не гарантія. Очікувані/офлайн-непоправні сектори важливіші. Цей диск погіршується.
Рішення: Замініть проактивно. Якщо RAID5/6, ризик відновлення зростає; плануйте відновлення з меншим навантаженням та перевіреними бекапами.
Завдання 6: Для апаратного RAID перевірити стан контролера/віртуального диска (приклад storcli)
cr0x@server:~$ sudo storcli /c0/vall show
Controller = 0
Status = Success
Description = Show Virtual Drives
DG/VD TYPE State Access Consist Cache Cac sCC Size Name
0/0 RAID5 dgrd RW No RWBD - OFF 10.913 TB data_vd0
Що це означає: Віртуальний диск dgrd (деградований). «Consist No» натякає на необхідність перевірки консистентності.
Рішення: Припиніть непотрібні записи, визначте несправні/передбачувані диски і переконайтеся, що маєте відновлюваний бекап перед відновленням.
Завдання 7: Підтвердити політику кешу запису та стан батареї/суперкапачу
cr0x@server:~$ sudo storcli /c0 show battery
Controller = 0
Status = Success
Description = Battery Status
BatteryType = iBBU
Status = Failed
Replacement required = Yes
Що це означає: Якщо захист кешу не працює, контролери часто вимикають write-back кеш або ризикують втратити підтверджені записи при відключенні живлення.
Рішення: Очікуйте змін продуктивності та потенційного ризику цілісності даних при некоректній політиці. Замініть батарею/суперкапач і перегляньте режим кешу.
Завдання 8: Виміряти, чи ви зацікавлені CPU чи IO (iostat)
cr0x@server:~$ iostat -xz 1 3
Linux 6.1.0 (server) 01/22/2026 _x86_64_ (16 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
12.34 0.00 5.12 31.45 0.00 51.09
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await aqu-sz %util
md0 85.0 5420.0 0.0 0.0 18.20 63.76 40.0 3120.0 44.10 2.90 98.7
Що це означає: Високий %iowait і %util близько 100% вказують на вузьке місце вводу/виводу. Латентність запису висока.
Рішення: Тротлити важкі завдання, перевірити чи не йде відновлення/скраб і розглянути переміщення «гарячого» навантаження з масиву під час стабілізації.
Завдання 9: Знайти процеси, що створюють найбільше IO (iotop)
cr0x@server:~$ sudo iotop -oPa -n 5
Total DISK READ: 55.43 M/s | Total DISK WRITE: 12.10 M/s
PID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
18422 be/4 postgres 40.22 M/s 8.10 M/s 0.00 % 92.00 % postgres: checkpointer
27109 be/4 root 12.11 M/s 0.00 B/s 0.00 % 15.00 % rsync -aH --delete /data/ /mnt/backup/
Що це означає: Ваше завдання бекапу та обслуговування бази даних конкурують. Це не моральна байка; це фізика.
Рішення: Переплануйте вікна бекапів/обслуговування або реалізуйте обмеження швидкості, щоб бекапи не спричиняли простої (або навпаки).
Завдання 10: Швидко перевірити помилки файлової системи (приклад ext4)
cr0x@server:~$ sudo dmesg | egrep -i "EXT4-fs error|I/O error|Buffer I/O error" | tail -n 6
[915230.112233] EXT4-fs error (device md0): ext4_find_entry:1531: inode #524301: comm nginx: reading directory lblock 0
[915230.112240] Buffer I/O error on device md0, logical block 12345678
Що це означає: Файлова система бачить помилки читання. RAID може маскувати деякі відмови, але не всі.
Рішення: Зупиніть сервіси, якщо можливо, зафіксуйте логи, заплануйте контрольований fsck (або відновлення), а не дозволяйте корупції поширюватися.
Завдання 11: Перевірити стан пулу ZFS та лічильники помилок
cr0x@server:~$ sudo zpool status -v
pool: tank
state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the faulted device, or use 'zpool clear' to mark the device repaired.
scan: scrub repaired 0B in 00:42:18 with 0 errors on Sun Jan 18 02:15:01 2026
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
mirror-0 DEGRADED 0 0 0
sdc FAULTED 0 0 8 too many errors
sdd ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
tank/data/app.db
Що це означає: ZFS виявив помилки контрольних сум і може сказати, який файл уражено. Це різниця між «ми підозрюємо» і «ми знаємо».
Рішення: Вважайте зазначені файли підозрілими. Відновіть уражені дані з бекапу або на рівні застосунку; замініть несправний диск.
Завдання 12: Перевірити знімки ZFS і не плутати їх з бекапами
cr0x@server:~$ sudo zfs list -t snapshot -o name,creation -s creation | tail -n 5
tank/data@hourly-2026-01-22-0600 Thu Jan 22 06:00 2026
tank/data@hourly-2026-01-22-0700 Thu Jan 22 07:00 2026
tank/data@hourly-2026-01-22-0800 Thu Jan 22 08:00 2026
tank/data@hourly-2026-01-22-0900 Thu Jan 22 09:00 2026
tank/data@hourly-2026-01-22-1000 Thu Jan 22 10:00 2026
Що це означає: Добре. Але якщо ці знімки живуть на тому ж пулі, вони не переживуть втрату пулу, компрометацію облікового запису або катастрофу сайту.
Рішення: Реплікуйте знімки до незалежної цілі з іншими обліковими даними і захистом від видалення.
Завдання 13: Підтвердити, що резервні копії існують і свіжі (приклад restic)
cr0x@server:~$ restic -r /mnt/backup/restic-repo snapshots --last
repository 9b2f1c12 opened (version 2, compression level auto)
ID Time Host Tags Paths
a1b2c3d4 2026-01-22 09:00:14 server /data
Що це означає: У вас є знімок резервної копії за сьогодні. Це початок.
Рішення: Валідовуйте можливість відновлення, а не лише існування. Якщо знімки перестали оновлюватися, вважайте це інцидентом.
Завдання 14: Зробити тестове відновлення одного файлу, щоб довести відновлюваність
cr0x@server:~$ mkdir -p /tmp/restore-test && restic -r /mnt/backup/restic-repo restore latest --target /tmp/restore-test --include /data/important/report.csv
repository 9b2f1c12 opened (version 2, compression level auto)
restoring <Snapshot a1b2c3d4 of [/data] at 2026-01-22 09:00:14 by cr0x@server> to /tmp/restore-test
Summary: Restored 1 files/dirs (42.133 KiB) in 0:00
Що це означає: Це момент, коли «у нас є бекапи» стає фактом. Ви успішно відновили реальний файл.
Рішення: Зробіть це регулярним завданням з випадковим вибором файлів і документуванням результатів.
Завдання 15: Перевірити, чи ваша «ціль бекапу» справді незалежна
cr0x@server:~$ mount | egrep "/data|/mnt/backup"
/dev/md0 on /data type ext4 (rw,relatime)
server:/export/backup on /mnt/backup type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2)
Що це означає: Резервні копії йдуть на NFS. Незалежність залежить від того, де тому NFS фізично знаходиться і хто може його видаляти.
Рішення: Якщо NFS знаходиться на тому самому сервері, у тій самій стійці або під тим самим набором адмін-облікових даних — це недостатньо незалежно. Виправте це.
Завдання 16: Підтвердити політику зберігання та іммутабельність на рівні файлової системи (chattr)
cr0x@server:~$ sudo lsattr -d /mnt/backup
-------------e---- /mnt/backup
Що це означає: Тут немає прапорів іммутабельності. Це може бути прийнятно, але тоді іммутабельність має забезпечуватися системою бекапів або ціллю зберігання.
Рішення: Якщо ransomware у вашій моделі загроз (а він у ній), реалізуйте блокування збереження/іммутабельність поза досяжністю основного адміністратора.
Завдання 17: Перевірити, чи ви на відстані одного опечатки від видалення бекапів (права)
cr0x@server:~$ namei -l /mnt/backup/restic-repo | tail -n 4
drwxr-xr-x root root /mnt
drwxr-xr-x root root /mnt/backup
drwxrwxrwx root root /mnt/backup/restic-repo
Що це означає: Репозиторій бекапів доступний для запису всім. Це не бекап; це громадський арт-проєкт.
Рішення: Заблокуйте права, відокремте облікові дані бекапу та розгляньте варіант append-only або іммутабельних цілей.
Завдання 18: Виявити відновлення або скраб, що тихо вбиває продуктивність
cr0x@server:~$ sudo zpool iostat -v 1 3
capacity operations bandwidth
pool alloc free read write read write
-------------------------- ----- ----- ----- ----- ----- -----
tank 2.10T 1.40T 820 210 92.1M 18.2M
mirror-0 2.10T 1.40T 820 210 92.1M 18.2M
sdc - - 420 105 46.0M 9.1M
sdd - - 400 105 46.1M 9.1M
-------------------------- ----- ----- ----- ----- ----- -----
Що це означає: Тривалі високі читання можуть вказувати на scrub/resilver або зміну навантаження. Потрібно зіставити це зі станом пулу та cron-завданнями.
Рішення: Якщо це збігається з болем користувачів, перенесіть scrubs, налаштуйте пріоритети resilver або додайте запас ємності/продуктивності.
Жарт №2: Відновлення RAID — це еквівалент «швидкої зміни в продакшні». Воно ніколи не швидке і точно все міняє.
Типові помилки: симптом → коренева причина → виправлення
Цей розділ навмисно конкретний. Загальні поради не витримують інциденту; вони просто цитуються в постмортемі.
1) «Масив здоровий, але файли пошкоджені»
- Симптоми: Помилки застосунку при читанні конкретних файлів; невідповідність контрольних сум на рівні застосунку; користувачі бачать спотворені медіа; RAID показує оптимальний стан.
- Коренева причина: Тиха корупція на диску/контролері/кабелі або застосунок записав некоректні дані. Парність/дзеркалювання RAID зберегли це.
- Виправлення: Використовуйте файлову систему з контрольними сумами (ZFS) або контрольні суми на рівні застосунку; запускайте scrubs; відновіть пошкоджені об’єкти з незалежних бекапів; замініть нестабільне обладнання.
2) «Ми не можемо відновити: другий диск відмовив під час відновлення»
- Симптоми: Віртуальний диск RAID5 відмовив під час відновлення; з’являються URE; кілька дисків мають помилки носія.
- Коренева причина: Однопарна захист плюс великі диски плюс велике навантаження читання під час відновлення; недостатній запас на латентні помилки секторів.
- Виправлення: Віддавайте перевагу RAID6/RAIDZ2 або дзеркалам для великих масивів; тримайте гарячі резерви; запускайте patrol reads/scrubs; замінюйте диски проактивно; переконайтеся, що у вас є відновлювані бекапи перед відновленням.
3) «Бекапи є, але відновлення надто повільне для RTO»
- Симптоми: Завдання бекапу повідомляє про успіх; відновлення займає дні; бізнес потребує годин.
- Коренева причина: RTO ніколи не було інженерно спроектовано; пропускної здатності цілі бекапу замало; занадто багато даних, занадто мало пріоритизації; немає поетапного плану відновлення.
- Виправлення: Визначте RTO/RPO по наборах даних; реалізуйте швидке локальне відновлення (знімки) плюс офсайтні бекапи; передзавантажуйте критичні набори; практикуйте часткові відновлення.
4) «Знімки нас врятували… поки пул не загинув»
- Симптоми: Впевнене планування знімків; потім катастрофічна втрата пулу; знімки пішли разом з ним.
- Коренева причина: Знімки зберігалися в тій самій домені відмов як первинні дані.
- Виправлення: Реплікуйте знімки на іншу систему/обліковий запис; додайте іммутабельність; вважайте «той самий хост» як «той самий радіус ураження».
5) «Ransomware зашифрував production і бекапи»
- Симптоми: Репозиторій бекапів видалено/зашифровано; збереження очищено; повноваження використано легітимно.
- Коренева причина: Система бекапів доступна/записувана тим же набором повноважень, які були скомпрометовані в production; немає іммутабельності/air gap.
- Виправлення: Розділіть облікові дані й увімкніть MFA; ролі тільки для запису; іммутабельний об’єктний лок або append-only цілі; офлайн-копія на випадок найгіршого; моніторинг подій видалення.
6) «Продуктивність впала після заміни диска»
- Симптоми: Пікові значення латентності після заміни диска; системи тайм-аутять; більше нічого не змінилося.
- Коренева причина: Rebuild/resilver наситив IO; контролер тротлить; деградований режим на парних масивах.
- Виправлення: Плануйте вікна відновлення; тротлте відновлення; перемістіть навантаження; додайте шпинделів/SSD; тримайте додатковий запас; не відновлюйте в піковий час, якщо вам не до вподоби хаос.
7) «Контролер помер і ми не можемо імпортувати масив»
- Симптоми: Диски видно, але метадані масиву не розпізнаються; інструмент вендора не бачить віртуальний диск.
- Коренева причина: Метадані апаратного RAID прив’язані до сімейства контролерів/прошивки; збій кеш-модуля; плутанина з foreign config.
- Виправлення: Стандартизуйте контролери і тримайте запасні; експортуйте конфіги контролера; надавайте перевагу програмно-визначуваному сховищу для портативності; найголовніше — майте бекапи, для відновлення яких наявність контролера не є обов’язковою.
Чеклісти / покроковий план: побудувати резервні копії, що переживуть реальність
Ось план, що працює, коли ви втомлені, недоукомплектовані й від вас все ще очікують правильних рішень.
Він суб’єктивний, бо продакшн — суб’єктивний.
Крок 1: Класифікуйте дані за наслідками для бізнесу
- Tier 0: автентифікація/ідентичність, білінг, дані клієнтів, критична база даних.
- Tier 1: внутрішні інструменти, аналітика, логи, потрібні для безпеки/форензики.
- Tier 2: кеші, артефакти збірки, відтворювані набори даних.
Якщо все «критично», то нічого не критично. Визначте RPO і RTO для кожного рівня. Запишіть це доступно для фінансів.
Крок 2: Виберіть базове правило, а потім перевищте його
Класичне правило — 3-2-1: три копії даних, на двох різних типах носіїв, одна копія поза сайтом. Це початок, не нагорода.
Для ransomware «поза сайтом» також означає «не можна видалити тими ж повноваженнями».
Крок 3: Розділяйте домени відмов навмисно
- Інше обладнання: не «інший каталог».
- Інша адміністративна межа: окремі облікові записи/ролі; production не повинен мати права видаляти бекапи.
- Інша географія: принаймні одна копія поза сайтом/стойкою/регіоном, який ви можете втратити.
Крок 4: Використовуйте знімки для швидкості, бекапи — для виживання
Локальні знімки — для швидкого «ой»: випадковість видалення, поганий деплой, швидкий відкат. Робіть їх частими з коротким періодом зберігання.
Бекапи — для випадків, коли машина, масив або обліковий запис зникли.
Крок 5: Шифруйте і автентифікуйте конвеєр бекапів
- Шифруйте в стані спокою й у транзиті (і керуйте ключами як важливими — бо вони важливі).
- Використовуйте виділені облікові дані бекапу з мінімальними правами.
- Віддавайте перевагу шляхам «тільки запис» з production до бекапу, коли це можливо.
Крок 6: Зробіть політику зберігання, а не інтуїцію
- Коротко: погодинні/щоденні для швидкого відкату.
- Середньо: щотижневі/щомісячні для бізнесових/юридичних потреб.
- Довго: щоквартальні/щорічні, якщо потрібно, зберігати дешево і іммутабельно.
Крок 7: Тестуйте відновлення серйозно
Найдорожча резервна копія — та, яку ви ніколи не відновлювали до дня потреби. Тести відновлення мають бути заплановані, зафіксовані та під відповідальністю.
Ротація відповідальності потрібна, щоб знання не жило лише в голові однієї людини.
Крок 8: Моніторте правильні речі
- Свіжість бекапів: час останнього успішного знімка по набору даних.
- Цілісність бекапів: періодична валідація або тест-відновлення.
- Події видалення: сповіщення про незвичні видалення бекапів.
- Здоров’я сховища: SMART, стан RAID, помилки ZFS, результати scrub.
Крок 9: Проведіть tabletop-вправу для найгірших сценаріїв
Практикуйте:
- Випадкове видалення (відновити директорію).
- Ransomware (припустіть, що зловмисник має production-admin права).
- Відмова контролера (припустіть, що первинний масив не відновлюваний).
- Втрата сайту (припустіть, що вся стійка/регіон пішов).
Крок 10: Вирішіть, для чого RAID потрібен (і перестаньте просити від нього роль резервної копії)
Використовуйте RAID/дзеркала/ерейжур-кодування для досягнення цілей доступності й продуктивності. Використовуйте бекапи для досягнення цілей відновлюваності.
Якщо вибір RAID керується аргументом «у нас не потрібно бекапів», ви проєктуєте архітектуру з надією.
Одна цитата, яку варто тримати над монітором
У вірі надія — не стратегія.
— генерал Джим Маттіс (часто цитують в інженерних та операційних колах)
Якщо ви будуєте сховище на надії, ви не будуєте сховище. Ви створюєте майбутній інцидент-звіт із тривалим терміном підготовки.
Питання та відповіді
1) Якщо в мене RAID1, чи потрібні мені ще бекапи?
Так. RAID1 захищає від відмови одного диска. Він не захищає від видалення, корупції, ransomware, багів контролера або втрати сайту.
RAID1 дозволяє системі продовжувати працювати під час неправильних подій.
2) Чи є знімки резервною копією?
Не автоматично. Знімки — це точки у часі, зазвичай збережені в тій самій системі. Вони стають «схожими на бекап» лише коли реплікуються
в незалежну ціль з політикою зберігання, яку неможливо випадково видалити.
3) Чи достатньо RAID6, щоб пропустити бекапи?
Ні. RAID6 зменшує ймовірність втрати масиву через відмови дисків під час відновлення. Він нічого не робить для логічних відмов (видалення, перезапис),
шкідливого ПЗ або катастрофічних подій. Бекапи потрібні, бо відмова диска — не єдина загроза.
4) А як щодо хмарного зберігання з надмірністю — чи це рахується як бекап?
Надмірність у провайдера хмари зазвичай стосується довговічності об’єктів, а не вашої здатності відновитися після власних помилок.
Якщо ви видалите або перезапишете, хмара це зробить надійно. Вам все ще потрібні версії, політики зберігання і незалежні копії.
5) Який мінімально життєздатний план резервного копіювання для малого бізнесу?
Почніть з: щоденні резервні копії в незалежну ціль, принаймні 30 днів зберігання і одна офсайтна копія. Додайте щотижневі/щомісячні версії за потребою.
Потім заплануйте тести відновлення. Якщо ви робите лише одну «просунуту» річ — робіть тести відновлення.
6) Як часто тестувати відновлення?
Для критичних систем місячно — розумна відправна точка, з меншими частковими відновленнями частіше (щотижня — добре).
Після великих змін — нового сховища, нових ключів шифрування, нового інструмента бекапу — тестуйте негайно.
7) У чому різниця між реплікацією та бекапом?
Реплікація копіює дані в інше місце, часто майже в реальному часі. Це чудово для високої доступності та низького RPO, але може миттєво реплікувати погані зміни.
Резервні копії версіоновані і зберігають історію, щоб ви могли повернутися до стану до інциденту. Багато середовищ використовують обидва підходи.
8) Як захистити бекапи від ransomware?
Розділіть облікові дані і обмежте права на видалення. Використовуйте іммутабельність/політики зберігання на цілі бекапу. Збережіть принаймні одну копію офлайн або в окремій
адміністративній домені. Моніторте підозрілі видалення і забороняйте доступ до репозиторію бекапів з звичайних хостів.
9) Чи усуває ZFS потребу в бекапах?
ZFS підвищує цілісність за допомогою контрольних сум і самовилікування (за наявності надмірності), а знімки — відмінні для швидкого відкату.
Але ZFS не зупиняє вас від видалення даних, шифрування їх або втрати всього пулу. Вам все одно потрібні незалежні бекапи.
10) Які RPO/RTO обрати?
Обирайте, виходячи з болю бізнесу, а не з бажань команди зберігання. Для Tier 0 даних RPO в межах хвилин/годин і RTO в межах годин може бути необхідним.
Для нижчих рівнів — дні можуть бути прийнятними. Головне, щоб числа були інженерно обґрунтовані та протестовані, а не оголошені.
Наступні кроки, які можна зробити цього тижня
RAID — це інструмент, щоб залишатися в мережі при певних апаратних відмовах. Він не машина часу. Він не свідок у суді. Йому байдуже,
чи дані правильні; йому важливо, щоб біти були консистентні між дисками.
Якщо ви керуєте продакшном, зробіть цього тижня такі кроки:
- Проведіть інвентаризацію сховища: рівень RAID, тип контролера, вік дисків і поведінка відновлення.
- Запишіть RPO/RTO для ваших трьох найважливіших наборів даних. Якщо не можете — у вас не план бекапів, а план надії.
- Перевірте незалежність: підтвердьте, що бекапи зберігаються поза первинною доменною зони відмови і поза досяжністю легкого видалення.
- Зробіть один тест відновлення: один файл, одну директорію і (якщо відважитесь) відновлення бази даних у тестовому середовищі.
- Налаштуйте оповіщення про свіжість бекапів і аномалії видалень, а не лише про стан дисків.
А потім, і лише потім, насолоджуйтеся своїм RAID. Він корисний, коли ви ставитеся до нього чесно: як до надмірності, а не як до порятунку.