База 1С разрослась до 200 ГБ: что делать по шагам

База 1С заняла 200 ГБ, бэкап идёт всю ночь, диск заканчивается - что делать? Первый совет, который выдают форумы, - “сделайте свертку”. Иногда он верный, но чаще преждевременный: до свертки нужно понять, из чего вообще состоят эти 200 ГБ. Бывает, что бизнес-данные там - 40 ГБ, а остальное служебный “жир”, который удаляется без потери единого документа и без риска свертки.

Ниже - почему база растёт, как за полчаса измерить “что сколько занимает”, и пошаговый разбор методов для баз диапазона 100-500 ГБ: от планового обслуживания до классической свертки. Материал рассчитан на ИТ-специалиста или администратора. Цифры - из наших боевых проектов 2026 года.

Почему база 1С растёт: данные против “жира”

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

Данные бизнеса - документы, справочники, движения регистров накопления и бухгалтерии. Это то, ради чего база существует. Уменьшить их объём можно только сверткой (переносом остатков на дату) или обрезкой истории - операциями рискованными и требующими сверки.

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

• кэши механизма разграничения доступа (RLS): ключи доступа, очереди пересчёта, история версий шаблонов ограничений;
• таблицы итогов регистров за избыточные периоды;
• версии объектов, если включено версионирование “на всё”;
• журналы регистрации, логи обменов и интеграций, история фоновых и регламентных заданий;
• устаревшие данные полнотекстового поиска;
• “воздух” в файлах базы данных - место, освобождённое внутри файла, но не возвращённое операционной системе;
• раздутый журнал транзакций (файл .ldf).

Соотношение этих частей бывает контринтуитивным. В нашем проекте с базой розничной сети fashion-сегмента (три страны, ~200 касс) карта объёмов показала: из 4,2 ТБ около 3,85 ТБ занимал мёртвый кэш RLS - история версий шаблонов ограничения доступа и две очереди пересчёта ключей на миллиарды строк. Больше 90 % “базы” не были данными бизнеса вообще. На масштабе 200 ГБ пропорции скромнее, но принцип тот же: пока не измерено, любое решение - гадание.

Быстрая самодиагностика: что занимает место

Прежде чем выбирать метод, постройте карту “что сколько занимает”. Это связка физических таблиц SQL с объектами 1С: какие таблицы самые крупные и что в них лежит.

Шаг 1. Топ таблиц по размеру на SQL

В Microsoft SQL Server список таблиц базы, отсортированный по занимаемому месту, даёт стандартный отчёт sp_spaceused по каждой таблице или запрос к системным представлениям sys.allocation_units, sys.partitions, sys.indexes. Практический результат - таблица вида “имя таблицы → строк → ГБ данных → ГБ индексов”. Смотрите первые 20-30 строк: как правило, 80-90 % объёма приходится на 5-10 таблиц.

Шаг 2. Расшифровка имён таблиц в объекты 1С

Имена таблиц SQL у 1С техничны (_Reference123, _AccumRg456, _InfoRg789). Чтобы понять, какой объект метаданных за ними стоит, используйте штатный метод: в 1С есть функция получения структуры хранения (ПолучитьСтруктуруХраненияБазыДанных, со вторым параметром Истина она отдаёт имена в терминах СУБД, как их видно в SQL), а также сторонние скрипты сопоставления. Ориентиры по префиксам:

Префикс таблицы	Что это
_Document…	таблицы документов и их табличных частей
_AccumRg…, _AccumRgT…	движения регистров накопления и их итоги
_AccRg…, _AccRgAT…	движения бухгалтерских регистров и итоги
_InfoRg…	регистры сведений, в том числе служебные: ключи доступа RLS и очереди их обновления лежат здесь
_Reference…	справочники
_CRg…	регистры расчёта
_Task…, _BPr…	задачи и бизнес-процессы

Число в имени у каждой базы своё. В тестовой УТ 11.5 ключи доступа к объектам лежат в _InfoRg31840, а очередь обновления ключей в _InfoRg33136, в другой базе у тех же регистров будут другие номера. Поэтому расшифровку берите только из структуры хранения своей базы.

Шаг 3. Отдельно проверьте служебные подозреваемые

Даже без полной карты стоит сразу посмотреть размеры очевидных кандидатов на “жир”:

