Как настроить резервное копирование баз 1С

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

Способ резервного копирования зависит от режима работы базы. Файловая база копируется выгрузкой в формат DT или прямым копированием файла 1Cv8.1CD, клиент-серверная — средствами СУБД (MS SQL Server, PostgreSQL) с правильной моделью восстановления. Универсального «лучшего» способа нет: у каждого свои ограничения по точке восстановления, влиянию на работу пользователей и требованиям к квалификации администратора.

Ниже разобраны рабочие схемы для обоих режимов, настройка расписания, правила хранения копий и обязательная проверка восстановления — без неё резервное копирование считается ненастроенным.

Определите режим работы базы: файловая или клиент-серверная

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

Файловая база хранится в одном файле 1Cv8.1CD и обслуживает обычно до нескольких одновременно работающих пользователей. Клиент-серверная база размещена в СУБД, а сервер 1С лишь посредник между пользователями и данными. Это принципиально разные ситуации: копировать файл 1Cv8.1CD у работающей клиент-серверной базы просто не получится, потому что такого файла не существует.

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

Для файловой базы доступны два основных подхода: выгрузка в DT и прямое копирование файла 1Cv8.1CD. Выгрузка надёжнее как архив — она включает внутреннюю проверку структуры и не зависит от того, корректно ли завершились сеансы. Прямое копирование быстрее и проще, но требует, чтобы в момент копирования с базой никто не работал: иначе файл может оказаться в несогласованном состоянии.

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

Автоматическая выгрузка DT по расписанию

Конфигуратор умеет работать в пакетном режиме из командной строки, что позволяет выгружать DT без участия человека. Команда запускается планировщиком заданий Windows, например ежедневно вечером, когда пользователи уже вышли.

"C:\Program Files\1cv8\<версия>\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /NАдмин /PПароль /DumpIB"D:\Backup\Trade_%date%.dt"

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

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

Прямое копирование файла 1Cv8.1CD

Если база большая и выгрузка DT занимает слишком много времени, допустимо копировать сам файл 1Cv8.1CD любым инструментом — robocopy, скриптом PowerShell или средством резервного копирования. Обязательное условие: в момент копирования в базе не должно быть активных сеансов. Некоторые администраторы копируют «на живую», полагаясь на удачу, — такая копия может не открыться или содержать повреждённые данные, что выяснится только при восстановлении.

Настройте резервное копирование клиент-серверной базы

В клиент-серверном режиме резервное копирование делается средствами СУБД, а не 1С. Для MS SQL Server настройте план обслуживания: полная резервная копия ежедневно и копии журнала транзакций каждые 15–60 минут, если база работает в модели восстановления Full. Это позволяет восстановить базу не только на момент ночной копии, но и на любую точку в течение дня — критично, если данные испорчены в середине рабочего дня.

Для PostgreSQL используются pg_dump для логической копии или настройка непрерывного архивирования WAL для точечного восстановления. Логическая копия pg_dump проще в администрировании и подходит большинству небольших внедрений; архивирование WAL требует больше настройки, но даёт восстановление на произвольный момент времени.

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

Организуйте хранение копий по правилу двух площадок

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

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

Проверяйте восстановление, а не только факт копирования

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

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

Избегайте типичных ошибок

Отдельная ошибка — путать резервное копирование с синхронизацией. Зеркалирование дисков (RAID) и репликация файлов защищают от отказа оборудования, но мгновенно тиражируют и удаление данных, и шифрование. Только версионные копии с историей позволяют вернуться к состоянию до инцидента.

Частые вопросы