Резервные копии на хостинге или в облаке: что надёжнее

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

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

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

Что такое бэкап на хостинге

Под этим обычно понимают одну из трёх вещей.

Снапшот всей файловой системы. Хостер делает снимок диска по расписанию и хранит его в своём хранилище. Это самый удобный вариант: восстановление часто доступно из панели одной кнопкой, файлы и база данных откатываются согласованно. Так делают Timeweb, Beget, Reg.ru, FirstVDS на VPS-тарифах.

Архив папки и дампа базы. Хостер раз в сутки или раз в неделю собирает tar-архив домашней папки и SQL-дамп базы, кладёт в отдельный каталог на том же диске. Иногда в /home/<user>/backup/, иногда в специальной папке вне webroot. Так часто работает CPanel-хостинг.

Бэкап в той же файловой системе. Хуже всего: некоторые провайдеры держат архивы в public_html/backup/ или в подпапке domain. Это формально бэкап, но фактически он лежит в одной корзине с боевыми файлами и не переживёт ни дисковой аварии, ни проникновения злоумышленника.

Все три варианта объединяет одно: бэкап и сайт хранятся в инфраструктуре одного провайдера. Если упадёт инфраструктура, бэкапы упадут вместе с сайтом.

Что такое бэкап в облаке

Облако в этом контексте это любое внешнее хранилище, не связанное с хостингом сайта. Варианты, которые я реально использую на клиентских проектах:

• Yandex Object Storage или VK Cloud Storage S3-совместимое хранилище. Платишь за объём (около 1.6 рубля за гигабайт в месяц) и за исходящий трафик. Доступно через скрипт по API.
• Selectel S3 дешевле для холодного хранения, есть тариф Cold Storage от 0.6 рубля за гигабайт.
• Backblaze B2 международный, около 0.005 доллара за гигабайт в месяц. Работает из России без проблем по https.
• rclone + любая sftp-машина если у клиента есть второй сервер или собственная NAS, можно лить туда.
• Dropbox, Google Drive, Mega работают, но для автоматизации хуже из-за лимитов API и нестабильного доступа.

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

Сценарии, против которых работает каждый тип

Чтобы не теоретизировать, разложу по конкретным проблемам, какой бэкап спасает.

Сайт случайно удалён или сломан правкой

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

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

Хостинг падает целиком

Дата-центр сгорел, провайдер обанкротился, забанили целиком за политику. Доступа нет, аккаунт заморожен.

Хостерские бэкапы недоступны вместе с сайтом. Спасает только внешняя копия.

В 2024 году в России было два таких случая, которые я наблюдал лично у знакомых: один регистратор перестал отвечать на тикеты после смены собственника, второй просто не продлил лицензию ПО и аккаунты заморозились. Люди с внешним бэкапом подняли сайт на новом хостинге за вечер. Без бэкапа собирали всё с веб-архива и из Яндекс кэша.

Аккаунт снесён по жалобе или за неуплату

Хостер закрыл аккаунт. Вернуть данные иногда можно за отдельную плату в течение 30 дней, иногда нельзя совсем.

Хостерский бэкап мог бы быть, но к нему нет доступа. Внешняя копия спасает.

Взлом, через который удалили или зашифровали файлы

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

Самый защищённый вариант: внешнее хранилище с write-only доступом для скрипта бэкапа. Скрипт может только класть новые файлы, удалять не может. Тогда даже взлом сайта не позволит уничтожить копии.

Логическая ошибка, замеченная не сразу

Самая злая категория. Например, у вас два месяца неправильно отрабатывает форма заявок и тихо записывает их в неправильное место. Или клиентская база медленно портится из-за бага. Через два месяца замечаете и хотите вернуться к состоянию до бага.

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

Сколько это реально стоит

Возьмём типовой WordPress-сайт услуг: 800 МБ файлов и 50 МБ база. С запасом на медиа и логи, считаем 1.5 ГБ на копию.

Хостерский бэкап на shared в Timeweb или Beget. Включён в тариф, отдельной строки в счёте нет. Хранится обычно 7 ежедневных копий и 4 еженедельных.

Yandex Object Storage. Если хранить 7 ежедневных копий по 1.5 ГБ это 10.5 ГБ. По цене 1.62 рубля за гигабайт получается 17 рублей в месяц. Плюс трафик на загрузку, который копеечный.

Selectel Cold Storage. Те же 10.5 ГБ обойдутся в 6 рублей в месяц.

Backblaze B2. 0.005 доллара за гигабайт это около 5 рублей за 10.5 ГБ в месяц по курсу 100.

Для маленького сайта это 5 200 рублей в месяц за внешнее хранилище. Цена страховки от потери всего бизнеса, если что-то идёт не так.

Для интернет-магазина с 50 ГБ медиа цифры другие: 100 ГБ хранения это уже 60 200 рублей в месяц. Но и стоимость потери выше.

Что я в реальности ставлю клиентам

Шаблон, который работает на всех проектах в моём портфеле:

