Как сделать резервную копию базы данных 1С

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

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

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

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

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

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

Есть и смешанный вариант: база хранится на SQL Server, но администратор привык делать выгрузки .dt через конфигуратор. Это допустимо как дополнительная мера, но не заменяет бэкап средствами СУБД, который быстрее и лучше подходит для больших объёмов.

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

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

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

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

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

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

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

Для файловой базы самый быстрый способ — скопировать весь каталог базы или хотя бы файл 1Cv8.1CD. Это занимает столько же времени, сколько обычное копирование файла такого размера, и не требует запуска конфигуратора.

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

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

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

Для баз на Microsoft SQL Server штатный метод — команда BACKUP DATABASE или план обслуживания в SQL Server Management Studio. Полная копия создаётся быстро, не требует остановки работы пользователей и поддерживает разностные копии и копии журнала транзакций, что позволяет восстановить базу на конкретный момент времени.

Пример команды для полного бэкапа:

BACKUP DATABASE [trade] TO DISK = N'D:\Backups\trade_full.bak' WITH COMPRESSION, CHECKSUM;

Для PostgreSQL используется утилита pg_dump или pg_basebackup. Учтите важную особенность: базы 1С на PostgreSQL требуют корректных настроек сортировки и локали, поэтому восстанавливать дамп нужно в окружение с теми же параметрами, иначе база не запустится.

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

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

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

Пример простого скрипта для файловой базы:

set src=D:\Bases\Trade\1Cv8.1CD
set dst=E:\Backups\Trade_%date:~6,4%-%date:~3,2%-%date:~0,2%.1CD
copy "%src%" "%dst%" && echo OK >> E:\Backups\backup.log

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

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

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

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

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

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

Типичные ошибки и их последствия

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

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

Частые вопросы о резервном копировании 1С