• Журнал транзакций (.ldf) - если он сопоставим с файлом данных или больше, данные тут ни при чём: смотрите модель восстановления, бэкапы лога и log_reuse_wait_desc. Разбор - в статье “Журнал транзакций 1С разросся”.
• Таблицы итогов регистров (…RgT, …RgAT) - распухают, если период рассчитанных итогов задан с избытком.
• Кэши RLS - в SQL у них обычные номерные имена вроде _InfoRg31840, слов вроде AccessKeys там нет. Если по структуре хранения за таблицей из топа стоит КлючиДоступаКОбъектам, ОбновлениеКлючейДоступаКДанным или другой объект управления доступом, это служебное.
• Свободное место внутри файла - отчёт sp_spaceused покажет unused; если его много, поможет шринк (но только после удаления данных, см. ниже).

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

Методы для базы 100-500 ГБ: по возрастанию сложности

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

Метод	Что делает	Типичный эффект	Риск
Обслуживание + шринк	Дефрагментация индексов, возврат ОС свободного места внутри файла	0 - десятки ГБ	Низкий
Вынос логов и журналов	Журнал регистрации, логи обменов - в архив/на ретеншн	Единицы - десятки ГБ	Низкий
Пересчёт итогов	Убирает избыточные периоды таблиц итогов	Проценты - десятки %	Низкий
Обрезка служебного	Удаляет мёртвые кэши RLS, версии, очереди	0 - 90+ % (зависит от диагноза)	Средний: доказать “мёртвость”
Свертка на дату	Остатки на дату - в базу, история - в архив	В разы	Высокий: сверка остатков

1. Плановое обслуживание и шринк

Начните с гигиены. Регулярное обслуживание - обновление статистики, дефрагментация и перестроение индексов - не уменьшает данные, но возвращает базе скорость и вскрывает “воздух” в файлах.

Шринк (DBCC SHRINKFILE) - самый популярный и самый переоценённый совет. Он не удаляет ни одной строки: он возвращает операционной системе место, которое уже свободно внутри файла. Если файл 200 ГБ и занято 195 ГБ - шринк даст 5 ГБ, что бы вы ни делали.

Шринк осмыслен ровно в одном случае: после массового удаления данных, когда внутри файла образовались освобождённые десятки-сотни гигабайт. В проекте розничной сети после удаления мёртвого кэша занятое место упало с 4 108 до 108 ГБ - и вот тогда сжатие файла имело смысл. Но помните: после шринка индексы фрагментированы, закладывайте время на их перестроение. Настройка планового обслуживания - часть услуги “обслуживание баз 1С”.

2. Вынос логов и журналов

Дешёвый и почти безрисковый метод: журнал регистрации, логи обменов и интеграций, устаревшие версии объектов выносятся в архивную базу или удаляются по сроку хранения. Эффект скромный, но иногда заметный: в проекте розничной сети вынос одного только лога действий кассира в отдельную архивную базу (через веб-сервисы, с автоочисткой и ретеншном 180 дней) дал −52 ГБ и 14,5 млн записей из боевой базы.

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

3. Пересчёт и сокращение итогов регистров

Таблицы итогов регистров - служебный ускоритель отчётов. Со временем они накапливают избыточные периоды и заметно распухают. Установка правильного периода хранения итогов и их пересчёт - штатная операция. Эффект по объёму реальный: в проекте розничной сети таблицы итогов сократились на 75 % - с 73,5 до 18,3 млн строк.

На базах 100-500 ГБ пересчёт обычно укладывается в ночное окно штатными средствами. На больших регистрах платформенный пересчёт может не влезть в окно - тогда его переносят на прямой SQL с побитовой сверкой против эталонного механизма.

4. Обрезка служебных данных

Самый недооценённый метод - и потенциально самый эффективный, если диагноз подтверждает наличие мёртвых кэшей. Кандидаты: кэши RLS, очереди пересчёта ключей доступа, история версий шаблонов, “хвосты” отключённых механизмов.

Главная сложность здесь не техническая, а доказательная: нужно строго обосновать, что данные мертвы. В проекте с кэшем RLS мы последовательно проверили и отбросили три правдоподобные гипотезы - “RLS отключён, можно удалять всё”, “мусор накопили уволенные сотрудники”, “виноват один медленный регистр”. Каждая непроверенная гипотеза стоила бы недели работы в неверном направлении - или поломки доступа у работающих кассиров. Удаляется только то, что доказано мёртвое.

5. Классическая свертка на дату

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

