Бэкап 1С идёт всю ночь: почему и как ускорить резервное копирование

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

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

Из чего складывается время бэкапа

Длительность полного резервного копирования определяется четырьмя множителями, и “медленный диск” - только один из них.

Размер базы. Самый прямой фактор: бэкап читает весь занятый объём файла данных. База на 4 ТБ физически не скопируется за то же время, что база на 400 ГБ, - при прочих равных разница десятикратная. И здесь кроется первая ловушка: часто “весит” база не тем, что вы думаете. В нашем проекте розничной сети из 4,2 ТБ файла больше 90 % занимал мёртвый служебный кэш механизма разграничения доступа - данные, которые бэкап честно копировал каждую ночь, хотя бизнесу они были не нужны.

Сжатие. Резервная копия почти всегда пишется со сжатием (WITH COMPRESSION в MS SQL, штатное сжатие в pg_dump/pg_basebackup зависит от инструмента). Сжатие экономит место и время записи на диск, но нагружает процессор. На сильно загруженном сервере, где CPU уже занят рабочими сессиями, компрессия бэкапа конкурирует за те же ядра.

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

Тип копии: полная против разностной и журнальной. Полный бэкап (FULL) копирует весь занятый объём каждый раз. Разностный (DIFFERENTIAL) - только страницы, изменившиеся с последней полной копии. Журнальный (LOG, для модели восстановления FULL) - только записи журнала транзакций с прошлого раза. Гонять полную копию каждую ночь на терабайтной базе, где за сутки меняется несколько процентов данных, - самый частый источник “бэкапа на всю ночь”.

Как ускорить: пять рычагов

Разберём по возрастанию эффекта - от быстрой настройки до пересмотра самой базы.

Рычаг	Что даёт	Когда применять
Схема FULL + разностные + журнальные	Убирает ежедневный полный проход	Почти всегда на базах от сотен ГБ
Отдельное хранилище под копии	Снимает конкуренцию за диск, повышает надёжность	Всегда
Настройка сжатия и параллелизма	Балансирует CPU против времени и объёма	На загруженных серверах
Разнос по времени с регламентами	Убирает конфликт бэкапа с обслуживанием	Всегда
Уменьшение самой базы	Сокращает объём, который вообще нужно копировать	Когда база раздута служебными данными

1. Правильная схема копий вместо ежедневного FULL

Базовая рабочая схема для боевой базы 1С: полный бэкап раз в неделю (в самое свободное окно, например в ночь на воскресенье), разностный - каждую ночь, журнальный - каждые 15-60 минут в течение рабочего дня. Такая связка даёт две вещи сразу: ночное окно разгружается (разностная копия в разы меньше полной), а точка восстановления становится минутной, а не суточной - при аварии в 16:00 вы теряете не весь день, а последние минуты.

Оговорка: журнальные копии имеют смысл только в модели восстановления FULL и требуют дисциплины - если журнал транзакций не бэкапится, он растёт бесконечно и съедает диск (частая причина, по которой к нам приходят с “журнал транзакций забил всё место”). Модель SIMPLE проще, но журнальных копий в ней нет и точка восстановления - только последний полный/разностный бэкап.

2. Отдельное хранилище - не роскошь, а условие

Бэкап должен физически лежать не на том диске и в идеале не на том сервере, где работает база. Это ускоряет копирование (чтение и запись не конкурируют за один массив) и, главное, спасает при аварии носителя: диск с базой умер - копия на другом устройстве цела. Оптимальная практика - правило “3-2-1”: три копии, на двух разных носителях, одна - вне площадки. Сетевое хранилище, второй сервер, объектное хранилище - конкретный выбор зависит от инфраструктуры, но принцип “копия отдельно от оригинала” не обсуждается. И проверьте, что в копию попадает всё: если вложения лежат в томах на диске, копия базы без каталога тома восстановится с записями, но без самих файлов. Как это проверить до аварии, разобрано в статье про бэкап томов хранения файлов.

3. Сжатие и параллелизм - по факту нагрузки

