Резервная копия позволяет восстановить данные, но ее прямое восстановление поверх активной базы данных может удалить законные изменения, внесенные после создания копии. Если проблема затрагивает одну запись или ограниченный набор данных, обычно цель состоит в том, чтобы восстановить утраченную информацию и сохранить остальное текущее состояние. Для этого к восстановлению нужно подходить как к операции сравнения и согласования, а не как к простой замене.
Выбор стратегии зависит от СУБД, схемы, наличия журналов аудита и масштаба повреждения. В PHP-приложении логику восстановления следует отделить от работающего в production приложения, документировать принятые решения и проверять валидации до записи данных. Если невозможно определить, какие изменения безопасны, остановиться и подготовить ручное согласование обычно менее рискованно, чем автоматизировать перезапись.
Определите, что означает восстановление данных
Полное восстановление заменяет базу данных, схему или большой набор данных содержимым точки восстановления. Выборочное восстановление, напротив, призвано вернуть конкретные строки или определенные значения, не изменяя остальные активные данные. Прежде чем выбирать подход, точно опишите ожидаемый результат: какая сущность отсутствует или изменена, какие поля нужно восстановить и какие последующие изменения необходимо сохранить.
Ограничьте область изменений с помощью стабильных идентификаторов, например первичного ключа, а не только значений, которые могли измениться, таких как имя или адрес электронной почты. Также выясните, затрагивает ли инцидент связанные записи: например, заказ может зависеть от позиций, платежей, адресов и событий изменения статуса. Восстановление только основной строки может сделать сущность внутренне несогласованной; восстановление всей группы может включить допустимые изменения, которые не следует откатывать.
- Зафиксируйте симптом, примерный временной интервал и того, кто сообщил о проблеме.
- Определите затронутые таблицы, первичные и внешние ключи, а также соответствующие ограничения.
- Укажите, какие поля нужно вернуть к прежнему значению, а какие должны остаться без изменений.
- Определите, кто утвердит операцию и какие проверки позволят считать ее завершенной.
Выберите точку восстановления и восстановите контекст
Выберите точку восстановления, которая позволит восстановить требуемое состояние; это не обязательно должна быть копия, созданная до повреждения. В зависимости от инцидента может потребоваться сравнить несколько резервных копий, журналы транзакций и данные аудита, чтобы определить, какую информацию нужно восстановить и какой последующий контекст следует сохранить. Восстановление на момент времени может создать временную базу, полезную для извлечения данных, но это не означает, что ее содержимое целиком безопасно переносить в production.
Проверьте дату и часовой пояс, охват резервной копии, схему, с которой она была создана, и результаты доступных проверок целостности. Непроверенную копию не следует по умолчанию считать надежным источником. Кроме того, выясните, могли ли идентификаторы использоваться повторно и есть ли процессы, которые во время расследования записывают данные в затронутые таблицы.
Восстановите копию в изолированном экземпляре с ограниченным доступом и без соединений, позволяющих записывать данные в production. Приложение не должно случайно подключиться к этому экземпляру, а запланированные задания не должны запускаться для него. Если данные содержат персональную или конфиденциальную информацию, ограничьте доступ и применяйте предусмотренные для таких данных меры защиты. Изолированная среда позволяет сравнивать состояния, не подвергая активную базу дополнительному риску.
Сравнивайте данные, не считая копию текущим источником истины
Сравните подходящие строки из резервной копии с текущими строками, используя стабильные ключи. Для каждой строки определите одну из трех ситуаций: запись отсутствует, запись существует, но некоторые ее поля изменены, либо существенных различий нет. Если доступны метки обновления, история событий или аудит, используйте их, чтобы выяснить, когда и почему запись изменилась. Одна лишь временная метка не доказывает, какой пользователь внес изменение и следует ли его сохранить.
При выборочном восстановлении особенно важно не копировать автоматически всю старую строку, если некоторые ее поля могли измениться допустимым образом. Например, сравнение может показать, что запись потеряла описательное поле, тогда как ее статус, владелец или связь с другой сущностью изменились позднее. Если это допускают бизнес-правила, восстановить только утраченное поле может быть безопаснее, чем заменять всю строку.
Также проверьте конфликты уникальности, внешние ключи, обязательные столбцы, значения по умолчанию и правила, применяемые приложением. В системах с логическим удалением выясните, не помечена ли запись как удаленная вместо того, чтобы действительно отсутствовать. Таблицы, участвующие в одной бизнес-операции, могут потребовать совместного согласования, чтобы избежать несогласованных балансов, статусов или ссылок.
Выполните ограниченную и проверяемую операцию
Подготовьте план с точным набором ключей и столбцов, которые будут изменены. Перед выполнением сохраните копию текущего состояния этих строк или предусмотрите равноценный механизм отката. Проверьте план на свежей копии активной базы данных и сравните результат с ожидаемым. Проверка должна учитывать реальные ограничения и зависимости, а не только импорт отдельных строк.
Если это допускают СУБД и операция, выполняйте изменения в транзакции. Транзакция не заменяет проверку: некоторые операции восстановления или импорта могут иметь особенности, связанные с конкретной СУБД, а внешние процессы могут одновременно обновлять данные. Используйте условия, позволяющие обнаруживать неожиданные изменения между сравнением и записью. Если строка больше не соответствует проверенному состоянию, остановите операцию и проанализируйте ее заново, а не перезаписывайте данные незаметно.
В PHP-приложении контролируемая задача или команда обслуживания может проверять входные данные, ограничивать затронутые ключи и записывать результаты. Не формируйте SQL-инструкции путем конкатенации значений. Используйте параметризованные запросы и механизм транзакций, предусмотренный применяемым в приложении слоем доступа к данным. Не размещайте такую операцию в публичных маршрутах и не выводите учетные данные или резервные копии в текстовые журналы.
Перед фиксацией изменений проверьте количество затронутых строк, ограничения и соответствующие связи. После этого проверьте восстановленные значения и работу приложения в связанных бизнес-операциях. Если проверка завершилась неудачей до фиксации транзакции, откатите ее. Если транзакция уже зафиксирована или существуют необратимые последствия, не выполняйте новые записи наугад: до начала операции задействуйте утвержденный план отката или восстановления и следуйте проверенной процедуре возврата к принятому состоянию с последующей проверкой. Если план не позволяет восстановить согласованное состояние, прекратите дальнейшие изменения, сохраните доказательства и передайте решение ответственным лицам.
Задокументируйте решение и определите, когда не следует автоматизировать
Задокументируйте инцидент, использованную точку восстановления, проверенные ключи, восстановленные поля и сохраненные последующие изменения. Зафиксируйте, кто проверил и утвердил операцию, когда она была выполнена, какие проверки проведены и каков результат. Не включайте в журнал лишние конфиденциальные данные. Такая прослеживаемость позволяет объяснить принятое решение и упрощает последующее расследование.
Выберите ручное согласование, если надежных ключей нет, бизнес-операции конфликтуют, невозможно отличить случайное изменение от допустимого или восстановление затрагивает связи, смысл которых зависит от контекста. Полное восстановление может быть уместно при масштабном повреждении, но необходимо оценить его влияние, простой, потерю последующих изменений и процедуру восстановления. Не следует выбирать этот вариант только потому, что его проще выполнить.
- Выборочное восстановление: повреждение четко ограничено, ключи надежны, а различия можно проверить.
- Ручное согласование: есть параллельные изменения или бизнес-правила, требующие участия человека.
- Полное восстановление: повреждение масштабное и есть утвержденный план управления простоем и изменениями, которые будут потеряны.
Контрольный список перед завершением восстановления
- Подготовка: определены ли масштаб, ключи, зависимости и ожидаемый результат? Выбрана и проверена ли подходящая точка восстановления?
- Среда и утверждение: восстановлена ли копия в изолированной среде, ограничен ли доступ и проверена ли процедура? Утвердили ли ответственные лица операцию и план отката или восстановления?
- Выполнение: сохранено ли текущее состояние затронутых строк, ограничена ли запись предусмотренными ключами и полями и обнаруживаются ли параллельные изменения?
- Проверка: проверены ли затронутые строки, ограничения, ссылки и бизнес-поведение? Если проверка не пройдена, прекратили ли новые записи и задействовали ли утвержденную процедуру?
- Прослеживаемость: задокументированы ли решение, выполнение, проверки, сохраненные изменения и результат без включения лишних конфиденциальных данных?
Если на соответствующие вопросы нельзя ответить утвердительно, отложите запись в production. Выбор между выборочным восстановлением, ручным согласованием и полным восстановлением должен основываться на масштабе повреждения, надежности доказательств, операционном влиянии и реальной возможности вернуть систему в согласованное состояние.
