Резервная копия 1С перед обновлением: проверяем восстановление на отдельном VPS

Файл резервной копии и восстановленная база — разные вещи, хотя в папке они выглядят одинаково: есть имя, есть размер, есть дата. Файл доказывает только то, что кто-то когда-то его создал. Восстановленная база доказывает больше: в ней под обычным пользователем открывается реализация номер такой-то от такого-то числа, проводки на месте, а отчёт за закрытый период показывает ту же сумму, что и вчера на рабочей базе. Именно второе спасает после неудачного обновления. Поэтому вопрос звучит не «есть ли у нас копия?», а «что мы увидим на экране через час после того, как начнём из неё поднимать базу?».

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

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

Первая ошибка репетиции — проверять «в целом». Кто-то запускает базу, видит список справочников, говорит «открывается» и закрывает окно. Но база может открыться и при этом потерять часть движений, неверно пересчитать итоги или лишиться вложенных файлов. Чтобы проверка была честной, признаки работоспособности нужно выбрать и записать до того, как копия снята, на рабочей базе, где данные заведомо правильные.

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

• Учебный документ. Допустим, реализация товаров и услуг от конца прошлого месяца, проведённая, с несколькими строками товаров, одним контрагентом и печатной формой накладной. Записываем номер, дату, сумму, контрагента, склад и признак проведения. Хороший кандидат — документ, у которого есть и движения по регистрам, и печатная форма, и, при желании, прикреплённый файл.
• Отчёт с известным итогом. Например, оборотно-сальдовая ведомость по расчётам с покупателями или продажи за закрытый месяц. Записываем параметры отчёта (период, организация, отборы) и итоговую цифру. Период должен быть закрыт: если в нём ещё вносят документы, цифра уплывёт сама, и вы не поймёте, виновата ли копия.

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

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

Платформа, конфигурация и копия: что нужно знать о них до первого запуска

Восстановление упирается в три вещи, которые должны быть согласованы: версия платформы, на которой копия снята и будет открыта; конфигурация (название и версия) внутри базы; формат самой копии. Мы не будем придумывать универсальные правила совместимости — они зависят от того, какие релизы платформы вы используете, и их нужно сверять по документации и информации о выпусках именно этих релизов. Зато можно составить «паспорт» базы, который эту сверку сделает возможной.

В паспорт запишите:

1. режим работы: файловая база или клиент-серверная;
2. для клиент-серверной — тип СУБД и её версию, имя базы, способ создания копии;
3. точный номер релиза платформы на рабочем сервере и на клиентских машинах;
4. название конфигурации, её версию и признак того, менялась ли она (были доработки, расширения);
5. список расширений и внешних обработок, без которых работа остановится;
6. версию релиза, на которую вы собираетесь обновляться, и промежуточные релизы, если путь не прямой.

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

Теперь о самой копии. В клиент-серверном режиме, как сказано в руководстве администратора 1С, рекомендованы средства СУБД, а не «выгрузка» из клиентского приложения. Это важно по практической причине: средства СУБД снимают копию той базы, которая лежит на сервере, а не её представление, прошедшее через клиентский интерфейс. Но из этого следует и другое: если у вас есть только копия, снятая средствами СУБД, то развернуть её можно только в такой же среде — с сервером баз данных. Поэтому тестовый VPS для клиент-серверной базы должен содержать и СУБД, и сервер приложений 1С, а не одну только платформу.

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

Отдельная среда: подбираем VPS и разворачиваем копию

Тестовая среда должна быть похожа на рабочую настолько, чтобы время и поведение были сопоставимы, и при этом не быть рабочей. Если вы ещё только готовите площадку, подробно собрать сервер под 1С помогает статья «Пошаговая настройка VPS под 1С в облаке с нуля»; здесь мы сосредоточимся на самой репетиции.

С ресурсами логика такая. Тарифная сетка VPS MAATRIX начинается с конфигурации Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe) и идёт через Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ) и Maat (8 vCPU, 16 ГБ, 240 ГБ) до Djed (16 vCPU, 32 ГБ, 320 ГБ). Эти цифры — отправная точка, а не обещание ёмкости: сколько пользователей и какой объём данных выдержит сервер, показывает только замер. Для репетиции важнее другое — диск. На нём одновременно должны уместиться файл копии, развёрнутая база, место под временные файлы при обновлении и, желательно, промежуточные копии между ступенями обновления. Грубая прикидка: объём диска должен покрывать как минимум копию плюс несколько размеров развёрнутой базы с запасом на систему и платформу. Если ваша база после распаковки занимает, например, 30 ГБ, диск в 40 ГБ уже не подойдёт, даже если сама система скромная.

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

