Резервное копирование внешнего VPS в Yandex Cloud Backup

С 25 августа 2026 года Yandex Cloud публично предлагает использовать Cloud Backup не только для собственных ресурсов облака, но и для:

• виртуальных машин у другого хостинг-провайдера;
• VPS/VDS;
• физических серверов в собственном ЦОД;
• гибридной инфраструктуры.

На внешний сервер устанавливается агент. Он выполняет резервное копирование по назначенной политике, а управление ресурсами, расписанием, retention и восстановлением доступно через консоль Yandex Cloud, CLI и API.

Это полезный сценарий для SEO Recipes: production может работать у одного провайдера, а резервная копия храниться в независимом облаке.

• Карточка Yandex Cloud
• Каталог провайдеров

Что это за резервная копия

Cloud Backup — не обычная синхронизация каталога в S3 и не копирование отдельных файлов через rclone.

Сервис работает через агент на защищаемой машине и поддерживает восстановление:

• обратно во внешнюю инфраструктуру;
• на совместимый ресурс Yandex Cloud;
• внешней VM — в Compute Cloud;
• внешнего физического сервера — в Yandex BareMetal.

Тип ресурса должен сохраняться:

виртуальная машина → виртуальная машина
физический сервер → физический сервер

Нельзя рассчитывать на прямое восстановление копии VM в Bare Metal или копии физического сервера в VM без отдельной миграции приложения и данных.

Основные сценарии

Независимый backup VPS

VPS у провайдера A
        ↓ агент
Yandex Cloud Backup
        ↓
копии вне production-площадки

Такой вариант защищает лучше, чем backup только на соседний диск или в S3 того же аккаунта и провайдера.

Disaster recovery

При полной потере исходной машины копию можно использовать для восстановления в другой совместимой среде. Но это не автоматический failover: заранее нужны сеть, DNS, IP, secrets, firewall, внешние зависимости и runbook переключения.

Миграция в Yandex Cloud

Backup можно использовать как промежуточный переносимый образ. Перед production-переездом всё равно необходимо проверить:

• драйверы и загрузчик;
• сетевые интерфейсы;
• cloud-init;
• лицензии;
• firewall;
• производительность диска;
• изменение IP и DNS;
• доступность внешних сервисов.

Поддерживаемые операционные системы

На момент проверки 27 августа 2026 года официальная статья перечисляет:

• CentOS 7;
• Debian 11;
• Ubuntu LTS 16.04–24.04.

Перед подключением нужно сверить актуальный список в документации. Наличие Linux само по себе не означает совместимость любой версии ядра, нестандартной файловой системы или собственного kernel module.

После обновления ядра Linux может потребоваться установка соответствующих kernel headers и пересборка модуля SnapAPI.

Сетевые требования

Внешнему ресурсу нужен постоянный исходящий доступ:

• в интернет;
• к endpoint Cloud Backup;
• к служебным адресам, указанным в документации;
• к DNS и времени, необходимым для корректной работы агента.

Не открывайте входящий доступ ко всему интернету только ради backup. Сначала проверьте официальный список направлений и разрешите минимально необходимый исходящий трафик.

Во время создания резервной копии защищаемый ресурс должен быть запущен.

Подготовка аккаунта

До установки агента:

1. Создайте или выберите каталог Yandex Cloud.
2. Активируйте Cloud Backup.
3. Проверьте платёжный аккаунт и бюджетные уведомления.
4. Выдайте оператору роль backup.user или более узкую подходящую роль по актуальной документации.
5. Создайте или проверьте политику резервного копирования.
6. Зафиксируйте допустимые RPO, RTO и retention.

После активации сервис создаёт стандартные политики, но production-систему не стоит подключать к ним автоматически без проверки расписания и срока хранения.

Подключение внешнего ресурса

В консоли:

1. Откройте Cloud Backup.
2. Перейдите к подключённым ресурсам.
3. Выберите подключение внешнего ресурса.
4. Укажите тип: внешняя VM или внешний сервер.
5. Скопируйте сформированную команду установки агента.
6. Запустите её на сервере с административными правами.
7. Назначьте backup policy.
8. Дождитесь появления ресурса и успешного первого задания.

Не публикуйте команду установки в issue, чат или статью: она может содержать данные, связанные с подключением конкретного ресурса.

Подключение также поддерживается через CLI и API. Для массового парка серверов лучше хранить инфраструктурную процедуру в конфигурационном управлении, но одноразовые registration tokens не должны попадать в Git.

Политика резервного копирования

Политика определяет:

• расписание;
• тип и частоту копий;
• retention;
• окно запуска;
• дополнительные параметры агента;
• правила очистки старых копий.

Практический стартовый пример:

ежедневная копия
retention 14–30 дней
еженедельная копия
retention 8–12 недель
ежемесячная копия
retention по бизнес-требованиям

Это не универсальная рекомендация. Для часто меняющейся базы данных RPO раз в сутки может быть неприемлемым, а для статического сайта — избыточным.

База данных и консистентность

Снимок диска не гарантирует логическую консистентность любой СУБД.

Перед backup или параллельно с ним стоит использовать подходящий механизм:

