Обслуживание базы 1С по расписанию: задания, проверки и резервные копии

Регламентные операции в 1С нужны, чтобы база не теряла данные, не тормозила и не ломалась от накопленного мусора. Минимальный набор: ежедневная резервная копия, работающие регламентные задания (Администрирование → Обслуживание → Регламентные операции), раз в месяц — тестирование и исправление или пересчёт итогов, а для SQL-базы — обновление статистики и индексов на стороне СУБД.

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

Что относят к регламентным операциям в 1С и зачем они базе

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

Зачем это нужно:

• 💾 Сохранность данных. Без свежей копии любой сбой диска или неудачное обновление означает ручное восстановление учёта за недели.
• 🚀 Скорость. Устаревшая статистика СУБД, разросшиеся таблицы итогов и журнал регистрации замедляют проведение и отчёты.
• 🧩 Целостность. Битые ссылки, «повисшие» итоги регистров и ошибки индексов копятся незаметно, пока не всплывёт ошибка при открытии документа.
• 🔄 Работа сервисов. Загрузка курсов валют, обмен с банком, обновление классификаторов, полнотекстовый поиск — всё это регламентные задания. Если они остановлены, сервисы молча перестают работать.

Виды регламентных операций: что, где и как часто

Набор зависит от режима работы базы. В файловой базе всё держится на платформе и копировании папки. В клиент-серверной добавляется кластер 1С и СУБД.

Чем грозит отказ от регламентного обслуживания

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

• 🐢 отчёты по большим периодам строятся минутами вместо секунд;
• ⚠️ при проведении появляются ошибки вида Ошибка при выполнении операции с информационной базой или сообщения о нарушении целостности;
• 📉 остатки в регистрах расходятся с движениями документов, оборотно-сальдовая ведомость показывает «странные» суммы;
• 💱 курсы валют не загружаются, обмен с банком висит, поиск по строке ничего не находит;
• 📦 файл базы 1Cv8.1CD растёт на гигабайты, хотя новых данных немного;
• 🔥 после сбоя питания базу нечем восстановить: последняя копия трёхмесячной давности или её нет вовсе.

Последний пункт самый дорогой. Восстановить учёт по первичке за квартал — это недели работы бухгалтера.

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

Как настроить регламентные операции в 1С пошагово

Порядок для типовых конфигураций на БСП: Бухгалтерия предприятия 3.0, ЗУП 3.1, УТ 11. Панель обслуживания в них находится в разделе Администрирование → Обслуживание; в новых релизах она называется «Поддержка и обслуживание».

Шаг 1. Проверьте регламентные задания

1. Откройте Администрирование → Обслуживание.
2. В группе «Регламентные операции» перейдите по ссылке «Регламентные и фоновые задания».
3. На вкладке регламентных заданий посмотрите колонки с состоянием и датой последнего выполнения.
4. Задания с ошибкой откройте двойным щелчком: там видно расписание и текст последней ошибки.
5. Ненужные задания выключите флажком «Включено». Например, загрузку курсов, если в организации нет валютных операций.

Для клиент-серверной базы проверьте ещё и кластер. В консоли администрирования серверов откройте свойства информационной базы: флажок «Блокировка регламентных заданий включена» должен быть снят. Его часто оставляют включённым после переноса или копирования базы, и задания перестают работать совсем.

В файловой базе регламентные задания выполняет сеанс клиента. Если никто не запустил программу, задания не идут. Для ночного обслуживания держат один постоянно открытый сеанс на сервере или переводят базу в клиент-серверный режим.

Шаг 2. Настройте резервное копирование

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

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

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

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

Шаг 3. Запустите тестирование и исправление

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

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

Шаг 4. Удаляйте помеченные объекты и следите за итогами

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

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

Шаг 5. Ограничьте журнал регистрации

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

Автоматизация регламентных операций: пакетный режим, планировщик, СУБД

Руками всё это быстро забывают. Надёжнее один раз написать скрипт и поставить его в планировщик Windows.

Пакетный запуск Конфигуратора

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

@echo off
rem Путь к нужной версии платформы
set V8="C:\Program Files\1cv8\8.3.xx.xxxx\bin\1cv8.exe"
set BASE=D:\Bases\Buh
set OUT=E:\Backup
set D=%date:~-4%%date:~3,2%%date:~0,2%

%V8% DESIGNER /F"%BASE%" /N"Администратор" /P"пароль" /DisableStartupMessages /DumpIB "%OUT%\buh_%D%.dt" /Out"%OUT%\dump_%D%.log"

%V8% DESIGNER /F"%BASE%" /N"Администратор" /P"пароль" /DisableStartupMessages /IBCheckAndRepair -LogIntegrity -RecalcTotals -TestOnly /Out"%OUT%\check_%D%.log"

Что учесть:

• 🗓 разбор даты через %date% зависит от региональных настроек Windows — проверьте имя файла на своём сервере;
• 🔑 пароль в открытом виде держите только в файле с ограниченными правами доступа, лучше заведите для обслуживания отдельного пользователя 1С;
• 🌐 для серверной базы вместо /F указывают /S"сервер\база";
• 📄 протокол из /Out читайте хотя бы раз в неделю, иначе скрипт годами будет падать незаметно.

Ключ /IBCheckAndRepair принимает те же параметры, что галочки в окне тестирования: -ReIndex, -LogIntegrity, -RecalcTotals, -IBCompression, -Rebuild. Без -TestOnly скрипт будет исправлять найденное, поэтому перед таким запуском обязательна свежая копия.

Блокировка сеансов перед ночным запуском

Выгрузке .dt и тестированию мешают открытые сеансы. В клиент-серверной базе в свойствах информационной базы в консоли кластера включают «Блокировку начала сеансов» и задают код разрешения. Скрипт затем подключается с параметром /UC"код".

План обслуживания СУБД

Для MS SQL Server в SQL Server Management Studio создают план обслуживания: обновление статистики ежедневно, реорганизацию или перестроение индексов раз в неделю, проверку целостности базы. После обновления статистики для 1С обычно очищают процедурный кэш:

EXEC sp_updatestats;
DBCC FREEPROCCACHE;

Для PostgreSQL проверьте, что работает autovacuum, и раз в неделю запускайте vacuumdb --all --analyze в ночное окно.

Регламентные операции в облаке и гибридных схемах 1С

В облачных сервисах часть регламента берёт на себя провайдер, но не весь.

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

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

Частые ошибки при выполнении регламентных операций

• ❌ Копия на том же диске. Защищает от ошибки пользователя, но не от отказа диска и шифровальщика.
• ❌ Тестирование и исправление без копии. Режим «Удалять ссылки на объекты» при битых ссылках может затереть реквизиты в сотнях документов.
• ❌ Сжатие и реструктуризация «на всякий случай» каждую неделю. На большой базе это часы простоя без пользы.
• ❌ Блокировка регламентных заданий осталась после переноса базы. Месяцами не грузятся курсы и не работает обмен, а заметят это только при закрытии квартала.
• ❌ Задания включены в тестовой копии. Копия выгружает данные в банк или на сайт вместо рабочей базы.
• ❌ Удаление помеченных в разгар рабочего дня. На большой базе процедура долгая и мешает пользователям.
• ❌ Скрипт без протокола. Ночное копирование может падать месяцами, пока копия не понадобится.

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