8 июля 2026 10 минут чтения

Бэкап, который действительно спасёт

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

Про резервное копирование вспоминают дважды: когда его настраивают и когда оно понадобилось. Между этими моментами обычно проходят годы, за которые успевает поменяться всё - объёмы, серверы, ответственные. Поэтому вопрос «есть ли у нас бэкап» почти бессмысленный. Правильный вопрос: когда вы в последний раз восстанавливались из него.

Два числа, с которых всё начинается

Прежде чем выбирать софт, нужно ответить на два вопроса бизнеса. Из ответов вытекает вся схема.

  • RPO - сколько данных допустимо потерять. Если копия снимается раз в сутки ночью, то авария в 17:00 стоит вам рабочего дня всей компании.
  • RTO - сколько времени допустимо восстанавливаться. Развернуть сервер из копии на новом железе - это часы, а иногда сутки.

Эти числа определяют бюджет. Потеря часа данных стоит одних денег, потеря суток - совсем других, и наоборот: непрерывная репликация дороже ночного копирования в разы.

Что защищаем Разумный RPO Разумный RTO
База 1С у торговой компании 1 час 2-4 часа
Файловый сервер с документами 1 сутки 1 рабочий день
Почта 1 час 4 часа
Сайт и интернет-магазин 1 сутки 2-4 часа
Рабочие места сотрудников 1 сутки 1-2 рабочих дня

Правило 3-2-1

Классика, которая не устарела: три копии данных, на двух разных типах носителей, одна из них вне офиса.

  • Три копии - оригинал плюс два бэкапа. Одна копия ломается вместе с тем, на чём лежит.
  • Два носителя - например, дисковый массив в серверной и облачное хранилище. Один тип носителя имеет один тип отказа.
  • Одна вне офиса - потому что пожар, залив и кража забирают всё, что стоит в одной комнате.

Современное дополнение к правилу: одна копия должна быть неизменяемой. Об этом дальше.

Защита от шифровальщика

Главная причина, по которой бэкапы перестали спасать - шифровальщики научились искать резервные копии. Вредонос заходит под учётной записью администратора, находит сетевую папку с бэкапами и шифрует её вместе со всем остальным. Компания обнаруживает, что копии есть, но открыть их нельзя.

  • Отдельные учётные данные для системы копирования. Пароль от бэкапа не должен совпадать с доменной учёткой администратора.
  • Хранилище не должно быть примонтировано как обычная сетевая папка на рабочих серверах.
  • Неизменяемые копии. Режим, при котором файл нельзя удалить или переписать до истечения срока, даже с правами администратора.
  • Офлайн-копия. Внешний диск, который физически отключают после копирования, до сих пор остаётся самым надёжным вариантом.

Шифровальщики часто сидят в сети неделями до момента запуска. Поэтому глубина хранения важнее частоты: если вы держите копии за 7 дней, а вредонос активировался на 14-й день после проникновения, все ваши копии уже заражены. Разумный минимум - месяц, плюс ежемесячные срезы за год.

Проверка восстановления

Успешное завершение задания копирования не означает, что из копии можно восстановиться. Проверять нужно именно восстановление, и по расписанию.

  • Раз в месяц - выборочное восстановление нескольких файлов и одной базы в тестовую среду.
  • Раз в квартал - полное развёртывание критичного сервера на резервном железе или в облаке, с замером времени.
  • Раз в год - учебная тревога: имитация потери серверной с полным восстановлением сервисов.

Замер времени в квартальной проверке даёт то самое реальное RTO. Почти всегда оно оказывается больше, чем предполагалось.

Шесть частых ошибок

  • Копия на том же сервере. Второй раздел того же диска - это не резервная копия, а иллюзия.
  • Никто не смотрит отчёты. Задание падает третий месяц, письма уходят на почту уволившегося сотрудника.
  • Копируются файлы базы «на горячую». Файлы 1С или SQL, скопированные без выгрузки или снапшота, часто оказываются нецелостными.
  • Забыли про конфигурации. Данные есть, а настройки почтового сервера, правила межсетевого экрана и схема сети - только в голове инженера.
  • Не хватает места, и глубина молча урезалась. Система удаляет старые точки, чтобы влезли новые, и об этом никто не узнаёт.
  • Нет плана восстановления. В момент аварии выясняется, что порядок запуска сервисов знает один человек, и он в отпуске.

Что копировать кроме файлов

Список, который чаще всего оказывается неполным.

  • Базы данных - с корректной выгрузкой, а не копированием файлов.
  • Почтовые ящики, включая облачную почту: провайдер отвечает за доступность, а не за ваши удалённые письма.
  • Конфигурации сетевого оборудования и межсетевых экранов.
  • Образы виртуальных машин целиком, а не только данные внутри них.
  • Каталог пользователей и групповые политики.
  • Лицензионные ключи и документы на ПО.
  • Сайт: файлы и база отдельно, у большинства хостингов бэкап хранится семь дней и не более.

Отдельно проверьте, что резервные копии сайта и почты вы можете забрать себе. Копия, которая существует только внутри панели хостера, исчезнет вместе с доступом к панели.

Коротко

Начните с двух чисел: сколько данных и сколько времени вы готовы потерять. Разложите копии по правилу 3-2-1 и добавьте к нему неизменяемость - иначе шифровальщик заберёт и бэкап. Проверяйте не задания, а восстановление, по расписанию и с секундомером. И держите отдельно от данных то, что обычно забывают: конфигурации, ключи и порядок запуска сервисов.

Настройку копий, хранение и регулярную проверку восстановления мы делаем в рамках услуги резервное копирование. Если задача шире - когда простой недопустим в принципе - смотрите защиту от простоев.

Настроим копирование и проверим восстановление

Расскажите, что нужно защитить и сколько времени вы готовы простоять при аварии. Предложим схему под эти цифры.