• PostgreSQL base backup/WAL;
• MySQL/MariaDB dump или physical backup;
• Redis persistence/replication;
• application-level export;
• quiescing hooks, если они поддерживаются выбранной схемой.

Для WordPress и Laravel полезно иметь отдельно:

backup файлов
backup базы данных
копию .env/secrets в защищённом хранилище
инфраструктурный runbook

Secrets нельзя бездумно складывать в общий архив или публичный bucket.

Стоимость

Для региона Россия официальный пример на 27 августа 2026 года использует две составляющие:

Компонент	Цена в месяц с НДС
Подключение одной защищаемой VM/сервера	280,80 ₽
Хранение 1 ГБ резервных копий	4,968 ₽

Пример для одной машины и 50 ГБ копий:

280,80 ₽ + 50 × 4,968 ₽ = 529,20 ₽/мес

Это стоимость Cloud Backup без учёта возможных расходов исходного провайдера на исходящий трафик.

Размер backup не обязан совпадать с размером диска:

• пустое место и сжатие могут уменьшить объём;
• длинный retention и высокая изменяемость данных — увеличить;
• база данных и большие mutable-файлы могут давать значительный ежедневный churn.

Важная ловушка тарификации

Ресурс начинает тарифицироваться после привязки к backup policy и продолжает тарифицироваться до отвязки, даже если сервер остановлен.

Для внешней VM или физического сервера отвязка выполняется вручную.

Удаление VPS у исходного провайдера не сообщает Yandex Cloud, что защищаемой машины больше нет.

Правильное завершение:

отключить policy
        ↓
отвязать внешний ресурс
        ↓
удалить ненужные backup archives
        ↓
проверить Billing
        ↓
удалить агент/credentials

Даже после удаления или отвязки ресурса сохранённые копии продолжают занимать место и тарифицироваться, пока их не удалить согласно политике и процедуре.

Ограничения

По официальному анонсу на дату запуска:

• для backup машина должна быть включена;
• нужен постоянный исходящий доступ к сервису;
• поддерживается ограниченный список ОС;
• при полном восстановлении нужно правильно сопоставить диски и разделы;
• ресурс перезапускается во время полного восстановления;
• пофайловое восстановление непосредственно на внешний ресурс пока не поддерживается;
• VM и physical server нельзя произвольно менять местами при восстановлении.

Это управляемая услуга резервного копирования, но не замена тесту восстановления и не гарантия работоспособности приложения после disaster recovery.

Первый restore-test

Backup без успешного восстановления — только предположение о защите.

Проводите тест на отдельном ресурсе:

1. Создайте контрольный файл и запись в базе.
2. Запустите backup вручную или дождитесь политики.
3. Зафиксируйте время начала и завершения.
4. Подготовьте изолированную сеть для восстановления.
5. Восстановите копию на совместимый тестовый ресурс.
6. Проверьте загрузку ОС.
7. Проверьте filesystem и permissions.
8. Проверьте базу данных.
9. Запустите сайт/API без production DNS.
10. Проверьте фоновые workers, cron и очереди.
11. Убедитесь, что восстановленный сервер не отправляет production-письма и webhooks.
12. Зафиксируйте фактические RPO и RTO.
13. После теста удалите временный ресурс и проверьте billing.

Что проверить для сайта

• [ ] HTTP и HTTPS запускаются;
• [ ] сертификаты и private keys доступны;
• [ ] Nginx/Apache config восстановлен;
• [ ] PHP/Node/runtime version совпадает;
• [ ] база данных консистентна;
• [ ] uploads и пользовательские файлы на месте;
• [ ] .env и secrets восстановлены безопасно;
• [ ] cron и queue workers не дублируются;
• [ ] SMTP не начинает повторно отправлять старую очередь;
• [ ] DNS можно переключить по runbook;
• [ ] мониторинг видит восстановленный сервис;
• [ ] backup agent после восстановления не создаёт конфликтующий ресурс.

Независимость копии

Размещение production у провайдера A и backup в Yandex Cloud снижает риск общей аварии одной площадки. Но остаются общие зависимости:

• один администратор;
• один пароль или компрометированный ноутбук;
• один доменный registrar/DNS;
• ошибка приложения;
• ransomware с доступом к backup credentials;
• ошибочное массовое удаление;
• юридические и санкционные ограничения.

Для критичных данных используйте принцип 3-2-1 и отдельные права:

3 копии данных
2 разных типа или контура хранения
1 копия вне основной площадки

Cloud Backup может быть одной из копий, но не обязательно единственной.

Влияние на оценку Yandex Cloud

Поддержка внешних VPS и физических серверов усиливает Yandex Cloud как российскую backup/DR-площадку. Категорию провайдера менять не требуется: он остаётся в «Рекомендую».

Новая возможность не делает Yandex Cloud дешёвым VPS, но позволяет использовать часть его инфраструктуры без переноса production.

Источники

• Yandex Cloud: Cloud Backup защищает внешние VM и серверы
• Подключение внешней VM или сервера
• Правила тарификации Cloud Backup
• Резервные копии Cloud Backup
• Политики резервного копирования