Бэкапы на хостинге и Cloud VPS: простой практический гайд

Цель этой статьи не «напугать потерей данных», а дать понятную, рабочую схему: что именно бэкапить, как, куда и как потом восстановиться, если что‑то пошло не так.

Зачем вообще нужны бэкапы на хостинге и Cloud VPS

На практике 90% проблем выглядят так:

обновили CMS/плагин/PHP — сайт упал;
сломали конфиг Nginx/Apache/PHP-FPM — сервисы не стартуют;
случайно удалили файлы или таблицу в базе;
на VPS пошёл кривой эксперимент — система не грузится.

Во всех этих случаях правильный бэкап превращает катастрофу в обычную задачу на 15–30 минут: откатились — и продолжили работать.

Что именно нужно бэкапить на хостинге

Сайт на виртуальном хостинге (cPanel/ISP/Hestia и т.п.)

Минимальный набор:

Файлы сайта
- директория public_html / www / domain.tld (зависит от панели);
- конфиги, если есть кастомные (.htaccess, wp-config.php и пр.).
База данных
- MySQL/MariaDB для CMS (WordPress, OpenCart, Bitrix и т.д.);
- дамп в .sql или .sql.gz.
(Опционально) Почта
- если почта лежит на хостинге (а не в внешнем сервисе типа Gmail/Workspace), имеет смысл бэкапить и её, но это уже больше для бизнес-критичных проектов.

Главное правило:

Без дампа базы ваш архив с файлами часто бесполезен. Бэкап сайта = файлы + БД.

Что бэкапить на Cloud VPS

На Cloud VPS у вас уже полноценный сервер. Тут два уровня бэкапа:

Уровень приложения
- дампы баз данных (MySQL/MariaDB/PostgreSQL);
- файлы приложений (/var/www/, каталоги с проектами, конфиги сервисов);
- docker-compose файлы, конфиги Nginx/Apache, systemd‑юниты.
Уровень всей ВМ (snapshot)
- Снимок Cloud VPS — сохраняет состояние виртуального диска ВМ целиком;
- идеально перед крупными изменениями: обновление ОС, миграция версии БД, перед установкой сложного ПО.

Обычно используют связку:

ежедневные/часовые дампы БД + архивы проектов;
снимок VPS перед рисковыми действиями (апгрейд, перенос, смена версии PHP/DB и т.д.).

Варианты бэкапов у хостера

У провайдера могут быть свои автоматические бэкапы (зависит от тарифа и услуги). Но как сисадмин я рекомендую считать так:

Бэкапы провайдера — это «подушка безопасности». Основной бэкап вы всё равно держите под своим контролем.

Рабочие варианты:

Встроенные бэкапы панели
- в cPanel/ISP/Hestia обычно есть раздел типа «Бэкапы/Резервные копии»;
- можно создать полный бэкап аккаунта или отдельные — файлов/БД;
- если на тарифе включены автоматические копии — уточняйте, за сколько дней можно откатиться.
Собственные бэкапы на удалённый сервер / облако
- забрать архив сайта и дамп БД по SFTP/rsync;
- хранить их на другом сервере или в облачном хранилище.
Снимки Cloud VPS (snapshots)
- создаются в панели управления VPS;
- удобно: перед обновлением → «создать снимок» → обновить → если что, откатиться.

Минимальная рабочая схема бэкапов

Обычный сайт на виртуальном хостинге

Простая и жизнеспособная схема:

Раз в день (или хотя бы раз в неделю):
- создать дамп базы через phpMyAdmin / панель / mysqldump;
- залить архив файлов сайта (public_html) + дамп БД в облако или на отдельный сервер.
Перед крупными изменениями:
- сделать отдельный бэкап «перед апдейтом» и не затирать его ближайшие несколько дней.

Cloud VPS с проектами и БД

Здесь уже лучше «минимальный 3‑2‑1»: в адаптированном варианте.

Ежедневно (через cron)
- дампы всех БД → в каталог /backup/db/;
- архивы важных директорий (/var/www, конфиги) → /backup/files/.
Еженедельно
- синхронизация /backup/ на удалённый сервер/облако (rsync/SFTP).
Перед рисковыми изменениями
- создать snapshot Cloud VPS;
- после успешного апдейта, через несколько дней, старый снимок можно удалить, чтобы не захламлять хранилище.

Практика: пример бэкапа сайта на виртуальном хостинге

Ручной бэкап через панель

Общая логика (названия пунктов могут отличаться):

Заходим в панель управления хостингом.
Открываем раздел «Резервные копии» / «Backups».
Создаём:
- бэкап файлов аккаунта или конкретного домена;
- отдельный бэкап БД (если панель это поддерживает).
Скачиваем архив файлов и дамп БД к себе (на ПК или в облако).

Ручной бэкап БД через phpMyAdmin

