Как создать бэкап 1С: полное руководство

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

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

Как определить режим работы базы и выбрать способ бэкапа

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

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

Способ 1: выгрузка базы в файл .dt через конфигуратор

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

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

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

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

Способ 2: копирование файловой базы

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

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

Для автоматизации используйте планировщик заданий Windows и простой скрипт. Перед копированием полезно проверить отсутствие сеансов, а после — сверить размер исходного файла и копии.

copy /Y "D:\Bases\Trade\1Cv8.1CD" "E:\Backups\Trade_%date:~6,4%%date:~3,2%%date:~0,2%.1CD"

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

Для баз на Microsoft SQL Server штатный инструмент — планы обслуживания (Maintenance Plans) в SQL Server Management Studio. Создаётся задача Back Up Database, выбирается тип Full (полная копия) и расписание, например ежедневно ночью. Для баз в режиме восстановления Full дополнительно настраивают резервирование журнала транзакций, что позволяет восстановить базу на произвольный момент времени, а не только на момент последней копии.

Для PostgreSQL используют утилиту pg_dump или pg_basebackup с последующим архивированием WAL. Полученный дамп восстанавливается через pg_restore или psql. Независимо от СУБД действует правило: резервную копию делают средствами самой СУБД, а не копированием файлов данных работающего сервера — «горячее» копирование файлов данных без штатных механизмов даёт неработоспособную копию.

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

Как проверить, что бэкап рабочий

Бэкап, который никогда не проверяли на восстановление, нельзя считать бэкапом. Файл .dt может быть битым из-за сбоя диска при записи, SQL-копия — неполной из-за нехватки места. Единственная надёжная проверка — тестовое восстановление на отдельной копии базы.

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

Как организовать регулярное резервирование

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

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

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