Резервное копирование серверов: как выстроить стратегию бэкапов

Один из самых частых сценариев, с которым сталкивается бизнес после потери данных: «У нас же RAID, как так вышло». RAID действительно защищает от отказа одного физического диска, но он бессилен против случайного удаления файла сотрудником, шифровальщика, ошибки в приложении, которая тихо портит данные, или пожара в серверной. Разберём, как выстроить стратегию бэкапов, которая закрывает эти риски.

RAID — это не резервная копия

Стоит закрыть этот вопрос сразу, потому что путаница встречается постоянно. Мы разбирали логику RAID подробно в статье RAID 1, 5, 6, 10 для сервера — сравнение: RAID защищает от физического отказа диска, реплицируя или распределяя данные между несколькими накопителями. Но если файл удалён, зашифрован вирусом или испорчен ошибкой в приложении — RAID честно реплицирует эту же порчу на все диски массива, потому что для него это просто ещё одна операция записи. Резервная копия — единственная защита именно от этого класса проблем.

Правило 3-2-1 как отправная точка

Это не жёсткий стандарт, а проверенная временем эвристика, от которой удобно отталкиваться при построении своей схемы:

• 3 копии данных — оригинал плюс минимум две резервные копии

• 2 разных типа носителей — например, локальный дисковый массив и лента или облачное хранилище, чтобы одна и та же неисправность не могла повредить оба варианта одновременно

• 1 копия хранится территориально отдельно — на случай пожара, затопления или кражи оборудования из серверной

Дальше схему можно и нужно адаптировать под масштаб бизнеса — но если вы не знаете, с чего начать, 3-2-1 закрывает подавляющее большинство сценариев потери данных.

RPO: сколько данных вы готовы потерять

RPO (Recovery Point Objective) — это не про скорость восстановления, а про то, на какой момент времени вы способны откатиться. Если бэкапы делаются раз в сутки в полночь, а сбой произошёл в 17:00, RPO в этом случае — весь рабочий день: все изменения с полуночи до момента сбоя будут потеряны безвозвратно.

Для базы данных, где каждая транзакция — это реальные деньги (например, база 1С с проводками), RPO в сутки часто неприемлем — здесь нужны более частые инкрементные копии или журналирование транзакций в реальном времени. Для файлового хранилища с документами, которые меняются нечасто, суточного RPO может быть вполне достаточно.

RTO: как быстро нужно вернуться в строй

RTO (Recovery Time Objective) — сколько времени бизнес может позволить себе простоять после сбоя, прежде чем восстановление станет критичным. Час простоя для интернет-магазина в высокий сезон и час простоя для внутренней файловой шары бухгалтерии — совершенно разные по цене события. Мы разбирали, как стоимость простоя входит в общую стоимость владения оборудованием, в статье про TCO серверного оборудования.

RPO и RTO стоит определять не «на глаз», а осознанно для каждой системы отдельно — почтовый сервер, файловое хранилище и база 1С почти всегда требуют разных значений обоих параметров.

Типы резервного копирования

• Полное копирование (Full) — снимок всех данных целиком. Самое надёжное и простое для восстановления, но самое медленное и затратное по месту хранения.

• Инкрементное копирование (Incremental) — сохраняет только изменения с момента последней копии, любой — полной или инкрементной. Быстрое и компактное, но восстановление требует последовательного применения всей цепочки копий, что увеличивает RTO.

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

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

Куда хранить копии

Правило «2 типа носителей» из схемы 3-2-1 на практике обычно реализуется так:

• Локальное хранилище — дисковая полка или отдельный сервер хранения, физически отдельный от основного массива. Дисковые полки под эту задачу мы разбирали в статье Дисковые полки HPE и Dell — быстрое восстановление именно с локальной копии в большинстве случаев.

• Территориально отдельное хранилище — облако, второй офис, дата-центр в другом городе. Медленнее для восстановления, но защищает от физических рисков на основной площадке.

• Холодное хранилище (лента, отключённые диски) — устойчиво к сетевым атакам, потому что физически недоступно системе большую часть времени. Особенно ценно как защита от шифровальщиков, которые целенаправленно ищут и шифруют подключённые сетевые бэкапы.

Тестирование бэкапов — шаг, который чаще всего пропускают

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

Ориентировочная схема по уровню критичности

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

Достаточно ли резервного копирования в облако без локальной копии? Только облако замедляет восстановление при крупном сбое — объём данных, который нужно скачать обратно, может занять часы или дни в зависимости от канала связи. Локальная копия для быстрого восстановления и облачная или территориально отдельная — для защиты от катастрофических сценариев — комбинация обычно надёжнее, чем что-то одно.

Как часто нужно менять схему бэкапов? Пересматривайте её при любом значимом изменении инфраструктуры — новая критичная система, рост объёма данных, изменение требований бизнеса к допустимому простою.

Защищает ли резервное копирование от шифровальщиков? Только если копии физически или логически изолированы от основной сети — иначе шифровальщик, добравшийся до сети, может зашифровать и подключённые резервные копии тоже. Холодное хранение или неизменяемые (immutable) копии — стандартная защита именно от этого сценария.

Если планируете организовать резервное копирование под новую или существующую инфраструктуру — напишите нам, поможем подобрать сервер хранения или дисковую полку под нужный объём и скорость восстановления.