Резервная копия журнала операций: как проверить восстановление

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

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

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

Что считать успешным восстановлением?

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

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

Успешное открытие базы подтверждает лишь часть результата. Для SQLite команда PRAGMA integrity_check проверяет структуру страниц и записей, индексы, а также ограничения UNIQUE, CHECK и NOT NULL. Нарушения внешних ключей она не выявляет — для них предусмотрена команда PRAGMA foreign_key_check. Если ошибок не найдено, integrity_check возвращает ok.

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

Как подготовить безопасный тест?

Сначала поместите резервный файл в отдельную папку и запретите тесту обращаться к рабочей базе. В названии папки укажите дату копии и дату проверки. Исходный файл оставьте без изменений, чтобы не потерять единственный экземпляр при неудачном импорте.

Версию приложения, формат копии и контрольную сумму файла лучше записать заранее. Контрольная сумма не доказывает полноту данных, но помогает установить, что повторная проверка выполнялась с тем же файлом, а не с похожей копией под тем же названием.

Для восстановления нужен предусмотренный продуктом механизм. SQLite Online Backup API копирует содержимое одной базы в другую и заменяет содержимое базы назначения, поэтому назначением должна быть тестовая база. pg_restore применяют к архивам pg_dump в форматах, отличных от обычного текстового SQL, и с его помощью реконструируют состояние базы на момент сохранения.

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

Какие данные сверить после запуска?

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

Далее проверьте устойчивые идентификаторы. В MetaTrader 5 билет сделки является уникальным идентификатором, а одной заявке могут соответствовать несколько сделок. Поэтому сравнивать только номера заявок недостаточно: частичное исполнение может восстановиться не полностью.

Сверьте время с учётом источника. В истории MetaTrader 5 время сделки указывается в часовом поясе торгового сервера брокера. Если журнал переводит его в местное время или UTC, заранее запишите правило преобразования и проверьте записи около полуночи и смены даты.

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

Как выбрать записи для ручной проверки?

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

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

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

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

Что записать в протокол теста?

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

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

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

Источники

• Using the SQLite Online Backup API — SQLite
• PRAGMA integrity_check — SQLite
• pg_restore — PostgreSQL
• Executing Trades: Trading Account History — MetaTrader 5

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