Резервное копирование базы 1С: что обязательно должно быть в регламенте

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

Зачем нужен регламент

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

RPO и RTO: сколько данных и времени можно потерять

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

• RPO (Recovery Point Objective) — момент, на который должны быть восстановлены данные, то есть сколько работы компания готова потерять при сбое. Измеряется во времени: «не больше часа», «не больше рабочего дня». Если копия создаётся раз в сутки ночью, а сбой случился вечером, потеряется весь рабочий день.
• RTO (Recovery Time Objective) — сколько времени система может простаивать, пока её восстанавливают. Копия базы объёмом в сотни гигабайт может разворачиваться несколько часов, и это нужно знать заранее, а не выяснять во время аварии.

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

Правило 3-2-1 и изолированная копия

Базовый принцип, который стоит закрепить в регламенте:

• не менее 3 копий данных — рабочая база и минимум две резервные;
• на 2 разных типах носителей или систем хранения, чтобы отказ одного диска или сервера не уничтожил все копии;
• 1 копия — на другой площадке: в другом здании, другом дата-центре или облачном хранилище. Сервер в той же серверной от пожара или кражи не защитит.

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

Особенности 1С: файловая и клиент-серверная база

Файловая база. Резервная копия — это копия файла информационной базы 1Cv8.1CD. Методические материалы 1С прямо указывают: для целостности и согласованности данных работа пользователей с базой на время копирования должна быть запрещена — в том числе при использовании программ резервного копирования. Штатного механизма разностных копий или копий журнала у файловой базы нет: восстановить можно только состояние файла на момент копирования.

Если ночного окна для копирования не хватает или нужны копии в течение дня, это весомый аргумент в пользу перехода на клиент-серверный вариант. Выгрузку базы в файл .dt иногда используют вместо копирования, но, по методическим материалам 1С, она занимает существенно больше времени, а при нарушениях в базе часть информации может не выгрузиться.

Клиент-серверная база. Копирование выполняется средствами СУБД; например, MS SQL Server позволяет создавать копии, пока база доступна пользователям. Копии журнала транзакций, созданные, например, каждые 15–30 минут, ограничивают потерю данных этим интервалом, а разностные копии сокращают число файлов, которые придётся восстанавливать, и тем самым время восстановления.

Копии журнала возможны только в полной модели восстановления или модели с неполным протоколированием, поэтому модель восстановления каждой базы нужно проверить и записать в регламент. В полной модели журнал растёт, пока не будет создана его копия, и без регулярных копий журнала может заполнить диск. В PostgreSQL похожую задачу решает непрерывное архивирование журнала предзаписи (WAL).

Расписание и глубина хранения

В регламенте должно быть явно указано:

• как часто создаются полные копии (обычно ежесуточно в нерабочее время) и нужны ли для клиент-серверных баз копии журнала в течение дня, чтобы уложиться в RPO;
• сколько версий хранится и как долго — например, ежедневные копии за последние две недели, еженедельные за три месяца, ежемесячные за год.

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

Ответственные и мониторинг

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

Тестовое восстановление — часто пропускаемая часть регламента

Копия, которую ни разу не пытались развернуть, — недоказанная гипотеза о том, что данные можно восстановить. Файлы могут оказаться повреждёнными, неполными или несовместимыми с версией СУБД или платформы на резервном стенде, и выясняется это обычно во время реального сбоя.

В регламенте стоит зафиксировать периодичность тестового восстановления — например, ежемесячно — и порядок проверки. Копия разворачивается на отдельном стенде и проверяется на целостность: средствами платформы («Тестирование и исправление» в конфигураторе работает и для файловых, и для клиент-серверных баз), а для MS SQL Server — ещё и командой DBCC CHECKDB. Затем контрольные показатели за закрытый период — например, остатки по ключевым счетам — сверяются с рабочей базой.

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

Чек-лист: что должно быть в регламенте

• перечень баз, которые подлежат копированию, и целевые RPO и RTO для каждой;
• способ копирования (файл базы или средства СУБД), модель восстановления (MS SQL Server) или настройки архивирования WAL (PostgreSQL);
• расписание полных копий и копий журнала, окно копирования и то, нужно ли на это время отключать пользователей;
• места хранения каждой копии, включая внешнюю площадку и изолированную копию;
• сроки хранения копий разной глубины;
• ответственный, его заместитель и порядок мониторинга с оповещением, если свежей копии нет;
• периодичность и порядок тестового восстановления с замером времени;
• пошаговая инструкция восстановления, которую сможет выполнить не только автор регламента.

Итог

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

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

Источники

• Рекомендации по организации резервного копирования информационной базы (28.10.2008) — методические материалы 1С:ИТС для администраторов — its.1c.ru
• Тестирование и исправление информационной базы — сайт платформы 1С:Предприятие 8 — v8.1c.ru
• Модели восстановления SQL Server — Microsoft Learn, «Recovery Models (SQL Server)» — learn.microsoft.com
• Резервные копии журнала транзакций — Microsoft Learn, «Transaction log backups» — learn.microsoft.com
• Проверка целостности базы данных — Microsoft Learn, «DBCC CHECKDB (Transact-SQL)» — learn.microsoft.com
• Непрерывное архивирование и восстановление на момент времени — документация PostgreSQL, «Continuous Archiving and Point-in-Time Recovery (PITR)» — postgresql.org
• Определения RPO и RTO — NIST Computer Security Resource Center, Glossary: «Recovery Point Objective», «Recovery Time Objective»
• Офлайн-копии и правило 3-2-1 как защита от программ-вымогателей — National Cyber Security Centre (UK), «Offline backups in an online world» — ncsc.gov.uk