Чем делать резервное копирование 1С

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

Главная ошибка — считать, что «копия как-то делается». На практике нередко выясняется, что выгрузка не выполнялась месяцами из-за нехватки места, смены пароля или того, что пользователи не выходили из базы. Поэтому важен не только инструмент, но и регулярная проверка того, что копии реально создаются и восстанавливаются.

Ниже разобраны основные способы резервного копирования 1С с их ограничениями, порядком настройки и типичными ошибками. Материал ориентирован на администраторов и пользователей, которые обслуживают базу самостоятельно.

Какие бывают способы резервного копирования 1С

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

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

Выгрузка базы через конфигуратор

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

Файл .dt содержит и данные, и конфигурацию, поэтому его удобно использовать для переноса базы на другой компьютер, между файловым и клиент-серверным вариантом, а также как архивную копию «на всякий случай». Обратная операция — «Загрузить информационную базу» — полностью замещает текущую базу содержимым файла, поэтому перед загрузкой стоит сделать отдельную копию текущего состояния.

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

Автоматическая выгрузка по расписанию

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

"C:\Program Files\1cv8\8.3.22.1750\bin\1cv8.exe" DESIGNER /F"D:\Bases\Trade" /N"Администратор" /P"пароль" /DumpIB"D:\Backup\trade_%date:~0,2%-%date:~3,2%.dt" /DisableStartupDialogs

Путь к исполняемому файлу платформы зависит от установленной версии — проверьте его в каталоге установки. Имя файла копии удобно формировать с датой, чтобы копии не затирали друг друга. Отдельно настройте очистку старых файлов: без неё диск рано или поздно заполнится, и копирование начнёт молча завершаться ошибкой.

1. 1
   Создайте отдельный каталог для копий на диске с запасом свободного места
2. 2
   Напишите bat-файл с командой выгрузки и проверьте его запуском вручную
3. 3
   Добавьте задание в планировщик Windows на время, когда пользователи не работают
4. 4
   Настройте удаление копий старше заданного срока хранения
5. 5
   Через неделю проверьте, что файлы реально создаются и имеют ненулевой размер

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

Если база работает на MS SQL Server или PostgreSQL, основным инструментом должны быть штатные механизмы СУБД. В MS SQL это планы обслуживания или задания агента с командой BACKUP DATABASE; в PostgreSQL — утилита pg_dump или физическое копирование с WAL-архивацией. Такие копии создаются быстро, не требуют выгона пользователей (при корректной настройке) и легко ставятся на расписание.

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

Для MS SQL имеет значение модель восстановления базы. При полной модели (Full) доступны разностные копии и копии журнала транзакций, позволяющие восстановить состояние на конкретный момент времени; при простой (Simple) — только полные и разностные копии. Выбор зависит от того, допустима ли потеря данных за период между копиями.

Копирование файловой базы как файла

Файловая база — это каталог, в котором основные данные хранятся в файле 1Cv8.1CD. Теоретически его можно просто копировать любым файловым менеджером или программой резервного копирования. Но делать это можно только тогда, когда база полностью закрыта всеми пользователями: если копировать открытый файл, есть риск получить повреждённую или несогласованную копию, которая не откроется.

На практике надёжнее копировать не сам файл базы «вживую», а результаты выгрузки .dt. Если всё же используете файловое копирование, настройте его на время, когда сеансов гарантированно нет, и периодически проверяйте копию открытием в тестовом режиме.

Внешние программы и облачное хранение

Программы резервного копирования (Veeam, Cobian Backup, средства NAS и подобные) и облачные хранилища полезны как второй уровень: они забирают уже готовые файлы .dt или бэкапы СУБД и складывают их в другое место — на сетевое хранилище, внешний диск или в облако. Это защищает от пожара, кражи сервера и шифровальщиков.

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

Как проверить, что копия рабочая

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

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

Часто задаваемые вопросы