Вопрос обеспечения сохранности данных для крупных информационных баз 1С — это ежедневная задача, требующая баланса между производительностью сервера и требованиями бизнеса к допустимым потерям информации (RPO) и времени восстановления (RTO). В этом материале мы проанализируем лучшие практики настройки бэкапов для баз объемом от 100 до 700+ ГБ.
Прежде всего, разберем распространенные заблуждения. Для баз объемом в сотни гигабайт выгрузки данных через XML или выгрузки в файл .dt являются крайне неэффективными и ненадежными методами. Они создают колоссальную нагрузку на сервер приложений, блокируют работу пользователей и не гарантируют целостность структуры базы. Мы рекомендуем использовать исключительно средства СУБД (MS SQL Server или PostgreSQL).
Многие специалисты в обсуждении пришли к выводу, что наиболее гибкий метод — это сочетание полных бэкапов и регулярного резервного копирования логов транзакций. В отличие от разностных (differential) бэкапов, логи позволяют восстановить базу на конкретную секунду времени (Point-in-Time Recovery).
Если специфика инфраструктуры не позволяет использовать логи транзакций, применяйте схему с разностными бэкапами. Это компромиссное решение для баз среднего размера.
Пример оптимальной схемы:
// Пример логики регламентного задания:
// 1. Полный бэкап - каждую ночь (02:00)
// 2. Разностный бэкап - каждые 30 минут в рабочее время
// 3. Хранение: ежедневные разностные бэкапы храним 7-14 дней,
// полные бэкапы храним от 1 до 12 месяцев.
Важно помнить: при использовании разностных копий вся цепочка файлов (полный + все последующие разностные) должна быть доступна и не повреждена. В случае выхода из строя одного дифференциального файла, восстановление станет невозможным.
Наличие файла бэкапа не означает наличие рабочей базы. Мы настоятельно рекомендуем внедрить процесс регулярных «учений» по развертыванию копий. Запомните: проверка «галочкой» в настройках MS SQL при создании бэкапа лишь подтверждает, что файл бэкапа не битый. Она не проверяет, не содержит ли ошибок сама база данных 1С.
Раз в неделю или чаще необходимо выполнять DBCC CHECKDB. Это позволит вовремя обнаружить логическую порчу данных внутри таблиц 1С и предотвратить ситуацию, когда вы годами бережно храните «битый» бэкап.
Для оптимизации места на дисковых массивах мы рекомендуем использовать трехуровневую систему хранения:
При использовании PostgreSQL важно учитывать, что длительные операции 1С, такие как реструктуризация таблиц или обновление конфигурации, могут накладывать блокировки. В таких случаях мы советуем:
WAL-архивирование), что позволяет делать копии «на лету» без остановки работы пользователей.Подводя итог нашей совместной работы по анализу стратегий: не пытайтесь сэкономить на месте, жертвуя частотой бэкапа логов транзакций. Современные дисковые системы стоят значительно дешевле, чем восстановление данных за целый день работы 300 пользователей. Всегда изолируйте бэкап-сервер от основного сервера приложений, чтобы минимизировать риски потери всех данных при вирусной атаке или выходе из строя RAID-массива основного сервера.