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

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

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

Главный риск — удалить не ту базу или потерять данные, которые ещё понадобятся для отчётности или аудита. Поэтому перед любыми действиями убедитесь, что база действительно не используется, а выгрузка (.dt) или бэкап средствами СУБД созданы и проверены на восстановление.

Что именно нужно удалить: состав базы 1С на сервере

Прежде чем удалять, важно понимать, из чего состоит «база 1С» в клиент-серверном варианте. Это не один файл, а набор связанных объектов, разбросанных по серверу или даже по нескольким серверам.

• Запись об информационной базе в кластере 1С — метаданные: имя базы, строка подключения к СУБД, настройки блокировок. Хранится в реестре кластера (файл 1CV8Clst.lst и связанные служебные файлы в каталоге srvinfo).
• База данных в СУБД — собственно данные: таблицы, индексы, хранимые процедуры. В MS SQL это .mdf и .ldf файлы, в PostgreSQL — каталог внутри data-директории кластера СУБД.
• Журнал регистрации — если он вынесен в отдельный каталог (формат .lgd или SQLite-файл), он не удаляется автоматически.
• Служебные каталоги — временные файлы, сессионные данные в каталоге srvinfo (reg_1541 и аналогичные).

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

Подготовка: резервная копия и проверка активности

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

Сделайте два независимых типа копий. Первый — выгрузка информационной базы через конфигуратор (Администрирование → Выгрузить информационную базу, файл .dt). Второй — полный бэкап базы средствами СУБД: в MS SQL это Full Backup в .bak, в PostgreSQL — pg_dump. Два формата страхуют друг друга: .dt переносим между СУБД, а бэкап СУБД восстанавливается быстрее и точнее.

Проверьте копию на восстановление: разверните .dt или .bak на тестовом сервере и убедитесь, что база открывается. Бэкап, который не проверен, — это не бэкап. Скопируйте файлы копий на отдельный носитель или сетевое хранилище, которое не пострадает при очистке сервера.

Удаление информационной базы из кластера 1С

Основной инструмент — консоль управления кластером серверов 1С (оснастка «Администрирование серверов 1С Предприятия»). Откройте её на сервере или с рабочего места администратора, найдите нужный кластер и раскройте ветку «Информационные базы».

Щёлкните правой кнопкой по базе и выберите «Удалить». Система предложит три варианта, и от выбора зависит, что произойдёт с данными в СУБД:

• «Удалить информационную базу» — удаляется и запись в кластере, и сама база данных в СУБД. Это вариант полного удаления.
• «Оставить без изменений» (очистить) — запись из кластера удаляется, а база в СУБД остаётся нетронутой. Подходит, если данные нужно сохранить в СУБД или подключить позже.
• «Очистить базу данных» — запись в кластере остаётся, а данные в СУБД удаляются. Используется редко, в основном для повторного наполнения тестовых баз.

1. 1
   Откройте оснастку «Администрирование серверов 1С Предприятия» и найдите нужный кластер
2. 2
   В ветке «Информационные базы» завершите все сеансы базы и установите блокировку сеансов
3. 3
   Сделайте выгрузку .dt и проверьте бэкап в СУБД
4. 4
   Щёлкните правой кнопкой по базе → «Удалить» и выберите вариант «Удалить информационную базу»
5. 5
   Дождитесь завершения операции и проверьте, что база исчезла из списка
6. 6
   Проверьте в СУБД, что база данных действительно удалена

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

Удаление базы данных в СУБД вручную

MS SQL Server

Если при удалении из кластера был выбран вариант «оставить базу в СУБД» или операция завершилась с ошибкой, базу нужно удалить средствами SQL Server. Откройте SQL Server Management Studio (SSMS), подключитесь к экземпляру, найдите базу в списке, щёлкните правой кнопкой → «Delete» и отметьте опцию «Close existing connections», чтобы принудительно закрыть соединения.

Альтернатива — команда T-SQL. Она удобна, когда нужно действовать скриптом или SSMS недоступна:

ALTER DATABASE [Base1C] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [Base1C];

После удаления проверьте, что файлы .mdf и .ldf исчезли из каталога данных SQL Server. Иногда при некорректном удалении файлы остаются «осиротевшими» и занимают место — их можно удалить вручную после остановки службы SQL Server или при отсоединённой базе.

PostgreSQL

В PostgreSQL база удаляется через pgAdmin или командой DROP DATABASE. Учтите ограничение: нельзя удалить базу, к которой есть активные подключения. Сначала завершите их принудительно:

SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = 'base1c' AND pid <> pg_backend_pid();
DROP DATABASE base1c;

Также удалите роль (логин), которая использовалась только для этой базы, если она больше не нужна: DROP ROLE user1c;. Оставшиеся роли с правами — потенциальная дыра в безопасности и лишний мусор в списке пользователей СУБД.

Очистка остатков: файлы, каталоги, публикации

После удаления базы из кластера и СУБД на сервере часто остаются следы, которые занимают место и засоряют систему. Пройдитесь по контрольному списку:

• Журнал регистрации — если он хранился в отдельном каталоге (путь указан в свойствах базы), удалите каталог с файлами .lgd или .lgp вручную.
• Каталог srvinfo — служебные данные кластера. Удалять его целиком нельзя: там живут настройки других баз. Устаревшие сессионные файлы чистятся агентом самостоятельно, ручное вмешательство требуется редко.
• Публикации на веб-сервере — если база была опубликована (IIS или Apache), удалите виртуальный каталог и соответствующую запись в файле default.vrd, иначе веб-сервер будет отдавать ошибку при обращении.
• Задания планировщика и скрипты бэкапа — отключите регламентные задания Windows и скрипты резервного копирования, которые ссылаются на удалённую базу, иначе журналы будут заполняться ошибками.
• Списки баз у пользователей — удалите запись из файла ibases.v8i или из списка в стартере, чтобы пользователи не видели несуществующую базу.

Удаление через командную строку и ras

Если графическая консоль недоступна (сервер Linux или нужна автоматизация), используйте утилиту администрирования rac в связке с сервисом ras. Сначала запустите ras, затем получите идентификаторы кластера и базы и выполните удаление:

rac infobase --cluster=<ID_кластера> drop --infobase=<ID_базы> --drop-database

Ключ --drop-database соответствует варианту «удалить вместе с базой данных в СУБД». Без него удалится только запись в кластере. Список баз с идентификаторами получают командой rac infobase summary list --cluster=<ID>. Этот способ удобен для скриптов очистки тестовых стендов, но требует аккуратности: ошибка в идентификаторе приведёт к удалению чужой базы.

Проверка результата и типичные ошибки

После всех действий убедитесь, что удаление действительно полное. Контрольные точки:

Если после удаления в консоли кластера появляются ошибки или база «висит» в списке, перезапустите службу агента сервера 1С и повторите попытку. В сложных случаях (повреждённый реестр кластера) помогает создание нового кластера и перенос в него оставшихся рабочих баз.

Часто задаваемые вопросы