Про резервные копии вспоминают в худший момент: сайт взломали, обновление сломало страницу, сотрудник случайно удалил раздел, хостинг закрыл аккаунт за неоплату. Если копия есть и из неё можно восстановиться, это неприятный эпизод на несколько часов. Если копии нет или она не работает, сайт приходится собирать заново. В статье разберём, что именно копировать, где хранить копии, как часто их делать и, главное, как проверить, что из них действительно можно восстановить сайт.
Из чего состоит сайт и что нужно копировать
Почти любой сайт на системе управления состоит из двух частей, и копировать нужно обе.
- Файлы. Код движка, шаблоны, модули и плагины, загруженные картинки и документы, файлы настроек. Картинки и документы обычно занимают больше всего места.
- База данных. Тексты страниц, статьи, товары, заявки, пользователи, настройки. Без базы файлы сайта бесполезны: страница откроется пустой или с ошибкой.
Частая ошибка: копируют только файлы через FTP, а про базу забывают. Или наоборот, хостинг хранит копию базы, а загруженные фотографии за пять лет нигде больше не лежат.
Кроме самого сайта, полезно хранить отдельно:
- список доступов: где хостинг, где домен, кто владелец аккаунтов (сами пароли храните в менеджере паролей, а не в документе);
- настройки, которые живут вне сайта: записи DNS у регистратора домена, почта на домене, настройки форм и интеграций с CRM;
- исходники дизайна и текстов, если они есть.
Правило трёх копий
Простой и надёжный принцип, который используют и в крупных компаниях: три копии данных, на двух разных носителях, одна из них в другом месте. Для сайта малого бизнеса это выглядит так:
- Рабочий сайт на хостинге.
- Автоматические копии хостинга. Большинство хостингов делают их сами и хранят определённое количество дней. Узнайте в панели или у поддержки, как часто делаются копии, сколько хранятся и как из них восстановиться.
- Своя копия вне хостинга. Архив файлов и базы на облачном диске, компьютере или у другого провайдера. Она спасает, если проблема с самим хостингом или с аккаунтом.
Копия, которая лежит в той же папке на том же сервере, что и сайт, это не резервная копия. При взломе или удалении аккаунта пропадёт вместе с сайтом.
Как часто делать копии
Частота зависит от того, как часто меняется сайт и сколько данных вы готовы потерять.
| Тип сайта | Разумная частота |
|---|---|
| Сайт-визитка, который редко меняется | Перед каждым изменением и раз в неделю или месяц автоматически |
| Корпоративный сайт с новостями и статьями | Ежедневно база, раз в неделю файлы |
| Интернет-магазин, сайт с заказами и личным кабинетом | Ежедневно, а базу чаще, если заказов много |
Отдельное правило без исключений: копия перед любым заметным изменением. Обновление движка или плагинов, установка нового модуля, перенос на другой хостинг, массовая правка товаров, смена дизайна. О том, как безопасно переезжать, есть статья «Как перенести сайт и не потерять позиции в поиске».
Сколько копий хранить
Хранить только последнюю копию опасно. Если сайт взломали незаметно, а заметили через две недели, все свежие копии уже будут заражены. Поэтому храните несколько поколений, например:
- ежедневные за последнюю неделю;
- еженедельные за последний месяц;
- ежемесячные за последние несколько месяцев.
Так можно вернуться в состояние «до проблемы», даже если её обнаружили поздно. Признаки взлома и первые действия описаны в статье «Признаки взлома сайта и что делать, если сайт взломали».
Как настроить: три варианта
Копии хостинга
Самый простой вариант. В панели хостинга обычно есть раздел резервного копирования: там видно список копий по датам и кнопка восстановления файлов или базы. Проверьте три вещи: копируются ли и файлы, и база; сколько дней хранятся копии; можно ли скачать копию себе. Если копирование на тарифе платное или отключено, это стоит знать заранее.
Плагин или модуль в системе управления
Для популярных движков есть модули резервного копирования, которые по расписанию отправляют архив в облачное хранилище. Удобно, но есть оговорки: модуль работает внутри сайта, и если сайт сломан или взломан, копирование может остановиться без предупреждения. Поэтому настройте уведомления об ошибках и раз в месяц смотрите, приходят ли свежие архивы.
Копирование силами подрядчика
Если сайт на поддержке, резервные копии входят в базовые обязанности. Уточните у подрядчика: где хранятся копии, как часто делаются, сколько поколений хранится и когда последний раз проверялось восстановление. Хороший ответ звучит конкретно. Ответ «у хостинга всё есть» означает, что своей копии нет. Что ещё входит в поддержку, рассказали в статье «Техническая поддержка сайта: что входит и зачем она бизнесу».
Главное: проверка восстановления
Копия, из которой ни разу не пробовали восстановиться, это надежда, а не защита. Бывает, что архив неполный, база выгрузилась с ошибкой кодировки и вместо русских букв знаки вопроса, файлы есть, а пароля к архиву никто не помнит. Узнавать это в день аварии поздно.
Как проверить, не трогая рабочий сайт:
- Возьмите последнюю копию файлов и базы.
- Разверните её в отдельном месте: на тестовом поддомене, в отдельной папке на хостинге или на локальном компьютере разработчика. Рабочий сайт при этом не трогается.
- Откройте восстановленную копию и пройдите по важным страницам: главная, услуги, каталог, контакты.
- Проверьте русские буквы в текстах, картинки, вход в админку, последние статьи и товары.
- Сравните дату самых свежих данных с датой копии: например, последняя заявка или последний заказ.
- Запишите, сколько времени занял процесс и какие были трудности. Это и есть ваш план восстановления.
- Удалите тестовую копию или закройте её от посторонних и от поисковиков, чтобы не появился дубль сайта.
Делайте такую проверку раз в несколько месяцев и после смены хостинга или способа копирования.
Безопасность самих копий
В резервной копии лежит всё: база с заявками и персональными данными клиентов, пароли к почте в файлах настроек, доступ к базе. Поэтому:
- не храните архивы в общедоступной папке сайта, откуда их можно скачать по прямой ссылке;
- облачное хранилище защитите паролем и двухфакторным входом;
- не пересылайте архивы по почте и в мессенджерах случайным людям;
- при расставании с подрядчиком уточните, где остались копии, и попросите их удалить или передать вам.
Про хранение данных клиентов и требования закона читайте в статье «Согласие на обработку персональных данных на сайте».
Короткий чек-лист
- Копируются и файлы, и база.
- Есть копия вне хостинга.
- Хранится несколько поколений копий.
- Перед каждым изменением делается свежая копия.
- Восстановление проверялось за последние несколько месяцев.
- Копии защищены и не лежат в открытом доступе.
- Вы знаете, кто и как восстановит сайт, если что-то случится.
Вопросы и ответы
Хостинг делает копии сам. Этого достаточно?
Для старта это лучше, чем ничего, но копии хостинга хранятся ограниченное время и находятся у того же провайдера. Если проблема с аккаунтом или с самим хостингом, они не помогут. Держите хотя бы одну свою копию в другом месте.
Можно ли сделать копию самому без программиста?
Часто да. В панели многих хостингов есть кнопки скачивания архива файлов и выгрузки базы. Сохраните оба файла в облачное хранилище. Проверить восстановление лучше вместе со специалистом.
Сколько места занимают копии?
Зависит в основном от количества картинок и документов. База данных у небольшого сайта обычно занимает немного. Если копии получаются огромными, имеет смысл проверить, нет ли на сайте лишних файлов: старых архивов, дублей фотографий, логов.
Что делать, если копии нет, а сайт сломался?
Не пытаться чинить наугад на рабочем сервере. Сначала сделать копию того, что есть, даже сломанного: это сохранит хотя бы данные. Затем обратиться к специалисту. Иногда помогают копии хостинга, о которых владелец не знал, или старые версии в архиве интернета для восстановления текстов.
Нужны ли копии, если сайт сделан на конструкторе?
Конструктор сам отвечает за хранение, но выгрузить сайт целиком часто нельзя. Сохраняйте у себя хотя бы тексты, картинки и список страниц, а также регулярно выгружайте заявки и заказы.
Нотикс настраивает резервное копирование файлов и базы с хранением вне хостинга и проверяет восстановление в рамках технической поддержки сайтов, в том числе сайтов, которые делали не мы.
