Резервная копия перед обновлением 1С: где лежит, как найти и как вернуть базу

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

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

Где искать копию: зависит от способа обновления

Первым делом вспомните, как именно запускали обновление. От этого зависит, была ли копия вообще.

Помощник обновления открывается в типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11): Администрирование → Обслуживание → Обновление версии программы. На шаге перед установкой он предлагает три варианта:

• 🚫 не создавать резервную копию;
• ⏳ создать временную копию — она нужна только на время обновления;
• 💾 создать копию и сохранить её в указанный каталог.

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

Временные файлы обновления и где их найти

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

Скрипт и журнал обновления

Помощник из режима «Предприятие» завершает сеанс и передаёт работу внешнему скрипту. Скрипт и его протокол лежат во временной папке пользователя Windows — %TEMP%. Откройте её через Win+R → %TEMP% → Enter и отсортируйте по дате изменения. Нужная папка или файлы появились в момент обновления.

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

Файлы обновлений конфигурации

Скачанные и установленные файлы обновлений (.cfu, .cf) хранятся в каталоге шаблонов. По умолчанию это:

%APPDATA%\1C\1cv8\tmplts\

Внутри — папки по поставщику и конфигурации, например 1c\Accounting\3_0_XXX_YY. Здесь лежат дистрибутивы обновлений, а не ваши данные. Удалять старые релизы отсюда можно, базе это не навредит.

Кэш пользователя

В папках %APPDATA%\1C\1cv8\ и %LOCALAPPDATA%\1C\1cv8\ есть каталоги с длинными именами-идентификаторами. Это кэш метаданных и настройки пользователя для каждой базы. После обновления кэш старого релиза иногда мешает: появляются странные ошибки форм. Его чистят при закрытой 1С или запуском с ключом /ClearCache.

Служебные папки, которые путают с копией базы

На форумах часто спрашивают: «1С создала какую-то папку рядом с базой — это бэкап?». Разберём, что лежит в каталоге файловой базы и рядом с ним.

• 📁 1Cv8.1CD — сама база: данные, конфигурация, пользователи. Единственный файл, который действительно нужно беречь.
• 📁 1Cv8Log — журнал регистрации. По нему видно, кто и когда запускал обновление и какие были ошибки.
• 📁 1Cv8FTxt — индекс полнотекстового поиска. Пересоздаётся.
• 📄 1Cv8.1CL — файл блокировки, существует, пока база открыта.

В клиент-серверном варианте на сервере 1С есть каталог srvinfo (обычно в папке установки платформы или в профиле службы). Внутри reg_1541 хранится реестр кластера и папки с идентификаторами баз. Это служебный кэш сервера, а не данные: таблицы с документами лежат в MS SQL или PostgreSQL.

Также после обновления платформы рядом с прежней версией в C:\Program Files\1cv8\ появляется новая папка вида 8.3.XX.XXXX. Старая версия остаётся, база при этом не копируется и не меняется.

Обновление серверной базы и роль RAS

Для клиент-серверной базы помощник обновления не делает копию сам. Причина простая: данные лежат в СУБД, и правильный бэкап делает сервер СУБД — полной копией через план обслуживания MS SQL или pg_dump для PostgreSQL. Куда он пишет файл, определяет администратор СУБД.

Помощнику при этом нужны параметры администрирования кластера. Он устанавливает блокировку сеансов, ждёт их завершения и обновляет базу. Для подключения к кластеру используется сервер администрирования RAS (по умолчанию порт 1545) или COM-соединение, в зависимости от настроек помощника.

Если вы обновляете серверную базу сами, порядок такой:

1. Сделайте бэкап базы средствами СУБД и проверьте, что файл появился и имеет разумный размер.
2. Заблокируйте начало сеансов и регламентные задания. Через консоль кластера это делается в свойствах базы, через RAS — утилитой rac:

rac infobase --cluster=<ID кластера> update --infobase=<ID базы> ^
  --infobase-user=Администратор --infobase-pwd=*** ^
  --sessions-deny=on --scheduled-jobs-deny=on ^
  --denied-message="Обновление программы" --permission-code=12345

3. Завершите оставшиеся сеансы. Список смотрят командой rac session list, параметры завершения — в rac help session.
4. Запустите Конфигуратор с кодом разрешения и обновите конфигурацию.
5. Снимите блокировку той же командой с --sessions-deny=off --scheduled-jobs-deny=off.

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

Как задать свой каталог для резервных копий

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

В помощнике обновления

На шаге резервного копирования выберите вариант с сохранением в каталог и укажите путь, например E:\Backup1C\Buh. Настройка запоминается для следующих обновлений.

В регламентном резервном копировании

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

Вручную перед обновлением в Конфигураторе

В Конфигураторе: Администрирование → Выгрузить информационную базу и выбор места для файла .dt. Это самый надёжный способ: вы точно знаете, где файл.

Тот же шаг можно автоматизировать bat-файлом:

@echo off
set V8="C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe"
set BASE=D:\Bases\Buh
set BACKUP=E:\Backup1C\Buh_%date:~6,4%-%date:~3,2%-%date:~0,2%.dt

%V8% DESIGNER /F"%BASE%" /N"Администратор" /P"пароль" /DumpIB %BACKUP% /Out"E:\Backup1C\dump.log"

Номер платформы в пути замените на свой. Перед выгрузкой все пользователи должны выйти из базы. Результат и ошибки пишутся в файл из параметра /Out.

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

Как назвать файлы и сколько их хранить

Имя файла копии лучше строить по схеме «база_дата_релиз», например Buh_2025-03-14_3.0.165.dt. Через полгода по такому имени сразу видно, до какого обновления сделана копия, и не нужно открывать файл.

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

Ошибки, из-за которых копии не оказывается на месте

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

• ❌ Выбрали «временную копию», обновление прошло, через неделю нашли ошибку в учёте. Временная копия к этому моменту уже удалена.
• ❌ Каталог копий указан на сетевой диск, а скрипт обновления запускается от пользователя без прав на запись. Выгрузка падает, обновление может остановиться на первом же шаге.
• ❌ Не хватило места на диске. Файл .dt обычно заметно меньше 1Cv8.1CD, но для баз в десятки гигабайт свободного места нужно с запасом.
• ❌ Серверную базу обновили помощником в уверенности, что он сделал копию. Не сделал: для СУБД копия делается отдельно.
• ❌ Копию сделали, но ни разу не проверяли. Битый .dt выясняется в момент, когда его пытаются загрузить.

Проверить копию просто: загрузите .dt в новую пустую файловую базу на своём компьютере и откройте её. Так вы узнаете о битом файле заранее, а не в день аварии.

Откат базы после неудачного обновления

Выбор способа зависит от того, на каком этапе остановилось обновление.

Как загрузить файл .dt

1. Откройте базу в режиме Конфигуратора.
2. Выберите Администрирование → Загрузить информационную базу.
3. Укажите файл .dt и подтвердите замену данных.
4. После загрузки Конфигуратор предложит перезапуститься — согласитесь.

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

Из командной строки то же самое делает параметр /RestoreIB:

"C:\Program Files\1cv8\8.3.24.1548\bin\1cv8.exe" DESIGNER /F"D:\Bases\Buh_restore" /N"Администратор" /P"пароль" /RestoreIB "E:\Backup1C\Buh_2025-03-14.dt"

Если копии нет, а база повреждена

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

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