Резервное копирование 1С: что это такое и как его организовать

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

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

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

Что такое резервная копия 1С и что она включает

Информационная база 1С содержит все данные учёта: документы, справочники, регистры, настройки, список пользователей и их права. В зависимости от режима работы эти данные хранятся либо в одном файле 1Cv8.1CD (файловый вариант), либо в базе данных на сервере СУБД — чаще всего Microsoft SQL Server, PostgreSQL или Oracle (клиент-серверный вариант).

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

Отдельно стоит понимать, чем резервная копия отличается от выгрузки данных для обмена. Выгрузка в формате XML для переноса между конфигурациями — это не бэкап: она не гарантирует полного восстановления базы и не предназначена для защиты от сбоев.

Какие виды резервных копий существуют

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

Выгрузка информационной базы в файл .dt — штатный механизм платформы, доступный в конфигураторе через меню «Администрирование — Выгрузить информационную базу». Файл .dt универсален: его можно загрузить в базу на другой платформе, другой СУБД, перенести между компьютерами. Однако выгрузка требует монопольного доступа (все пользователи должны выйти), на больших базах занимает много времени и не сохраняет некоторые внешние данные — например, файлы, хранящиеся в томах на диске.

Резервная копия средствами СУБД — стандартный бэкап базы данных (например, через SQL Server Management Studio или pg_dump). Это основной способ для клиент-серверных баз: работает быстрее, поддерживает расписание, разностные копии и копии журнала транзакций, не требует выгона пользователей в большинстве режимов. Минус — восстановить такую копию можно только на ту же СУБД совместимой версии.

Как настроить копирование файловой базы

Файловая база — самый распространённый вариант в небольших организациях. Здесь доступны два рабочих подхода: выгрузка в .dt и копирование файла базы.

Выгрузка в .dt делается через конфигуратор: «Администрирование — Выгрузить информационную базу», указать папку и имя файла. Перед выгрузкой все пользователи должны завершить работу, иначе конфигуратор не даст выполнить операцию. Для автоматизации используют пакетный режим запуска конфигуратора с параметрами командной строки — так выгрузку можно поставить в планировщик заданий Windows на ночное время.

"C:\Program Files\1cv8\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /N"Админ" /P"пароль" /DumpIB"D:\Backup\trade_%date%.dt"

Копирование файла 1Cv8.1CD проще, но требует того же условия: ни один сеанс не должен держать базу открытой. Скопированный «на живую» файл с высокой вероятностью окажется повреждённым и не откроется. Надёжная схема — скрипт, который проверяет отсутствие сеансов, копирует файл и складывает копии в папки с датами.

1. 1
   Создайте отдельную папку для копий, желательно на другом физическом диске или сетевом хранилище.
2. 2
   Напишите скрипт выгрузки в .dt или копирования файла с подстановкой даты в имя.
3. 3
   Добавьте задание в планировщик задач Windows на время, когда пользователи не работают.
4. 4
   Настройте удаление копий старше заданного срока, чтобы не переполнить диск.
5. 5
   Раз в месяц выполните тестовое восстановление копии в отдельную папку и откройте базу.

Как организовать бэкап клиент-серверной базы

В клиент-серверном варианте копирование возлагается на СУБД — это правильнее и надёжнее, чем выгрузка в .dt. Для Microsoft SQL Server настраивают план обслуживания: полная копия ежедневно, разностные копии в течение дня, при необходимости — копии журнала транзакций для восстановления на произвольный момент времени.

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

BACKUP DATABASE [TradeBase] TO DISK = N'D:\Backup\TradeBase_full.bak' WITH INIT, COMPRESSION;

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

Сколько копий хранить и где их размещать

Ключевой принцип — копии не должны лежать только на том же диске и том же сервере, где работает база. При отказе диска, краже сервера или шифровании ransomware вы потеряете и базу, и копии одновременно.

Практичная схема для небольшой компании: ежедневные копии за последние 7–14 дней на сетевом хранилище или отдельном сервере, плюс еженедельные копии за 1–2 месяца, плюс ежемесячный архив. Одну из копий желательно держать вне офиса — в облачном хранилище или на носителе в другом помещении.

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

Как проверить, что копия восстанавливается

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

Для файловой базы создайте пустую папку, загрузите туда файл .dt через конфигуратор («Администрирование — Загрузить информационную базу») или положите скопированный файл 1Cv8.1CD и добавьте базу в список. Откройте базу в режиме предприятия, проверьте свежие документы и сформируйте пару отчётов.

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

Типичные ошибки и частые вопросы

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

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

Часто задаваемые вопросы