Почему бэкап не равен отказоустойчивости

Когда бэкап есть, а бизнес всё равно стоит

При обсуждении систем резервного копирования и отказоустойчивости от новых клиентов часто можно услышать: «Бэкапы у нас есть».

Обычно это звучит уверенно: база 1С копируется, серверы архивируются, резервные копии хранятся отдельно. Формально все необходимые меры приняты.

Пока не происходит авария:

• сервер 1С становится недоступен;
• SQL Server не запускается;
• СХД выходит из строя;
• база повреждается;
• площадка становится недоступна;
• инфраструктуру шифрует вирус.

После одного из таких инцидентов уверенность быстро пропадает.

Выясняется неприятная вещь: копия действительно есть, но бизнес уже стоит. Продажи остановлены, кассы не работают, склад не видит остатки, пользователи не могут войти в 1С, обмены с маркетплейсами не выполняются.

Проблема не в бэкапе. Проблема в том, что от него ожидают не ту функцию.

В этом материале разберём, почему бэкап не равен отказоустойчивости.

Что такое бэкап

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

Для 1С это может быть:

• резервная копия базы SQL Server;
• копия файловой базы;
• образ виртуальной машины;
• копия сервера 1С;
• архив конфигурации;
• копия файлового хранилища.

Бэкап отвечает за сохранность данных, но не обеспечивает работу системы в текущий момент.

Он не гарантирует доступность сервера, не запускает SQL Server вместо отказавшего узла и не переключает пользователей на резервную площадку. Он также не восстанавливает автоматически работу касс, обменов, печати, терминалов сбора данных и интеграций.

Наличие резервной копии означает только одно: данные можно попытаться восстановить. Скорость и полнота восстановления, а также готовность инфраструктуры к запуску системы — отдельные вопросы.

Что такое отказоустойчивость

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

Это не один сервер, не одна программа и не отдельная лицензия. Отказоустойчивость представляет собой связку компонентов и процедур:

• серверов;
• системы хранения данных;
• сети;
• SQL Server;
• серверов 1С;
• резервной площадки;
• репликации;
• мониторинга;
• регламента переключения;
• регулярных тестов восстановления.

Под репликацией здесь понимается само понятие, а не конкретная технология. Например, репликация виртуальных машин в Hyper-V сама по себе не обеспечивает отказоустойчивость в полной мере.

Цель отказоустойчивости — сократить простой и потерю данных до уровня, который бизнес считает допустимым.

RTO и RPO

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

RTO — допустимое время простоя.

Например, бизнес может работать без 1С 15 минут, один час, четыре часа или сутки.

RPO — допустимая потеря данных.

Например, компания готова потерять данные за пять минут, 30 минут, один час или рабочий день.

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

Схема 1. Сравнение логики бэкапа и отказоустойчивости

Главное отличие бэкапа от отказоустойчивости

Бэкап — это механизм восстановления.

Отказоустойчивость — это механизм непрерывности.

Практический пример: 1С, розница, склад и кассы

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

Через 1С проходят:

• продажи;
• кассы;
• складские остатки;
• заказы;
• отгрузки;
• обмены с маркетплейсами;
• обмены с внешними сервисами;
• отчёты для руководства.

Происходит авария: основной сервер 1С становится недоступен, SQL Server не запускается или выходит из строя СХД. Формально у компании есть резервная копия базы.

Однако в момент сбоя она не решает операционную проблему:

• кассир не может пробить чек;
• склад не видит актуальные остатки;
• менеджер не может оформить заказ;
• маркетплейсы не получают обновления;
• бухгалтерия и продажи ждут восстановления;
• руководство не видит текущую картину по бизнесу.

Даже после восстановления базы необходимо поднять сервер, проверить SQL Server, подключить пользователей, вернуть обмены и проверить кассовое оборудование, регламентные задания, печать, интеграции и права доступа.

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

• где будет запущена 1С;
• как быстро переключится SQL Server;
• что произойдёт с кассами;
• кто выполнит переключение;
• сколько времени бизнес фактически будет простаивать.

Для розницы вопрос заключается не только в сохранности базы. Главный вопрос — в непрерывности продаж.

Схема 2. Один из возможных контуров для критичной 1С

Почему одного бэкапа недостаточно

1. Восстановление может занять часы или дни

Сама копия данных не равна работающей системе. Необходимо подготовить сервер, восстановить базу, проверить её целостность, настроить доступы и вернуть пользователей.

2. Может отсутствовать инфраструктура для восстановления

