Резервное копирование: как не потерять сайт

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

Почему копии нужны каждому сайту

Распространённое убеждение звучит так: «У нас хороший хостинг, он же делает копии». Отчасти это правда, но полагаться на неё опасно. Копии хостинг-провайдера создаются для защиты его собственной инфраструктуры, а не ваших интересов. Они могут храниться недолго, хранить только часть данных или восстанавливаться по запросу в течение нескольких дней. А в договоре обычно прямо написано, что ответственность за сохранность информации лежит на клиенте.

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

Что именно нужно копировать

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

Файлы

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

База данных

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

О чём забывают

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

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

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

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

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

Правило трёх копий

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

1. Рабочая версия на основном сервере — это не копия, а оригинал.
2. Копия на том же сервере или в хранилище того же провайдера — для быстрого отката.
3. Копия в удалённом хранилище у другого поставщика — на случай, если пострадал сам провайдер или была взломана вся учётная запись.

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

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

Срок хранения и ротация

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

Разумная схема ротации называется «дед, отец, сын». Ежедневные копии хранятся неделю или две, еженедельные — месяц, ежемесячные — несколько месяцев. Так вы получаете возможность откатиться и на вчерашнее состояние, и на состояние до давней проблемы, не занимая лишнего места.

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

Автоматизация и контроль

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

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

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

Проверка восстановления: самая важная часть

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

Регулярно, хотя бы раз в квартал, проводите учебное восстановление.

1. Разверните копию на отдельной тестовой площадке, а не на боевом сервере.
2. Проверьте, что сайт открывается, работает вход в панель управления, отправляются формы.
3. Убедитесь, что в базе присутствуют самые свежие записи, а изображения отображаются.
4. Засеките, сколько времени заняло восстановление, и сравните с допустимым.
5. Запишите найденные проблемы и исправьте процесс.

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

Что делать, когда случилась авария

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

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

Копии перед рискованными действиями

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

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

Тестовая площадка как страховка

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

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

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

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

Вывод

Резервное копирование — это не разовая настройка, а непрерывный процесс: определить, что и как часто копировать, хранить копии отдельно от сайта, шифровать их и регулярно проверять восстановление. Затраты на это несоизмеримо малы по сравнению с ценой потерянной базы заказов или недели простоя. Специалисты студии «Фрилансеры» настроят автоматическую схему копирования под ваш проект, организуют удалённое хранение и будут регулярно проверять, что в нужный день сайт действительно удастся поднять.