Ночное задание завершилось, файл копии лежит в папке, журнал не показывает ошибок. Но база ещё не спасена. Задание могло оборваться из-за заполненного диска, смены пароля или нового пути к каталогу.
Рабочий статус бэкап получает после отдельного восстановления. Нужно открыть базу через 1С, сверить данные и выполнить тестовую операцию. На первую проверку заложите 1–1,5 часа: такой срок приводит инструкция «Доктор Сервер».
За вечер вы получите ответы на три вопроса: открывается ли копия, сохранились ли нужные данные и сколько времени займёт возврат 1С после сбоя.
Файл копии подтверждает запись, но не восстановление
Размер файла и зелёная отметка в журнале говорят только о работе задания. Они не подтверждают, что архив читается, база разворачивается, а сотрудники смогут продолжить работу.
Инструкция Ukved описывает случай, когда лог показывает успешное завершение даже после обрыва выгрузки. Поэтому контроль заканчивается не просмотром журнала, а входом в восстановленную базу.
| Что проверили | Что это доказывает | Какой дефект останется незамеченным |
|---|---|---|
| Файл появился в каталоге | Задание создало объект на диске | Неполная запись, повреждение содержимого, нехватка места при выгрузке |
| Размер файла похож на предыдущий | В копию попал сопоставимый объём данных | Повреждённые таблицы, незавершённые операции, ошибки внутри архива |
| Архив открылся без сообщения об ошибке | Программа прочитала структуру файла | Ошибка восстановления, несовместимость платформ, пропавшие данные |
| База восстановилась и запускается | Платформа открыла информационную базу | Ошибка в документах, правах, отчётах или рабочем сценарии |
| Пользователь проверил данные и операцию | Копия годится для возврата к работе | Неизвестным остаётся только фактическое время переключения всей системы |
Зелёный журнал подтверждает выполнение задания, но не работоспособность базы.
Проверить недостающие уровни можно только на отдельной машине. Разворачивать копию рядом с рабочей базой не нужно: сама проверка нагружает диск и процессор.
Подготовьте изолированный тестовый контур
Возьмите компьютер или виртуальную машину, которые не обслуживают рабочие сеансы 1С. Изоляция защищает продуктивную базу от ошибки администратора, совпадения имён и лишней нагрузки.
Не загружайте .dt поверх действующей базы. Для проверки создайте новую информационную базу с отдельным каталогом или отдельную базу в тестовом экземпляре СУБД.
Если свободной виртуальной машины нет, тест можно провести на выведенном из эксплуатации оборудовании. Сначала проверьте диски, питание и сеть по инструкции о том, как подготовить бывший рабочий сервер к тестовым восстановлениям.
Посчитайте место до начала восстановления
Инструкция Ukved рекомендует держать на тестовом диске запас в два-три размера файла .dt. Пространство потребуется самому архиву, распакованной базе и временным файлам.
Допустим, свежий .dt занимает 80 ГБ. Нижняя граница составит 80 × 2 = 160 ГБ, верхняя — 80 × 3 = 240 ГБ. Для своей базы подставьте фактический размер файла.
Запас в два размера подходит для чистого тестового диска без соседних баз. Три размера оставляйте, если на машине уже работают службы СУБД или хранятся прежние восстановления.
Перед запуском проверьте ещё три вещи: версию платформы, доступ к копии и права учётной записи. Более старая платформа может отказаться загружать .dt, созданный новой версией. Ukved приводит для такого случая сообщение «Формат данных не соответствует формату файла».
Файловую и клиент-серверную базу проверяют по-разному
Способ восстановления зависит от того, где 1С хранит данные. Файловая база лежит в 1Cv8.1CD, а клиент-серверная — в MS SQL Server или PostgreSQL.
Для файловой базы годится копия каталога, снятая после выхода пользователей. Копирование во время работы может захватить связанные изменения в разных состояниях. На тестовой машине такую копию подключают как отдельную файловую базу.
Клиент-серверную базу восстанавливают средствами той же СУБД. Дамп или цепочку копий разворачивают в отдельную базу данных, после чего создают тестовую информационную базу 1С с новым подключением.
| Тип базы | Какую копию брать | Где разворачивать | Что считать успешным результатом |
|---|---|---|---|
Файловая, копия 1Cv8.1CD | Каталог, скопированный после выхода пользователей | В новом каталоге на отдельном компьютере | База открылась, контрольные данные совпали, тестовая операция прошла |
Файловая, выгрузка .dt | Свежий файл выгрузки и сведения о версии платформы | В новой файловой информационной базе | Конфигуратор загрузил файл, а клиент 1С открыл базу |
| 1С на PostgreSQL | Дамп либо физическая копия с нужными WAL | В отдельном экземпляре или тестовом кластере PostgreSQL | СУБД завершила восстановление, 1С подключилась, документы открылись |
| 1С на SQL Server | Полная копия и необходимые части цепочки | В отдельной базе тестового экземпляра SQL Server | Команда восстановления завершилась, база доступна через клиент 1С |
| Любая восстановленная база | Копия плюс перечень контрольных данных | В контуре без рабочих пользователей и обменов | Проверены документы, отчёты, права и одна рабочая операция |
Одинаковое расширение файла не делает способы проверки взаимозаменяемыми: путь задаёт тип рабочей базы и метод создания копии.
Для PostgreSQL заранее проверьте, из чего состоит комплект восстановления. Отдельное руководство объясняет разницу между pg_dump, физической копией и архивом WAL.
Для SQL Server важна целостность всей цепочки. Порядок её создания и контроля описан в инструкции по полным, разностным и журнальным копиям SQL Server.
Проведите восстановление, а не просмотр архива
Создайте новую базу и загрузите в неё выбранную копию. Не используйте рабочее имя, каталог или строку подключения: похожие реквизиты повышают риск открыть не тот контур.
Перед входом отключите регламентные задания, обмены и отправку почты, если они запускаются автоматически. Иначе тестовая база может обратиться к рабочим системам. Выполняйте это только в восстановленной копии.
Засеките время перед началом загрузки. Остановите таймер после входа в режим 1С:Предприятия, а не после завершения команды СУБД. Компании нужно знать срок возврата прикладной системы, а не длительность одной технической операции.
Запишите четыре значения, которые рекомендует хранить регламент Serverzilla: дату копии, версию платформы, длительность восстановления и ответственного. Добавьте тип копии и имя тестового контура — они помогут воспроизвести проверку через квартал.
Если восстановление остановилось, не перебирайте действия на рабочей базе. Сохраните сообщение об ошибке, журнал СУБД и параметры тестового контура. Затем устраните причину на тестовой машине и повторите попытку с новой копией базы назначения.
Открытая база ещё не доказывает пригодность данных
Успешный вход подтверждает только запуск платформы. Проверка заканчивается на рабочем действии, которое затрагивает те же данные, что обычная работа компании.
Заранее выберите от трёх до пяти контрольных объектов. Ukved предлагает сверять ключевые документы и отчёты. Берите объекты, состояние которых известно: вчерашнюю реализацию, остатки по складу, закрытый заказ, оборотно-сальдовую ведомость на сохранённую дату.
Не пытайтесь проверить всю базу за один вечер. Контрольный набор должен покрывать главные операции и оставаться одинаковым от теста к тесту. Тогда расхождение заметно без долгого расследования.
| Проверка | Что сделать | Признак успеха | Что записать |
|---|---|---|---|
| Вход пользователя | Открыть базу под тестовой учётной записью | Интерфейс загрузился, нужные разделы доступны | Имя роли и результат входа |
| Документы | Открыть 3–5 заранее выбранных документов | Даты, номера, суммы и статусы совпали с контрольными | Перечень проверенных объектов |
| Отчёт | Сформировать отчёт на сохранённую дату | Итог совпал с заранее записанным значением | Название отчёта, период и итог |
| Тестовая операция | Создать и провести документ в тестовой базе | Проведение завершилось, движения появились | Тип документа и результат |
| Повторный вход | Закрыть клиент и подключиться снова | База открывается после выполненной операции | Время входа и обнаруженные ошибки |
Один знакомый документ проверяет данные точнее, чем беглый просмотр десятка разделов.
После тестовой операции пометьте восстановленную базу как проверочную. Не переносите созданный документ в рабочую систему и не подключайте тестовый контур к продуктивным обменам.
Если вам нужен отдельный порядок для реального отказа, используйте инструкцию по восстановлению базы без загрузки поверх рабочего экземпляра. Там задача другая: сохранить текущее состояние и выбрать допустимую точку возврата.
Сопоставьте время восстановления с допустимым простоем
Сам факт восстановления отвечает только на вопрос «можем ли вернуть базу». Бизнесу нужен второй ответ: «когда сотрудники снова войдут в 1С».
Сравните измеренное время с допустимым простоем. Если склад может ждать два часа, а тест занял 50 минут, запас есть. Если кассы должны вернуться за 30 минут, тот же результат не подходит.
Это не показатель скорости сервера и не лабораторный тест. Вы измеряете свой процесс целиком: получение копии, развёртывание, подключение 1С, сверку данных и допуск пользователей.
Зафиксируйте начало и конец каждого этапа. При следующем тесте станет видно, где выросло время: на передаче файла, команде СУБД, запуске 1С или проверке документов.
Если проверка не укладывается в допустимый простой, сначала меняйте регламент. Подготовьте команды восстановления, доступы, адрес тестовой площадки и перечень контрольных документов. Покупка другого сервера нужна только тогда, когда измерения показывают упор в ресурсы машины.
Назначьте следующий тест сразу после первого
Один успешный запуск доказывает пригодность одной копии в одной конфигурации. После обновления платформы, смены СУБД или переезда сервера условия меняются.
Инструкция «Доктор Сервер» советует повторять полное восстановление не реже раза в квартал и после крупных изменений. Для активно меняющейся базы интервал стоит привязать к допустимому риску: чем дороже простой и потеря данных, тем чаще нужен тест.
Запишите следующую дату в журнал восстановлений сразу. Без даты квартальная проверка быстро превращается в задачу «когда будет время».
Храните минимум две копии в разных местах. Одну размещайте вне офиса и закрывайте для записи из рабочей сети. Такая схема защищает от потери диска, кражи, пожара и шифровальщика, который добрался до сетевых каталогов.
Несколько поколений нужны не ради количества. Ошибку в данных или заражение могут обнаружить после того, как свежая копия уже сохранила повреждённое состояние. Тогда возвращаться придётся к более ранней дате.
Когда копию можно назвать рабочим бэкапом
Копия готова к аварии, если вы развернули её отдельно, открыли через 1С, сверили 3–5 контрольных документов и провели тестовую операцию. В журнале остались дата, версия платформы, длительность и имя ответственного.
На вечер нужен один чек-лист:
- Выберите свежую копию и запишите её дату.
- Подготовьте отдельную машину и диск с запасом в 2–3 размера
.dt. - Восстановите файловую базу или копию СУБД в новом контуре.
- Откройте 3–5 контрольных объектов и выполните тестовую операцию.
- Запишите длительность, результат и дату следующей проверки.
Если хотя бы один пункт не выполнен, у вас есть файл копии, но ещё нет доказанного восстановления.