Порядок разворачивания для клиент-серверной базы выглядит так:

1. Установить на VPS ту же СУБД и тот же релиз платформы, что на рабочем сервере (по паспорту).
2. Перенести файл копии и, если он есть, архив журнала регистрации и хранилище двоичных данных.
3. Убедиться, что к базе, в которую будет идти восстановление, нет подключений: руководство прямо указывает, что при восстановлении подключений быть не должно. На свежем сервере это условие выполняется само собой, но если вы повторяете восстановление в одну и ту же базу несколько раз (а на репетиции придётся), закрывайте сеансы и проверяйте список подключений перед каждым запуском.
4. Восстановить базу средствами СУБД.
5. Создать в кластере 1С информационную базу, привязанную к восстановленной базе СУБД, и открыть её клиентом.

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

Как только база открылась, не торопитесь радоваться. Откройте учебный документ из тетради. Сверьте номер, дату, сумму, контрагента, признак проведения; нажмите печать и убедитесь, что форма формируется; откройте движения документа. Затем сформируйте отчёт с теми же параметрами и сравните итог. Если все совпало, поставьте в тетради отметку «восстановление до обновления подтверждено». Только теперь у вас есть точка отсчёта, с которой можно сравнивать всё, что произойдёт после.

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

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

Поэтому до первого запуска пройдитесь по списку точек, через которые база общается с внешним миром:

• Обмен с другими базами и сайтами: адреса, каталоги обмена, веб-сервисы. Подмените их на несуществующие или тестовые, а лучше закройте исходящие соединения тестового VPS на уровне межсетевого экрана и разрешайте только то, что нужно для репетиции.
• Электронная почта: учётные записи с рабочими паролями. Отключите отправку, замените сервер на заглушку, которая не доставляет письма.
• Регламентные задания: выгрузки, рассылки, загрузки банковских выписок. Отключите их в тестовой базе или запускайте базу так, чтобы регламентные задания не выполнялись.
• Интеграции с оборудованием и сервисами: онлайн-касса, маркировка, электронный документооборот. Лишний вызов с копии может создать реальную запись у внешней стороны.
• Пользователи и пароли: тестовый VPS не должен быть доступен всем, у кого есть доступ к рабочему серверу. Оставьте минимальный круг учётных записей.

Здесь же вспомните про Windows. Если на рабочем сервере копирование базы организовано заданием планировщика, и вы переносите этот сценарий на тестовый VPS, чтобы проверить его, держите в голове поведение планировщика: задание может завершиться без ожидаемого результата, а «успешно выполнено» в списке ещё не значит «копия создана». Microsoft в материале о невыполняющихся заданиях советует отдельно проверять сам скрипт, смотреть статус и историю задания и журнал TaskScheduler/Operational, а при поиске причины — упрощать скрипт и вести собственный журнал действий. Для копирования 1С это превращается в конкретную практику: скрипт должен записывать в свой лог, что он начал, какой файл создал, каков его размер и чем закончил. Тогда после ночного запуска вы увидите не только зелёную отметку, но и строку «файл такой-то, столько-то гигабайт», и сможете сопоставить её с реальным файлом. Репетиция на тестовом сервере — хороший случай проверить, что скрипт работает не только под вашей учётной записью в интерактивном сеансе, но и из планировщика.

Обновление копии: время, шаги и узнаваемые операции

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

Заведите на время обновления простой журнал с засечками:

• время начала обновления и завершения каждой ступени;
• время первого запуска после обновления (обычно именно оно самое долгое — выполняются обработчики обновления);
• сообщения об ошибках и предупреждения, которые видны при запуске;
• загрузка процессора, памяти и диска сервера в пиковые минуты.

Последний пункт полезен для выбора ресурсов. Если во время обновления процессор стоит на ста процентах, а диск почти не загружен, обновлению не хватает процессорных ядер; если наоборот — упирается в диск, помогут быстрые накопители (на NVMe такие операции обычно идут лучше, чем на обычных дисках, но фактический выигрыш для вашей базы покажет только замер). Если память заканчивается и система начинает вытеснять данные на диск, то это сигнал выбрать конфигурацию с большим объёмом RAM. Репетиция даёт не абстрактные рекомендации, а ваши цифры.

