Автоматическое сохранение данных в 1С 8.3

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

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

Что именно сохраняется и когда

Запись объекта в 1С — это уже сохранение. Когда вы нажимаете Записать в форме документа, данные уходят в базу; Провести дополнительно формирует движения по регистрам. Пока форма открыта и вы ничего не нажали, изменения живут только в оперативной памяти, и аварийное закрытие программы их потеряет. Поэтому правило простое: ввели важные данные — запишите, не держите наполовину заполненный документ открытым часами.

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

Резервная копия — это снимок всей базы на момент создания. В файловом варианте база хранится в одном файле 1Cv8.1CD, и копия представляет собой либо его выгрузку в формат .dt, либо архив самого файла. Из такой копии базу можно развернуть заново, если текущая перестала открываться.

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

Автоматическое копирование в файловой базе

Механизм встроен в типовые конфигурации на библиотеке стандартных подсистем — БП 3.0, ЗУП 3.1, УТ 11 и другие. Работает он только в файловом варианте: если база развёрнута на сервере 1С с СУБД, раздел настройки резервного копирования будет недоступен, и копии делаются средствами СУБД.

Порядок настройки:

1. Откройте Администрирование → Обслуживание.
2. Разверните группу Резервное копирование и восстановление.
3. Перейдите в Настройка резервного копирования.
4. Выберите режим создания копий.
5. Укажите каталог хранения и количество хранимых копий.
6. Запишите настройку.

Доступные режимы:

• 🔕 Не создавать автоматически — копии только вручную по кнопке.
• 🚪 При завершении работы — копия создаётся, когда закрывается последний сеанс. Подходит для одиночного пользователя.
• ⏰ По расписанию — копия создаётся с заданным интервалом (например, раз в день в определённое время). Подходит, когда база работает весь день.

Каталог для копий выбирайте на отдельном физическом диске или в сетевой папке, а не рядом с рабочей базой. Копия на том же диске, что и база, не спасёт при отказе этого диска.

Расписание и интервал резервирования

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

Количество хранимых копий определяет глубину отката. Храните не одну, а хотя бы 5–7 последних: ошибку в данных часто замечают не сразу, и единственная свежая копия может уже содержать испорченные данные. Старые копии программа удаляет сама, когда их число превышает заданное.

Прикиньте и место на диске: одна копия крупной базы — это сотни мегабайт, а при семи копиях и ежедневном графике объём быстро растёт. Каталог хранения должен это выдерживать.

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

Резервные копии в клиент-серверном варианте

Когда база работает на сервере 1С:Предприятия с СУБД (PostgreSQL, MS SQL), встроенный механизм из раздела «Обслуживание» недоступен. Копии делаются на уровне СУБД, и это правильный путь для многопользовательской базы:

• MS SQL Server — план обслуживания (Maintenance Plan) с полным бэкапом по расписанию и регулярными копиями журнала транзакций. Если база в модели восстановления Full, резервные копии журнала позволяют откатиться не только к ночной копии, а к состоянию на точку времени — например, за минуту до ошибочной операции.
• PostgreSQL — утилита pg_dump для логической копии отдельной базы или физический бэкап каталога данных; запуск по расписанию через планировщик ОС или cron. Для копии на точку времени настраивают архивирование WAL.

Копии средствами СУБД снимаются без остановки пользователей и не зависят от того, запущена ли 1С, — в этом их главное преимущество перед встроенным механизмом. Ответственность за них лежит на администраторе сервера, а не на бухгалтере в программе.

Помимо копий средствами СУБД, можно периодически выгружать базу в .dt через Конфигуратор — как дополнительный переносимый снимок. Но для серверной базы .dt требует монопольного доступа (все пользователи должны выйти), поэтому как ежедневный механизм он не годится — только как разовая выгрузка перед обновлением или переносом.

Отложенное проведение документов

Этот механизм к резервному копированию не относится, но его часто ищут рядом, когда речь о сохранности данных при массовом вводе. Включается он в Администрирование → Проведение документов.

Смысл отложенного проведения: документ при проведении формирует не все движения сразу, а минимальный набор, а полный пересчёт по регистрам выполняет регламентное задание позже, в фоне. Это снижает взаимные блокировки, когда много пользователей проводят документы одновременно, и ускоряет работу в пиковые часы.

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

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

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

Если база перестала открываться или в ней появились ошибки после аварийного завершения, порядок действий зависит от варианта.

Файловая база. Сначала попробуйте штатную проверку файла базы утилитой chdbfl.exe — она лежит в каталоге bin установленной платформы. Запустите её, укажите путь к файлу 1Cv8.1CD, поставьте флажок «Исправлять обнаруженные ошибки» и запустите проверку. Перед проверкой с исправлением скопируйте файл базы — на случай, если исправление пройдёт неудачно. Эта утилита чинит физическую структуру файла (разрушенную таблицу, оборванную запись), но не логические ошибки учёта — для них нужно тестирование и исправление из Конфигуратора. Перед запуском chdbfl.exe все пользователи должны выйти из базы.

Если это не помогло, восстановите базу из резервной копии: тем же разделом Администрирование → Обслуживание → Резервное копирование и восстановление → Восстановление из резервной копии, либо загрузкой .dt через Конфигуратор (Администрирование → Загрузить информационную базу).

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

Клиент-серверная база . Файл 1Cv8.1CD и утилита chdbfl.exe относятся только к файловому варианту — для серверной базы они неприменимы. Там целостность проверяют тем же тестированием и исправлением из Конфигуратора, а восстановление делают из бэкапа СУБД силами администратора сервера.

Автоматизация копий внешним сценарием

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

Команда выгрузки базы в .dt запускает Конфигуратор в пакетном режиме:

"C:\Program Files\1cv8\8.3.x.x\bin\1cv8.exe" DESIGNER /F "C:\Bases\Buh" /N "Администратор" /P "пароль" /DumpIB "D:\Backup\buh_%date%.dt"

Где /F — путь к каталогу файловой базы, /N и /P — пользователь и пароль, /DumpIB — выгрузка в указанный файл. Обратная операция — /RestoreIB "файл.dt".

Сохраните команду в .bat-файл, добавьте очистку копий старше N дней и повесьте запуск на планировщик задач Windows (Создать задачу → Триггер → Ежедневно). Так копия будет создаваться по расписанию ОС, а не внутри сеанса 1С.

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

Отдельно стоит проверять, что копии действительно рабочие. Регулярно разворачивайте свежую копию в тестовую базу и убеждайтесь, что она открывается и данные на месте. Копия, которую ни разу не пробовали восстановить, нередко оказывается нечитаемой именно в тот момент, когда понадобилась. Эта проверка занимает несколько минут раз в месяц и снимает главный риск любой схемы резервирования — иллюзию защиты при неработающих копиях.

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