Свертка уместна, когда карта объёмов показала: основной объём - это действительно старые документы и движения, которые операционной работе больше не нужны. На базах до ~100 ГБ со стандартной конфигурацией часто хватает типовой обработки “Свертка информационной базы” - но только на копии и со сверкой остатков “до/после”. На сотнях гигабайт и на “долгоживущих” объектах (договоры, залоги, длинные взаиморасчёты) типовая обработка перестаёт доходить до конца, и нужны посекционные процедуры на SQL с полным контуром контроля. Подробнее - в услуге “свертка и обрезка баз 1С”.

Когда какой метод: короткий алгоритм

1. Топ занимает журнал транзакций? Сначала модель восстановления и бэкапы лога, потом шринк лога. Данные это не уменьшит, но вернёт десятки-сотни ГБ.
2. Много свободного места внутри файла данных? Шринк файла данных - но только если объём уже был удалён.
3. В топе журналы, версии, логи обменов? Вынос в архивную базу с ретеншном.
4. Распухли таблицы итогов регистров? Пересчёт и сокращение периодов итогов.
5. В топе служебные кэши (RLS, очереди, история шаблонов)? Обрезка служебного - после строгого доказательства “мёртвости”.
6. Топ - действительно старые документы и движения? Свертка на дату. До ~100 ГБ и на типовой конфигурации - можно пробовать типовую обработку на копии; больше - процедуры на SQL с контролем.
7. В любом сценарии: сначала копия прода, репетиция, сверка “до/после” - потом боевая база. Как держать эту копию свежей, не перезаливая её целиком, - в статье про отставшую тестовую базу.

Методы комбинируются. В проекте розничной сети сработала связка “обрезка служебного + индексы + пересчёт итогов + шринк”, давшая 4 197 → 105 ГБ (−97,5 %) без потери единого документа. Полный разбор - в кейсе “Обрезка базы 4,2 ТБ → 105 ГБ”.

Чего не делать

• Не начинайте со свертки “на всякий случай”. Если основной объём - служебный кэш, свертка даст считаные проценты эффекта при максимальном риске. Сколько она освободит именно у вас, можно посчитать до решения: Калькулятор свёртки базы 1С читает статистику MS SQL или PostgreSQL и показывает, сколько весят периоды старше двух прошлых лет, данные базы он не трогает. Как прикинуть это кодом 1С без обработки, описано в статье о расчёте эффекта свёртки.
• Не делайте шринк как самоцель. Без предварительного удаления данных он вернёт лишь уже свободное место, зато фрагментирует индексы.
• Не удаляйте служебные таблицы, не доказав, что они мертвы. Ошибочно удалённый кэш RLS ломает разграничение доступа - кассир увидит чужой магазин или не увидит ничего.
• Не режьте историю по дате вслепую на объектах с длинным жизненным циклом. Документ пятилетней давности может быть действующим.

Чек-лист

• Построена карта объёмов: топ таблиц SQL с привязкой к объектам 1С.
• Проверены отдельно: журнал транзакций, таблицы итогов, кэши RLS, свободное место в файле.
• Определено соотношение “данные бизнеса” / “служебный жир”.
• Метод выбран по топу таблиц, а не по совету с форума.
• Всё обкатано на копии прода со снятием таймингов.
• Есть сверка “до/после” и свежий полный бэкап перед необратимой операцией.
• Изменения деструктивного характера выполняются в согласованное ночное окно с планом отката.

С чего начать

База в 200 ГБ - ещё не повод для терабайтной свертки. Скорее всего, значительную долю занимает служебный “жир”, который убирается дешевле и безопаснее. Но узнать это можно только по карте объёмов: как она выглядит на боевой базе - топ объектов, табличные части отдельными строками, служебные регистры вроде ключей доступа RLS и отдельный список таблиц платформы. Лишние гигабайты чаще всего прячутся как раз в служебном.

Проще всего начать с бесплатного экспресс-аудита: по его итогам вы получите диагноз “из чего состоит ваша база” и прогноз эффекта в гигабайтах по каждому применимому методу - до того, как принимать решение о работах. Если захотите передать работу нам - мы делаем свертку и обрезку больших баз 1С как отдельную услугу: от карты объёмов до ночного окна с протоколом сверки остатков.

Порядок цифр по деньгам смотрите на странице цен, там вилки по всем услугам сразу. Компаниям из Алматы, Астаны и Шымкента мы сделали отдельные страницы с местным контекстом, хотя работаем одинаково удалённо по всей стране.