Ночное задание завершилось без ошибки, а файл копии лежит на диске. Это доказывает лишь одно: задание создало файл. Откроется ли из него база после сбоя, пока неизвестно.
Проверка отвечает на практический вопрос: сможете ли вы вернуть 1С без риска для рабочей базы. Для этого свежую копию разворачивают отдельно, входят под обычным пользователем и проводят тестовый документ. По оценке «Доктор Сервер», такой тест занимает около часа-полутора.
На выходе у вас останутся два результата. Первый — восстановленная база, в которой можно работать. Второй — записанное время от начала подготовки до завершения прикладной проверки.
Подготовьте отдельный контур
Не восстанавливайте копию поверх рабочей базы. Возьмите другой компьютер, временную виртуальную машину или отдельный экземпляр СУБД.
Изоляция нужна не только для сохранности продакшена. Восстановленная база может запустить обмен, отправить почту или обратиться к рабочим сервисам. Ограничьте ей сеть либо замените адреса внешних систем до первого запуска фоновых заданий.
Для регулярных проверок подойдёт старый сервер после проверки дисков, питания и сети. Если отдельной машины нет, поднимите временную виртуальную машину и удалите её после теста.
| Что подготовить | Файловая база | Клиент-серверная база | Признак готовности |
|---|---|---|---|
| Свежая копия | Каталог с 1Cv8.1CD или файл .dt | Резервная копия средствами СУБД | Известны дата и время создания |
| Тестовый контур | Отдельный каталог и новая запись в списке баз | Отдельный экземпляр либо тестовая база СУБД | Рабочая база не меняется |
| Версии программ | Совместимая платформа 1С | Совместимые версии платформы и СУБД | Копию принимает нужный движок |
| Учётная запись | Обычный пользователь 1С | Пользователь 1С и доступ сервера к СУБД | Вход проверяется не под администратором |
| Контрольные данные | Известные документы, отчёты и итоги | Те же прикладные данные | Есть с чем сравнить результат |
| Журнал проверки | Время начала, этапы, ошибки | Время начала, этапы, ошибки | Результат можно повторить и сравнить |
Проверку начинайте после физического или логического отделения тестового контура от рабочей системы.
Способ создания копии зависит от архитектуры. Файловый каталог копируют после выхода пользователей либо через согласованный снимок. Копия открытой файловой базы может получить несогласованные данные.
Для клиент-серверной базы используйте штатное резервное копирование СУБД. Оно снимает копию без выхода пользователей и учитывает устройство журнала транзакций.
Перед началом запишите свободное место на тестовом диске. Не выводите нужный запас из размера сжатого архива: после развёртывания база займёт больше. Ориентируйтесь на размер рабочей базы и предусмотрите место для временных файлов СУБД.
Восстановите копию тем же путём, который нужен при аварии
Проверка должна повторять будущий порядок восстановления. Если при сбое вы планируете возвращать .bak, проверяйте .bak. Успешная загрузка .dt не доказывает работоспособность резервной цепочки SQL Server.
Файловую копию разверните в новый каталог. Добавьте его в список информационных баз под отдельным названием. Проверьте, что путь не указывает на рабочий 1Cv8.1CD.
Файл .dt загружайте только в новую информационную базу. Не используйте рабочую базу как приёмник даже тогда, когда она кажется ненужной: ошибка в выборе каталога уничтожит её текущее состояние.
Для SQL Server или PostgreSQL создайте отдельную базу и восстановите копию туда. Используйте то же средство, которое записано в аварийном регламенте. Проверка ручной команды не проверит скрипт, учётную запись и доступ к хранилищу.
Документация Microsoft требует проверять все сочетания копий из принятой стратегии SQL Server. Если схема состоит из полной, дифференциальной и журнальных копий, восстановите всю цепочку. Проверка одной полной копии оставит журнальную часть без доказательства.
Засеките три отрезка:
- Подготовка тестовой машины, сети, учётных записей и пустой базы.
- Перенос архива и восстановление данных.
- Запуск 1С, сверка данных и тестовая операция.
Сумма покажет фактическое время возврата базы. NinjaOne включает в критерии успешного теста запуск приложения, вход пользователя, допустимую потерю данных и попадание в согласованное время восстановления.
Не подменяйте измерение временем одной команды СУБД. Если восстановление заняло 25 минут, а подготовка доступов и проверка — ещё 50, бизнес ждал бы 75 минут.
Проверьте базу на трёх уровнях
Сообщение «восстановление завершено» говорит только о работе инструмента СУБД. Пользователь 1С может столкнуться с ошибкой подключения, несовместимой конфигурацией или неполными данными.
Сначала проверьте структуру. СУБД должна принять архив, прочитать служебные записи и привести базу в согласованное состояние. Для SQL Server документация Microsoft отдельно требует проверять физическую целостность восстановленной базы.
Затем сверьте данные. Откройте несколько документов за известную дату, ключевой отчёт и справочник с понятным содержимым. Сравните итоги с заранее записанными контрольными значениями.
Последний уровень — работа через клиент 1С. Войдите под обычной учётной записью, откройте рабочие разделы и проведите тестовый документ. Затем пометьте его на удаление либо уничтожьте весь тестовый контур.
| Проверка | Что подтверждает | Чего не подтверждает | Критерий успеха |
|---|---|---|---|
| Файл появился по расписанию | Задание создало объект в хранилище | Полноту и восстановимость данных | Размер и дата выглядят ожидаемо |
| Контрольная сумма совпала | Файл не изменился при переносе | Логическую целостность базы | Хеш до и после переноса одинаков |
| СУБД восстановила архив | Движок прочитал копию и собрал базу | Работу клиента 1С | База доступна без ошибок восстановления |
| Пользователь вошёл через 1С | Работают подключение и аутентификация | Полноту прикладных данных | Открылась нужная база и роль |
| Контрольные данные совпали | Нужные документы и итоги попали в копию | Возможность записи | Значения соответствуют выбранной дате |
| Тестовый документ проведён | Работают чтение, запись и прикладная логика | Все редкие операции конфигурации | Проведение завершилось без ошибки |
Бэкап проходит проверку после прикладного действия в восстановленной базе. Наличие файла и совпавший хеш до этой точки остаются промежуточными признаками.
Не запускайте «Тестирование и исправление» ради обычной проверки бэкапа. Этот инструмент меняет данные, если включить исправление. Порядок выбора операций описан в материале о диагностике отдельной копии перед изменением данных.
Запишите, сколько данных потеряется
Время восстановления отвечает лишь на половину вопроса. Нужно определить и точку, к которой вернулась база.
Сравните время последней операции в восстановленной копии со временем начала теста. Разница показывает возможную потерю данных при таком сценарии. Если копия ночная, дневные документы в неё не попадут.
Для SQL Server с полной моделью восстановления проверьте возврат журналов транзакций. Полная копия вернёт состояние на момент своего завершения. Последующие журнальные копии сокращают разрыв, если вся цепочка доступна и исправна.
Пример расчёта: полная копия закончилась в 02:00, журналы снимаются каждые 15 минут, сбой произошёл в 11:07. При доступной цепочке последний завершённый журнал относится к 11:00. Расчётный разрыв равен семи минутам: 11:07 − 11:00.
Это расчёт, а не гарантия. Если один файл журнала повреждён или отсутствует, восстановление остановится раньше. Поэтому проверяйте цепочку целиком, а не только последний файл.
Для файловой базы граница проще. Если каталог копируют раз в сутки после выхода пользователей, потеря составит время между копированием и сбоем. При сбое перед следующим ночным заданием компания потеряет почти рабочий день.
Разберите провал по этапу
Не записывайте итог одной строкой «бэкап не работает». Зафиксируйте этап, полный текст ошибки, версии платформы и СУБД, размер копии, свободное место и затраченное время.
Такая запись отделяет разовую ошибку оператора от дефекта схемы. Она же подсказывает, что проверять перед следующим запуском.
| Наблюдаемый признак | Вероятная причина | Как проверить | Что исправить перед повтором |
|---|---|---|---|
| Свежего файла нет | Закончилось место, сменился пароль или путь | Проверить журнал задания и каталог назначения | Исправить доступ, путь или ротацию |
| Архив не принимает СУБД | Копия повреждена либо несовместима с версией | Сверить версии и журнал восстановления | Взять другую дату или совместимый экземпляр |
| Файл повредился при переносе | Ошибка носителя или сетевой передачи | Сравнить контрольные суммы | Повторить перенос и проверить хранилище |
| База восстановилась, но 1С не входит | Нет доступа, неверный адрес или расходятся версии | Проверить строку подключения и журнал платформы | Исправить подключение тестовой базы |
| Документы открываются с ошибками | Копия неполная либо нарушена логика данных | Сверить контрольные документы и отчёты | Исправить создание копии, не тестовый результат |
| Тестовый документ не проводится | Не работает прикладная запись или внешняя зависимость | Повторить действие под обычной ролью | Исправить контур и снова восстановить исходную копию |
| Время превышает допустимый простой | Долго готовится среда, переносится архив или идёт проверка | Сравнить длительность трёх этапов | Сократить самый долгий этап |
Исправляйте цепочку создания, хранения или развёртывания копии. Ручная починка тестовой базы не сделает следующий бэкап рабочим.
После исправления удалите тестовый результат и повторите восстановление с начала. Иначе вы проверите уже отремонтированную базу, а не исходную резервную копию.
Внесите тест в регламент
Один успешный запуск доказывает состояние схемы только на дату проверки. Обновление платформы, перенос сервера или смена пароля могут нарушить следующий цикл.
«Доктор Сервер» рекомендует небольшой компании проверять восстановление хотя бы раз в квартал. Публикация UKVED предлагает для активно используемой базы месячный интервал. Для критичной розницы, склада или ERP автор рекомендует еженедельную проверку.
Это редакционные рекомендации, а не норматив для любой компании. Выберите интервал по допустимой потере данных, цене простоя и частоте изменений. После обновления платформы, конфигурации или схемы копирования проведите внеплановый тест.
Храните несколько копий за разные даты. Одна последняя копия не поможет, если повреждение появилось раньше и успело попасть в архив.
Хотя бы одна копия должна находиться вне сервера. Документация Microsoft советует хранить резервные файлы SQL Server на другом физическом устройстве. Копия в соседнем каталоге исчезнет вместе с диском или сервером.
Шифровальщик доберётся и до сетевого хранилища, доступного на запись с рабочего контура. Отдельная копия должна пережить отказ диска, заражение сервера и потерю помещения.
Расписание, способы создания копий и сроки хранения лучше закрепить в регламенте копирования и смены архивов. Рядом храните журнал тестов: дата, выбранная копия, результат, потеря данных и полное время возврата.
Пять признаков рабочего бэкапа
Проверку можно закрыть, когда выполнены все пять условий:
- копия развёрнута отдельно и не затронула рабочую базу;
- обычный пользователь вошёл через клиент 1С;
- контрольные документы, отчёты и итоги совпали;
- тестовый документ провёлся без ошибки;
- полное время уложилось в допустимый для компании простой.
На ближайший вечер план короткий: выберите свежую копию, поднимите отдельный контур и запустите таймер. Восстановите базу, выполните прикладную проверку и запишите результат.
Файл бэкапа подтверждает работу задания. Восстановление подтверждает только база, которую подняли отдельно и проверили через 1С.