Резервное копирование в 1С: полное руководство для администратора

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

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

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

Что нужно резервировать и какие есть способы

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

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

Выгрузка базы в файл .dt через конфигуратор

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

1. 1
   Завершите сеансы пользователей через консоль кластера или попросите выйти заранее
2. 2
   Откройте базу в конфигураторе
3. 3
   Выберите Администрирование → Выгрузить информационную базу
4. 4
   Укажите папку на отдельном диске или сетевом ресурсе, а не рядом с базой
5. 5
   Дождитесь завершения и проверьте размер файла — он должен быть сопоставим с размером базы
6. 6
   Периодически загружайте копию в тестовую базу для проверки целостности

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

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

Резервное копирование файловой базы копированием

Файловая база — это фактически один файл 1Cv8.1CD плюс служебные каталоги. Её можно копировать как обычный файл, но только когда с ним никто не работает: активный сеанс держит файл открытым, и копия получится неконсистентной. Признаком занятости служит наличие файла 1Cv8.1CL рядом с базой.

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

@echo off
set SRC=D:\Bases\Trade\1Cv8.1CD
set DST=E:\Backups\Trade_%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2%.1CD
if exist "D:\Bases\Trade\1Cv8.1CL" (echo Base is locked & exit /b 1)
copy /Y "%SRC%" "%DST%"

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

Резервирование клиент-серверной базы средствами СУБД

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

В PostgreSQL используйте pg_dump для логических копий или pg_basebackup с архивированием WAL для физических. Логическая копия проще для восстановления отдельной базы, физическая быстрее на больших объёмах и поддерживает point-in-time recovery.

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

Автоматизация и расписание резервного копирования

Ручное копирование рано или поздно перестаёт выполняться — это главный риск любой схемы. Автоматизируйте процесс через планировщик заданий Windows, cron, планы обслуживания SQL Server или типовую обработку «Резервное копирование ИБ» из библиотеки стандартных подсистем, если она встроена в вашу конфигурацию.

Придерживайтесь правила «3-2-1»: минимум три копии данных, на двух разных типах носителей, одна — вне основной площадки. На практике это выглядит так: ночная копия на NAS в том же здании плюс регулярная синхронизация архива в облачное хранилище или на площадку в другом здании.

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

Проверка копий и восстановление

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

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

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