Если основной сервер вышел из строя, нужна площадка, на которой можно восстановить систему: сервер, дисковое пространство, сеть, лицензии, доступы, установленные SQL Server и 1С.

3. Копия может быть повреждена

Задание резервного копирования может завершиться успешно, но при восстановлении копия окажется неполной или повреждённой.

4. Копия может быть устаревшей

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

5. Может отсутствовать понятный регламент

Во время аварии важно заранее знать, кто принимает решение, кто выполняет восстановление, какие системы запускаются первыми и кто проверяет результат.

6. Бэкап не восстанавливает бизнес-процесс целиком

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

7. Шифровальщик может затронуть резервные копии

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

8. Без тестов неизвестно реальное время восстановления

Оценка «восстановимся за час» ничего не значит, если компания ни разу не проводила тестовое восстановление.

9. Бэкап не защищает от отказа инфраструктуры

Отказ канала связи, ЦОД, СХД, сервера приложений 1С, сетевого оборудования или SQL Server требует не только копии данных, но и резервного контура.

10. После восстановления необходимо проверить всю цепочку

Для 1С недостаточно просто открыть базу. Необходимо убедиться, что работают пользователи, фоновые задания, обмены, отчёты, кассы, склад и внешние сервисы.

Как правильно оценивать защиту

Вопрос «Есть ли у нас бэкап?» слишком узкий. Он показывает только наличие копии, но не отражает готовность бизнеса к аварии.

Правильнее задать следующие вопросы:

• Сколько времени компания может работать без 1С?
• Сколько данных допустимо потерять?
• Где будет запущена система при отказе основного сервера?
• Есть ли резервный сервер?
• Есть ли резервная площадка?
• Кто выполняет переключение?
• Есть ли инструкция на случай аварии?
• Проверялось ли восстановление за последние три месяца?
• Известно ли реальное время восстановления?
• Что произойдёт с кассами при отказе 1С?
• Что произойдёт со складом при отказе SQL Server?
• Что произойдёт с обменами и маркетплейсами?
• Защищены ли бэкапы от удаления и шифрования?
• Сколько денег стоит один час простоя?

Ответы показывают, что именно нужно компании: только резервное копирование или полноценный сценарий отказоустойчивости.

Когда достаточно бэкапа, а когда нужна отказоустойчивость

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

Что должно быть кроме бэкапа

Полноценная защита критичной ИТ-системы обычно включает несколько уровней.

Схема 3. Бэкап — нижний слой защиты, а не вся защита целиком

Резервное копирование

Бэкапы должны выполняться регулярно, контролироваться и храниться в нескольких точках восстановления.

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

Недостаточно видеть статус «Успешно». Необходимо периодически восстанавливать копии в тестовую среду и проверять, что база действительно запускается.

Резервный сервер или площадка

Должно быть заранее определено, где будет запущена система при отказе основного сервера или ЦОД.

Репликация данных

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

Отказоустойчивый SQL Server

Для баз 1С на SQL Server необходимо отдельно проектировать доступность СУБД: использовать кластер, Always On, резервный узел или другой подходящий сценарий.

Кластер 1С

Сервер 1С не должен оставаться единственной точкой отказа, если через него проходят критичные бизнес-процессы.

Мониторинг

Необходимо контролировать серверы, базы, службы 1С, SQL Server, СХД, каналы связи, репликацию, свободное место и успешность выполнения бэкапов.

Защита резервных копий

Копии должны быть защищены от удаления, перезаписи и шифрования. Желательно иметь внешнюю или географически удалённую копию.

Регламент аварийного восстановления

В инструкции должно быть указано:

• кто принимает решение;
• кто выполняет необходимые действия;
• что переключается в первую очередь;
• как проверяется результат;
• кто сообщает бизнесу о текущем статусе.

Тестовые переключения

Переключение на резервный контур необходимо проверять заранее. Во время аварии должна выполняться отработанная процедура, а не импровизация.

Вывод

Бэкап нужен каждой компании. Он защищает данные и позволяет восстановиться после сбоя, ошибки или атаки.

Однако бэкап не гарантирует, что бизнес продолжит работать во время аварии.

Если простой 1С, SQL Server, касс, склада, заказов или обменов приводит к потере денег, одного резервного копирования недостаточно. Необходимо проектировать сценарий непрерывной работы, включающий резервную инфраструктуру, репликацию, мониторинг, регламент переключения и регулярные тесты.

• Бэкап отвечает на вопрос: «Можно ли восстановить данные?»
• Отказоустойчивость отвечает на вопрос: «Сможет ли бизнес работать при отказе?»

Приложение. Чек-лист проверки готовности