1. Хостерский бэкап включён. Бесплатно, удобно, восстанавливается одной кнопкой при мелких авариях.
2. Свой скрипт ежедневного бэкапа в Yandex Object Storage. С хранением 30 ежедневных копий, 12 еженедельных, 12 ежемесячных.
3. Шифрование на стороне сайта перед загрузкой в облако (gpg или openssl), чтобы даже сотрудник облачного провайдера не мог прочитать содержимое.
4. Ежеквартальная учебная тревога: беру случайную копию из облака, разворачиваю на тестовой машине, проверяю, что всё запустилось. Без этого бэкап существует только формально.

Скрипт пишется один раз и кладётся в /usr/local/bin/site-backup.sh на VPS или в cron в shared-аккаунте. Примерный шаблон без подробностей:

#!/bin/bash
set -e
DATE=$(date +%Y-%m-%d)
SITE=site.ru

mysqldump -u user -p'пароль' base > /tmp/${SITE}-${DATE}.sql
tar czf /tmp/${SITE}-${DATE}.tar.gz 
    -C /home/user/sites/${SITE}/public_html . 
    /tmp/${SITE}-${DATE}.sql

gpg --batch --yes --passphrase-file /root/.gpgpass -c 
    /tmp/${SITE}-${DATE}.tar.gz

rclone copy /tmp/${SITE}-${DATE}.tar.gz.gpg 
    yandex:my-backups/${SITE}/

rm /tmp/${SITE}-${DATE}*

Запускается раз в сутки ночью. Логирует в отдельный файл, и раз в неделю отчёт капает мне в Telegram через бот.

Где люди обычно ошибаются

Семь самых частых ошибок, которые я разбирал у клиентов.

Бэкап есть, но никто не пробовал восстановить. Файлы пишутся, скрипт работает, но при первой реальной аварии оказывается, что архив повреждён или в нём не хватает таблиц. Учебная тревога раз в квартал решает.

Бэкап лежит на том же сервере. Если упадёт диск, всё умрёт вместе. Если зашифрует ransomware, тоже всё умрёт.

Доступ к бэкапам у того же пользователя, что и доступ к сайту. Скомпрометировали FTP получили доступ и к бэкапам. Лечится отдельным пользователем для бэкапов с правами write-only.

В архиве нет базы данных или нет файлов. Старая ошибка, в которой бэкап делается через WordPress-плагин, который видит только wp-content, и не видит .htaccess, не видит письма из mail-папки, не видит crontab. Лечится снимком всей файловой системы и отдельным дампом базы.

Бэкап шифруется на стороне облака, а не у вас. Если облако скомпрометировано, ключи шифрования у провайдера. Лечится клиентским шифрованием перед загрузкой.

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

Никто не следит, что бэкап на самом деле создаётся. Cron-задача может молча падать месяцами. Лечится мониторингом: получили лог-строчку с размером архива, не получили в течение часа, прилетел алерт.

Когда хватит только хостерского бэкапа

Я на этом обычно осторожничаю, но бывают случаи, когда внешнее облако избыточно.

• Сайт это статика, которую вы держите в Git. Полная копия истории и так на GitHub или GitLab, и при потере хостинга вы за час раскатаете снова.
• Сайт строится в Tilda или другом конструкторе, где сам провайдер хранит ваш проект, а вы платите за хостинг отдельно. В этом случае проект уже в облаке у Tilda, экспорт делается ручным архивом раз в месяц.
• Сайт это лендинг без формы и без CRM, и в случае его исчезновения вы за вечер соберёте новый.

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

Как проверить, что бэкап у вас вообще работает

Простой чек-лист, который я гоняю на каждом новом клиенте.

1. Зайти в панель хостинга и попросить показать список текущих копий. Записать дату самой свежей и самой старой.
2. Если есть собственный скрипт, скачать одну случайную копию из облака. Проверить, что архив открывается и в нём есть и файлы, и SQL-дамп.
3. Развернуть скачанный архив на чистом локальном сервере (например, в Docker или на запасной поддомен). Проверить, что главная страница открывается, что логин в админку работает, что одна случайная запись из базы видна.
4. Записать в чек-лист дату учений и поставить следующую через 90 дней.

Этот процесс занимает час. И до первой реальной аварии кажется бесполезным. После первой аварии становится самым важным часом года.

Куда смотреть дальше

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

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

Частые вопросы

Что надёжнее: бэкап у хостера или в облаке

Они закрывают разные сценарии. Хостерский быстрее разворачивается при обычной поломке. Внешний спасает, когда проблема с самим хостингом: блокировка, авария, спор по оплате.

Сколько стоит хранить копии в облаке

Порядка полутора рублей за гигабайт в месяц, для холодного хранения дешевле. Сайт услуг на несколько гигабайт обходится в десятки рублей в месяц.

Сколько хранить копии

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

Как проверить, что бэкап работает

Развернуть его на тестовой площадке и открыть сайт. Раз в квартал этого достаточно, чтобы не узнать в момент аварии, что архивы битые.