---
title: 'Бэкапы на хостинге и Cloud VPS: простой практический гайд | Zomro'
description: ''
image: 'https://zomro.com/static/site/images/logo/logo-white.png?v=1790950739'
---

![opened image]()

  * [Zomro](https://zomro.com/rus/)
  * [FAQ](https://zomro.com/rus/blog/faq/)
  * Бэкапы на хостинге и Cloud VPS: простой практический гайд 



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

06-12-2025

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

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

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

  * обновили CMS/плагин/PHP — сайт упал;

  * сломали конфиг Nginx/Apache/PHP-FPM — сервисы не стартуют;

  * случайно удалили файлы или таблицу в базе;

  * на VPS пошёл кривой эксперимент — система не грузится.




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

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

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

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

  1. **Файлы сайта**

     * директория `public_html` / `www` / `domain.tld` (зависит от панели);

     * конфиги, если есть кастомные (`.htaccess`, `wp-config.php` и пр.).

  2. **База данных**

     * MySQL/MariaDB для CMS (WordPress, OpenCart, Bitrix и т.д.);

     * дамп в `.sql` или `.sql.gz`.

  3. (Опционально) **Почта**

     * если почта лежит на хостинге (а не в внешнем сервисе типа Gmail/Workspace), имеет смысл бэкапить и её, но это уже больше для бизнес-критичных проектов.




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

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

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

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

  1. **Уровень приложения**

     * дампы баз данных (MySQL/MariaDB/PostgreSQL);

     * файлы приложений (`/var/www/`, каталоги с проектами, конфиги сервисов);

     * docker-compose файлы, конфиги Nginx/Apache, systemd‑юниты.

  2. **Уровень всей ВМ (snapshot)**

     * _Снимок Cloud VPS_ — сохраняет состояние виртуального диска ВМ целиком;

     * идеально перед крупными изменениями: обновление ОС, миграция версии БД, перед установкой сложного ПО.




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

  * **ежедневные/часовые дампы БД + архивы проектов** ;

  * **снимок VPS перед рисковыми действиями** (апгрейд, перенос, смена версии PHP/DB и т.д.).




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

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

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

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

  1. **Встроенные бэкапы панели**

     * в cPanel/ISP/Hestia обычно есть раздел типа «Бэкапы/Резервные копии»;

     * можно создать полный бэкап аккаунта или отдельные — файлов/БД;

     * если на тарифе включены автоматические копии — уточняйте, за сколько дней можно откатиться.

  2. **Собственные бэкапы на удалённый сервер / облако**

     * забрать архив сайта и дамп БД по SFTP/rsync;

     * хранить их на другом сервере или в облачном хранилище.

  3. **Снимки Cloud VPS (snapshots)**

     * создаются в панели управления VPS;

     * удобно: перед обновлением → «создать снимок» → обновить → если что, откатиться.




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

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

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

  1. **Раз в день** (или хотя бы раз в неделю):

     * создать дамп базы через phpMyAdmin / панель / `mysqldump`;

     * залить архив файлов сайта (`public_html`) + дамп БД в облако или на отдельный сервер.

  2. **Перед крупными изменениями** :

     * сделать отдельный бэкап «перед апдейтом» и не затирать его ближайшие несколько дней.




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

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

  1. **Ежедневно (через cron)**

     * дампы всех БД → в каталог `/backup/db/`;

     * архивы важных директорий (`/var/www`, конфиги) → `/backup/files/`.

  2. **Еженедельно**

     * синхронизация `/backup/` на удалённый сервер/облако (rsync/SFTP).

  3. **Перед рисковыми изменениями**

     * создать snapshot Cloud VPS;

     * после успешного апдейта, через несколько дней, старый снимок можно удалить, чтобы не захламлять хранилище.




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

### 

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

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

  1. Заходим в панель управления хостингом.

  2. Открываем раздел **«Резервные копии» / «Backups»**.

  3. Создаём:

     * бэкап файлов аккаунта или конкретного домена;

     * отдельный бэкап БД (если панель это поддерживает).

  4. Скачиваем архив файлов и дамп БД к себе (на ПК или в облако).




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

  1. Открыть phpMyAdmin.

  2. Выбрать нужную базу.

  3. Вкладка **«Экспорт»** → режим «Быстрый» → формат `SQL`.

  4. Сохранить файл `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, панели управления;

  * перед переносом проекта, если меняете много настроек сразу.




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

  1. Остановить критичные сервисы (по ситуации) или хотя бы БД, чтобы зафиксировать консистентное состояние.

  2. Создать снимок в панели Cloud VPS.

  3. Выполнить планируемые изменения.

  4. Если всё ок — оставить снимок ещё на несколько дней, потом удалить.

  5. Если после изменений всё сломалось — откатиться к снимку одним действием в панели.




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

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

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

  1. Возьмите свежий бэкап сайта.

  2. Разверните его на тестовом домене/поддомене или на отдельной тестовой VPS.

  3. Убедитесь, что:

     * сайт открывается;

     * авторизация работает;

     * БД на месте, нет ошибок.




Для Cloud VPS:

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

  * проверяйте запуск сервисов, логи ошибок.




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

  1. **Не храните единственный бэкап на том же диске, где и боевой сервер.**

  2. **Всегда бэкапите и файлы, и БД.** Только файлы — почти всегда недостаточно.

  3. **Перед апдейтами — отдельный бэкап/снимок.** Это экономит нервы и время.

  4. **Автоматизируйте всё, что можно.** Cron + простой скрипт на bash уже сильно поднимают уровень безопасности.

  5. **Следите за местом.** Залитый под завязку диск ломает и бэкапы, и работу сервисов.

  6. **Храните доступы и шифруйте важное.** Если бэкап попал в чужие руки в открытом виде — это уже не защита, а риск.




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

Похожие статьи

[Как установить AdGuard Home в Docker](https://zomro.com/rus/blog/faq/300-kak-ustanovit-adguard-home-v-docker) [Защита от сканеров портов в Linux](https://zomro.com/rus/blog/faq/651-protection-against-port-scanners-in-linux) [Основы работы в mysql](https://zomro.com/rus/blog/faq/264-osnovy-raboty-v-mysql) [Менеджер файлов cPanel](https://zomro.com/rus/blog/faq/177-menedzher-fajlov-cpanel) [Как установить свой терминал MT на FXTrade аккаунт?](https://zomro.com/rus/blog/faq/184-kak-ustanovit-svoj-terminal-mt-na-fxtrade-akkaunt)

[ Виртуальный хостинг от €3.98/мес ](/rus/virtual)