Сжатие бэкапа почти всегда выгодно: меньше объём записи, меньше времени на диске, меньше места в хранилище. Но на сервере, где процессор и так под нагрузкой, стоит проверить, не становится ли компрессия узким местом, - иногда выгоднее запустить бэкап чуть раньше, в менее загруженный час, чем душить сжатием и без того занятый CPU. Инструменты вроде многопоточного копирования (несколько файлов копии параллельно) на больших базах дают ощутимый выигрыш за счёт распараллеливания чтения. Как всегда: сначала замер, потом настройка.

4. Разнести бэкап и регламентное обслуживание

Частая незамеченная причина “долгого бэкапа” - он идёт одновременно с перестроением индексов, обновлением статистики или проверкой целостности. Все эти операции читают ту же базу и грузят тот же диск. Мы наступали на это в проекте обрезки: параллельный плановый бэкап валил операцию сжатия файла с ошибкой 3140, а после прерванных попыток в базе оставался “залипший” флаг сжатия, который лечился только переводом базы offline/online. Вывод простой: регламент обслуживания и расписание бэкапов нужно строить как единое целое, чтобы тяжёлые операции не наступали друг другу на пятки. Именно так мы и собираем обслуживание баз 1С: одно расписание на бэкапы, индексы, статистику и проверку целостности, а не три независимых плана, которые дерутся за диск.

5. Уменьшить базу - и бэкап ускорится сам

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

В нашем проекте розничной сети это сработало напрямую. После того как из базы был убран служебный кэш механизма разграничения доступа (больше 90 % объёма) и сжат файл, полный ночной бэкап сократился с 556 до 18,3 ГБ, а время копирования - с двух часов до считаных минут. Ни один документ бизнеса при этом удалён не был: сокращение объёма шло за счёт служебных данных, которые база копировала вхолостую. Разбор этого проекта целиком - в кейсе “Обрезка базы 4,2 ТБ → 105 ГБ”.

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

Бэкап без теста восстановления - не бэкап

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

Что реально ломается в бэкапах, которые “вроде бы делаются”:

• Копия битая - сбой носителя, файл недописан из-за нехватки места или повреждён при передаче по сети. RESTORE VERIFYONLY - необходимый минимум, но не достаточный.
• Копия есть, но восстановить нельзя - не хватает цепочки журнальных копий, потеряна разностная база, несовместимая версия СУБД.
• Восстановление дольше допустимого - 6 часов там, где бизнес переживёт только 1. Про это узнают только на учениях.

Единственный способ убедиться, что бэкап рабочий, - регулярно восстанавливать его на отдельном сервере и проверять, что база открывается и данные на месте. Не “посмотреть, что файл создался”, а поднять копию и войти в неё. Сами скрипты восстановления - RESTORE с подстановкой имён через FILELISTONLY для MS SQL, pg_restore для PostgreSQL, с предохранителями от затирания боевой базы - лежат в отдельном разборе. Это же восстановление удобно использовать для другой полезной задачи - снятия нагрузки проверок целостности и тяжёлых отчётов с продуктива на актуальную копию.

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

Два числа, которые стоит определить до того, как что-то настраивать, - они задают всю схему:

• RPO (Recovery Point Objective) - сколько данных бизнес готов потерять при аварии. Час? 15 минут? Ноль? Ответ определяет частоту журнальных копий.
• RTO (Recovery Time Objective) - за сколько база должна снова работать. Ответ определяет, годится ли восстановление из полной копии или нужна горячая реплика.

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

Сколько будет восстанавливаться: замерьте своё число

RTO не назвать без скорости восстановления на вашем железе, и как сильно она гуляет, видно по двум нашим прогонам. Первый - стенд из трёх баз смежных систем: одна СУБД в контейнере, 4 ядра, 7,8 ГБ памяти. Дамп заливали в отдельную базу при работающем проде, так что остановка сервисов, проверка после заливки и переключение нагрузки в аварии добавятся сверху.

База	Копия	Восстановление	Скорость
первая, 23 ГБ	дамп 1,5 ГБ, снимался 7,5 мин	19 мин 39 с	1,07 ГБ/мин (поднятая база 21 ГБ)
вторая, 3,4 ГБ	дамп 296 МБ	около 3 мин	1,13 ГБ/мин
третья, 597 МБ	дампа нет	-	-

