Резервное копирование для бизнеса: план защиты и проверка восстановления

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

Шаг 1. Определить, что защищать

Бэкапить «всё подряд» — дорого и, что хуже, ненадёжно: в куче данных теряется главное. Начните с инвентаризации — списка данных, потеря которых останавливает или калечит бизнес:

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

Для каждого пункта ответьте на два вопроса: сколько часов простоя терпимо при восстановлении и какой объём потерянных данных допустим — день работы, час, ничего? Эти два ответа определяют, как часто делать копии и сколько платить за инфраструктуру хранения. У базы 1С и у архива сканов ответы будут разными — и это нормально.

Шаг 2. Несколько независимых копий

Главный принцип: копии не должны разделять судьбу оригинала и друг друга. Классический ориентир — правило «3-2-1»: три экземпляра данных, на двух разных типах носителей, один — вне офиса. Важно понимать: это ориентир для проектирования, а не магическая формула-гарантия — конкретная схема зависит от ваших данных и рисков.

Что означает «независимость» на практике:

• Копия на том же сервере, что и оригинал, не является независимой. При отказе диска или сервера она погибает вместе с оригиналом.
• Копия на диске, постоянно подключённом к серверу, уязвима для шифровальщиков. Вредоносная программа, получившая нужные права на сервере, может зашифровать доступные подключённые диски — включая такую копию. Хотя бы одна копия должна быть недостижима из основной сети: облако с отдельной учётной записью, отключаемый носитель, хранилище с версионированием или неизменяемыми копиями — если это поддерживает выбранный сервис и подтверждает техкоманда.
• Вне офиса — защита от пожара, потопа и кражи. Для большинства компаний эту роль играет облако; подойдёт и сервер в другом филиале.
• Версии, а не зеркало. Синхронизация в облако — не бэкап: испорченный файл синхронизируется поверх здорового. Нужна история версий хотя бы за несколько недель — повреждение данных не всегда замечают в тот же день.

Шаг 3. Хранение и доступы

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

• Доступ к хранилищу копий — только у тех, кому он необходим по работе. «Пароль от облака знает весь офис» — частая проблема.
• Учётная запись для бэкапов — отдельная, не личная почта сотрудника и не общий админский аккаунт. Уволился человек — бэкапы не должны уехать вместе с ним.
• Копии с персональными и финансовыми данными — в зашифрованном виде, ключи хранятся отдельно от самих копий.
• Проверьте, что происходит при увольнении ИТ-специалиста или смене подрядчика: остаются ли у компании доступы и документация по схеме резервного копирования. Это часть общей гигиены доступов — подробнее о ней в описании услуги ИТ-безопасность для бизнеса.

Шаг 4. Тест восстановления — главный шаг, который пропускают

Единственное доказательство работоспособности бэкапа — успешно восстановленные данные. Не отчёт «задание выполнено», не зелёная галочка в программе, а открытая база и рабочие файлы.

Как выглядит нормальная практика:

• Регулярно восстанавливать выборочно: одну базу, одну папку — на тестовое место, не поверх боевых данных. Периодичность зависит от критичности; ориентир для большинства офисов — хотя бы раз в квартал.
• Раз в год — учения посерьёзнее: восстановление критичной системы целиком с замером времени. Именно тогда выясняется, что «восстановимся за пару часов» на деле означает сутки.
• Фиксировать результат: дата, что восстанавливали, сколько заняло, что пошло не так. Четыре строчки в журнале, которые превращают веру в знание.

Если ваш подрядчик или сисадмин ни разу не показывал вам результат тестового восстановления — это первый вопрос, который стоит задать после прочтения статьи.

Шаг 5. Ответственность и график

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

• Назначен ответственный — конкретный человек или подрядчик, поимённо. «За бэкапы отвечают айтишники» — значит, никто.
• Есть график: что копируется, как часто, сколько версий храним, когда тесты восстановления.
• Сбои задания видны сразу: уведомление о неудавшемся бэкапе приходит человеку, а не в лог, который никто не читает. Молчащий три недели бэкап должен быть ЧП, а не сюрпризом при аварии.
• Схема описана документально — так, чтобы восстановить данные мог не только тот, кто настраивал.

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

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

У нас всё в облаке — Google Диск, 1С в облаке. Нам нужен бэкап?

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

Сколько это стоит?

Зависит от объёма данных и допустимого простоя, поэтому честной универсальной цифры не существует. Правильный способ оценить бюджет — сравнить его не с абстрактной «ценой бэкапа в месяц», а с вашей же цифрой из шага 1: стоимостью часа простоя и ценой потерянных данных. Это сравнение каждая компания делает на своих числах.

Как часто нужно делать копии?

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

С чего начать прямо завтра?

Задайте своим ИТ-специалистам три вопроса: что именно у нас бэкапится, где лежит копия, недостижимая для шифровальщика, и когда последний раз проверяли восстановление. Если хотя бы на один вопрос нет уверенного ответа — начните с него.

← Ко всем статьям