«У нас же есть бэкапы» — эту фразу мы слышим почти от каждого клиента, который обращается к нам после аварии. А затем выясняется, что копии хранились на том же сервере, что и сайт, и исчезли вместе с ним. Или что копировались только файлы без базы данных. Или что последняя удачная копия была создана полгода назад, а потом скрипт тихо перестал работать. Резервное копирование кажется простой темой, но именно в ней чаще всего кроются фатальные ошибки. Ниже — правила, которые мы выработали на сотнях проектов и которые реально спасали сайты наших клиентов.
Правило первое: копия — это файлы плюс база данных
Современный сайт на CMS состоит из двух независимых частей. Файлы — это ядро системы, тема оформления, плагины, загруженные изображения и документы. База данных — это тексты страниц, настройки, пользователи, заказы, комментарии. Одно без другого бесполезно: файлы без базы дадут пустой каркас, а база без файлов — набор записей, которым негде отображаться.
Отдельное внимание стоит уделить конфигурационным файлам сервера и настройкам, которые хранятся вне папки сайта: правилам перенаправлений, параметрам кеширования, заданиям планировщика. Их часто забывают, а после восстановления сайт вроде бы открывается, но работает не так, как раньше.
- Файлы сайта целиком, включая скрытые служебные файлы.
- Полный дамп базы данных со всеми таблицами, а не только с таблицами CMS.
- Конфигурация веб-сервера и PHP, если вы управляете ими сами.
- Список заданий планировщика и сведения о внешних интеграциях.
- Документ с доступами и описанием, как всё это собрать обратно.
Правило второе: «три — два — один»
Классический принцип надёжного хранения данных звучит так: три копии, на двух разных типах носителей, одна из которых находится в другом месте. Применительно к сайтам мы трактуем его следующим образом.
- Рабочая версия на основном хостинге — это первая «копия».
- Локальный бэкап средствами хостинга или панели управления — быстро восстановить после неудачного обновления.
- Внешний бэкап в независимом облачном хранилище или на сервере другого провайдера — на случай, если пострадал сам хостинг, аккаунт заблокирован или взломан.
Внешняя копия — самая важная. Если злоумышленник получил доступ к панели хостинга, он может удалить и сайт, и все локальные копии. Если хостинг-провайдер прекратил работу или у вас возник спор с ним, доступ к локальным бэкапам тоже окажется закрыт. Копия у независимого провайдера — единственное, что останется в вашем распоряжении.
Совет от студии: доступ к внешнему хранилищу бэкапов не должен совпадать с доступом к хостингу. Отдельный логин, отдельный пароль, по возможности — двухфакторная авторизация. Тогда компрометация одного аккаунта не уничтожит всё сразу.
Правило третье: частота определяется ценой потери
Как часто делать копии? Правильный вопрос звучит иначе: сколько данных вы готовы потерять? Если сайт обновляется раз в месяц, еженедельной копии более чем достаточно. Если это интернет-магазин, где за день оформляются десятки заказов, потеря даже суток означает потерянные заказы, клиентов без подтверждений и путаницу в складском учёте.
| Тип проекта | Файлы | База данных | Сколько хранить |
|---|---|---|---|
| Лендинг, сайт-визитка | Раз в неделю | Раз в неделю | 4–8 копий |
| Корпоративный сайт с блогом | Раз в неделю | Ежедневно | 14–30 копий |
| Интернет-магазин | Ежедневно | Несколько раз в день | 30 дней и ежемесячные архивы |
| Сайт с личными кабинетами | Ежедневно | Каждый час или чаще | По требованиям бизнеса |
Обратите внимание на глубину хранения. Одна свежая копия не спасёт, если вирус попал на сайт три недели назад и всё это время тихо копировался в бэкапы. Поэтому важно иметь «лесенку»: ежедневные копии за последние недели плюс еженедельные и ежемесячные за более длительный период.
Правило четвёртое: непроверенная копия не существует
Это самое недооценённое правило. Резервное копирование — это не процесс создания архивов, а процесс, гарантирующий восстановление. И проверить эту гарантию можно только одним способом — регулярно восстанавливать сайт из копии на тестовой площадке.
Что может пойти не так, если не проверять:
- Архив создаётся, но обрывается на середине из-за ограничения времени выполнения скрипта.
- Дамп базы сохраняется в неправильной кодировке, и после восстановления весь текст превращается в нечитаемые символы.
- Плагин резервного копирования исключает «тяжёлую» папку с загрузками, чтобы уложиться в лимит, и фотографии товаров не попадают в копию.
- Хранилище переполнилось, и новые копии перестали записываться — без всяких уведомлений.
- Пароль к зашифрованному архиву никто не помнит.
Мы в студии раз в месяц или квартал (в зависимости от тарифа) разворачиваем случайно выбранную копию клиентского сайта на тестовом сервере и проходим ключевые сценарии: главная, каталог, карточка, форма заявки, вход в админку. Только после этого копия считается рабочей.
Правило пятое: копия перед каждым рискованным действием
Помимо регулярного расписания, существуют моменты, когда внеплановая копия обязательна. Это обновление ядра CMS или крупных плагинов, смена темы оформления, массовый импорт товаров, изменение структуры URL, переход на новую версию PHP, перенос на другой хостинг, любые правки в базе данных напрямую.
Даже если автоматический бэкап был сделан ночью, за день на сайте могли появиться новые заказы или заявки. Копия «здесь и сейчас» перед изменениями позволяет откатиться за минуты, не теряя свежих данных. Это привычка, которая отличает аккуратного администратора от того, кто «надеется, что пронесёт».
Как организовать бэкапы на практике
Существует несколько уровней, на которых можно настроить резервное копирование, и у каждого свои сильные и слабые стороны.
Средствами хостинга
Большинство провайдеров делают копии автоматически. Это удобно и не нагружает сайт, но копии хранятся у того же провайдера, глубина хранения ограничена, а восстановление иногда возможно только через заявку в поддержку.
Плагинами CMS
Гибкие настройки расписания и возможность отправлять архивы во внешнее облако. Минус — плагин работает внутри сайта: если сайт взломан или не запускается, плагин тоже недоступен. Кроме того, на больших сайтах создание архива средствами PHP может упираться в лимиты хостинга.
Серверными скриптами
Самый надёжный вариант для VPS и выделенных серверов: копирование по расписанию системными средствами с передачей на удалённое хранилище. Требует квалификации для настройки и контроля, зато не зависит от состояния самого сайта.
Оптимально сочетать минимум два уровня. Например, автоматические копии хостинга для быстрого отката плюс серверный или плагинный бэкап во внешнее хранилище для катастрофических сценариев. Именно такую схему мы настраиваем клиентам в рамках услуги администрирования.
Безопасность самих резервных копий
Бэкап содержит всё: пароли к базе данных, личные данные клиентов, историю заказов. Утечка архива равносильна утечке всего сайта. Поэтому копии нужно защищать не хуже, чем сам проект.
- Никогда не храните архивы в публично доступной папке сайта — их легко найти и скачать по типовым именам.
- Шифруйте архивы, если они передаются во внешнее хранилище.
- Ограничьте круг людей, имеющих доступ к хранилищу.
- Удаляйте устаревшие копии по расписанию, а не храните их бессрочно.
- Учитывайте требования к хранению персональных данных — бэкап тоже является местом их обработки.
Вывод: бэкап — это процесс, а не галочка
Надёжное резервное копирование складывается из нескольких простых, но обязательных правил: копировать и файлы, и базу; хранить минимум одну копию вне основного хостинга; выбирать частоту исходя из цены потери данных; регулярно проверять восстановление; делать внеплановую копию перед любыми рискованными изменениями и защищать сами архивы. Если хотя бы одно правило нарушено, система бэкапов может подвести в самый важный момент. Хотите проверить, насколько защищён ваш сайт? Мы проведём аудит текущей схемы копирования и, если нужно, настроим надёжную с нуля — напишите нам.
