Бэкапы, из которых реально восстанавливаются: схема 3-2-1 для бухгалтерской фирмы
Бухгалтерская аутсорсинговая фирма: 12 сотрудников, порядка 60 обслуживаемых компаний. У каждой своя база 1С, рядом общий архив первички и корпоративный сайт. Потеря данных бьёт тут не по своей конторе, а по шести десяткам чужих бухгалтерий разом. С отчётностью и сроками, которые не двигаются.
Почему к нам пришли
Пришли после чужой беды. У знакомой фирмы шифровальщик уничтожил и рабочие базы, и «бэкапы»: те лежали на том же сервере. Руководитель попросил проверить свою схему. Внутренний админ описывал её словами «бэкапы вроде делаются».
Задачу сформулировали коротко. Нужен проверяемый ответ на вопрос «а мы восстановимся?». Не надежда, а ответ.
Что сделали
- Начали с аудита. Находки предсказуемые: скрипт копирования четыре месяца молча падал на части баз, копии складывались на соседний диск того же сервера, ротации не было, старые архивы съели почти всё место.
- Договорились про RPO и RTO простыми словами. Рабочие базы 1С теряем не больше чем за один рабочий день и поднимаем в течение рабочего дня. Для сайта и архива требования мягче. От этих цифр посчитали схему и её стоимость.
- Построили схему 3-2-1. Локальные копии на отдельном хранилище в офисе, чтобы поднимать быстро. Вторая линия в S3-совместимом облаке российского провайдера. Для критичных баз immutable-копии, защищённые от изменения и удаления.
- Настроили ротацию «день-неделя-месяц» с понятными сроками хранения. Хранилище перестало распухать.
- Мониторинг сделали от противного. Алерт приходит, когда копия не создалась или её размер выглядит странно. Тишина в обе стороны больше не считается хорошей новостью.
- Поставили тестовые восстановления в календарь. Раз в месяц случайная база и сайт разворачиваются на отдельной площадке, по итогам короткий отчёт.
- Написали инструкцию восстановления. По ней справится любой админ, необязательно автор схемы.
Где споткнулись
Две базы копировались, но не восстанавливались
Первое же тестовое восстановление вскрыло главное. Файловые базы 1С копировались «на горячую», прямо во время работы пользователей. Файлы в копиях лежали. Но две базы из выборки развернулись битыми, с ошибками целостности. Процесс перестроили. Файловые базы теперь выгружаются штатными средствами 1С по ночному расписанию, с контролем завершения. Самые большие копируются тогда, когда сеансы точно закрыты. Открытие неприятное, зато на тесте, а не после пожара.
Ключ от облачных копий лежал рядом с данными
В первой версии схемы ключ от облачного хранилища хранился на том же сервере, что и данные. Это ровно та история с шифровальщиком: вредонос забирает сервер и стирает заодно оригиналы и копии. Переделали. Завели отдельную учётную запись только на запись, без права удаления. Сверху включили object lock на бакете: записанную копию не удалит никто до истечения срока хранения, включая сам сервер-источник.
Ночное окно оказалось короче, чем нужно
Выгрузки всех шести десятков баз поставили в очередь, и они перестали влезать в ночь. Под утро сервер ещё молотил архивы и мешал первым сотрудникам. Развели задачи. Выгрузки пошли конвейером с ограничением параллельности. Тяжёлая отправка в облако встала после локального копирования. Архив первички перестали гонять целиком каждый день, перевели на инкремент. Ночь снова стала ночью.
Что получилось
- На последнем тестовом восстановлении рабочая база 1С поднялась из облачной копии за 35 минут, сайт за 40. Цифры лежат в отчёте, а не в формулировке «примерно быстро».
- Настоящий инцидент уже случился: сотрудница удалила папку с первичкой клиента. Закрыли за час штатной процедурой по инструкции, без героизма.
- Руководитель раз в месяц получает одностраничный отчёт. Что копируется, куда, когда последний раз восстанавливались и за сколько. Бэкапы переехали из области веры в область отчётности.
- Схема обходится умеренно. Класс хранения и сроки подобрали под ценность данных, а не по принципу «максимум на всякий случай».
Если ваша схема резервного копирования описывается словами «вроде делается», аудит нужен до инцидента, а не после. Опишите в форме на странице услуги, что надо защитить и где оно живёт. Проверим и предложим схему с тестовыми восстановлениями.