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

В этой статье разберём все этапы настройки архивирования: от выбора типа резервной копии до тонкостей работы с dt- и cf-файлами. Особое внимание уделим автоматизации процесса через планировщик задач и скрипты, а также типичным ошибкам, которые приводят к неработоспособным бэкапам. Если вы администрируете 1С или просто хотите обезопасить свои данные — читайте далее.

Сразу отметим: инструкции актуальны для всех конфигураций на платформе 1С:Предприятие 8.3 (включая Бухгалтерию 3.0, УТ 11, ЗУП 3.1 и др.), но некоторые параметры могут отличаться в зависимости от версии платформы и типа СУБД (Microsoft SQL Server, PostgreSQL или файловая база). Для корректной работы всегда сверяйте настройки с документацией вашей конкретной конфигурации.

1. Типы архивов в 1С 8.3: какой выбрать для ваших задач

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

Файловая копия (.dt) — самый простой и универсальный вариант. Подходит для файлового варианта работы (без СУБД) и создаётся через стандартный механизм Выгрузить информационную базу. Такой архив содержит все данные, включая документы, справочники и настройки, но не включает в себя cf-файл конфигурации. Главный плюс — простота создания и восстановления, минус — большой размер файла (особенно для крупных баз).

Копия через СУБД (для клиент-серверных баз) — используется, если 1С работает с Microsoft SQL Server или PostgreSQL. Здесь архивирование выполняется средствами самой СУБД (например, через SQL Server Management Studio или pg_dump), что позволяет гибко настраивать частоту бэкапов и сжимать данные. Такой подход оптимален для больших баз с высокой нагрузкой, но требует знаний администрирования СУБД.

Инкрементальные и дифференциальные копии — продвинутый метод, при котором архивируются только изменения с последнего полного бэкапа. Экономит место на диске и время, но восстановление занимает больше шагов (нужно последовательно применить все инкрементальные архивы). В 1С этот механизм реализуется через сторонние утилиты или скрипты.

  • 📁 Файловая копия (.dt) — для небольших баз и файлового режима. Легко создаётся вручную.
  • 🗄️ СУБД-бэкап — для клиент-серверных баз. Требователен к настройке, но надёжен.
  • ⚡ Инкрементальный бэкап — для экономии места. Нужны дополнительные инструменты.
⚠️ Внимание: Если ваша база работает на PostgreSQL, учитывайте, что стандартный pg_dump не всегда корректно архивирует данные 1С из-за специфики хранения BLOB-объектов. Для надёжности используйте утилиту pg_dump с флагом --format=custom или специализированные решения вроде Barman.

2. Ручное архивирование: пошаговая инструкция для файловой базы

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

Чтобы выгрузить базу в файл .dt:

  1. Закройте все сеансы работы с 1С:Предприятие (включая фоновые задачи).
  2. Запустите 1С:Предприятие в режиме Конфигуратор (для этого удерживайте Shift при запуске ярлыка).
  3. В меню выберите Администрирование → Выгрузить информационную базу.
  4. Укажите путь для сохранения файла (рекомендуется использовать внешний диск или сетевой ресурс).
  5. Дождитесь завершения процесса (в статусной строке появится сообщение Выгрузка завершена).

Готовый файл .dt будет содержать все данные базы на момент выгрузки. Для восстановления используйте команду Администрирование → Загрузить информационную базу.

Закрыты все пользовательские сеансы|Проверено свободное место на диске (не менее 1.5× от размера базы)|Указан путь вне системного диска (C:)|Сделан тестовый бэкап на небольшой базе для проверки процесса-->

Если база большая (от 10 ГБ), выгрузка может занять несколько часов. В этом случае лучше использовать архивирование через СУБД или настроить автоматический бэкап (об этом — в следующем разделе).

💡

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

3. Автоматическое архивирование: настройка через планировщик задач

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

Для файловой базы автоматизацию можно реализовать через планировщик задач Windows или специализированные утилиты (например, 1C:Backup). Рассмотрим оба варианта.

Способ 1: Планировщик задач Windows + командная строка

