Как не потерять сайт вместе с хостингом: где хранить резервные копии
6 мин 9
Коротко
- Не рассчитывайте только на копии хостинга. Если недоступен сам провайдер, вместе с сайтом могут оказаться недоступны и резервные копии. Так произошло при сбое Beget 2 ноября 2026 года.
- Храните копии независимо друг от друга: у хостинга для быстрого восстановления и ещё у другого поставщика или на отдельном диске. Git сохраняет код, но не заменяет полноценную резервную копию сайта.
- Для небольшого сайта: базу данных копировать ежедневно, файлы – раз в неделю. Версии хранить не меньше 30 дней.
- Проверяйте восстановление. Раз в несколько месяцев разворачивайте копию в отдельной среде и убеждайтесь, что сайт действительно запускается.
- Минимальная безопасная схема – две независимые копии: одна у хостинга для быстрого отката, вторая вне его инфраструктуры на случай, если недоступен сам хостинг.
По состоянию на 2 ноября 2026 года. Цены облачного хранилища – по панели управления на эту дату, без учёта запросов и исходящего трафика.
Почему копий только на хостинге недостаточно
Обычная схема выглядит вполне надёжно: сайт работает на сервере, хостинг каждый день делает резервные копии, в панели доступны несколько последних версий. Что-то сломали при обновлении – выбрали вчерашнюю копию и вернули сайт. Для таких случаев копии хостинга действительно удобны.
Проблема начинается, когда недоступен не сайт, а сам хостинг.
2 ноября 2026 года у Beget произошёл крупный сбой: перестали открываться сайты, панель управления и личный кабинет. Компания сообщила, что проблема затронула все уровни инфраструктуры. В такой ситуации у владельца сайта может быть несколько исправных резервных копий – и ни одной возможности ими воспользоваться, пока провайдер не восстановит доступ.
То же самое может произойти при проблемах с сервером, аккаунтом или повреждении данных. Если рабочий сайт и все его копии находятся внутри одной системы, вы одновременно зависите от неё и как от места хранения сайта, и как от способа его восстановить.
Есть ещё один сценарий – взлом. Вредоносный код не всегда обнаруживают сразу. Он может находиться на сайте несколько дней или недель, пока хостинг продолжает исправно создавать ежедневные копии. Если заражение произошло десять дней назад, а резервные версии хранятся только семь дней, все доступные копии уже могут содержать тот же вредоносный код.
Поэтому вопрос не в том, делает ли хостинг резервные копии. Обычно делает.
Вопрос в другом: останется ли у вас доступная и чистая копия, если проблема затронет сам хостинг или обнаружится не сразу.
Копии у хостинга нужны для быстрых откатов. Но хотя бы одна актуальная версия сайта должна храниться независимо от него – у другого поставщика, в отдельном облачном хранилище или на собственном диске.
Хранить единственную запасную копию там же, где находится оригинал, – примерно как держать запасной ключ внутри квартиры.
Где хранить копии: четыре места
Сайт – это код, база данных (тексты, товары, заявки, клиенты) и загруженные файлы (картинки, документы). Копировать нужно все три части. Базу удобнее хранить отдельным архивом и снимать вместе с файлами на один момент, иначе после восстановления в базе будут ссылки на картинки, которых нет. Отдельно, в защищённом месте, держите настройки сервера и доступы к регистратору домена и DNS: без них сайт из копии не на что направить.
Надёжная схема – копии в нескольких местах, которые не зависят друг от друга. У каждого места своя задача.
| Где | Зачем | Что не спасает |
|---|---|---|
| На хостинге | Быстро восстановиться после неудачного обновления или случайно удалённых файлов | Сбой или блокировку самого хостинга |
| У другого поставщика (облачное хранилище) | Копии доступны, даже если основной хостинг лежит | Если доступ к хранилищу украден вместе с доступом к сайту |
| На компьютере или внешнем диске | Страховка на случай, когда недоступны и хостинг, и облако | Если диск постоянно подключён и его зашифрует вирус |
| История кода в Git | Видно, что изменилось в коде, можно вернуть прежнюю версию | Базу данных, заказы, заявки, загруженные файлы |
На хостинге
Копии хостинга нужны для быстрых откатов: обновление модуля сломало страницу, кто-то удалил папку с картинками. Восстановиться так быстрее всего. Перед обновлением 1С-Битрикс, модулей или массовой правкой каталога стоит сделать внеплановую копию: откатиться на неё проще, чем на ночную.
Но это только первый уровень защиты. Архив в папке /backup на том же сервере – не вторая копия, а та же точка отказа: сервер недоступен, и пропадают обе. Отдельное хранилище того же хостера надёжнее, но аккаунт, компания и её инфраструктура остаются общими с сайтом. Так же коротко хостинг хранит и журналы посещений – как забирать их к себе, рассказываю в гайде про access-логи.
На 1С-Битрикс встроенное копирование находится в административном разделе: Настройки → Инструменты → Резервное копирование, а расписание – в пункте Регулярное резервное копирование того же меню. Архив можно хранить на сервере или в облаке 1С-Битрикс.
У другого поставщика
Например, в российском облачном хранилище, которое работает по S3 – стандартному формату такого хранения. Если основной хостинг недоступен, копии остаются доступны независимо от него.
В российском облачном хранилище, которым пользуюсь я, стандартное хранение стоит 2,57 р. за гигабайт в месяц. Расчёт по тарифу: сайт с 5 ГБ файлов, в хранилище 4–5 недельных наборов – 20–25 ГБ, около 51–64 р. в месяц. Копии базы добавляют несколько рублей. Запросы и скачивание оплачиваются отдельно: загрузка копий стоит копейки (0,714 р. за 1000 запросов), а скачать при восстановлении набор 5 ГБ – около 7 р. (1,377 р. за гигабайт исходящего трафика).
Холодное хранение дешевле – от 1,25 р. за гигабайт, зато запросы и скачивание там дороже. Оно подходит для старых архивов, а не для копии, из которой восстанавливаются в первую очередь.
Хранилище стоит настроить так, чтобы копии нельзя было удалить или перезаписать раньше срока даже с вашим ключом доступа. Тогда взломщик, добравшийся до сервера, не сотрёт и их.
Так с ноября 2026 года устроены копии сайтов на моём сервере: базы уходят в облачное хранилище каждую ночь, файлы – по воскресеньям, удалить копию раньше 30 дней нельзя никому, а при сбое отправки мне приходит сообщение в MAX.
На компьютере или внешнем диске
Дополнительная страховка на случай, если хостинг и облако окажутся недоступны одновременно. Лучше отдельный зашифрованный диск, который не подключён к компьютеру постоянно: вредоносной программе сложнее добраться до копии, которой нет в системе.
История кода в Git
Git хранит историю кода: кто, что и когда менял, любую версию можно вернуть. Базы и загруженных файлов в нём нет, поэтому одного Git мало.
Как часто делать копии
Зависит от того, сколько данных вы готовы потерять при аварии. Если копия делается раз в сутки, в худшем случае пропадёт всё, что появилось на сайте за последние сутки.
| Тип сайта | База данных | Файлы | Сколько хранить |
|---|---|---|---|
| Корпоративный сайт, лендинг | Каждую ночь | Раз в неделю и после важных изменений | 30 дней |
| Интернет-магазин | Каждую ночь, а если заказов десятки в день – ещё и днём | Каждую ночь – только новые и изменённые | 30–60 дней |
| Крупный сервис | Непрерывно: журнал изменений позволяет вернуть базу на любую минуту, плюс копия на втором сервере в другом дата-центре | Каждый час или сразу при загрузке | 60–90 дней |
Для большинства небольших сайтов я рекомендую ежедневную копию базы, хранилище у другого поставщика и срок хранения не меньше 30 дней. Ошибку не всегда замечают сразу: после обновления перестала сохраняться часть заявок, и это обнаружили через неделю. Если хранятся только три последние ночные копии, во всех уже та же ошибка. Со взломом так же: свежие копии к моменту обнаружения тоже заражены, выручит копия месячной давности.
Копия есть. А сайт из неё восстановится?
Резервное копирование может месяцами работать без ошибок. Архивы создаются по расписанию, место на диске занято, в панели всё выглядит нормально.
А при первой серьёзной аварии выясняется, что восстановить сайт из этой копии нельзя.
Причины бывают вполне обычные: в архив не попала часть загруженных файлов, база сохранилась не полностью, пропущены важные настройки или сама копия оказалась повреждённой.
Поэтому наличие резервного архива ещё не означает, что сайт защищён.
Проверять нужно не только то, что копия создаётся, но и то, что из неё действительно можно развернуть рабочий сайт.
Для важных проектов я бы периодически делала полноценное восстановление в отдельной среде и проверяла результат: открываются ли страницы, подключается ли база, на месте ли изображения и документы, работает ли авторизация, отправляются ли формы, сохраняются ли новые данные.
Отдельно важно проверять такие копии после переноса сайта, обновления системы управления, изменения структуры базы или схемы резервирования.
Если сайт ни разу не восстанавливали из резервной копии, вы знаете только то, что архив существует. Насколько он пригоден для реального восстановления, пока неизвестно.
Как защитить копии
- Вход – по коду из приложения. Хостинг, облачное хранилище, Git и личный кабинет регистратора домена защищены не только паролем, но и кодом из приложения на телефоне.
- Доступ к хранилищу – отдельный. Не тот пароль, что у хостинга, и не у всех, у кого есть доступ к сайту.
- Копии с персональными данными – шифровать. В базе сайта лежат имена, телефоны и почта клиентов, то есть персональные данные. Если копия утечёт, это утечка персональных данных по 152-ФЗ – так же, как при взломе самого сайта.
- Знать, кто отвечает. Кто проверяет, что копии делаются, и кто восстанавливает сайт при аварии – это должно быть известно заранее, а не выясняться ночью во время сбоя.
- Следить, что копии приходят. Сломанное расписание молчит: копий нет, а ошибок никто не видит. Нужно уведомление, если свежей копии нет. Как я сделала такой контроль для сайта на 1С-Битрикс, рассказываю в кейсе о модуле контроля диска и бэкапов.
Проверьте свой сайт за пять минут
Хорошая резервная копия отвечает на три вопроса: где она лежит, за какую дату и можно ли из неё восстановиться. Ответьте на пять вопросов про свой сайт:
Если ответа нет на два-три вопроса, систему копий лучше проверить до того, как она понадобится.
Проверю резервные копии вашего сайта
Проверю, где лежат копии вашего сайта, на кого оформлен домен (он должен быть на вас, а не на подрядчике) и что будет, если хостинг упадёт. Настрою копии в облако и Git с уведомлением о сбоях, включу шифрование и вход по коду. Если хостинг всё-таки упадёт – помогу поднять сайт на новом месте из этих копий. Напишите мне – начну с проверки, где сейчас лежат копии вашего сайта.
Частые вопросы
Где хранить резервные копии сайта?
Минимум в двух местах, не зависящих друг от друга. На хостинге – для быстрых откатов. У другого поставщика, в облачном хранилище, – на случай сбоя самого хостинга. Дополнительно – на отдельном зашифрованном диске, который не подключён постоянно. Копии на другом тарифе того же хостинга независимыми не считаются.
Хватит ли резервных копий, которые делает хостинг?
Для быстрых откатов после неудачного обновления – да. От сбоя самого хостинга – нет: копии лежат у него же и недоступны вместе с сайтом, как при сбое Beget 2 ноября 2026 года. Нужна ещё хотя бы одна копия у другого поставщика.
Как часто делать бэкап сайта?
Зависит от того, сколько данных вы готовы потерять. Для небольшого корпоративного сайта – база каждую ночь, файлы раз в неделю, хранить 30 дней. Для интернет-магазина – база каждую ночь, а при десятках заказов в день ещё и днём, файлы – каждую ночь, только новые и изменённые, хранить 30–60 дней.
Как восстановить сайт из резервной копии, если хостинг не работает?
Нужны копии файлов и базы вне хостинга, доступ к управлению доменом и новое место размещения. Сайт поднимают на новом хостинге из копий и направляют на него домен. Заранее, раз в несколько месяцев, восстановление пробуют в отдельной среде.
Как проверить, что из копии можно восстановить сайт?
Раз в несколько месяцев восстановить сайт из копии в отдельной среде и убедиться, что работают страницы, база данных, изображения и формы.
Что сохранять, кроме файлов и базы данных?
Настройки сервера (версия PHP, параметры подключения к базе), доступы к регистратору домена и DNS. Пароли и ключи хранят отдельно, в защищённом месте, а файлы и базу копируют на один момент времени.
Сколько стоит хранить копии сайта в облаке?
В российском облачном хранилище S3 стандартное хранение стоит около 2,57 р. за гигабайт в месяц (по панели на 2 ноября 2026 года). Расчёт по тарифу: 20–25 ГБ копий обойдутся примерно в 51–64 р. в месяц. Запросы и скачивание при восстановлении оплачиваются отдельно, холодное хранение дешевле, но скачивание из него дороже.
Git – это резервная копия сайта?
Нет. Git хранит историю программного кода и помогает вернуть прежнюю версию после неудачного обновления. Базу данных, заказы, заявки и загруженные файлы он обычно не хранит, поэтому резервные копии нужны отдельно.
Можно ли заказать проверку и настройку резервных копий?
Да. Начинаю с проверки: где лежат копии, как часто делаются, можно ли из них восстановиться и на кого оформлен домен. Потом настраиваю хранение у другого поставщика с уведомлениями о сбоях. Стоимость и срок зависят от сайта и хостинга – напишите мне через форму контактов.
Материалы по теме
Что почитать дальше по этой теме
