Как настроить бэкап 1С: практическое руководство

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

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

Ниже разобраны оба сценария: как организовать выгрузку и копирование файловой базы, как настроить бэкап средствами SQL Server, как автоматизировать процесс по расписанию и как убедиться, что копия действительно восстанавливается.

Определяем режим работы базы и подходящий способ копирования

Первый шаг — выяснить, в каком режиме работает ваша информационная база. Откройте список баз в окне запуска 1С, выделите базу и посмотрите строку подключения внизу окна. Если указан путь к каталогу вида \\server\1c\buh — это файловый режим. Если указан сервер 1С и имя базы — клиент-серверный.

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

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

Настраиваем выгрузку файловой базы в DT

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

Чтобы не выполнять операцию вручную каждый день, выгрузку автоматизируют через командную строку платформы. Конфигуратор поддерживает пакетный режим с параметром /DumpIB, который запускает выгрузку без открытия интерфейса. Команду помещают в bat-файл и ставят в планировщик заданий Windows на ночное время.

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F "D:\1c\buh" /N Админ /P Пароль /DumpIB "E:\backup\buh_%date:~6,4%-%date:~3,2%-%date:~0,2%.dt" /DisableStartupDialogs

Обратите внимание на путь к исполняемому файлу платформы: номер версии в каталоге меняется при обновлении платформы, и после апгрейда bat-файл может перестать работать. Проверяйте скрипты после каждого обновления платформы.

1. 1
   Создайте каталог для копий на отдельном диске или сетевом ресурсе.
2. 2
   Напишите bat-файл с командой 1cv8.exe DESIGNER /DumpIB и проверьте его запуск вручную.
3. 3
   Откройте планировщик заданий Windows и создайте задачу с запуском bat-файла в нерабочее время.
4. 4
   Задайте запуск от учётной записи с правами доступа к базе и к каталогу копий.
5. 5
   Проверьте появление DT-файла после первого срабатывания и его размер.

Копирование файла базы: быстрый вариант с ограничениями

Если база файловая и ночью с ней гарантированно никто не работает, допустимо простое копирование файла 1Cv8.1CD средствами robocopy или xcopy. Это значительно быстрее выгрузки DT и не требует запуска конфигуратора.

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

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

Настраиваем бэкап клиент-серверной базы на MS SQL Server

Для базы на MS SQL Server резервное копирование выполняется средствами СУБД и не требует остановки работы пользователей. Откройте SQL Server Management Studio, подключитесь к серверу, найдите нужную базу, щёлкните правой кнопкой и выберите «Задачи» → «Создать резервную копию». Укажите тип «Полная» и путь к файлу бэкапа с расширением .bak.

Для регулярного копирования удобнее план обслуживания (Maintenance Plan) или задание агента SQL Server с T-SQL-командой. Команда полного бэкапа выглядит так:

BACKUP DATABASE [buh] TO DISK = N'E:\backup\buh_full.bak' WITH INIT, COMPRESSION, CHECKSUM;

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

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

Организуем хранение копий и ротацию

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

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

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

Проверяем, что бэкап реально восстанавливается

Бэкап, который никогда не проверяли восстановлением, нельзя считать рабочим. Регулярно — хотя бы раз в месяц — выполняйте тестовое восстановление на отдельной тестовой базе. Для DT-файла это загрузка через конфигуратор («Администрирование» → «Загрузить информационную базу») в пустую базу. Для SQL-бэкапа — команда RESTORE DATABASE в новую базу с другим именем.

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

Настройте уведомления о результате бэкапа: хотя бы отправку письма при ошибке выполнения задания. Без этого контроль превращается в ручную проверку, которую рано или поздно перестают делать.

Отдельные меры перед обновлением конфигурации

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

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

Частые вопросы о бэкапе 1С