Загляните в свою тестовую базу и посмотрите на дату последнего восстановления из прода. У большинства это будет не вчера и не неделю назад. Месяц, квартал, а где-то и "подняли, когда разворачивали тест, и с тех пор так и живём". Мы тестируем правки на данных, которых в проде уже нет, гоняем отчёты по остаткам, которые давно разошлись, и удивляемся, почему на бою поведение другое. Это не авария, поэтому никто не бьёт тревогу. Просто фон, к которому привыкли.
А привыкли зря. Разберу, почему тестовая база протухает у всех одинаково, покажу реальный прогон на живом MS SQL и PostgreSQL, и главное - что это лечится один раз. Не разово поднять копию сегодня, а поставить задание, после которого тест обновляется из прода сам, каждую ночь, без вашего участия и без похода к админу.
Почему тестовая база протухает
Механика боли простая и от команды к команде не меняется.
Восстановить свежую копию прода на тест - работа на стороне СУБД. Нужен доступ к серверу, права на RESTORE, знание логических имён файлов базы и путей, куда их класть. У администратора всё это есть, у 1С-разработчика нет и, скорее всего, не будет. Значит каждый раз, когда нужна свежая копия, начинается переписка: попроси, дождись, напомни. Раз в неделю так делать неудобно обоим, и постепенно перестают все. Тест застывает на том срезе, когда его подняли последний раз.
Второй слой - страх. Даже если доступ у вас есть, ручное восстановление означает набрать RESTORE с правильными MOVE, не перепутать источник и цель, не залить копию поверх боевой базы. Один неверный ввод, и вы затёрли прод. Поэтому руками это делают редко и с оглядкой, а не по расписанию. Осторожность понятная, но платит за неё свежесть теста.
Спрос на решение видно по самой площадке. Старые статьи про резервное копирование и восстановление SQL держат сотни тысяч просмотров: инструкция 2013 года набрала больше 360 тысяч, соседняя под 280 тысяч, пошаговое восстановление 155 тысяч, гайд по PostgreSQL под 85 тысяч. Люди годами читают, как это делать руками. Обработки под 1С, которая собрала бы это за них и поставила на автомат, в каталоге почти нет.
Разворот: это ставится один раз
Ключевая мысль, ради которой затевалась обработка. Протухший тест - не про то, что восстановление сложное. Восстановление делается за пару минут, ниже покажу прогон. Протухает тест потому, что восстановление делают руками и каждый раз, а руками и каждый раз никто долго не выдерживает.
Убираем "руками и каждый раз" - боль исчезает. Задание по расписанию поднимает тест из свежего бэкапа ночью, само, столько раз, сколько попросили. Настроил один раз, дальше утром садишься за базу, в которой данные вчерашние. Именно расписание, а не разовое восстановление, и есть суть инструмента.
Мы собрали это в отдельную обработку: Тестовая база сама обновляется из свежего прода. По расписанию и без доступа к SQL. Дальше по тексту разбираю, что именно она печатает и почему это не нарушает правила площадки.
Что делает обработка
Вы открываете обработку прямо в своей базе. Платформенными средствами она показывает, из какого кластера и какой информационной базы вы работаете (СтрокаСоединенияИнформационнойБазы() отдаёт Srvr и Ref). Вы указываете, куда восстанавливать копию, подтверждаете SQL-координаты, и на форме сразу собирается готовый скрипт. Его видно целиком, можно сохранить в .sql или .bat и отдать администратору.
Скриптов обработка печатает несколько:
- разовое восстановление MS SQL - RESTORE с автоподстановкой логических имён и путей;
- бэкап рабочей базы - чтобы было из чего восстанавливать;
- расписание - задание SQL Server Agent с выбором частоты (ежедневно, еженедельно, вручную) и времени;
- ветка PostgreSQL - связка pg_dump в кастомном формате и pg_restore, с тем же предохранителем.
Для MS SQL логические имена файлов и пути обработка заранее не угадывает. Она встраивает в скрипт шаг RESTORE FILELISTONLY FROM DISK, и имена берутся из самого бэкапа в момент выполнения. Знать их наперёд не нужно, скрипт разбирается сам. Расписание собирается через штатный конструктор 1С: вы задаёте периодичность привычным диалогом, а обработка переводит его и в параметры задания SQL Agent, и в строку cron для PostgreSQL.
Почему это проходит модерацию
Момент, который многих останавливает. Инфостарт не пропускает публикации, где обработка пишет в СУБД в обход платформы. Здесь этого нет. Обработка не подключается к SQL-серверу и не выполняет ни одной команды. Она собирает текст скрипта и показывает его вам. Запускает скрипт администратор, вручную, от своих прав. Тот же приём уже прошёл модерацию у наших предыдущих инструментов, которые к СУБД не обращаются.
У разделения есть и вторая польза, помимо формальной. Обработка физически не может навредить базе, потому что физически ничего с базой не делает. Ответственность за запуск лежит на человеке с правами, и он видит скрипт целиком до того, как нажмёт "выполнить".
Предохранители
Автовосстановление, направленное не туда, затирает боевую базу. Поэтому в каждый генерируемый скрипт вшиты проверки. Это условие, а не опция.
- Цель не равна источнику. Первой же строкой скрипт сверяет имя целевой базы с исходной. Совпали - падает с понятной ошибкой, до восстановления дело не доходит.
- Источник только читается. Восстановление идёт из файла бэкапа, к боевой базе скрипт на запись не подключается вообще.
- Не системная база. Целью не может стать master, msdb и прочая служебная база.
- Имя цели задано явно. Никаких умолчаний, целевую базу вы подтвердили на форме до сборки скрипта.
- Шапка-комментарий. В начале скрипта дата генерации, источник и цель. Через полгода в задании SQL Agent видно, что и куда льётся, без раскопок.
Первый предохранитель я проверял отдельно, специально подсунул совпадающие имена источника и цели. Скрипт отказался работать, выдал RAISERROR уровня 16 и остановился до восстановления. Ровно то поведение, которое нужно от защиты: не тихое затирание, а громкий отказ. Важно, что проверки живут в самом скрипте, а не в обработке. Скрипт защищён и тогда, когда обработку давно закрыли, а задание в SQL Agent крутится само.
Реальный прогон на живом MS SQL
Проверял не на бумаге. Прогон 21.08.2026, локальный MS SQL Server 2022 (16.0.1000.6), рабочая база 17,8 ГБ.
Сначала бэкап рабочей базы: сжатый .bak вышел 3,57 ГБ, снялся за 134 секунды, источник при этом только читался. Потом скрипт восстановления из генератора: копия поднялась за 140 секунд, в ней оказалось 8511 таблиц, столько же, сколько в оригинале, база встала в статус ONLINE. Копия полная и живая. Логические имена файлов скрипт взял из бэкапа через FILELISTONLY, не угадывал. За собой я убрал, тестовую базу и .bak удалил.
Дальше самое главное - расписание. Скрипт задания SQL Server Agent, который сгенерировала обработка, я не просто посмотрел глазами, а создал задание в SQL Agent и дал ему отработать. Оно реально подняло базу из свежего .bak по расписанию. Это не заглушка и не просто верный на вид синтаксис, а проверенный запуском шаг.
Ветку PostgreSQL прогнал отдельно, на PostgreSQL 17.9. Скриптами из обработки: pg_dump в кастомном формате снял источник на 72 таблицы, pg_restore развернул целевую базу, все 72 таблицы доехали как в оригинале. Предохранитель "цель равна источнику" на PG тоже сработал, скрипт вышел с ошибкой до восстановления.
Смысл цифр такой. База почти на 18 гигов поднимается из свежего бэкапа за пару минут, и всё, что для этого нужно человеку, - один раз собрать скрипт расписания и отдать админу. Дальше тест обновляется ночами сам, а разработчик про восстановление вообще забывает.
Откуда выросла тема: бэкап 556 ГБ, копия 18,3 ГБ
Розничная сеть fashion-сегмента, три страны, около 200 касс. Полный бэкап там 556 ГБ, а поднятая из него рабочая копия занимает 18,3 ГБ. На таких объёмах ручное восстановление на тест превращается в отдельную процедуру со своим окном и своим дежурным, и делать её регулярно не рвётся никто. Тест там отставал от прода надолго ровно по этой причине: слишком дорого поднимать вручную, чтобы делать это часто.
Когда восстановление собрано скриптом и поставлено на ночное задание, размер перестаёт мешать. Ночью времени достаточно, сервер свободен, а утром тест свежий. Инструмент не ускоряет восстановление, он снимает с человека необходимость его запускать.
А не утечка ли это: прод с живыми данными на тесте
Резонный вопрос, его задают под любым таким инструментом. Свежая копия прода несёт реальную персоналку: клиентов, контрагентов, зарплаты. Отвечу честно, без маркетинга.
Сама схема восстановления безопаснее ручной. Источник только читается, боевая база под угрозой не находится в принципе, а копия поднимается на тестовом сервере под тестовым именем и прод не подменяет. Но данные в ней боевые, и это вопрос вашей политики доступа к тестовому контуру. Если тест доступен людям, которым живые данные видеть нельзя, восстановление стоит дополнять обезличиванием: после подъёма копии прогнать по ней маскирование персональных полей. Это отдельный шаг отдельным прогоном, обработка его на себя не берёт. Не буду делать вид, что автовосстановление решает вопрос приватности. Оно решает вопрос свежести, приватность закрывает тот, кто настраивает доступ к тесту.
Граница честности: что проверено, а что подтверждаете вы
Не хочу продавать то, чего не мерил, поэтому про рамки прямо.
Кластер и имя информационной базы обработка берёт платформенно, это проверено на серверной УТ 11.5. Имя SQL-сервера и SQL-базы платформа встроенным языком не отдаёт. Здесь два пути: если доступен RAS, координаты подтягиваются автоматом, если нет, поле предзаполнено из Ref (имя SQL-базы часто с ним совпадает), и вы его подтверждаете. Скрипт корректен в обоих случаях, потому что цель подтверждена человеком до сборки.
По СУБД обе ветки прогнаны end-to-end на живых базах: MS SQL со всем циклом до отработавшего задания SQL Agent, PostgreSQL с полным pg_dump и pg_restore. Синтаксис заданий и путей всё равно стоит один раз просмотреть под свою инфраструктуру: у SQL Agent бывают выключены, у Express его нет вовсе (для таких случаев обработка печатает альтернативу через Windows Task Scheduler), а у PostgreSQL расписание вешается на pgAgent или cron по вашему хозяйству.
Как это выглядит по шагам
Чтобы было видно, сколько тут работы человека.
- Открываете обработку в своей базе. Кластер и информационная база подтянулись сами, SQL-поля предзаполнены, вы сверяете их глазами.
- Указываете целевую тестовую базу, подтверждаете SQL-координаты. Скрипт на форме пересобирается на лету.
- Выбираете вид "расписание", задаёте частоту и время штатным конструктором. Читаете готовый текст задания.
- Сохраняете скрипт и отдаёте администратору. Он запускает его один раз.
Дальше вашего участия не требуется. Задание поднимает свежую копию каждую ночь, а вся возня с логическими именами файлов, путями и координатами уместилась в минуту работы с формой. Разовый скрипт под рукой тоже остаётся, на случай "нужна свежая копия прямо сейчас, до ближайшей ночи".
Где взять
Обработка лежит здесь же на Инфостарте, отдельной карточкой, 10 SM: Тестовая база сама обновляется из свежего прода. По расписанию и без доступа к SQL.
Другие наши инструменты для СУБД под 1С:
- Чек-ап СУБД - прежде чем лить свежую копию каждую ночь, стоит проверить, правильно ли стоит сам сервер.
- Карта объёмов базы 1С - если бэкап прода не лезет на тестовый диск, отсюда видно, чем именно он набит.
- Проверка базы перед миграцией на PostgreSQL - когда тест поднимают уже на PostgreSQL, а прод пока на MS SQL.
- Аудит паролей СУБД - ночное задание живёт под учёткой с правами на прод, и вопрос, кто ещё её достанет.
А теперь вопрос к вам. Загляните всё-таки в дату последнего восстановления своего теста и скажите: насколько он отстал от прода? День, месяц, квартал? И если отстал надолго - что вас держит от того, чтобы повесить обновление на ночное задание: нет доступа к SQL, страшно за прод, или руки не дошли и так вроде работает?
Вступайте в нашу телеграмм-группу Инфостарт