Резервное копирование и восстановление сайта: частота, удалённое хранение и проверка восстановления
1. Единственный критерий приёмки резервной копии — «восстановление возможно»
Сначала обозначим границы этой статьи:Базовая защита рассказывает, как выстроить рубеж обороны от вторжений,Ежемесячное обслуживание рассказывает, какое место занимает резервное копирование в ежемесячном регламенте, а эта статья посвящена только самому резервному копированию — что копировать, куда копировать, как часто проверять и сколько занимает восстановление. Оборона — это предварительная защита, обслуживание — это регулярность, резервное копирование — это последняя страховка, и эти три вещи не заменяют друг друга.
У большинства компаний резервное копирование сайта существует «для вида»: панель хостинга показывает успешное копирование, в списке плагинов лежат записи о бэкапах, и все по умолчанию считают, что в случае аварии сайт можно спасти. Но в ночь аварии выясняются три вещи: файл резервной копии повреждён или не обновлялся несколько месяцев, копия и сайт хранились на одном хостинге и пропали вместе, и никто не знает конкретных шагов восстановления. Первое — проблема качества, второе — проблема хранения, третье — проблема процесса; эти три проблемы соответствуют трём разделам ниже.
| Форма фиктивного бэкапа | Как проявляется в обычное время | Что произойдёт при аварии |
|---|---|---|
| Копия на том же сервере | Панель показывает успешное копирование, никто не скачивает | При отказе хостинга пропадает вместе с сайтом |
| Копируется только база данных, без файлов | Копия небольшая, создаётся быстро | После восстановления тема отсутствует, вёрстка нарушена, все изображения не работают |
| Задача резервного копирования давно выдаёт ошибки | В админке иногда появляется красное уведомление, которое никто не обрабатывает | Последняя рабочая копия датируется несколькими месяцами назад, все промежуточные данные потеряны |
| Целостность никогда не проверялась | Размер файла копии то больше, то меньше | При восстановлении выясняется, что архив повреждён и не распаковывается |
| Порядок восстановления есть только у провайдера | Нет письменного регламента | После окончания рабочего дня или при недоступности поддержки восстановление выполнить некому |
Чтобы понять, настоящий ли у вас бэкап, достаточно ответить на один вопрос: когда вы в последний раз полностью восстановили сайт из резервной копии и сколько это заняло. Если ответить не можете — считайте, что бэкапа нет. Этот критерий не связан с сообщением «копирование успешно» — уведомление об успешной задаче доказывает лишь то, что задача выполнилась, но не то, что результат пригоден.
2. Что резервировать: четыре категории объектов — пропустите одну, и восстановление будет неполным
Сначала составьте полный список объектов резервного копирования, и только потом говорите о частоте. У обычного отдельного сайта на WordPress есть четыре категории объектов, которые обязательно нужно охватить. Пропустите любую из них — и восстановленный сайт будет неполным.
| Объект резервного копирования | Что охватывает | Последствия пропуска | Рекомендуемая частота |
|---|---|---|---|
| База данных | Статьи, страницы, отправленные формы, данные пользователей и заказов | Весь контент и записи заявок потеряны | Ежедневно |
| Файлы, темы и плагины | Ядро программы, код темы, плагины и их настройки | Функциональность не восстановить, вёрстка на сайте ломается | Раз в неделю и перед изменениями |
| Каталог загрузок | Изображения товаров, PDF-материалы, фото и видео кейсов | Все изображения на сайте отдают 404, скачивание материалов не работает | Еженедельно |
| Конфигурация и сертификаты | Конфигурация веб-сервера, SSL-сертификат, экспорт DNS-записей | Сайт не запускается или HTTPS выдаёт ошибки по всему сайту | При каждом изменении |
Три дополнения. Первое: каталог загрузок обычно самый объёмный, и многие команды из-за размера просто не бэкапят его — в итоге восстанавливают сайт без изображений товаров, а для покупателя это почти то же самое, что сайта нет. Второе: конфигурацию и сертификаты упускают чаще всего, потому что они обычно находятся на уровне хостинга, а не в системе управления сайтом, и область резервного копирования плагина до них просто не достаёт. Третье: заявки и данные заказов хранятся в базе данных — это самая ценная с коммерческой точки зрения категория из четырёх: изображения можно загрузить заново, а потерянные клиентские лиды восстановить нечем, поэтому частоту резервного копирования базы данных нужно отдельно выводить на самый высокий уровень.
3. Три режима резервного копирования и сроки хранения
Частота и срок хранения — это парный параметр: задать только частоту и не задать срок хранения — значит не задать ничего.
| Уровень | Частота | Срок хранения | Типичные сценарии, которые покрывает |
|---|---|---|---|
| Ежедневный инкремент | 1 раз в день | 14 дней | Случайно удалили статью, ошибочно изменили страницу, откат к сегодняшнему контенту |
| Еженедельный полный бэкап | 1 раз в неделю | 8 недель | Постепенное повреждение базы данных, нужен откат на несколько недель назад |
| Снимок перед крупными изменениями | Вручную, перед обновлением, редизайном или сменой темы | 90 дней | Откат после неудачного обновления, сверка при квартальном разборе |
Логика сроков хранения такая: случайные удаления и ошибочные правки обычно обнаруживаются в течение одной-двух недель, и 14-дневного инкремента достаточно, чтобы их покрыть; некоторые повреждения происходят не мгновенно — например, база данных постепенно сбоит или в неё поэтапно внедряется спам-контент, — и к моменту обнаружения часто проходит уже несколько недель, поэтому 8-недельный полный бэкап даёт более длинное окно отката; снимки на 90 дней служат именно крупным изменениям — если через три месяца после редизайна выяснится, что с новой версией есть проблемы, всё ещё можно вернуться и сравнить.
Одну границу нужно обозначить чётко: частота резервного копирования следует за частотой обновления контента, не стоит рубить всех под одну гребёнку. Если сайт обновляется всего раз-два в месяц, ежедневный инкремент — это лишние траты на хранение и силы на поддержку, достаточно еженедельного полного бэкапа плюс снимка перед изменениями; и наоборот, если формы приносят заявки каждый день, а заказы постоянно записываются, частота резервного копирования базы данных не должна быть ниже одного раза в день, а при возможности можно делать инкремент каждые шесть часов.
4. Правило разных мест: бэкап на том же сервере — это не бэкап
«Разные места» — это три отличия: другой сервер, другой аккаунт, другой регион. Бэкап на том же сервере исчезнет вместе с сайтом, если что-то случится с хостингом — сбой диска, взлом, закрытие провайдера, блокировка аккаунта. Ни в одном из этих случаев бэкап на том же сервере вас не спасёт.
| Где хранится бэкап | Сбой диска хостинга | Взлом сайта | Кража основного аккаунта | Вывод |
|---|---|---|---|---|
| Тот же сервер | Потеряется вместе с сайтом | Потеряется вместе с сайтом или удалён | Потеряется вместе с сайтом | Недопустимо |
| Облако или объектное хранилище на том же аккаунте | Не пострадает | Может быть удалён | Потеряется вместе с сайтом | Не подходит |
| Хранилище в том же регионе, но на другом аккаунте | Не пострадает | Безопасность | Безопасность | Приемлемо |
| Хранилище в другом регионе и на другом аккаунте | Не пострадает | Безопасность | Безопасность | Рекомендуется |
Столбец «Кража основного аккаунта» большинство упускает из виду. Получив контроль над хостингом, злоумышленник первым делом ищет и удаляет бэкапы, чтобы вы не восстановили сайт. Поэтому аккаунт для хранения бэкапов должен быть полностью независим от аккаунта сайта, на нём должна быть включена двухфакторная аутентификация, а права на стороне сайта не должны включать удаление бэкапов. Выполните эти три условия — и даже при полном контроле над сайтом злоумышленник не доберётся до вашего пути к отступлению.
Есть и практическое ограничение: скорость доступа через границу. Если хранилище бэкапов находится в другом регионе, скачивание при восстановлении может идти в несколько раз медленнее, чем в том же регионе: бэкап на 300 МБ в том же регионе скачается за несколько минут, а с другого континента может занять больше получаса. Компромисс такой: основную копию держите в ближнем регионе, холодную копию — в дальнем, а при учебном восстановлении замеряйте время по основной копии.
5. Сравнение инструментов и способов резервного копирования
У каждого из четырёх распространённых способов своя сложность восстановления. Главный критерий выбора — не то, насколько удобно делать бэкап, а то, насколько гладко он восстанавливается.
| Способ | Степень автоматизации | Сложность восстановления | Когда применяется |
|---|---|---|---|
| Автоматический бэкап в панели хостинга | Высокая, выполняется по расписанию | Низкая, обычно восстановление в один клик | Хостинг с управлением, нет выделенного технического специалиста |
| Плагин резервного копирования | Средне-высокая, можно настроить расписание и выгрузку в другое место | Средняя, нужно переустановить в среде восстановления и импортировать | Обычная практика для сайтов на WordPress |
| Скрипт плюс объектное хранилище | Высокая, выполняется по заданию планировщика | Средне-высокая, нужны операции в командной строке | Команды с техническими специалистами |
| Ручной снимок силами провайдера | Низкая, по запросу | Низкая, выполняет провайдер | Подстраховка перед миграцией и обновлением |
Разберём два момента. Бэкап в один клик из панели хостинга — самый простой вариант, но обязательно проверьте, что файл бэкапа можно скачать локально: если бэкап заперт в панели провайдера, вы передаёте ему и возможность восстановления, и при проблемах у провайдера у вас не останется ни одной копии. Плюс плагина резервного копирования в том, что он умеет автоматически выгружать бэкапы в облако или объектное хранилище и попутно решает задачу хранения в другом месте; минус — восстановление зависит от работоспособности самого плагина, а после серьёзного повреждения сайта плагин может быть уже сломан, поэтому на важных этапах всё равно нужен снимок уровня панели или ручной снимок как подстраховка. Рекомендуемое сочетание из четырёх вариантов: плагин отвечает за ежедневные инкрементные бэкапы и выгрузку в другое место, панель хостинга — за еженедельный полный бэкап, а перед крупными изменениями делайте ручной снимок.
VI. Учебное восстановление: пять шагов и ожидаемое время
Учебное восстановление — это не символическое нажатие кнопки «восстановить», а полный проход по процессу с замером времени. Шаги и критерии прохождения ниже.
| Шаг | Действие | Критерий прохождения |
|---|---|---|
| 1. Получить резервную копию | Скачать последнюю полную копию из удалённого хранилища | Объём файла и контрольная сумма в норме, архив распаковывается |
| 2. Развернуть среду восстановления | Временный поддомен или локальная среда | Программа запускается, ошибок окружения нет |
| 3. Импорт и восстановление | Восстановить базу данных и все файлы | Вход в админку и на сайт работает |
| 4. Выборочная проверка функций | Отправить форму, открыть страницу товара, проверить загрузку изображений | Все ключевые функции работают |
| 5. Сверка данных | Сверить содержимое и число заявок с записями до учебного восстановления | Данные не потеряны |
Рекомендуемая частота: полное учебное восстановление — раз в полгода, в период низкой нагрузки; выборочное восстановление одного файла — раз в квартал, случайная статья или изображение для проверки. В результатах фиксируйте две вещи: общее время и этап, на котором застряли. Именно этот этап — главный риск при реальной аварии. Решайте проблему сразу, не оставляйте на ночь аварии.
| Размер сайта | Объём данных | Время полного восстановления |
|---|---|---|
| Небольшой корпоративный сайт | База данных меньше 200 МБ | 30–60 минут |
| Средний сайт | От 200 МБ до 2 ГБ | 60–120 минут |
| Сайт с большим числом изображений и заказов | Больше 2 ГБ | Порядка половины дня |
Заранее подготовьте замену на время восстановления: статическую страницу-заглушку по пути обслуживания с указанием ожидаемого времени восстановления и запасных контактов (резервная почта или аккаунт WhatsApp), а на основном домене повесьте временное объявление. Смысл этой страницы не технический, а в том, чтобы клиент, который сейчас зашёл, знал: вы не исчезли и с вами можно связаться другим способом. Если нужен проект резервного копирования и восстановления под ваш сайт, напишите нам —связаться с нами опишите текущую ситуацию.
VII. Безопасность самих резервных копий и четыре момента, когда нужно делать копию вручную
Резервная копия содержит весь контент, клиентские заявки и базу данных — это чувствительные данные, и их утечка тоже авария.
| Что проверить | Требование | Периодичность проверки |
|---|---|---|
| Шифрование хранилища | Резервные копии хранятся с шифрованием на стороне сервера или в зашифрованном архиве | Проверять при смене хранилища |
| Права доступа | Минимальные права, удаление — с повторным подтверждением | Ежеквартально |
| Двухфакторная аутентификация | Обязательна для аккаунта хранилища резервных копий | Один раз, проверять при смене аккаунта |
| Оповещение о сбое задачи | Уведомление о сбое резервного копирования приходит конкретному человеку | Проверять раз в месяц после настройки |
Кроме регулярного графика есть четыре момента, когда нужно сразу делать копию вручную, не дожидаясь следующей задачи по расписанию.
| Когда нужно делать копию вручную | Причина |
|---|---|
| Перед крупным обновлением версии программы | Сбои при обновлении случаются чаще всего, нужна чёткая точка отката |
| Перед сменой темы или запуском новых функций | Изменения перезапишут файлы, для отката нужен полный снимок |
| Перед массовым изменением контента или импортом данных | Массовые операции нельзя отменить по одной — ошибка сразу во всём |
| Перед переносом на другой хостинг | Несогласованность данных при переносе требует полной страховки |
Все четыре ситуации объединяет одно: действие нельзя отменить. Регулярное резервное копирование закрывает повседневные риски, ручной снимок — риски человеческой ошибки, и одно не заменяет другое. В команде стоит договориться: кто запускает обновление или редизайн, тот первым нажимает кнопку снимка — это первый шаг процесса, а не опция. О полной связке для переезда читайте в разделе Переезд и передача 301 в этой статье.
FAQ: частые вопросы
В заключение
Бэкап — самая контринтуитивная инвестиция: в обычной жизни её ценность не видна, а в момент аварии именно она определяет потолок потерь. Сложных технологий тут не нужно — нужно, чтобы три вещи происходили вовремя: ритм не сбивался, копии действительно лежали в другом месте, восстановление действительно было отработано. Уберите любую из трёх — и сколько бы записей о бэкапах ни было, это лишь успокоение для себя.
Порядок внедрения предлагаем такой: сначала разместите бэкапы в другом аккаунте и другом регионе, затем проверьте, все ли четыре типа объектов резервного копирования охвачены, и в конце поставьте в календарь учебное восстановление раз в полгода и записывайте, сколько времени оно занимает. После этих трёх шагов большинство историй «случилась авария, а спасти нечем» можно предотвратить.Достаточно запомнить одну фразу: бэкап, который не проверяли восстановлением, — это не бэкап.