После обновления возвращаемся к тетради. Сначала — тот же учебный документ: открывается ли он, совпадают ли реквизиты, проведён ли. Затем — тот же отчёт с теми же параметрами: сумма должна совпасть с записанной до обновления. Если итог изменился, не спешите обвинять обновление: выясните, чем он мог измениться. Иногда новая версия конфигурации меняет логику отчёта или правила расчёта, и расхождение — ожидаемое, оно описано в сведениях о релизе. Но вы обязаны знать причину, а не списывать на «так бывает».

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

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

Две разные дороги назад: версия программы и данные на прежний момент

Здесь легко запутаться, потому что в разговоре «откатить обновление» звучит как одно действие. На самом деле это два разных вопроса.

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

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

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

Эту разницу нужно показать на тех же предметах из тетради. После восстановления на прежний момент должны открыться учебный документ и отчёт с прежней суммой — всё как до обновления. Если же вы откатили только версию программы, а данные остались в новой структуре, то учебный документ может не открыться вовсе или открыться с ошибкой, а отчёт — дать иную цифру. Для репетиции полезно проделать оба сценария: сначала посмотреть, что даёт попытка запустить старую конфигурацию на уже обновлённой копии (если вы вообще хотите это знать), затем — восстановить базу из копии и убедиться, что документ и отчёт вернулись. Так вы увидите разницу собственными глазами, а не из чужого рассказа.

Новые данные, которые нельзя потерять при возврате

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

Составьте перечень категорий:

• Документы, введённые вручную после запуска: реализации, поступления, кассовые операции. Если их немного, их можно перенести повторным вводом по списку, который вы получите из рабочей базы перед возвратом (например, отчёт или список документов с отбором по дате создания).
• Загруженные банковские выписки и платежи. Перезагрузка выписки после возврата обычно возможна, но порядок и дубли нужно проверить; фиксируйте, какие файлы уже загружены.
• Данные, пришедшие через обмен. Здесь опасно: внешняя система уже считает документ переданным. После возврата базы вторая сторона может не прислать его заново, а ваша база о нём не знает. Заранее продумайте, как инициировать повторную передачу или как сверить две базы.
• Вложенные файлы. Если они хранятся в хранилище двоичных данных, которое восстанавливается отдельно, его состояние должно соответствовать базе. Рассинхронизация даёт ссылки на файлы, которых нет, или файлы, на которые никто не ссылается.
• События, о которых база уже сообщила наружу: отправленные письма, переданные в кассу чеки, поданные отчёты. Их откатить нельзя, а значит, нужно хотя бы знать список.

Практичный приём — перед возвратом выгрузить из повреждённой базы всё, что появилось после точки копии. Для этого вам нужны надёжные признаки «новизны»: дата создания, номер диапазона, автор. Журнал регистрации помогает увидеть, какие документы создавались и когда, — именно поэтому его восстановление и хранение стоит продумать заранее, а не после аварии. Журнал и хранилище двоичных данных восстанавливаются отдельно, поэтому репетицию нужно проводить и для них: убедиться, что они на месте, читаются и согласованы с базой.

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

Сколько стоит возвращение: считаем минуты и называем границу

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

Итого час сорок пять в условном примере. Но настоящее число вы получите, только когда засечёте каждый шаг на тестовом VPS: если восстановление из копии заняло у вас не 35 минут, а полтора часа, весь план меняется. Учтите и то, что боевой сервер может отличаться от тестового диском и нагрузкой, поэтому в журнал стоит записывать не только время, но и размер копии и скорость чтения/записи, чтобы можно было пересчитать.

Второе число — граница потери данных. Если копия снята в 19:00, обновление началось в 19:10, а вход в базу снова открыт в 21:30 после успешной приёмки, то при возврате на копию вы теряете то, что введено после 19:00. Если в окне 19:00–21:30 в базе никто не работал, потеря нулевая. Если же вход открыли в 21:30, а проблема всплыла утром, то потеряны документы всего рабочего утра до момента возврата. Эту границу нужно произнести вслух до обновления: «возвращаясь на копию, мы теряем всё, что введено после такого-то часа; для этих документов у нас есть такой-то способ повторного ввода».

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