Администрирование · 10 мин
Как лучше делать бэкап 1С: практическое руководство
Как делать бэкап 1С: выгрузка в dt, бэкап средствами СУБД, расписание копий, правило 3-2-1, проверка восстановления и типичные ошибки администраторов.
Бэкап информационной базы 1С — это не формальность, а единственный способ восстановить учёт после сбоя диска, ошибки обновления, действий вируса-шифровальщика или случайного удаления данных. При этом «делать бэкап» и «уметь восстановиться из бэкапа» — разные вещи: копия, которая никогда не проверялась, может оказаться битой именно в тот момент, когда она понадобится.
Правильный способ резервного копирования зависит от формата базы. Файловая база (один файл 1Cv8.1CD) копируется иначе, чем клиент-серверная на MS SQL, PostgreSQL или Oracle. Универсальный метод, работающий в обоих случаях, — выгрузка в файл dt через конфигуратор, но у него есть ограничения по скорости и требованию монопольного доступа.
Ниже разобраны основные способы бэкапа 1С, их сравнение, настройка расписания, правила хранения копий и обязательная проверка восстановления. Материал подходит администраторам и ответственным пользователям, которые обслуживают базу самостоятельно.
Выгрузка в dt — универсальный способ для любой базы
Выгрузка информационной базы в файл с расширением dt выполняется через конфигуратор: меню «Администрирование» → «Выгрузить информационную базу». Платформа упаковывает данные и конфигурацию в один файл, который затем можно загрузить в пустую базу на любом компьютере с подходящей версией платформы.
Главное условие — монопольный доступ: во время выгрузки в базе не должно быть активных сеансов пользователей и фоновых заданий. Если кто-то работает, выгрузка либо не запустится, либо будет прервана. Поэтому dt-выгрузку обычно ставят на ночь или раннее утро, предварительно завершая сеансы принудительно.
Ограничения метода: на больших базах (десятки гигабайт) выгрузка занимает часы, а сам файл dt не пригоден для инкрементального копирования — каждый раз создаётся полная копия. Для файловых баз небольшого и среднего размера это, тем не менее, самый простой и надёжный вариант, потому что dt не зависит от структуры каталогов и переносится между компьютерами без дополнительных настроек.
- 1Завершите сеансы всех пользователей и отключите регламентные задания
- 2Откройте базу в конфигураторе под пользователем с полными правами
- 3Выберите «Администрирование» → «Выгрузить информационную базу»
- 4Укажите путь и имя файла, дождитесь завершения без ошибок
- 5Проверьте, что файл dt существует и имеет ненулевой размер
Копирование файловой базы напрямую
Файловая база — это каталог, в котором главную роль играет файл 1Cv8.1CD. Технически достаточно скопировать этот файл (а лучше весь каталог) в другое место — и копия готова. Такой способ быстрее выгрузки в dt и легко автоматизируется скриптом или планировщиком задач Windows.
Критическое условие то же: в момент копирования с базой никто не должен работать. Если скопировать файл, пока пользователи проводят документы, копия может оказаться логически повреждённой — она откроется, но данные будут в несогласованном состоянии. Поэтому скрипт копирования должен либо запускаться в гарантированно нерабочее время, либо предварительно блокировать соединения.
Бэкап клиент-серверной базы средствами СУБД
Если 1С работает на MS SQL Server, PostgreSQL или другой СУБД, правильное место для бэкапа — сама СУБД, а не конфигуратор. Средства СУБД создают согласованную копию «на горячую», без остановки работы пользователей, и поддерживают разностные копии и копии журнала транзакций, что позволяет восстановить базу на произвольный момент времени, а не только на момент последнего полного бэкапа.
Для MS SQL настраивают план обслуживания: полная копия ежедневно, разностные — несколько раз в день, копии журнала транзакций — каждые 15–60 минут при модели восстановления Full. Для PostgreSQL используют pg_dump для логических копий или pg_basebackup с архивированием WAL для физических. Конкретный механизм выбирают исходя из допустимого времени простоя и требований к точке восстановления.
Важно понимать: бэкап средствами СУБД восстанавливается только в ту же СУБД, а не через конфигуратор. Поэтому даже в клиент-серверном варианте полезно периодически (например, раз в неделю или перед обновлением) делать дополнительную выгрузку в dt — она служит независимой страховкой и упрощает перенос базы на другую платформу или в файловый вариант.
Сравнение способов бэкапа 1С
Универсально, переносимо между платформами; требует монопольного доступа и медленно на больших базах
Быстро и просто для файловых баз; опасно при активных сеансах, нет контроля целостности
Горячее копирование без остановки работы, точка восстановления на любой момент; требует навыков администрирования СУБД
Централизованное расписание, дедупликация, хранение в облаке; нужно проверять корректность работы с открытыми файлами и СУБД
Расписание и правило 3-2-1
Частота бэкапов определяется допустимой потерей данных: задайте вопрос «сколько часов работы мы готовы ввести заново?». Если ответ — один рабочий день, достаточно ежедневной копии ночью. Если потеря даже часа критична (касса, склад, онлайн-заказы), нужны копии журнала транзакций или несколько бэкапов в течение дня.
Хранение строится по правилу 3-2-1: минимум три копии данных, на двух разных носителях, одна — вне основной площадки. На практике это означает: копия на сервере или NAS в локальной сети плюс копия в облачном хранилище или на выносном диске. Глубина хранения — обычно от нескольких дней до месяца ежедневных копий плюс месячные архивы за более длинный период.
Отдельно защитите бэкапы от шифровальщиков: учётная запись, под которой работают пользователи и службы 1С, не должна иметь права записи в каталог архива. Идеально, если копии забирает отдельная служба с правами только на чтение источника или если хранилище недоступно для записи с рабочих станций.
Автоматизация и контроль выполнения
Ручной бэкап «когда вспомнили» не работает — копирование должно запускаться по расписанию без участия человека. Для файловых баз используют планировщик задач Windows со скриптом, который блокирует соединения, делает выгрузку или копирование и снимает блокировку. Для СУБД — встроенные планы обслуживания или задания агента SQL Server / cron.
Не менее важен контроль: система должна сообщать, если бэкап не выполнен. Минимальный набор — лог с датой и результатом каждого запуска, уведомление на почту при ошибке и регулярный визуальный контроль наличия свежих файлов. Типичная ситуация отказа: диск под копии переполнился месяц назад, скрипт падает с ошибкой, а узнают об этом только при попытке восстановления.
Проверка восстановления — обязательный этап
Бэкап считается рабочим только после успешного восстановления. Раз в месяц (минимум — раз в квартал) загрузите свежий dt в пустую тестовую базу или восстановите копию СУБД на отдельный сервер. Проверьте, что база открывается, конфигурация соответствует рабочей, а ключевые отчёты (оборотно-сальдовая ведомость, остатки склада) показывают осмысленные данные.
Заодно замерьте время восстановления. Если база восстанавливается шесть часов, а бизнес готов ждать два — это нужно знать заранее и либо менять метод бэкапа (например, физические копии вместо dt), либо честно фиксировать допустимое время простоя в регламенте.
Как проверить результат
Свежий файл с ожидаемой датой и размером, сопоставимым с предыдущими
Файл отсутствует, устарел или резко уменьшился в размере
База открывается, отчёты формируются без ошибок
Ошибки загрузки dt, нехватка данных, падение платформы
Каждый запуск завершается успешным кодом, ошибки с уведомлением
Ошибки в логе без уведомлений, пропуски запусков
FAQ: частые вопросы о бэкапе 1С
Достаточно ли копировать базу перед каждым обновлением?
Нет. Копия перед обновлением защищает только от неудачного обновления, но не от сбоя диска, шифровальщика или случайного удаления данных между обновлениями. Нужен регулярный бэкап по расписанию, а копия перед обновлением — дополнительная мера.
Чем dt-выгрузка отличается от бэкапа СУБД?
dt — логическая выгрузка средствами платформы 1С, переносимая между СУБД и файловым вариантом, но требующая монопольного доступа. Бэкап СУБД — физическая копия на уровне базы данных, делается без остановки работы и позволяет восстановиться на произвольный момент времени, но привязана к конкретной СУБД.
Как часто нужно делать бэкап?
Ориентируйтесь на допустимую потерю данных: ежедневная копия подходит, если готовы повторно ввести документы за день. При непрерывной работе (торговля, склад) добавляют разностные копии или копии журнала транзакций несколько раз в день.
Можно ли хранить бэкапы только в облаке?
Можно, но лучше не только там: при проблемах с интернетом или аккаунтом восстановление затянется. Оптимально — локальная копия для быстрого восстановления плюс облачная как защита от пожара, кражи оборудования и шифровальщиков.
Что делать, если бэкап не восстанавливается?
Сначала проверьте предыдущие копии — именно для этого хранят историю, а не один файл. Для файловых баз можно попробовать утилиту chdbfl.exe из каталога платформы для проверки и исправления физической целостности. Если повреждены все копии, восстановление возможно только специализированными средствами с диска, и результат не гарантирован.
Нужно ли делать бэкап, если база в облачном сервисе 1С?
Да. Облачный провайдер делает свои копии, но доступ к ним и сроки восстановления ограничены условиями сервиса. Регулярная собственная выгрузка в dt даёт независимость: базу можно развернуть локально или у другого провайдера в любой момент.
Что важно запомнить
Настройте автоматический бэкап по расписанию: dt для файловых баз в нерабочее время, средства СУБД — для клиент-серверных. Храните копии по правилу 3-2-1 с изоляцией от шифровальщиков, контролируйте выполнение заданий и регулярно проверяйте восстановление на тестовой базе. Непроверенный бэкап — это отсутствие бэкапа.