Открыть phpMyAdmin.
Выбрать нужную базу.
Вкладка «Экспорт» → режим «Быстрый» → формат SQL.
Сохранить файл dbname-YYYYMMDD.sql.

Практика на Cloud VPS: скрипт бэкапа (пример)

Ниже пример базового скрипта для Linux‑VPS (Ubuntu/Debian). Он:

делает дампы всех MySQL/MariaDB баз;
архивирует директорию с сайтами;
чистит старые бэкапы старше N дней.

#!/bin/bash

BACKUP_DIR="/backup"
WWW_DIR="/var/www"
DAYS_TO_KEEP=7

DATE=$(date +"%Y-%m-%d")
DB_BACKUP_DIR="$BACKUP_DIR/db/$DATE"
FILES_BACKUP_DIR="$BACKUP_DIR/files/$DATE"

mkdir -p "$DB_BACKUP_DIR" "$FILES_BACKUP_DIR"

# 1. Dump all MySQL/MariaDB databases
MYSQL_USER="root"
MYSQL_PASS="YOUR_PASSWORD"  # better use .my.cnf, this is just an example

# list of databases without system ones
DBS=$(mysql -u"$MYSQL_USER" -p"$MYSQL_PASS" -e 'SHOW DATABASES;' \
  | grep -Ev '^(Database|information_schema|performance_schema|mysql|sys)$')

for DB in $DBS; do
  echo "Dumping $DB"
  mysqldump -u"$MYSQL_USER" -p"$MYSQL_PASS" "$DB" \
    | gzip > "$DB_BACKUP_DIR/${DB}.sql.gz"
done

# 2. Archive project files
cd "$WWW_DIR" || exit 1
tar czf "$FILES_BACKUP_DIR/www.tar.gz" .

# 3. Cleanup old backups
find "$BACKUP_DIR/db" -maxdepth 1 -type d -mtime +"$DAYS_TO_KEEP" -exec rm -rf {} +
find "$BACKUP_DIR/files" -maxdepth 1 -type d -mtime +"$DAYS_TO_KEEP" -exec rm -rf {} +

echo "Backup completed: $DATE"

Добавляем в cron, например, ежедневный запуск в 03:15:

crontab -e

Строка:

15 3 * * * /usr/local/sbin/backup.sh >/var/log/backup.log 2>&1

Дальше можно:

либо по cron/скрипту пересылать /backup на удалённый сервер через rsync;
либо периодически забирать бэкапы вручную.

Снимки Cloud VPS (snapshots): когда и как использовать

Снимок VPS — это «фото» диска сервера на момент времени. Это не замена обычным бэкапам, а страховка перед опасными действиями.

Использовать snapshot имеет смысл:

перед обновлением ОС или больших пакетов (например, apt dist-upgrade);
перед обновлением ключевых компонентов: MySQL/MariaDB/PostgreSQL, Docker, панели управления;
перед переносом проекта, если меняете много настроек сразу.

Типичный рабочий сценарий:

Остановить критичные сервисы (по ситуации) или хотя бы БД, чтобы зафиксировать консистентное состояние.
Создать снимок в панели Cloud VPS.
Выполнить планируемые изменения.
Если всё ок — оставить снимок ещё на несколько дней, потом удалить.
Если после изменений всё сломалось — откатиться к снимку одним действием в панели.

Как проверять, что бэкапы работают

Бэкап, который ни разу не проверяли восстановлением, — это иллюзия защиты.

Минимум раз в месяц:

Возьмите свежий бэкап сайта.
Разверните его на тестовом домене/поддомене или на отдельной тестовой VPS.
Убедитесь, что:
- сайт открывается;
- авторизация работает;
- БД на месте, нет ошибок.

Для Cloud VPS:

периодически поднимайте тестовую VM из snapshot/бэкапа (если панель это поддерживает);
проверяйте запуск сервисов, логи ошибок.

Краткие практические рекомендации

Не храните единственный бэкап на том же диске, где и боевой сервер.
Всегда бэкапите и файлы, и БД. Только файлы — почти всегда недостаточно.
Перед апдейтами — отдельный бэкап/снимок. Это экономит нервы и время.
Автоматизируйте всё, что можно. Cron + простой скрипт на bash уже сильно поднимают уровень безопасности.
Следите за местом. Залитый под завязку диск ломает и бэкапы, и работу сервисов.
Храните доступы и шифруйте важное. Если бэкап попал в чужие руки в открытом виде — это уже не защита, а риск.

Этот гайд можно использовать как базовый чек-лист при настройке бэкапов на хостинге и Cloud VPS. Дальше можно углубляться: отдельные бэкапы Docker‑контейнеров, репликация БД, offsite‑копии в другом дата‑центре, но фундамент всегда один и тот же: регулярные, проверенные бэкапы под вашим контролем.