Администрирование · 10 мин
Резервное копирование 1С: как настроить и не потерять данные
Как настроить резервное копирование 1С: выгрузка через конфигуратор, планировщик заданий, копирование файловой базы, проверка восстановления и типичные ошибки.
Потеря базы 1С — одна из самых дорогих аварий в работе бухгалтерии или отдела продаж: вместе с ней исчезают первичные документы, остатки, расчёты с контрагентами и история за годы. При этом настройка резервного копирования занимает от получаса до пары часов, а восстановление из исправной копии — минуты. Разница между «настроенным бэкапом» и «надеждой, что диск не сломается» становится очевидной только в момент сбоя.
Способ резервного копирования зависит от режима работы базы: файлового или клиент-серверного. Для файловой базы достаточно регулярно копировать файл 1Cv8.1CD и делать выгрузки в формате .dt. Для серверной базы на MS SQL, PostgreSQL или другой СУБД копии делаются средствами самой СУБД, а выгрузка через конфигуратор служит дополнительной страховкой. Ниже разобраны оба сценария, автоматизация через планировщик и проверка того, что копии действительно восстанавливаются.
Что именно нужно копировать в 1С
В файловом режиме вся информационная база хранится в одном файле 1Cv8.1CD, который лежит в каталоге базы. Рядом могут находиться служебные папки и файлы журналов, но критичен именно этот файл — его копия и есть резервная копия базы. Важно понимать: скопировать файл корректно можно только тогда, когда с базой никто не работает, иначе файл может оказаться заблокированным или скопируется в несогласованном состоянии.
В клиент-серверном режиме данные физически хранятся в СУБД (MS SQL Server, PostgreSQL, IBM Db2, Oracle), а сервер 1С лишь обеспечивает доступ. Копирование каталога сервера 1С здесь бессмысленно — резервировать нужно базу данных средствами самой СУБД. Дополнительно имеет смысл делать выгрузку .dt: она независима от СУБД и позволяет развернуть базу даже на другой платформе.
Выгрузка базы через конфигуратор
Ручная выгрузка через конфигуратор — базовый способ, который работает для любого режима. Откройте базу в конфигураторе, выберите пункт меню «Администрирование» → «Выгрузить информационную базу» и укажите путь для сохранения файла .dt. Перед выгрузкой завершите работу всех пользователей: для файловой базы конфигуратор сам потребует монопольный доступ, а в серверном режиме активные сеансы могут привести к несогласованности данных в копии.
Выгрузка .dt имеет важное ограничение: она не предназначена для ежедневного копирования больших серверных баз. Процесс идёт медленно, создаёт нагрузку и не сохраняет некоторые серверные настройки. Для серверной базы .dt — это страховочный вариант на случай миграции или полного отказа инфраструктуры, а не основной механизм бэкапа.
Проверить результат просто: файл .dt должен появиться в указанной папке, иметь ненулевой размер, соизмеримый с размером базы, и — в идеале — успешно загружаться в пустую тестовую базу. Если выгрузка завершилась ошибкой, файл может существовать, но быть непригодным.
Копирование файловой базы
Для файловой базы самый быстрый способ резервного копирования — скопировать файл 1Cv8.1CD целиком. Обязательное условие: все пользователи должны выйти из базы, а сеансы — завершиться. Если копировать файл «на живую», при активной записи копия может содержать повреждённые страницы данных, и база из неё не откроется или откроется с ошибками.
Практичный вариант — настроить автоматическое копирование ночью, когда работа гарантированно не ведётся. Для этого используется планировщик заданий Windows и простой скрипт, который копирует файл в папку с датой в имени. Храните копии за несколько дней или недель, чтобы можно было откатиться не только на «вчера», но и на состояние до ошибочного удаления документов, которое заметили поздно.
- 1Определите точный путь к каталогу базы и файлу 1Cv8.1CD
- 2Создайте папку для копий на другом диске или сетевом ресурсе
- 3Напишите bat-файл с командой копирования и подстановкой даты в имя архива
- 4Добавьте задание в планировщик Windows на ночное время
- 5Проверьте выполнение: копия появилась, размер совпадает с исходным файлом
- 6Раз в месяц открывайте копию в 1С и убеждайтесь, что база работает
@echo off
set SRC=D:\Bases\Trade\1Cv8.1CD
set DST=\\NAS\Backup1C\%DATE:~6,4%-%DATE:~3,2%-%DATE:~0,2%_1Cv8.1CD
copy /Y "%SRC%" "%DST%"
if %errorlevel%==0 (echo OK >> \\NAS\Backup1C\log.txt) else (echo FAIL >> \\NAS\Backup1C\log.txt)Резервное копирование серверной базы через СУБД
Для базы на MS SQL Server резервное копирование настраивается штатными средствами: через SQL Server Management Studio создаётся план обслуживания с полной копией (Full backup) ежедневно и, при необходимости, копиями журнала транзакций в течение дня. Это позволяет восстановить базу не только на начало суток, но и на произвольный момент времени, что критично при больших объёмах ввода документов.
Для PostgreSQL используется утилита pg_dump или pg_basebackup, запускаемые по расписанию через планировщик ОС. Преимущество серверных средств в том, что они делают согласованную копию без остановки работы пользователей — в отличие от выгрузки .dt, которая требует монопольного доступа.
Независимо от СУБД соблюдайте два правила: копии не должны лежать на том же диске, что и рабочая база, и хотя бы одна копия должна находиться вне сервера — на сетевом хранилище, другом сервере или в облаке. Пожар, кража оборудования или выход из строя RAID-массива уничтожат и базу, и лежащие рядом бэкапы.
Как часто делать копии и сколько их хранить
Частота определяется допустимой потерей данных: сколько часов работы вы готовы ввести заново. Если в базу ежедневно загружаются десятки документов, разумный минимум — ежедневная копия. При интенсивной работе на серверной базе добавляют промежуточные копии журнала транзакций каждые 1–4 часа.
По глубине хранения практична схема: ежедневные копии за последнюю неделю, еженедельные — за месяц, ежемесячные — за год. Это защищает не только от аппаратных сбоев, но и от «тихих» ошибок: если документы удалили две недели назад, а заметили только сейчас, вчерашняя копия уже бесполезна, а месячная — спасёт.
Сравнение способов резервного копирования
Универсально и переносимо между платформами, но медленно на больших базах и требует монопольного доступа. Подходит как страховочный вариант.
Быстро и просто для файловых баз, но требует завершения всех сеансов. Не применимо к серверным базам.
Единственный корректный способ для серверных баз: работает без остановки пользователей, поддерживает восстановление на момент времени. Требует навыков администрирования СУБД.
Централизованное управление копиями множества систем, дедупликация и контроль. Избыточны для одной небольшой базы, оправданы в инфраструктуре с несколькими серверами.
Проверка копий и типичные ошибки
Резервная копия, которая не проверялась, — это предположение, а не защита. Минимальный контроль: раз в месяц загружать свежую копию .dt или разворачивать backup СУБД в тестовую базу и открывать её в 1С. Проверьте, что база запускается, ключевые отчёты строятся, а даты последних документов соответствуют ожиданиям.
Отдельно контролируйте сам факт выполнения копирования: задания планировщика молча отваливаются из-за смены пароля учётной записи, переполнения диска или отключения сетевого ресурса. Настройте хотя бы журналирование результата в текстовый файл и периодически просматривайте его.
Как проверить результат
Файл появляется по расписанию, размер соизмерим с базой
Файл отсутствует, нулевого размера или не обновлялся несколько дней
База загружается из копии и открывается без ошибок
При загрузке или открытии возникают ошибки, база не запускается
В восстановленной копии есть документы за последний рабочий день
Последние документы датированы давно — копирование фактически не работает
Свободное место с запасом на несколько циклов копирования
Диск почти заполнен — очередное копирование завершится ошибкой
Частые вопросы
Можно ли настроить автоматическую выгрузку .dt по расписанию?
Да. Конфигуратор 1С поддерживает пакетный режим запуска из командной строки с параметрами выгрузки, поэтому можно создать скрипт и запускать его через планировщик Windows. Учтите, что для выгрузки потребуется монопольный доступ — сеансы пользователей придётся завершать принудительно, поэтому такое задание ставят на ночное время.
Достаточно ли копировать базу раз в неделю?
Зависит от интенсивности работы. Если за неделю в базу вводится мало документов и их легко восстановить по бумажным источникам, недельной копии может хватить. Для активно используемой базы потеря недели ввода обычно неприемлема — нужна ежедневная копия.
Чем выгрузка .dt отличается от копии файла 1Cv8.1CD?
Копия файла — это побайтовый снимок базы, который можно использовать только в том же файловом режиме. Выгрузка .dt — логический переносимый архив: из него базу можно загрузить и в файловый, и в серверный режим, а также перенести на другую СУБД. При этом .dt создаётся дольше и требует монопольного доступа.
Нужно ли делать бэкап, если база работает в облаке у франчайзи?
Обычно облачный провайдер выполняет резервное копирование сам, но стоит уточнить условия: глубину хранения копий, порядок и сроки восстановления по запросу. Для критичных данных разумно периодически делать собственную выгрузку .dt и хранить её локально — это защищает и от ошибок самого провайдера, и от спорных ситуаций при смене сервиса.
База не открывается, а свежей копии нет. Что делать?
Не запускайте многократные попытки открытия и не применяйте «тестирование и исправление» бездумно — при некоторых повреждениях это ухудшает ситуацию. Сначала сделайте копию повреждённого файла в отдельную папку, затем попробуйте утилиту chdbfl.exe из каталога платформы для файловой базы. Если данные критичны и копии нет совсем, лучше обратиться к специалисту по восстановлению до любых экспериментов.
Что важно запомнить
Определите режим базы и выберите подходящий способ: копирование файла для файловой базы, backup средствами СУБД для серверной, выгрузка .dt как универсальная страховка. Автоматизируйте копирование через планировщик, храните копии на отдельном носителе с глубиной от недели до года и регулярно проверяйте восстановление — только проверенная копия считается настоящей.