Утром владелец интернет-магазина открывает сайт и вместо каталога видит ошибку. Ночью обновился плагин, что-то пошло не так, база повреждена, а разработчик предлагает восстановить вчерашнюю версию. Казалось бы, ничего страшного. На хостинге ведь есть резервные копии. Через несколько минут выясняется, что последняя копия была создана неделю назад. Или в архив попали только файлы, а базы данных там нет. Или копия хранится на том же сервере, который сейчас недоступен. Еще хуже, когда архив существует, но восстановить из него рабочий сайт не получается.
Именно в такой момент становится понятно, что резервная копия нужна не для того, чтобы в панели стояла зеленая галочка «бэкап создан». Ее единственная настоящая задача состоит в том, чтобы после сбоя вернуть проект в рабочее состояние с приемлемой потерей данных.
Поэтому хороший бэкап начинается не с кнопки «Создать архив», а с вопроса: что именно мы будем делать, если сайт исчезнет прямо сейчас?
Что нужно сохранять, чтобы действительно восстановить сайт
С обычным статическим сайтом все относительно просто. Если проект состоит из HTML, CSS, JavaScript, изображений и других файлов, их полная копия уже содержит большую часть необходимого.
С динамическим сайтом ситуация другая.
Возьмем WordPress. У него есть файлы ядра, темы, плагины, загруженные изображения, конфигурация и другие файлы. Отдельно существует база данных MySQL или MariaDB, где находятся записи, страницы, комментарии, настройки и множество данных плагинов.
Официальная документация WordPress прямо разделяет резервное копирование на две части: файлы и базу данных. Простое скачивание каталога сайта обычно не копирует базу, потому что она хранится отдельно в системе управления базами данных. citeturn0search0turn0search2
И обратная ситуация тоже опасна. Экспорт базы не содержит загруженные фотографии, файлы темы и плагины. WordPress рекомендует рассматривать файлы и базу как единый комплект резервной копии, созданный примерно в одно время. citeturn0search2
Для интернет-магазина к этому нужно относиться особенно внимательно. Между копированием файлов и базы могут появиться новые заказы, измениться остатки или зарегистрироваться покупатель.
Кроме самого сайта иногда нужно сохранять и окружение: конфигурацию веб-сервера, задания cron, параметры PHP, правила межсетевого экрана, контейнеры, переменные окружения, конфигурацию почтовых сервисов. На обычном виртуальном хостинге значительной частью этого управляет провайдер. На собственном VPS ответственность уже лежит на администраторе.
Копия на том же сервере спасает далеко не от всего
Представим простой скрипт. Каждую ночь он упаковывает сайт в архив и складывает его в каталог /backup на том же VPS.
От случайного удаления одного файла такая схема может спасти.
От потери всего сервера она не спасет.
Если повредится файловая система, будет удалена виртуальная машина, злоумышленник получит административный доступ или возникнет серьезная проблема у поставщика инфраструктуры, рабочие данные и все резервные копии могут исчезнуть одновременно.
Именно поэтому резервирование строят так, чтобы одна авария не уничтожала все версии данных.
Классическое правило 3-2-1 формулируется просто: иметь три копии важных данных, использовать два разных типа носителей и хранить одну копию вне основной площадки. Такой подход описывает и американское агентство CISA в рекомендациях по резервному копированию. citeturn0search36
Для сайта это правило не обязательно нужно понимать буквально как три жестких диска разных производителей.
Практическая идея важнее цифр. Рабочий сайт находится на сервере. Автоматическая резервная копия может храниться в инфраструктуре хостинга. Еще одна независимая копия отправляется в другое хранилище или периодически скачивается владельцем.
Если одна система перестанет быть доступна, останется другая.
Официальная документация WordPress в актуальной редакции также рекомендует держать несколько последних копий в разных местах и приводит в качестве примера хостинг, облачное хранилище и локальный компьютер. citeturn0search2
Резервные копии хостинга полезны, но я бы не делала их единственной защитой
Хороший хостинг может автоматически создавать копии сайта и базы, хранить несколько версий и позволять восстановить проект прямо из панели.
Для владельца небольшого сайта это прекрасная функция.
Но сначала стоит узнать условия, а не просто увидеть слово «бэкапы» в описании тарифа.
Как часто создаются копии? Сколько дней они хранятся? Копируется ли база данных? Можно ли скачать архив себе? Восстановление выполняется самостоятельно или только через поддержку? Есть ли дополнительная плата? Где физически или логически хранятся копии относительно основной инфраструктуры?
Особенно важна возможность получить резервную копию независимо от работающего сайта.
WordPress в своей документации отмечает, что многие хостинги создают серверные копии, но владельцу все равно полезно иметь собственное резервирование файлов. citeturn0search0
Причина не в недоверии к хостеру. Просто разные копии защищают от разных событий.
Резервная система провайдера прекрасно помогает после неудачного обновления. Независимая копия становится особенно ценной, если проблема затрагивает учетную запись, саму площадку или доступ к панели.
Как часто делать резервную копию
Универсального ответа «раз в сутки» нет.
Частота зависит не от типа хостинга, а от того, сколько данных вы готовы потерять.
Информационный сайт обновляется два раза в месяц. Если вчерашняя копия отсутствует, а последняя сделана три дня назад, возможно, вообще ничего ценного не потеряно.
Новостной проект публикует десятки материалов ежедневно. Интернет-магазин получает заказы каждый час. Форум постоянно пополняется сообщениями. Для них недельный бэкап почти бесполезен.
Удобно мыслить не расписанием, а допустимой потерей.
Если бизнес может пережить потерю данных за сутки, ежедневная копия может быть достаточной. Если потеря часа заказов уже болезненна, резервирование базы нужно делать чаще или использовать более продвинутые механизмы восстановления.
Официальная документация WordPress приводит ориентир: для небольших малоактивных сайтов резервирование может выполняться еженедельно, а для активно обновляемых сайтов рекомендуется ежедневный режим. При этом сама документация подчеркивает, что частота зависит от активности проекта и допустимой потери информации. citeturn0search2
Есть еще одно правило, которое полезнее любого расписания: создавайте резервную копию перед рискованным изменением.
Обновляете WordPress, тему или важный плагин? Меняете структуру базы? Переносите сайт? Обновляете PHP? Вносите крупную правку в код?
Сначала копия, потом эксперимент.
WordPress отдельно рекомендует резервировать базу перед обновлениями. citeturn0search1
Сколько старых копий хранить
Если каждую ночь создавать новый архив и сразу удалять вчерашний, у вас всегда будет только одна точка восстановления.
Представим, что сайт взломали пять дней назад, но вредоносный код заметили сегодня. Все это время автоматический скрипт исправно копировал уже зараженный сайт.
Одна последняя копия не поможет.
Поэтому нужны версии за разные даты.
Для небольшого проекта разумная схема может выглядеть так: несколько ежедневных копий, несколько недельных и одна или несколько более старых контрольных версий. Точный срок зависит от объема данных, стоимости хранения и того, насколько быстро обычно обнаруживаются проблемы.
Необязательно хранить каждый ежедневный архив годами. Можно использовать ротацию.
Например, семь ежедневных копий, четыре недельных и несколько месячных. Это не универсальный стандарт, а понятный пример того, как получить несколько точек восстановления без бесконечного роста хранилища.
Для интернет-магазина правила будут строже. Для сайта-визитки можно проще.
Главное, чтобы ошибка, обнаруженная не в день ее появления, не уничтожала все шансы на восстановление.
Снимок виртуального сервера очень удобен, но это еще не вся стратегия
На VPS и облачных платформах часто можно сделать снимок диска или всей виртуальной машины.
Перед крупным обновлением это великолепный инструмент. Сделали снимок, обновили систему, обнаружили серьезную проблему и вернули прежнее состояние.
Но снимок и полноценная стратегия резервного копирования решают не полностью одинаковые задачи.
Снимок может находиться в той же учетной записи и инфраструктуре. При ошибочном удалении ресурсов, компрометации аккаунта или проблеме самой площадки вместе с сервером могут оказаться недоступны и связанные с ним снимки.
Есть и вопрос согласованности данных. Если снимок делается на работающем сервере в момент активной записи в базу, нужно понимать возможности конкретной платформы и приложения. Снимок диска фиксирует состояние хранилища, но это не всегда то же самое, что корректный логический экспорт базы.
Поэтому снимок удобен как дополнительный быстрый уровень восстановления, особенно перед изменениями. Независимую резервную копию он не отменяет.
WordPress требует копировать не только uploads
Иногда встречается совет: достаточно сохранить wp-content/uploads и экспорт базы, потому что WordPress, тему и плагины всегда можно скачать заново.
Для простого стандартного сайта такая минимальная схема действительно сохраняет значительную часть уникальных данных. Но полагаться на нее как на универсальную я бы не стала.
В wp-content находятся не только изображения. Там могут быть темы, дочерние темы, плагины, кэш и другие данные. В корне находится wp-config.php с настройками подключения и дополнительными параметрами. Могут существовать собственные PHP-файлы, правила .htaccess и нестандартные компоненты.
Официальная документация WordPress рекомендует резервировать файлы каталога сайта и отдельно обращает внимание на wp-content и wp-config.php. citeturn0search0
Если вы точно знаете архитектуру проекта, можно построить более экономную схему и не копировать каждый раз то, что легко воспроизводится из исходного кода.
Но для владельца обычного WordPress безопаснее иметь возможность восстановить сайт целиком, а не вспоминать после аварии, какая версия платной темы использовалась три года назад и где лежит измененный вручную файл.
Автоматический бэкап должен работать без вашего участия
Ручное резервное копирование хорошо перед важным изменением. В качестве основной ежедневной защиты оно ненадежно по одной простой причине: человек забывает.
Первые две недели владелец дисциплинированно скачивает архив каждую пятницу. Потом отпуск, срочный проект, праздники, и внезапно оказывается, что последняя копия сделана четыре месяца назад.
Поэтому регулярное резервирование нужно автоматизировать.
На виртуальном хостинге это может делать панель провайдера или специальный механизм CMS. На VPS используются системные задания, программы резервного копирования, средства панели управления или инструменты облачной платформы.
Но автоматизация создает новую проблему: сбой тоже становится автоматическим.
Скрипт может месяцами завершаться с ошибкой. Хранилище переполнилось. Изменился пароль. Закончился токен доступа. Плагин перестал работать после обновления. Архив создается размером ноль байт.
Поэтому система должна не только запускать задание, но и сообщать о результате. А владелец или администратор должен периодически проверять, что свежие копии действительно появляются.
WordPress рекомендует время от времени дополнять автоматические копии ручной проверкой, чтобы убедиться, что процесс работает. citeturn0search2
Копия, которую никто не пробовал восстановить, еще не доказала свою полезность
Это, пожалуй, самая недооцененная часть резервного копирования.
Архив существует. Размер выглядит правдоподобно. Дата сегодняшняя. Значит все хорошо?
Не обязательно.
В архиве может отсутствовать база. SQL-файл может оказаться поврежден. Файлы скопировались не полностью. Пароль шифрования утерян. Для восстановления требуется доступ, которого больше нет. Процедура восстановления занимает восемь часов, хотя бизнес рассчитывает вернуться в работу за тридцать минут.
Узнавать это после аварии поздно.
Поэтому резервные копии нужно тестировать.
Для небольшого сайта можно периодически восстановить копию на тестовом домене или локальном окружении и проверить главные страницы, административную часть и работу базы.
Для интернет-магазина проверка должна быть глубже: каталог, изображения, авторизация, заказы, настройки, интеграции и другие критичные функции.
Тест восстановления отвечает сразу на два вопроса. Данные действительно сохранены? И умеем ли мы вернуть их достаточно быстро?
Второй вопрос иногда оказывается даже важнее первого.
Резервная копия после взлома требует осторожности
Сайт заражен, и хочется просто откатиться на вчера.
Это может сработать, если точно известно, когда произошел взлом и каким способом злоумышленник попал внутрь.
Но если причина не устранена, восстановленный сайт могут взломать снова через несколько минут.
Кроме того, вредоносный код мог находиться в проекте задолго до того, как его заметили. Тогда вчерашняя копия уже заражена.
После инцидента нужно определить точку компрометации, закрыть уязвимость, сменить скомпрометированные учетные данные и только затем возвращать чистые данные.
Именно здесь несколько исторических копий намного полезнее одной последней.
Для важного проекта также стоит подумать о защите самих бэкапов от изменения и удаления. Если злоумышленник получил полный доступ к серверу, обычный подключенный каталог с резервными архивами он способен удалить вместе с рабочими файлами.
Независимое хранилище и отдельные учетные данные уменьшают этот риск.
Нужно ли шифровать резервные копии
В резервном архиве может находиться намного больше чувствительной информации, чем кажется.
База интернет-магазина содержит данные клиентов и заказов. Конфигурационные файлы могут содержать пароли базы, ключи API и другие секреты. Архив корпоративного сайта иногда включает внутренние документы.
Если копия отправляется во внешнее хранилище или переносится на физическом носителе, вопрос защиты данных становится особенно важным.
Шифрование резервных копий полезно, но создает ответственность за ключ.
Потеряли ключ или пароль, и идеальный архив превращается в набор недоступных байтов.
Поэтому секрет для расшифровки нельзя хранить только внутри того же сервера, который резервируется. Для бизнеса нужен понятный порядок хранения и передачи ключей ответственным людям.
Защищать следует и канал передачи. Например, официальные учебные материалы WordPress рекомендуют при ручном переносе файлов использовать SFTP вместо обычного FTP, чтобы учетные данные не передавались по сети открытым способом. citeturn0search3
Простая схема резервирования для обычного сайта
Не каждому проекту нужна сложная корпоративная система.
Для небольшого WordPress-сайта я бы начала с автоматической ежедневной копии базы и файлов средствами хостинга, если такая услуга надежно предоставляется.
Хранила бы несколько последних версий, а не только одну.
Дополнительно настроила бы регулярную независимую копию в другое хранилище. Не обязательно каждую версию держать бесконечно, но хотя бы одна актуальная копия должна пережить потерю основной площадки.
Перед обновлением WordPress, темы, плагинов или серьезной правкой создавала бы дополнительную контрольную копию.
Раз в некоторое время проверяла бы восстановление на тестовой площадке.
И обязательно записала бы короткую инструкцию: где находятся резервные копии, как получить к ним доступ и что делать для восстановления.
Последний пункт кажется лишним, пока сайтом занимается один человек. Через два года пароль хранится неизвестно где, разработчик сменился, а владелец помнит только, что «где-то все копировалось автоматически».
Для интернет-магазина схема должна быть строже
Магазин отличается от обычного информационного сайта тем, что данные меняются постоянно.
Если восстановить вчерашнюю копию блога, можно потерять одну новую статью.
Если восстановить вчерашнюю копию магазина, можно потерять заказы, изменения статусов, регистрации клиентов и сведения об остатках.
Поэтому для базы данных магазина часто требуется более частое резервирование и продуманная процедура восстановления.
Нужно заранее решить, что произойдет с заказами, созданными между последней копией и аварией. Есть ли возможность получить их из внешней платежной системы, CRM или почтовых уведомлений? Как будут синхронизироваться остатки?
Для крупных проектов применяют журналы транзакций, репликацию и другие механизмы, позволяющие уменьшить потерю данных. Это уже выходит за рамки обычного «скачать архив раз в день».
Но принцип остается тем же: частота копирования должна соответствовать реальной цене потерянного промежутка.
Сколько места понадобится под резервные копии
Если сайт занимает 20 ГБ, это не означает, что семь ежедневных копий обязательно займут 140 ГБ.
Современные системы могут использовать инкрементное или дедуплицированное хранение, когда после первой полной копии сохраняются только изменения или одинаковые блоки не дублируются.
Но конкретная экономия зависит от типа данных.
База данных и текстовые файлы хорошо сжимаются. Уже сжатые JPEG, видео и архивы обычно уменьшаются намного хуже.
При выборе хранилища нужно учитывать не только его объем, но и стоимость восстановления. У некоторых облачных сервисов хранение дешево, а получение большого объема данных или операции тарифицируются отдельно.
Для маленького сайта разница копеечная. Для десятков терабайт она становится частью бюджета.
Что проверить у хостинга до того, как случится авария
Откройте описание своего тарифа сегодня, а не после сбоя.
Узнайте периодичность резервного копирования и срок хранения версий. Проверьте, входят ли базы данных. Посмотрите, можете ли вы скачать копию самостоятельно. Выясните, сколько занимает восстановление и можно ли вернуть отдельный файл или только весь аккаунт целиком.
Затем представьте худший реалистичный сценарий.
Если завтра вы потеряете доступ к текущему хостингу, существует ли у вас копия, из которой сайт можно поднять в другом месте?
Если ответ «нет», резервирование зависит от одной площадки сильнее, чем кажется.
Если копия есть, следующий вопрос: когда вы последний раз проверяли, что она восстанавливается?
Именно эти два вопроса намного лучше рекламной фразы «ежедневные бэкапы» показывают реальную защищенность проекта.
Резервное копирование нужно проектировать от восстановления
Можно купить терабайты хранилища, поставить несколько плагинов и каждый час создавать архивы. Но если никто не знает, как из них вернуть работающий сайт, система не выполняет свою главную задачу.
Начните с результата.
Сколько данных допустимо потерять? За какое время сайт должен вернуться в работу? Кто будет выполнять восстановление? Где находится копия, если основная площадка полностью недоступна?
Ответы определят частоту, количество версий и место хранения намного точнее универсальных советов.
Для небольшого сайта решение может быть очень простым: ежедневные копии хостинга, независимый архив в другом месте, несколько исторических версий и периодическая проверка восстановления.
Для интернет-магазина или сервиса требования будут значительно строже.
Но одно правило одинаково для всех.
Не считайте резервной копией то, что существует только рядом с оригиналом и никогда не проверялось восстановлением.
Хороший бэкап незаметен почти все время. А в тот единственный день, когда он действительно понадобится, его ценность может оказаться выше стоимости самого хостинга за многие годы.
