Как в 1С настроить автосохранение и защитить данные от потери

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

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

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

Что в 1С сохраняется автоматически, а что нет

Понимание архитектуры избавляет от ложных ожиданий. Когда пользователь нажимает «Записать» или «Провести», платформа фиксирует данные в информационной базе сразу — в файловом варианте это запись в файл 1Cv8.1CD, в клиент-серверном — транзакция в СУБД. Пока документ просто открыт и редактируется, его содержимое существует только в памяти клиентского приложения. Закрытие сеанса без записи означает безвозвратную потерю введённых данных.

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

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

Автосохранение в конфигураторе для разработчика

Единственное место в платформе, где есть прямая настройка автосохранения, — это конфигуратор. Откройте меню «Сервис → Параметры» и перейдите на вкладку «Модули». Здесь находится группа настроек автосохранения текстов модулей: можно включить сохранение редактируемых модулей через заданный интервал времени и указать каталог для временных копий.

Установите флажок автосохранения и задайте интервал — разумное значение для активной разработки составляет 3–5 минут. Слишком маленький интервал создаёт лишнюю нагрузку при работе с большими модулями, слишком большой — снижает ценность защиты. Каталог для автосохранённых копий лучше разместить на отдельном диске или в папке, которая сама попадает в резервное копирование.

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

1. 1
   Откройте конфигуратор и перейдите в меню Сервис → Параметры
2. 2
   Выберите вкладку «Модули»
3. 3
   Установите флажок автосохранения и укажите интервал 3–5 минут
4. 4
   Задайте каталог для временных копий на отдельном диске
5. 5
   Откройте любой модуль, внесите правку и дождитесь интервала — проверьте появление копии в каталоге

Защита пользовательских данных: дисциплина записи и напоминания

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

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

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

Резервное копирование файловной базы: ручной и автоматический способы

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

Альтернатива без выгрузки — копирование самого файла 1Cv8.1CD. Это допустимо только когда с базой никто не работает, иначе копия может оказаться неконсистентной. Для автоматизации удобно использовать планировщик заданий Windows и простой командный файл, запускаемый в нерабочее время, например ночью.

Типовой подход: скрипт завершает сеансы (или запускается в часы, когда сеансов гарантированно нет), копирует файл базы в архивный каталог с датой в имени и удаляет копии старше заданного срока. Храните копии на другом физическом носителе или сетевом ресурсе — копия на том же диске не спасёт при отказе диска.

@echo off
set SRC=C:\Bases\Trade\1Cv8.1CD
set DST=D:\Backup\1C
set NAME=trade_%date:~6,4%-%date:~3,2%-%date:~0,2%.1CD
copy "%SRC%" "%DST%\%NAME%"
forfiles /p "%DST%" /m *.1CD /d -14 /c "cmd /c del @path"

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

Автосохранение и бэкап в клиент-серверном варианте

В клиент-серверной архитектуре данные хранятся в СУБД (MS SQL Server, PostgreSQL и др.), и резервное копирование выполняется штатными средствами самой СУБД. Это надёжнее и гибче: для MS SQL настраивается план обслуживания с полной копией ежедневно и копиями журнала транзакций несколько раз в день, что позволяет восстановить базу на произвольный момент времени.

Для PostgreSQL применяется pg_dump по расписанию через планировщик или настройка непрерывного архивирования WAL. В обоих случаях копирование не требует остановки работы пользователей — это ключевое преимущество перед файловым вариантом.

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

Проверка, что защита действительно работает

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

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

Типичные ошибки и ограничения

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

Отдельно отметим ограничение автосохранения модулей: оно не работает как система контроля версий. Если нужна история изменений конфигурации и возможность отката, используйте хранилище конфигурации или внешние системы контроля версий (например, Git через EDT).

Частые вопросы