Резервные копии, отказоустойчивость и восстановление: что нужно вашему сайту

• Сохранить сведенияИметь копии, из которых можно вернуть данные.
• Продолжить работуПодготовить замену на случай определённых поломок.
• Восстановить сайтЗнать, кто и как вернёт нужные возможности.

Почему одной резервной копии бывает недостаточно

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

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

При этом даже хорошо подготовленный запасной сервер требует понятного порядка действий. Кто заметит проблему, примет решение о переходе и убедится, что заказы снова поступают? Ответы входят в план восстановления. Эти три меры дополняют друг друга, но решают разные задачи.

Прокрутите таблицу вправо, чтобы увидеть все столбцы.

Какая работа должна продолжаться во время сбоя

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

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

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

От каких проблем не спасёт второй сервер

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

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

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

Как объяснить подрядчику, какой результат вам нужен

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

В техническом предложении эти требования могут называться RPO и RTO. Первое связано с тем, до какого момента нужно вернуть данные, второе — с допустимой длительностью восстановления. Определения приведены в глоссарии NIST: NIST — Recovery Point Objective и NIST — Recovery Time Objective. Владельцу удобнее начать с обычных слов и только затем согласовать показатели со специалистом.

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

Как сравнить предложения по защите сайта

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

Выбор стоит связывать с последствиями остановки бизнеса. Такой подход описан в руководстве NIST SP 800-34 — планирование восстановления. Для небольшого сайта не обязательно составлять большой документ: достаточно записать важные функции, допустимые ограничения и действия при отказе.

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

Как понять, что защита действительно настроена

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

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

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

Почему к настройкам нужно возвращаться

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

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

Проверка по пунктам

Короткие ответы на частые вопросы

Нужна ли такая защита небольшому сайту с контактами?

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

Что обсудить с подрядчиком перед выбором защиты

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

Отказоустойчивость и резервное копирование

Читайте также

• Почему резервной копии у хостинга может быть недостаточно
• Как подготовить резервную площадку для сайта и проверить переключение
• Слабые места сайта: что может остановить работу и как это проверить
• Сколько стоит отказоустойчивость сайта и как выбрать достаточный уровень защиты
• Как часто делать резервные копии сайта, чтобы не потерять заявки и заказы

Источники

• NIST — Recovery Point Objective
• NIST — Recovery Time Objective
• NIST SP 800-34 — планирование восстановления

Обновлено 10 октября 2026 года.