Скорость у двух баз почти совпала, и на этом стенде её можно умножать на объём: 100 ГБ поедут около полутора часов, 1 ТБ за 15-16 часов, 3 ТБ около двух суток.

Второй прогон из разбора про восстановление базы 1С из бэкапа: база 17,8 ГБ поднялась из .bak на локальном SQL Server 2022 за 140 секунд, около 7,6 ГБ в минуту, раз в семь быстрее стенда. Формат копии и железо другие, поэтому ни одна из двух скоростей вашей базе не норма. Своё число даёт пробное восстановление у себя, с ним и идут к бизнесу обсуждать простой.

Копия есть, но от соседней базы

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

Подмену выдаёт арифметика: размер базы, делённый на размер дампа, должен давать привычное сжатие. На стенде это 15,3 раза у первой базы и 11,8 у второй:

• дамп, снятый стадией третьей системы, весил 302 МБ;
• дамп соседней базы на 3,4 ГБ весил 296 МБ, разница 2 %;
• база 597 МБ при сжатии 11,8 раза дала бы около 50 МБ, в шесть раз меньше.

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

Откат без значений по умолчанию

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

Правила простые: без явно заданной цели восстановление падает с ошибкой, а копирование и откат собирают путь к копии одной строкой кода. Проверку цели внутри скрипта для MS SQL и PostgreSQL мы показывали в скриптах восстановления с предохранителями.

Сколько данных потеряете и что не вернёт ни одна копия

Фактический RPO есть у любой базы: это время с последней копии. На стенде на момент разбора:

База	Копии	Потеря при аварии
первая	ежедневная	до суток работы
вторая	только перед выкаткой	всё с последней выкатки
третья	никаких	вся история

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

Записанное после последней копии не вернёт ни одна копия, и добрать его из внешних систем в разобранных базах было нельзя: источники отдавали только текущее состояние. Безвозвратно ушли бы журнал решений робота, ежедневные срезы цен конкурентов, история рейтингов и остатков. Только таблицы с посчитанным размером дают 2,6 ГБ, около 11 % первой базы.

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

Чек-лист: почему у вас бэкап долгий

1. Каждую ночь идёт полный бэкап? Перейти на схему “FULL раз в неделю + разностные + журнальные”. Обычно это сразу разгружает ночное окно.
2. Копия пишется на тот же диск, где база? Вынести на отдельное хранилище - быстрее и безопаснее.
3. Бэкап идёт одновременно с обслуживанием индексов? Развести по расписанию, строить регламент и бэкап как единую систему.
4. База раздута? Построить карту объёмов. Если топ занимают служебные данные, а не документы, - уменьшение базы ускорит бэкап сильнее любой настройки копирования.
5. Восстановление из бэкапа хоть раз проверяли? Если нет - это первое, что нужно сделать, до всякого ускорения. Скорость бесполезна, если из копии нельзя подняться. Раз в полгода открывайте каталог копий (файл, имя базы, размер, дата) и засекайте одно восстановление.

Коротко

Бэкап идёт всю ночь по одной из четырёх причин: раздутая база, ежедневный полный проход вместо разностных копий, конкуренция за диск и конфликт с регламентным обслуживанием. Лечится это схемой “полный раз в неделю + разностные + журнальные”, отдельным хранилищем, разнесением с обслуживанием и - самое эффективное - уменьшением самой базы (в нашем проекте бэкап сжался с 556 до 18,3 ГБ просто потому, что из базы убрали служебный балласт). Но ни одна из этих настроек не имеет смысла, пока восстановление из копии ни разу не проверено: бэкап без теста восстановления - это не страховка, а её имитация.

Если хочется, чтобы резервное копирование стало предсказуемым и проверяемым, - мы настраиваем обслуживание баз 1С под ключ: схема бэкапов с нужной точкой восстановления, отдельное хранилище, регулярные пробные восстановления и контроль под мониторингом. Если бэкап тормозит из-за размера базы - начать стоит со свертки и обрезки, которые уберут балласт. А понять текущее состояние без обязательств можно с бесплатного экспресс-аудита: по его итогам вы получите диагноз, из чего состоит база и что именно замедляет резервное копирование.