Администрирование · 11 мин
Как сделать бэкап данных в 1С: способы, инструкции и ошибки
Пошаговая инструкция по созданию резервной копии базы 1С: выгрузка DT, копирование файловой базы, бэкап SQL и автоматизация регламентных копий.
Потеря информационной базы 1С — одна из самых дорогих аварий в учёте: вместе с ней пропадают документы, остатки, начисления и история за годы. При этом регулярное резервное копирование занимает минуты, а восстановление из копии обычно укладывается в часы. Главная сложность не в самой процедуре, а в выборе правильного способа под конкретную конфигурацию: файловая база, клиент-серверный вариант на SQL и облачный сервис требуют разных подходов.
Существует три базовых способа сделать бэкап в 1С: выгрузка информационной базы в файл DT через конфигуратор, копирование файла базы (для файлового режима) и резервное копирование средствами СУБД (для клиент-серверного варианта). Каждый из них имеет свои ограничения, и ниже разобраны все три с точными шагами, проверками результата и типичными ошибками.
Какие способы резервного копирования существуют в 1С
Перед выбором метода определите, в каком режиме работает ваша база. Откройте конфигуратор или предприятие и посмотрите строку подключения: если путь ведёт к папке на диске — это файловый вариант, если указан сервер и имя базы — клиент-серверный. От этого зависит весь дальнейший порядок действий.
Выгрузка в DT — штатный механизм платформы, который упаковывает данные и конфигурацию в один файл. Он независим от СУБД, но на больших базах работает медленно и требует монопольного доступа. Копирование файла базы — самый быстрый вариант для файлового режима, но требует, чтобы все пользователи вышли. Бэкап средствами СУБД — стандарт для клиент-серверных развёртываний: он быстрый, поддерживает расписание и не требует выгона пользователей при использовании полной модели восстановления.
Сравнение способов бэкапа
Подходит для любых баз, переноса между платформами и архивных снимков. Ограничения: нужен монопольный доступ, медленно на больших базах, нет гарантии целостности при повреждённой базе.
Только файловый режим. Быстро и просто, но требует завершения всех сеансов, иначе копия будет неконсистентной.
Только клиент-серверный вариант. Работает по расписанию без остановки работы, но восстановление требует навыков администрирования SQL.
Выгрузка базы в файл DT через конфигуратор
Это самый универсальный метод. Запустите конфигуратор нужной базы, убедитесь, что в ней не работают пользователи, и выполните выгрузку. Процедура одинакова для большинства типовых конфигураций.
- 1Завершите работу всех пользователей: конфигуратор → Администрирование → Активные пользователи.
- 2Откройте меню Администрирование → Выгрузить информационную базу.
- 3Укажите папку и имя файла, добавьте в имя дату, например base_2026-01-15.dt.
- 4Дождитесь завершения выгрузки — на больших базах это может занять десятки минут.
- 5Проверьте размер файла: он не должен быть нулевым или подозрительно маленьким.
- 6Скопируйте файл на отдельный носитель или сетевое хранилище.
Важно понимать, что выгрузка DT — это не просто копия данных: в файл входит и конфигурация. Поэтому DT-файл удобен для переноса базы на другой компьютер, создания тестовой копии или архивного снимка перед обновлением. Однако при повреждённой базе выгрузка может оборваться с ошибкой, и тогда единственным источником восстановления останется копия на уровне файлов или СУБД.
Копирование файловой базы
Файловая база хранится в одном файле 1Cv8.1CD внутри каталога базы. Чтобы узнать путь, откройте список баз при запуске 1С и посмотрите строку подключения, либо в конфигураторе выберите Администрирование → Свойства. Скопируйте весь каталог целиком — помимо основного файла там могут быть вспомогательные данные.
Обязательное условие — отсутствие активных сеансов. Если копировать файл во время работы пользователей, копия окажется в рассогласованном состоянии и при открытии может потребовать тестирования и исправления. Для регулярного копирования удобно настроить скрипт, который проверяет отсутствие блокировок и копирует файл по расписанию.
xcopy "D:\Bases\Trade" "E:\Backups\Trade_%DATE%" /E /I /YХраните копии с ротацией: например, ежедневные за неделю, еженедельные за месяц, ежемесячные за год. Так вы сможете откатиться не только на вчерашний день, но и на состояние до ошибки, которую заметили спустя время.
Резервное копирование клиент-серверной базы
В клиент-серверном варианте данные хранятся в СУБД — чаще всего Microsoft SQL Server или PostgreSQL. Копирование файлов базы данных вручную недопустимо: это почти гарантированно приведёт к повреждённой копии. Используйте штатные механизмы СУБД.
Бэкап в Microsoft SQL Server
Откройте SQL Server Management Studio, найдите нужную базу, щёлкните правой кнопкой и выберите Tasks → Back Up. Укажите тип Full и путь к файлу .bak. Для регулярных копий настройте план обслуживания (Maintenance Plan) с расписанием — например, полная копия ночью и разностные копии днём.
Бэкап в PostgreSQL
Используйте утилиту pg_dump или pg_dumpall. Команда создаёт целостный снимок без остановки работы пользователей:
pg_dump -U postgres -F c -f /backups/1c_base_$(date +%F).dump имя_базыАвтоматизация: бэкап по расписанию
Ручное копирование рано или поздно забудется, поэтому бэкап должен выполняться без участия человека. Для файловых баз настройте задачу в планировщике Windows, запускающую скрипт копирования ночью. Для SQL Server используйте планы обслуживания, для PostgreSQL — cron или планировщик с вызовом pg_dump.
Некоторые типовые конфигурации содержат встроенный механизм резервного копирования (раздел «Администрирование» → «Резервное копирование и восстановление»). Он удобен для небольших файловых баз, но работает только при запущенном сеансе и не заменяет внешнее копирование. Не полагайтесь на него как на единственный уровень защиты.
Как выбрать схему автоматизации
Проверка и восстановление: как убедиться, что копия рабочая
Бэкап, который никогда не проверяли, нельзя считать бэкапом. Практика показывает: значительная часть копий оказывается непригодной из-за обрыва выгрузки, переполненного диска или копирования во время активных сеансов. Минимальная проверка — сопоставить размер файла с предыдущими копиями; полная — восстановить копию в тестовую базу и открыть её.
Для восстановления из DT создайте пустую базу, зайдите в конфигуратор и выберите Администрирование → Загрузить информационную базу. Для файловой копии достаточно вернуть каталог на место и прописать путь в списке баз. Для SQL Server используйте Restore Database, для PostgreSQL — pg_restore.
Как проверить результат
Сопоставим с предыдущими копиями, отклонение объяснимо ростом данных
Файл резко меньше обычного или равен нулю — выгрузка оборвалась
База открывается, отчёты за последний день показывают ожидаемые данные
Ошибки при открытии, требование тестирования и исправления
Копии есть минимум на двух физически разных носителях
Копия лежит только на том же диске, что и рабочая база
Свежая копия создаётся по расписанию, логи подтверждают успех
Последняя копия старше установленного интервала, уведомлений об ошибках нет
Типичные ошибки и ограничения
Большинство потерь данных связано не с отсутствием технологии, а с ошибками в её применении. Ниже — ситуации, которые встречаются чаще всего.
Отдельно стоит сказать об ограничениях: выгрузка DT не подходит как единственный механизм для баз объёмом в десятки гигабайт — процесс занимает часы и требует монопольного доступа. В таких случаях переходите на клиент-серверный вариант с бэкапом средствами СУБД. И наоборот: бэкап SQL не перенесёт базу на другую платформу, для миграции понадобится именно DT.
Полезно делать обязательную выгрузку DT перед каждым обновлением конфигурации, даже если настроен регулярный бэкап СУБД. Откат после неудачного обновления через загрузку DT обычно проще и быстрее, чем восстановление базы данных целиком.
Частые вопросы о бэкапе в 1С
Чем выгрузка в DT отличается от копирования файла базы?
DT — это логическая выгрузка данных и конфигурации штатным механизмом платформы, она переносима между разными СУБД и версиями хранения. Копирование файла 1Cv8.1CD — физическая копия, которая быстрее, но привязана к файловому режиму и требует отсутствия активных сеансов. Для надёжности лучше комбинировать оба подхода.
Как часто нужно делать резервные копии?
Минимум — ежедневно для активно используемой базы. Если за день вводится много документов, добавьте промежуточные копии (разностные бэкапы СУБД или дополнительные выгрузки). Ориентир простой: потеря какого объёма работы будет для вас приемлемой — такой и должен быть максимальный интервал между копиями.
Можно ли сделать бэкап, не выгоняя пользователей?
Для клиент-серверной базы — да: бэкап средствами SQL Server или pg_dump создаёт согласованный снимок без остановки работы. Для файловой базы и выгрузки DT — нет, требуется завершение сеансов, иначе копия будет неконсистентной.
Где безопасно хранить резервные копии?
Минимум на двух разных носителях: например, на отдельном сервере в локальной сети и во внешнем хранилище или облаке. Копии не должны быть доступны на запись с рабочих станций — это защищает от шифровальщиков. Соблюдайте ротацию: дневные, недельные и месячные копии.
База не открывается, а свежего бэкапа нет. Что делать?
Сначала сделайте копию текущего состояния базы любым доступным способом, чтобы не усугубить ситуацию. Затем запустите утилиту chdbfl.exe из каталога платформы для проверки физической целостности файловой базы или используйте тестирование и исправление в конфигураторе. Если механизмы платформы не помогают, обратитесь к специалистам по восстановлению — самостоятельные эксперименты могут уничтожить остатки данных.
Нужен ли бэкап, если база работает в 1С:Фреш?
Сервис выполняет собственное резервное копирование, но оно защищает от сбоев инфраструктуры, а не от ошибочных действий пользователей — например, массового удаления документов. Поэтому периодически выгружайте данные штатной командой сервиса и храните локальные копии DT.
Что важно запомнить
Выбирайте способ бэкапа под режим работы базы: DT — универсально, копирование файла — для файлового режима, бэкап СУБД — для клиент-серверного. Автоматизируйте копирование по расписанию, храните копии на отдельных носителях с ротацией и регулярно проверяйте восстановление — только проверенная копия считается настоящим бэкапом.