Как найти последнюю резервную копию 1С

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

Единого «штатного» хранилища резервных копий в 1С нет: платформа сама по себе не делает бэкапы автоматически. За копирование отвечает либо администратор, настроивший регламент, либо средства СУБД, либо внешнее ПО. Поэтому поиск последней копии — это всегда расследование: сначала выясняем, каким способом настроено резервное копирование, затем ищем файлы и проверяем их актуальность.

Ниже разобраны все основные сценарии: поиск на файловом сервере, проверка заданий планировщика Windows, поиск бэкапов SQL Server, работа с облачными сервисами и проверка того, что найденная копия действительно пригодна для восстановления.

Шаг 1. Выясните, каким способом делаются копии

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

Основные варианты, которые встречаются на практике:

• Выгрузка информационной базы (.dt) — делается вручную через конфигуратор или скриптом. Файл обычно лежит в сетевой папке или на диске сервера.
• Бэкап средствами СУБД (.bak для MS SQL, .backup для PostgreSQL) — настраивается планом обслуживания или скриптом на стороне сервера баз данных.
• Скрипт в планировщике задач Windows — копирует файл базы 1Cv8.1CD (для файловых баз) или запускает выгрузку.
• Стороннее ПО для бэкапа — Veeam, Cobian Backup, Acronis и подобные, со своими хранилищами.
• Облачные сервисы — 1С:Фреш, Яндекс.Диск, сетевые хранилища с версионированием.

Шаг 2. Проверьте планировщик задач Windows

Наиболее частый способ автоматического бэкапа в небольших организациях — скрипт, запускаемый планировщиком задач. Откройте его на сервере: Win+R → taskschd.msc. Просмотрите библиотеку планировщика и ищите задачи с названиями вроде «Backup 1C», «Выгрузка», «Архив», «1C dump».

Откройте найденную задачу и посмотрите вкладку «Действия»: там указан путь к скрипту или команде. Откройте сам скрипт (обычно .bat, .cmd или .ps1) — в нём прописан каталог, куда складываются копии. Вкладка «Триггеры» покажет расписание, а вкладка «Журнал» (если включено ведение истории) — когда задача реально выполнялась последний раз и с каким результатом.

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

1. 1
   Откройте taskschd.msc на сервере, где работает 1С
2. 2
   Найдите задачи, связанные с бэкапом или выгрузкой 1С
3. 3
   Посмотрите вкладку «Действия» и найдите путь к скрипту
4. 4
   Откройте скрипт и выпишите каталог назначения копий
5. 5
   Проверьте журнал задачи: дата последнего успешного запуска
6. 6
   Перейдите в каталог и отсортируйте файлы по дате изменения

Шаг 3. Найдите бэкапы на стороне SQL Server

Если база работает в клиент-серверном варианте на MS SQL Server, резервные копии почти наверняка делаются средствами самой СУБД. Откройте SQL Server Management Studio (SSMS), подключитесь к серверу и разверните узел «Управление» → «Планы обслуживания». Если план настроен, внутри будет задача «Резервное копирование базы данных» с указанием целевой папки.

Также проверьте узел «Агент SQL Server» → «Задания» — бэкап может быть оформлен как задание агента с T-SQL скриптом. Откройте шаг задания: в команде BACKUP DATABASE указан путь к файлам .bak.

Стандартные расположения бэкапов SQL Server — подкаталог Backup в каталоге установки экземпляра, например C:\Program Files\Microsoft SQL Server\MSSQL15.MSSQLSERVER\MSSQL\Backup, но администраторы часто перенастраивают путь на отдельный диск. Точный путь смотрите в свойствах задания или плана обслуживания, а не угадывайте.

Для PostgreSQL логика аналогична: ищите задания cron (на Linux — crontab -l) или скрипты с командой pg_dump, в которых указан выходной каталог.

SELECT database_name, backup_finish_date, physical_device_name FROM msdb.dbo.backupset bs JOIN msdb.dbo.backupmediafamily bm ON bs.media_set_id = bm.media_set_id WHERE database_name = 'ИмяБазы' ORDER BY backup_finish_date DESC;

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

Шаг 4. Поищите файлы копий на дисках и сетевых ресурсах

Если механизм копирования выяснить не удалось, ищите файлы напрямую. Типовые расширения и маски для поиска в проводнике Windows или через PowerShell:

• *.dt — выгрузки информационной базы из конфигуратора;
• *.bak — бэкапы MS SQL Server;
• .backup, .sql — выгрузки PostgreSQL;
• 1Cv8.1CD — копии файловой базы целиком;
• .zip, .7z, *.rar — архивированные копии (ищите по имени с ключевыми словами backup, buh, trade, zup, 1c).

Ищите на всех локальных дисках сервера, на подключенных сетевых папках и на NAS. Команда PowerShell для быстрого поиска по диску:

Get-ChildItem -Path D:\, E:\ -Recurse -Include <em>.dt,</em>.bak -ErrorAction SilentlyContinue | Sort-Object LastWriteTime -Descending | Select-Object -First 20 FullName, LastWriteTime, Length

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

Шаг 5. Проверьте облачные сервисы и стороннее ПО

Если база работает в облаке 1С:Фреш, резервные копии создаются автоматически на стороне сервиса — искать файлы не нужно. Выгрузку своей базы можно запросить через личный кабинет менеджера сервиса или в разделе управления абонентом. Учтите: выгрузка предоставляется в виде файла .dt или архива данных и может формироваться не мгновенно.

Проверьте также наличие установленного ПО для бэкапа: откройте список установленных программ на сервере и поищите Veeam, Acronis, Cobian Backup, Handy Backup и подобные. Если такая программа есть, откройте её интерфейс и посмотрите историю заданий и пути к хранилищу. Сетевые хранилища (NAS Synology, QNAP) часто имеют собственные службы версионирования — зайдите в их панель управления и проверьте снапшоты папок.

Шаг 6. Проверьте, что найденная копия рабочая

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

Для файла .dt создайте пустую тестовую базу и загрузите выгрузку через конфигуратор («Администрирование» → «Загрузить информационную базу»). Для .bak выполните восстановление в новую базу с другим именем через SSMS. После восстановления откройте базу в режиме предприятия и проверьте даты последних документов — так вы увидите, на какой момент данные реально сохранены.

Частые ошибки при поиске резервных копий

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

Что делать, если копий не нашлось

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

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

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