Бэкапы, из которых реально восстанавливаются: схема 3-2-1 для бухгалтерской фирмы

Бухгалтерская аутсорсинговая фирма: 12 сотрудников, порядка 60 обслуживаемых компаний. У каждой своя база 1С, рядом общий архив первички и корпоративный сайт. Потеря данных бьёт тут не по своей конторе, а по шести десяткам чужих бухгалтерий разом. С отчётностью и сроками, которые не двигаются.

Почему к нам пришли

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

Задачу сформулировали коротко. Нужен проверяемый ответ на вопрос «а мы восстановимся?». Не надежда, а ответ.

Что сделали

• Начали с аудита. Находки предсказуемые: скрипт копирования четыре месяца молча падал на части баз, копии складывались на соседний диск того же сервера, ротации не было, старые архивы съели почти всё место.
• Договорились про RPO и RTO простыми словами. RPO это сколько данных допустимо потерять, RTO это за сколько мы обязаны поднять систему. Рабочие базы 1С теряем не больше чем за один рабочий день и поднимаем в течение рабочего дня. Для сайта и архива требования мягче. От этих цифр посчитали схему и её стоимость.
• Построили схему 3-2-1. Локальные копии на отдельном хранилище в офисе, чтобы поднимать быстро. Вторая линия в S3-совместимом облаке российского провайдера. Для критичных баз immutable-копии, защищённые от изменения и удаления.
• Настроили ротацию «день-неделя-месяц» с понятными сроками хранения. Хранилище перестало распухать.
• Мониторинг сделали от противного. Алерт приходит, когда копия не создалась или её размер выглядит странно. Тишина в обе стороны больше не считается хорошей новостью.
• Поставили тестовые восстановления в календарь. Раз в месяц случайная база и сайт разворачиваются на отдельной площадке, по итогам короткий отчёт.
• Написали инструкцию восстановления. По ней справится любой админ, необязательно автор схемы.

Где споткнулись

Две базы копировались, но не восстанавливались

Первое же тестовое восстановление вскрыло главное. Файловые базы 1С копировались «на горячую», прямо во время работы пользователей. Файлы в копиях лежали. Но две базы из выборки развернулись битыми, с ошибками целостности. Процесс перестроили. Файловые базы теперь выгружаются штатными средствами 1С по ночному расписанию, с контролем завершения. Самые большие копируются тогда, когда сеансы точно закрыты. Открытие неприятное, зато на тесте, а не после пожара.

Ключ от облачных копий лежал рядом с данными

В первой версии схемы ключ от облачного хранилища хранился на том же сервере, что и данные. Это ровно та история с шифровальщиком: вредонос забирает сервер и стирает заодно оригиналы и копии. Переделали. Завели отдельную учётную запись только на запись, без права удаления. Сверху включили object lock на бакете: записанную копию не удалит никто до истечения срока хранения, включая сам сервер-источник.

Ночное окно оказалось короче, чем нужно

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

Что получилось

• На последнем тестовом восстановлении рабочая база 1С поднялась из облачной копии за 35 минут, сайт за 40. Цифры лежат в отчёте, а не в формулировке «примерно быстро».
• Настоящий инцидент уже случился: сотрудница удалила папку с первичкой клиента. Закрыли за час штатной процедурой по инструкции, без героизма.
• Руководитель раз в месяц получает одностраничный отчёт. Что копируется, куда, когда последний раз восстанавливались и за сколько. Бэкапы переехали из области веры в область отчётности.
• Схема обходится умеренно. Класс хранения и сроки подобрали под ценность данных, а не по принципу «максимум на всякий случай».

Проверьте свою схему за пять минут

Эти вопросы руководитель задаёт админу сам, без нас. Ответы обычно отрезвляют.

• Где физически лежат копии? Если ответ «на этом же сервере», схемы нет.
• Когда копию последний раз разворачивали? Если «никогда», у вас не бэкапы, а файлы с надеждой.
• Приходит ли письмо, когда копия не создалась? Молчание должно тревожить, а не успокаивать.
• Может ли вирус с рабочего сервера дотянуться до хранилища копий и стереть их?
• Сколько данных вы готовы потерять и за сколько часов согласны подняться? Если цифр нет, считать схему не от чего.
• Кто восстановит базу, если админ в отпуске и недоступен? Есть ли письменная инструкция?

Три «не знаю» из шести означают, что защита от шифровальщика у вас держится на удаче.

Из чего собирают такую схему

Мы не привязаны к одному вендору и подбираем стек под бюджет клиента.

• Копии рядом держим на отдельном сервере или NAS в офисе. Оттуда поднимаемся быстрее всего.
• Вторую линию уносим в S3-совместимое хранилище российского провайдера. Их на рынке несколько, выбираем по цене за терабайт и по тому, умеют ли они object lock.
• Базы выгружаем штатными средствами 1С по расписанию. Клиент-серверные отдаём средствам самой СУБД.
• Следит за этим любая система, которая умеет проверить файл и его размер и прислать алерт в мессенджер.
• Тестируем на отдельной виртуалке: поднимаем её под проверку, потом гасим.

Сколько это стоит и сколько занимает

Цифры этого проекта закрыты договором. Порядок сумм на похожих схемах выглядит так.

• Проверяем, как вы копируете сейчас: от 30 тысяч рублей, неделя. Отдаём отчёт с находками и вариантами.
• Собираем схему для одной компании с парой баз 1С и сайтом: от 90 тысяч рублей, две недели.
• Строим схему масштаба этого кейса, где десятки баз и общий архив: от 250 тысяч рублей, месяц-полтора, пока не пройдут первые тесты.
• Храним копии: от 8 тысяч рублей в месяц за терабайт, если считать обе линии и глубину в месяц.
• Сопровождаем схему, тестируем раз в месяц и присылаем отчёт: от 15 тысяч рублей в месяц.

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

Что нужно от вас

• Перечислите, что нельзя потерять, и расставьте приоритеты. Обычно это собирают за час на совещании.
• Дайте доступы к серверам, базам и сайту. Если админ приходящий, попросите у него час на передачу.
• Назначьте ответственного, который решит, сколько данных допустимо потерять. Это решает бизнес, а не техника.
• Разрешите работать ночью: выгружаем тогда, когда сеансы закрыты.
• Тратьте час в месяц, чтобы прочитать отчёт о тестовом восстановлении. Иначе схема снова уедет в область веры.

Что происходит после запуска

Схема живая, и ломается она тихо. Поэтому за ней кто-то должен смотреть.

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

Если ваша схема резервного копирования описывается словами «вроде делается», аудит нужен до инцидента, а не после. Опишите в форме на странице услуги резервного копирования с проверкой восстановления, что надо защитить и где оно живёт. Проверим и предложим схему с тестовыми восстановлениями. Обычно рядом всплывают соседние дыры, поэтому есть смысл сразу посмотреть аудит инфраструктуры и безопасности и мониторинг 24/7. Если сервер при этом доживает свой век в подсобке, посмотрите кейс про переезд 1С в Яндекс Облако.