Этот метод подходит для баз, работающих в файловом режиме. Вам понадобится:

  1. Создать .bat-файл с командой выгрузки базы. Пример скрипта: 
    "C:\Program Files\1cv8\8.3.20.1500\bin\1cv8.exe" DESIGNER /S"C:\Bases\MyBase" /NАдминистратор /P12345 /DumpIB"D:\Backups\MyBase_$(date +%Y%m%d).dt"

    Здесь:

    • /S — путь к базе;
    • /N и /P — имя и пароль администратора;
    • /DumpIB — команда выгрузки;
    • $(date +%Y%m%d) — подстановка текущей даты в имя файла (для Linux/macOS; в Windows используйте %DATE%).
  • Сохранить файл как backup.bat.
  • Открыть Планировщик задач Windows (taskschd.msc) и создать новую задачу:
    • Триггер: Ежедневно в 23:00;
    • Действие: Запустить программу → указать путь к backup.bat;
    • Установить флаг Выполнять с наивысшими правами.

    • Способ 2: Утилита 1C:Backup

    Для клиент-серверных баз удобнее использовать 1C:Backup — бесплатную утилиту от 1С, которая поддерживает:

    • 🔄 Автоматическое создание бэкапов по расписанию;
    • 🗃️ Хранение нескольких версий архивов;
    • 📧 Отправку уведомлений о результате архивирования;
    • 🔒 Шифрование резервных копий.

    Скачайте утилиту с сайта 1С и настройте её через интерфейс:

    1. Добавьте информационную базу (укажите путь или строку подключения к СУБД).
    2. Настройте расписание (например, ежедневно в 1:00).
    3. Укажите путь для хранения бэкапов (желательно на другом физическом диске).
    4. Включите опцию Проверять целостность архива после создания.

    Ежедневно|Раз в неделю|Раз в месяц|Только перед обновлениями|Не делаю бэкапы-->

    ⚠️ Внимание: Если ваша база работает на SQL Server, не полагайтесь только на встроенные средства 1С для бэкапа. Настройте дополнительно native backup через SQL Server Management Studio с параметром COMPRESSION — это ускорит процесс и уменьшит размер архива.

    4. Архивирование баз на SQL Server и PostgreSQL

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

    Для Microsoft SQL Server

    Оптимальный способ — настроить план обслуживания (Maintenance Plan) через SQL Server Management Studio:

    1. Откройте SSMS и подключитесь к серверу.
    2. В Обозревателе объектов разверните Управление → Планы обслуживания.
    3. Создайте новый план и добавьте задачу Резервное копирование базы данных.
    4. Выберите базу 1С (обычно её имя начинается с 1C_).
    5. Укажите тип бэкапа:
      • Полное — для основной копии (рекомендуется еженедельно);
      • Дифференциальное — для ежедневных бэкапов;
      • Журнал транзакций — для минимальных потерь данных (каждые 15–30 минут).
    6. Настройте расписание и путь сохранения (например, D:\SQLBackups\).

      7. Для восстановления используйте команду: 

      RESTORE DATABASE [1C_Base]

      FROM DISK = 'D:\SQLBackups\1C_Base_full.bak'
      

      WITH REPLACE, STATS = 10;

      Для PostgreSQL

      В PostgreSQL архивирование выполняется через утилиту pg_dump. Пример команды для полного бэкапа: 

      pg_dump -U postgres -Fc -d 1c_base -f "D:\Backups\1c_base_$(date +%Y%m%d).dump"

      Где:

      • -U postgres — имя пользователя;
      • -Fc — формат custom (сжатый);
      • -d 1c_base — имя базы данных.

    Для автоматизации добавьте команду в cron (Linux) или Планировщик задач (Windows).

    Параметр SQL Server PostgreSQL
    Тип бэкапа Полный, дифференциальный, журнал транзакций Полный (pg_dump), инкрементальный (WAL-архивирование)
    Сжатие Да (опция COMPRESSION) Да (формат custom)
    Восстановление Через RESTORE DATABASE Через pg_restore
    Автоматизация Планы обслуживания cron или pgBackRest

    5. Проверка целостности архивов и восстановление данных

    Создание бэкапа — только половина дела. Не менее важно проверять целостность архивов и уметь быстро восстанавливать данные в случае сбоя. Рассмотрим оба процесса.

    Проверка архива

    Для файловой копии (.dt):

    1. Создайте тестовую базу через Конфигуратор (Файл → Новая информационная база).
    2. Загрузите в неё архив (Администрирование → Загрузить информационную базу).
    3. Проверьте, что база открывается без ошибок и содержит актуальные данные.

    Для SQL Server используйте команду: 

    RESTORE VERIFYONLY

    FROM DISK = 'D:\SQLBackups\1C_Base_full.bak';

    Для PostgreSQL: 

    pg_restore --verify -d postgres "D:\Backups\1c_base.dump"

    Восстановление данных

    Если база повреждена, действуйте по алгоритму:

    1. Остановите все сеансы работы с 1С.
    2. Для файловой базы:
      • Удалите повреждённую базу (или переместите её в другой каталог).
      • Создайте новую базу через Конфигуратор.
      • Загрузите резервную копию (.dt).
    3. Для SQL Server: 
      RESTORE DATABASE [1C_Base]

      FROM DISK = 'D:\SQLBackups\1C_Base_full.bak'
      

      WITH REPLACE, RECOVERY;

    4. Для PostgreSQL: 
      pg_restore -U postgres -d 1c_base "D:\Backups\1c_base.dump"
      5. Что делать, если бэкап повреждён?

      Если архив не восстанавливается, попробуйте:

      1. Использовать более раннюю резервную копию.

      2. Для .dt-файлов — попробовать открыть его через утилиту chdbfl.exe (входит в комплект 1С):

      chdbfl.exe D:\Backups\MyBase.dt /F

      Флаг /F попытается исправить ошибки.

      3. Для SQL Server — попробовать восстановить с опцией CONTINUE_AFTER_ERROR.

      4. Если ничего не помогает — обратитесь в службу поддержки 1С с логами ошибок.

      ⚠️ Внимание: При восстановлении базы на PostgreSQL убедитесь, что версия сервера совпадает с версией, на которой был создан бэкап. Восстановление на более новую версию возможно, а на более старую — нет.

      6. Типичные ошибки и как их избежать

      Даже опытные администраторы иногда сталкиваются с проблемами при архивировании. Вот самые распространённые ошибки и способы их предотвращения:

      • 🚫 Бэкап на системный диск — если Windows выйдет из строя, вы потеряете и архивы. Всегда сохраняйте копии на отдельный физический диск или в облако.
      • 🕒 Несоблюдение расписания — если бэкапы создаются в рабочее время, это может замедлить работу 1С. Настраивайте архивирование на ночное время.
      • 🔄 Отсутствие ротации — накопление старых бэкапов занимает место и усложняет поиск актуальной копии. Настройте автоматическое удаление архивов старше 30 дней.
      • 🔑 Хранение паролей в открытом виде — в скриптах бэкапа не должны содержаться пароли в чистом виде. Используйте переменные окружения или 1С:Хранилище паролей.
      • 📉 Игнорирование журналов транзакций — для SQL Server это критично: без бэкапа журналов вы потеряете данные между полными копиями.

      Критическая ошибка: многие администраторы не тестируют восстановление из бэкапов, считая, что если архив создался — он рабочий. По статистике, до 30% резервных копий не восстанавливаются из-за скрытых ошибок (например, повреждения файлов или несовместимости версий). Регулярно проверяйте архивы на тестовом стенде!

      Ещё одна распространённая проблема — блокировки базы во время архивирования. Если в момент создания бэкапа в базе работают пользователи, файловая копия (.dt) может получиться неполной. Решение:

      • Используйте режим монопольного доступа (для файловой базы);
      • Для SQL Server настройте бэкап журналов транзакций;
      • Для PostgreSQL используйте pg_dump с флагом --exclude-table-data для больших таблиц.

      7. Облачное архивирование: плюсы и минусы

      Хранение бэкапов в облаке (например, Яндекс Диск, Google Drive или специализированные сервисы вроде 1C:Fresh) имеет свои преимущества, но и ограничения. Разберём ключевые моменты.

      Плюсы:

      • 🌍 Доступность из любой точки мира;
      • 🔒 Защита от физических повреждений оборудования (пожар, кража);
      • 📈 Масштабируемость — не нужно заботиться о месте на диске;
      • 🤖 Автоматизация — многие облачные сервисы поддерживают API для загрузки бэкапов.

      Минусы:

      • 🐢 Низкая скорость восстановления (зависит от скорости интернета);
      • 💰 Стоимость (для больших баз может быть дорого);
      • 🔐 Риски безопасности (данные хранятся на сторонних серверах);
      • 📡 Зависимость от интернет-соединения.

      Для автоматизации загрузки бэкапов в облако можно использовать скрипт на PowerShell (для Windows) или Bash (для Linux). Пример для Яндекс Диска: 

      # Установите Yandex Disk CLI (https://yandex.ru/dev/disk/cli/)

      yandex-disk upload "D:\Backups\MyBase.dt" "/1C_Backups/MyBase_$(date +%Y%m%d).dt"

      Для 1C:Fresh бэкапы создаются автоматически, но их можно выгрузить вручную через личный кабинет. Обратите внимание, что в бесплатном тарифе хранится только одна резервная копия — актуальная на момент последнего обновления.

      ⚠️ Внимание: При использовании облачных сервисов убедитесь, что они соответствуют требованиям ФЗ-152 (о персональных данных). Для бухгалтерских баз с данными сотрудников и клиентов рекомендуется шифровать архивы перед загрузкой (например, через 7-Zip с паролем).

      8. Оптимизация процесса: как ускорить архивирование и сэкономить место

      Крупные базы (от 50 ГБ) требуют особого подхода к архивированию. Вот несколько способов оптимизировать процесс:

      • ⚡ Исключение временных данных — если в базе есть большие временные таблицы (например, лог изменений), исключите их из бэкапа. В PostgreSQL это делается через pg_dump --exclude-table=temp_table.
      • 🗜️ Сжатие — используйте встроенные средства СУБД или сторонние утилиты (7-Zip, WinRAR). Для SQL Server включите опцию COMPRESSION.
      • 🔄 Инкрементальные бэкапы — архивируйте только изменения с последнего полного бэкапа. В SQL Server это дифференциальные копии, в PostgreSQL — WAL-архивирование.
      • 📁 Разделение на части — для очень больших баз (<100 ГБ) разбейте бэкап на несколько файлов. В SQL Server это делается через опцию FILE в команде BACKUP.

      Пример команды для SQL Server с сжатием и разделением на файлы по 10 ГБ: 

      BACKUP DATABASE [1C_Base]

      TO DISK = 'D:\SQLBackups\1C_Base_part1.bak',
      

      DISK = 'D:\SQLBackups\1C_Base_part2.bak'
      

      WITH COMPRESSION, MAXTRANSFERSIZE = 10737418240, STATS = 10;

      Для ускорения восстановления держите под рукой шаблон пустой базы с предварительно настроенной структурой. Это сократит время на создание таблиц и индексов при восстановлении.

      💡

      Регулярно анализируйте размер бэкапов. Если они растут слишком быстро (например, на 20% в месяц), проверьте базу на наличие "мусорных" данных (удалённых документов, неиспользуемых справочников) и очистите её с помощью обработки 1С:Предприятие → Все функции → Очистка данных.

      FAQ: Частые вопросы по архивированию 1С 8.3

      Можно ли сделать бэкап, если пользователи работают в базе?

      Для файловой базы — нет, нужно закрыть все сеансы. Для клиент-серверной базы (SQL/PostgreSQL) — да, но рекомендуется использовать бэкап журналов транзакций, чтобы избежать потери данных.

      Если прервать работу пользователей невозможно, используйте режим монопольного доступа (для файловой базы) или настройте репликацию (для СУБД).

      Как часто нужно делать бэкапы?

      Зависит от интенсивности работы с базой:

      • Ежедневно — для активных баз (например, торговля или бухгалтерия с ежедневными проводками);
      • Еженедельно — для справочных баз с редкими изменениями;
      • Перед критическими операциями (обновление конфигурации, массовая загрузка данных).

    Дополнительно настройте бэкап журналов транзакций (для SQL) каждые 15–30 минут, если данные критически важны.

    Что делать, если бэкап занимает слишком много места?

    Попробуйте следующие методы:

    1. Используйте сжатие (в SQL Server — опция COMPRESSION, в PostgreSQL — формат custom).
    2. Настройте инкрементальные бэкапы (для SQL — дифференциальные, для PostgreSQL — WAL-архивирование).
    3. Очистите базу от ненужных данных (удалённые документы, старые логи).
    4. Исключите из бэкапа временные таблицы или большие BLOB-объекты (например, прикреплённые файлы).

    Если проблема сохраняется, рассмотрите вариант разделения базы на логические части (например, вынести архивные данные в отдельную базу).

    Как защитить бэкапы от вирусов-шифровальщиков?

    Вирусы типа WannaCry или Locky часто шифруют резервные копии. Чтобы этого избежать:

    • Храните бэкапы на отдельном физическом диске, отключённом от сети;
    • Используйте шифрование архивов (например, 7-Zip с паролем);
    • Настройте доступ по сети только для определённых IP-адресов;
    • Регулярно проверяйте бэкапы на вирусы до их использования для восстановления.

    Для максимальной безопасности используйте правило 3-2-1: 3 копии данных, на 2 разных типах носителей, 1 копия вне офиса (например, в облаке).

    Можно ли восстановить базу на более новую версию платформы 1С?

    Да, но с оговорками:

    • Файловая база (.dt) — восстановится, но потребуется обновить конфигурацию через Конфигуратор;
    • SQL/PostgreSQL — база восстановится, но может потребоваться обновление структуры через Тестирование и исправление;
    • Если разница версий платформы значительная (например, с 8.3.10 на 8.3.20), сначала обновите тестовую копию базы и проверьте её работоспособность.

    Восстановление на более старую версию платформы невозможно!