EKORKUNOV — Евгений Коркунов

Инфраструктура

Правило 3–2–1: почему одной резервной копии сайта недостаточно

Архив рядом с сайтом может исчезнуть вместе с ним. Объясняю правило 3–2–1 на простом примере: сколько копий нужно, где их хранить и что проверить заранее.

Автор
Евгений Коркунов
Опубликовано
Чтение
7 мин
1 просмотр
Правило 3–2–1: сайт, отдельное облачное хранилище и внешний диск для резервных копий
Иллюстрация к правилу резервного копирования 3–2–1.

Сайт может перестать работать после обычного обновления. Сотрудник может случайно удалить нужный раздел. У сервера может выйти из строя диск.

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

Поэтому вопрос «У нас есть резервная копия?» я бы дополнил ещё одним: «Сможем ли мы воспользоваться ею, если с основным сайтом что-то случится?»

Правило 3–2–1 помогает организовать хранение так, чтобы одна проблема не уничтожила всё сразу.

Что означает правило 3–2–1

Запомнить его можно по трём цифрам.

3 — рабочие данные и две резервные копии.
2 — разные типы носителей.
1 — копия вне основной площадки.

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

Два разных типа носителей. В классической схеме данные размещают на разных носителях. Например, рабочие данные находятся на SSD, а одна из копий — на внешнем жёстком диске. Три папки на одном диске не выполняют это условие.

Хотя бы одна резервная копия вне основной площадки. Если сайт находится в дата-центре, одна из копий должна храниться в другом месте. Тогда происшествие на основной площадке не затронет сразу все экземпляры.

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

Как это может выглядеть для обычного сайта

Один из возможных вариантов:

  • сайт работает на SSD хостинга;
  • резервная копия отправляется в отдельное облачное хранилище вне площадки этого хостинга;
  • ещё одна копия сохраняется на внешнем жёстком диске у владельца.

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

Простой вопрос для проверки: если основной сервер станет полностью недоступен, откуда мы возьмём сайт?

Если ответ — «из папки на этом же сервере», схема требует доработки.

Но ведь хостинг уже делает резервные копии

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

Уточните:

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

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

Что именно нужно сохранять

Для сайта на WordPress обычно нужны и файлы, и база данных.

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

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

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

Как часто делать копии

Начните с вопроса: изменения за какой период вы готовы потерять?

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

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

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

Перед обновлением, переносом или крупной доработкой также стоит сделать отдельную свежую копию. Она дополняет регулярное расписание.

Почему синхронизация не заменяет резервное копирование

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

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

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

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

Главная проверка — получится ли восстановить сайт

Сообщение «копирование завершено» означает, что задача отработала. Оно ещё не подтверждает, что сайт получится запустить из сохранённых данных.

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

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

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

Пять вопросов, которые стоит задать сегодня

  1. Где находится резервная копия, независимая от основного сайта?
  2. За какую дату она сделана?
  3. Есть ли в ней файлы, база и необходимые настройки?
  4. Кто сможет получить к ней доступ при сбое?
  5. Когда из неё последний раз проверяли восстановление?

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

Правило 3–2–1 не отменяет сбои. Оно помогает подготовиться к ним и сохранить возможность вернуть важные данные.

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

Комментарии

0

Пока нет опубликованных комментариев. Вы можете отправить первый — он появится после модерации.

Оставить комментарий

Комментарии проходят модерацию. Не публикуйте персональные данные, рекламу и неподтверждённые обвинения.

Все статьи
Бизнес и технологии9 мин чтения
Иллюстрация об оплате зарубежных сервисов: виртуальная карта, ноутбук и названия Claude и ChatGPT

Как оплачивать ChatGPT, Claude и другие зарубежные сервисы: мой опыт за 6 месяцев

Как я оплачиваю Claude и ChatGPT картой «Плати по всему миру»: что удобно в повседневном использовании, сколько стоит карта и что проверить перед оформлением.

Читать статью
Инфраструктура20 мин чтения
Какой хостинг выбрать: обзор Beget в 2026 году

Какой хостинг выбрать в 2026 году: Beget и мой опыт за 8 лет

Я пользуюсь услугами Beget восемь лет. Разбираю виртуальный хостинг через задачи владельца сайта: панель, CMS, HTTPS, антивирус, резервные копии, почту и выбор тарифа. С настоящими снимками кабинета и условиями на 1 октября 2026 года.

Читать статью