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

Что может пойти не так при ручной правке

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

Что должна включать резервная копия перед правками

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

Автоматизация резервного копирования как постоянная практика

Регулярное автоматическое резервное копирование (ежедневное или хотя бы еженедельное, в зависимости от частоты обновления сайта) должно быть настроено независимо от текущей задачи по устранению юридических рисков — это базовая гигиена работы с любым сайтом. Но перед конкретной, значимой правкой (особенно массовой заменой нескольких файлов сразу) разумно сделать дополнительную, свежую резервную копию непосредственно перед началом работы, а не полагаться только на плановое расписание.

Где хранить резервную копию

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

Тестирование восстановления — не только создание резервной копии

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

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