Резервное копирование базы 1С 8.3: все рабочие способы

Копия файловой базы — это копия файла 1Cv8.1CD из каталога базы, снятая при полностью вышедших пользователях. Копия клиент-серверной базы — это бэкап средствами СУБД (MS SQL или PostgreSQL) либо выгрузка в файл .dt через конфигуратор. Третьего не дано: способ зависит от того, файловая у вас база или серверная.

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

Файловая база: копируем сам файл базы

У файловой базы все данные лежат в одном файле — 1Cv8.1CD в каталоге информационной базы. Скопировать этот файл и есть самый быстрый способ снять копию.

Где лежит каталог, видно в окне запуска 1С: выделите базу в списке — путь показан внизу под списком. Либо через Конфигуратор → Администрирование → Информация — там тоже есть каталог базы.

Порядок действий:

1. Попросите всех пользователей выйти из базы. Пока кто-то работает, файл копировать нельзя — копия получится битой.
2. Убедитесь, что в каталоге нет файлов блокировки 1Cv8.1CL и 1Cv8tmp.1CD (они появляются, когда база открыта).
3. Скопируйте весь каталог базы целиком, а не один 1Cv8.1CD. В каталоге могут быть вспомогательные файлы, и забирать лучше всё.
4. Заархивируйте копию в ZIP — файл базы хорошо сжимается, место экономится в разы.

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

Минус у способа один: он работает только для файловых баз и только при вышедших пользователях. Онлайн, на работающей базе, скопировать 1Cv8.1CD корректно не получится.

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

Выгрузка в .dt — это «логическая» копия: 1С сама упаковывает все данные и конфигурацию в один файл. Способ работает и для файловой, и для клиент-серверной базы.

Как сделать:

1. Запустите базу в режиме Конфигуратор.
2. Откройте Администрирование → Выгрузить информационную базу.
3. Укажите имя и папку для файла .dt и нажмите «Сохранить».

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

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

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

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

MS SQL Server. Резервная копия создаётся командой BACKUP DATABASE или через SQL Server Management Studio: правой кнопкой на базе → Tasks → Back Up. Есть три вида копий, и обычно их комбинируют:

• полная — вся база целиком, обычно раз в сутки ночью;
• разностная (differential) — только то, что изменилось после последней полной копии, быстрее и легче;
• копия журнала транзакций — изменения с момента прошлой копии журнала, снимается часто в течение дня.

Копии журнала транзакций возможны, только если у базы задана полная модель восстановления (Full recovery model). При простой модели (Simple) восстановиться можно лишь на момент последней полной или разностной копии — весь день работы между ночными бэкапами будет потерян. Для боевой базы выбирают полную модель.

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

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

Способы коротко в таблице:

Автоматизация: копии по расписанию

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

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

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

"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /F"C:\Bases\Buh" /DumpIB "D:\Backup\buh_%date%.dt"

Для серверной базы вместо /F указывается /S Сервер\ИмяБазы. Параметр /DumpIB выгружает базу в указанный файл. Пакетный запуск так же требует монопольного доступа, поэтому ставьте его на ночь.

Серверная база — средствами СУБД. В MS SQL копии по расписанию делаются планом обслуживания (Maintenance Plan) или заданием SQL Server Agent. В PostgreSQL — скрипт с pg_dump в планировщике (cron в Linux, планировщик задач в Windows).

Какое бы расписание вы ни выбрали, настройте удаление старых копий. Иначе архивы за месяцы забьют диск, и в самый нужный момент очередной бэкап просто не запишется из-за нехватки места. В плане обслуживания MS SQL за это отвечает задача очистки (Maintenance Cleanup Task), в скрипте для PostgreSQL — удаление файлов старше заданного срока.

Где хранить архивы и как проверить целостность

Копия, которая лежит на том же диске, что и база, — это полкопии. Сгорит диск или зашифрует вирус — пропадёт и то, и другое.

Простое правило хранения (его называют «3-2-1»):

• 📦 три копии данных (рабочая база + два бэкапа);
• 💽 на двух разных носителях (например, диск сервера и сетевое хранилище);
• 🏠 одна копия — вне офиса (облако, другой адрес).

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

Отдельно про проверку: копия, которую ни разу не разворачивали, — это копия, в которой вы не уверены.

Как убедиться, что архив рабочий:

1. Разверните копию на тестовой базе и зайдите в неё. Открылась, данные на месте — копия годная. Это самый надёжный тест.
2. Для файловой базы прогоните Конфигуратор → Администрирование → Тестирование и исправление на копии — он найдёт логические ошибки в данных.
3. Для MS SQL быстро проверить бэкап можно командой RESTORE VERIFYONLY — она читает файл копии и подтверждает, что он не повреждён (но не заменяет пробное восстановление).

Как восстановить базу из копии

Восстановление — обратная операция, и у каждого способа копирования свой способ отката.

Из копии каталога (файловая база). Попросите всех выйти, удалите или переименуйте текущий каталог базы, распакуйте на его место копию. Запустите 1С — база откроется в том состоянии, в котором её копировали.

Из файла .dt. Запустите Конфигуратор → Администрирование → Загрузить информационную базу и укажите .dt. Загрузка полностью затирает текущие данные базы — то, что есть сейчас, будет потеряно. Поэтому перед загрузкой .dt снимите свежую копию текущего состояния.

Из бэкапа СУБД. В MS SQL — команда RESTORE DATABASE или SSMS → Tasks → Restore. В PostgreSQL — pg_restore (для копий pg_dump в формате custom) или psql (для обычного дампа). Восстановление серверной базы требует монопольного доступа к СУБД, пользователей из базы нужно отключить.

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

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