Резервное копирование и план восстановления сайта
Что происходит, если ваш сайт взломали, сервер вышел из строя или страница удалена по ошибке? Понятный план частоты резервных копий и теста восстановления.
Команда rabbitclipПубликация: 5 мин чтения
Коротко
План резервного копирования должен отвечать на три вопроса: как часто делается копия, хранится ли она отдельно от рабочего сервера, и пробовали ли вы на самом деле её восстановить. Не хватает одного из трёх ответов, и копия, на которую вы рассчитываете, лишь предположение, вплоть до того самого момента, когда она понадобится.
Восстановление после сбоя звучит как тема для крупных компаний, но оно так же реально и для малого бизнеса. Если система записи сети спа-салонов ломается во время обновления, или база данных интернет-магазина удаляется по ошибке, время на восстановление напрямую превращается в упущенную выручку.
Что должна на самом деле охватывать резервная копия
Резервная копия сайта состоит из двух частей: файлов, темы, плагинов, загруженных изображений, и базы данных, товаров, заказов, учётных записей пользователей, записей блога. Если обе части не сохраняются вместе, восстановление, в котором одной не хватает, оставляет половину сайта рабочей, а другую пустой.
В интернет-магазине база данных меняется постоянно, может понадобиться ежедневное или даже ежечасное резервное копирование; для корпоративного сайта-визитки обычно достаточно еженедельного. Правильная частота следует за тем, как часто сайт на самом деле меняется.
Где должна храниться резервная копия
Держать копию на том же сервере, что и рабочий сайт, самая распространённая ошибка. Если сервер становится полностью недоступен, копия, которая на нём лежит, исчезает в тот же момент. Копия должна существовать и в совершенно отдельном месте, на другом сервере, в облачном хранилище или в собственном архиве компании.
Единственно верного ответа на вопрос, сколько копий и где, не существует; это зависит от размера бизнеса. Неизменное правило таково: как минимум одна копия должна находиться в месте, полностью независимом от сервера, на котором размещён сайт.
Почему тест восстановления пропускают, и почему этого не стоит делать
Большинство компаний знают, что делают резервные копии, но никогда по-настоящему не пробовали что-то восстановить. Повреждённый файл резервной копии, отсутствующая таблица базы данных или несовместимая версия плагина, всё это проявляется только при попытке восстановления, и редко в удобный момент.
Тест восстановления можно провести в отдельной тестовой среде, не трогая рабочий сайт. Выполняемый несколько раз в год, он превращает часы неопределённости в реальном кризисе в считанные минуты.
Что на самом деле должен содержать план восстановления после сбоя
В отличие от резервной копии, план восстановления после сбоя письменно описывает, кто что делает, когда что-то идёт не так. Это может быть всего одна страница, но она должна отвечать на три вопроса.
- Если сайт становится полностью недоступен, кому звонят в первые 30 минут и у кого есть доступ к панели хостинга
- Где находится последняя рабочая резервная копия и у кого есть к ней доступ
- Какое сообщение видят клиенты, или работающая страница продаж, пока идёт восстановление
Какие события запускают этот план
Восстановление после сбоя касается не только отказа сервера. Сайт, который ломается после обновления, конфликт плагинов, случайно удалённая страница, попытка взлома или сбой у самого хостинг-провайдера, всё это требует одного и того же плана.
Если страница каталога товаров производителя напольных покрытий ломается во время обновления, это не масштабная катастрофа, но тот же план должен работать и в малом масштабе: к какой резервной копии вернуться, кто это утверждает, и за какое время.
Частые ошибки в резервном копировании
Самая частая ошибка, сохранять только на уровне файлов, забывая о базе данных. Если еженедельная резервная копия производственного сайта охватывает только тему и изображения, форма заказа или запись контакта может пропасть в момент восстановления.
Вторая ошибка, никто на самом деле не читает уведомление о резервном копировании. Автоматический инструмент может каждую ночь отправлять письмо, но если оно неделями остаётся непрочитанным, копия, которая какое-то время незаметно даёт сбой, остаётся незамеченной так же долго.
Третья, полностью полагаться на собственную систему хостинг-провайдера без какой-либо копии в другом месте. Если сайт сети спа-салонов держится на единственной копии, хранящейся на сервере провайдера, спор или проблема с аккаунтом у этого провайдера может забрать с собой и доступ к резервной копии.
Как проходит восстановление после сбоя, шаг за шагом
В момент сбоя первое, что нужно сделать, не поддаваясь панике, это понять масштаб проблемы: затронута только одна страница, или сайт полностью недоступен.
- Определите масштаб проблемы: одна страница, весь сайт, или затронута только почта
- Найдите последнюю заведомо рабочую резервную копию и запишите её дату
- По возможности сначала попробуйте восстановление в тестовой среде
- Подготовьте временное сообщение для клиентов, прежде чем выводить восстановление в рабочую версию
- Не возвращайте ту же резервную копию в рабочую версию, не устранив сначала причину проблемы
На что смотреть при выборе инструмента или сервиса резервного копирования
Первое, что стоит проверить при выборе инструмента резервного копирования, это где на самом деле хранится копия; инструмент, который резервирует только на тот же сервер, не даёт реальной защиты, если этот сервер выходит из строя. Второй момент, сколько технических знаний на самом деле требует восстановление; инструмент, который владелец бизнеса может восстановить одним щелчком в панели, позволяет действовать быстро, не дожидаясь технической команды.
Третий момент, срок хранения, насколько далеко назад инструмент на самом деле хранит версии. Некоторые инструменты держат только последние несколько дней, что бесполезно, если проблема остаётся незамеченной неделями, прежде чем её обнаружат; инструмент, который хранит несколько недель версий, даёт реальную защиту от такого рода запоздалых обнаружений.
Хороший план резервного копирования оценивают не по тому, существует ли копия, а по тому, действительно ли она работает после восстановления; где она хранится и насколько далеко назад доступна, важно не меньше самого инструмента. На технической проверке с rabbitclip мы можем проверить вашу нынешнюю систему резервного копирования и вместе закрыть пробелы.
Частые вопросы
Резервное копирование должно быть автоматическим или ручным?
Автоматическим. Ручное резервное копирование в итоге забывают делать. Регулярный график, настроенный через панель хостинга или плагин, убирает человеческий фактор из процесса.
Сколько резервных копий следует хранить?
Фиксированного числа нет; как минимум одна актуальная копия должна находиться независимо от рабочего сервера, а несколько более старых версий защищают от проблем, которые какое-то время оставались незамеченными.
Достаточно ли одной резервной копии, если сайт взломан?
Копия позволяет вернуться к чистой версии, но не закрывает лазейку, которой воспользовалась атака; уязвимость нужно найти и устранить до восстановления, иначе та же проблема повторится.
Кто должен писать план восстановления после сбоя?
Тот, кто размещает или обслуживает сайт, часто агентство, должен его написать, но владелец бизнеса всё равно должен знать, кому звонить и что важнее всего.
На что обращать больше всего внимания при выборе инструмента резервного копирования?
На то, где он хранит копию, и сколько версий сохраняет; резервная копия, которая живёт только на том же сервере и охватывает лишь один день, не спасает от проблем, обнаруженных с задержкой.
