Резервная копия 1С 8.3: где хранится и как её найти

Резервная копия 1С 8.3 не имеет единого «главного» места хранения: путь зависит от того, каким способом копия создавалась. Если выгрузку делали вручную через конфигуратор, файл лежит там, куда пользователь указал при сохранении. Если копирование настроено штатной обработкой «Резервное копирование и восстановление», файлы складываются в каталог, заданный в её настройках. Автоматические механизмы, например скрипты планировщика Windows или средства СУБД, пишут копии в свои папки.

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

Отдельно стоит понимать разницу между форматами. Файл с расширением .dt — это выгрузка информационной базы целиком, универсальный формат переноса. Файл .zip, который создаёт штатная обработка резервного копирования, — это архив каталога файловой базы. Копия, сделанная средствами MS SQL или PostgreSQL, — это .bak или дамп, который восстанавливается только средствами той же СУБД. Путать эти форматы нельзя: .dt не откроется в SQL Server Management Studio, а .bak не загрузится конфигуратором.

Какие виды резервных копий существуют в 1С 8.3

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

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

Где лежит копия, созданная вручную через конфигуратор

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

Чаще всего такие файлы оказываются в типовых местах: на рабочем столе, в папке «Документы», в корне диска D:\ или в специально созданных каталогах вроде C:\Backup1C или D:\1C_Backup. Если файл искал другой сотрудник и не помнит путь, помогает поиск по диску с фильтром по расширению .dt и сортировкой по дате изменения.

1. 1
   Откройте проводник и перейдите в корень диска, где обычно работают с базой (чаще C:\ или D:\).
2. 2
   В строке поиска введите *.dt и дождитесь результатов.
3. 3
   Отсортируйте список по дате изменения и найдите файл нужного периода.
4. 4
   Сверьте размер файла: выгрузка активно используемой базы обычно занимает от десятков мегабайт и больше; файл в несколько килобайт — признак прерванной выгрузки.
5. 5
   Запишите полный путь и дату файла, чтобы не искать его повторно.

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

Где хранятся копии штатной обработки резервного копирования

В типовых конфигурациях на Библиотеке стандартных подсистем (БСП) есть встроенный механизм: Администрирование → Обслуживание → Резервное копирование и восстановление. Он работает только с файловыми базами и создаёт zip-архивы по расписанию или по требованию при завершении работы.

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

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

Где искать копии файловой базы, сделанные копированием каталога

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

Копии, сделанные вручную или скриптом, обычно складывают рядом с базой или в отдельный архивный каталог. Типичные признаки такой копии: папка с файлом 1Cv8.1CD внутри и именем, содержащим дату, например «Бухгалтерия_копия_15_03». Если копирование автоматизировано через планировщик заданий Windows, путь прописан в самом скрипте — откройте задание и посмотрите команду, которую оно выполняет.

Проверить целостность скопированной базы можно через утилиту chdbfl.exe из каталога установки платформы (подкаталог bin). Она выполняет проверку физической целостности файла 1Cv8.1CD. Запускать проверку следует на копии, а не на рабочей базе.

Где хранятся копии клиент-серверных баз

Если база работает в клиент-серверном варианте, её данные физически находятся в СУБД — MS SQL Server, PostgreSQL или другой поддерживаемой платформой. Резервные копии в этом случае создаются и хранятся средствами самой СУБД, и искать их нужно на сервере баз данных, а не в папках 1С.

В MS SQL Server копии по умолчанию пишутся в каталог Backup экземпляра сервера, путь к которому виден в свойствах сервера в SQL Server Management Studio. Если резервирование настроено через план обслуживания (Maintenance Plan) или задание агента SQL Server, целевой каталог указан в настройках этого задания. Файлы имеют расширение .bak.

Для PostgreSQL копии обычно создаются утилитой pg_dump по расписанию, и путь определяется скриптом, который её вызывает. Найдите задание в планировщике (cron в Linux, планировщик заданий в Windows) и посмотрите, куда направлен вывод дампа.

-- Посмотреть последние резервные копии базы в MS SQL Server
SELECT database_name, backup_start_date, physical_device_name
FROM msdb.dbo.backupset s
JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE database_name = 'ИмяВашейБазы'
ORDER BY backup_start_date DESC;

Этот запрос к системным таблицам MS SQL покажет, когда создавались копии конкретной базы и в какие файлы они записывались — это самый быстрый способ узнать фактический путь, если документация по серверу утеряна.

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

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

Для zip-архива штатной обработки достаточно распаковать его и убедиться, что внутри есть файл 1Cv8.1CD и сопутствующие каталоги. Для .bak проверка выполняется тестовым восстановлением в отдельную базу на SQL-сервере с другим именем.

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

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

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

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