RAID на VPS: нужен ли он и что важнее

RAID часто подают как главную гарантию сохранности данных. На деле для VPS важнее понять, что RAID делает, а чего не делает, и почему бэкапы плюс NVMe нередко значат больше, чем красивая аббревиатура в описании тарифа.

Что такое RAID и что он решает

RAID объединяет несколько физических дисков в один массив ради надёжности и/или скорости. На стороне провайдера ноды почти всегда строятся на RAID, чтобы отказ одного диска не уронил десятки клиентских VPS. Это инфраструктурная защита от аппаратного отказа диска — и только.

Важно понимать, чего RAID не делает: он не спасает от удаления файла, взлома, ошибочного rm -rf, повреждения БД или шифровальщика. Ошибка мгновенно отражается на всех дисках массива. Поэтому RAID — не замена бэкапам, а дополнение к ним.

Уровни RAID кратко

• RAID 0 — только скорость, без избыточности. Отказ любого диска — потеря всех данных. Для хранилища не годится.
• RAID 1 — зеркало: данные на двух дисках. Переживает отказ одного диска. Просто и надёжно.
• RAID 10 — зеркало + чередование. Надёжность RAID 1 плюс скорость. Стандарт для серьёзных нод.
• RAID 5/6 — избыточность на чётности, экономит диски, но медленнее на запись. На NVMe-нодах применяют реже.

Для клиента VPS уровень RAID на ноде — вопрос к провайдеру. Хороший ответ — RAID 1 или RAID 10 на NVMe.

Почему NVMe + бэкапы важнее уровня RAID

Для реального проекта надёжность данных складывается из двух вещей: массив на ноде переживает отказ диска, а бэкапы переживают всё остальное (ошибки, взломы, порчу данных). RAID закрывает только первое.

MAATRIX использует NVMe-хранилище на быстрых нодах и делает ежедневные бэкапы — это и есть рабочая связка: скорость NVMe для нагрузки плюс ежедневная точка восстановления на случай любой катастрофы, не только отказа диска.

NVMe при этом снимает главный минус классических RAID из HDD — низкую скорость случайного доступа. На NVMe даже без экзотических уровней массива диск не становится узким местом.

Как проверить диск на своём VPS

Скорость и здоровье диска проверяются за пару минут. Ставим fio — стандарт для тестов ввода-вывода.

apt install -y fio

# случайное чтение/запись 4k — самый показательный тест для БД и веба
fio --name=randrw --ioengine=libaio --direct=1 \
    --rw=randrw --bs=4k --size=1G --numjobs=4 \
    --runtime=60 --group_reporting

# линейная скорость записи
dd if=/dev/zero of=testfile bs=1M count=2048 oflag=direct
rm -f testfile

Смотрим IOPS и пропускную способность. На NVMe случайные 4k-операции измеряются десятками и сотнями тысяч IOPS — на порядок выше, чем на SATA SSD, и несопоставимо с HDD.

Заодно проверьте задержку диска — для баз данных она важнее «крупной» пропускной способности. Отдельный тест latency на очереди глубиной 1 показывает, как быстро диск отвечает на одиночный запрос:

fio --name=lat --ioengine=libaio --direct=1 \
    --rw=randread --bs=4k --iodepth=1 --size=512M \
    --runtime=30 --group_reporting

Смотрим строку clat (completion latency). На NVMe она измеряется десятками микросекунд, на HDD — миллисекундами, то есть в сотни раз медленнее. Именно эта разница делает базу данных и загрузку страниц отзывчивыми.

Проверяем свои бэкапы

Бэкап, который никто не проверял восстановлением, — это не бэкап, а надежда. Регулярно убеждайтесь, что дамп реально разворачивается. Достаточно раз в месяц поднять копию на тестовой базе:

# проверка целостности gzip-дампа без распаковки на диск
gunzip -t /backup/mydb_2026-07-09.sql.gz && echo OK

# пробное восстановление в отдельную БД
createdb -U postgres mydb_restore_test
gunzip -c /backup/mydb_2026-07-09.sql.gz | psql -U postgres mydb_restore_test

Если восстановление проходит без ошибок и данные на месте — стратегия рабочая. Ежедневные бэкапы на стороне провайдера (как у MAATRIX) снимают рутину, но собственный проверенный дамп базы даёт гранулярный откат под ваш контроль.

Правильная стратегия сохранности данных

• RAID на ноде (задача провайдера) — защита от отказа диска.
• Ежедневные бэкапы — защита от ошибок, взломов и порчи данных.
• Свои дампы БД вне сервера — на случай, если нужен гранулярный откат.

# свой ежедневный дамп PostgreSQL в cron
0 3 * * * pg_dump -U postgres mydb | gzip > /backup/mydb_$(date +\%F).sql.gz

Частые вопросы