Часть ссылок на этой странице - партнёрские. На наши рекомендации они не влияют - см. дисклеймер о партнёрских ссылках.

Сообщество середины октября 2026 провело неделю в спорах об устойчивости облаков. Инцидент с третьим дата-центром крупного облачного провайдера и приостановка расширения дата-центров у другого заняли верх трендов - сообщество подаёт это как сигнал «одиночный провайдер = скрытый риск». Воспринимайте это как настроение, а не факт: ни один провайдер не публикует гарантию, что регион, не то что парк дата-центров, останется в строю. Зато можно проверить другое - от чего ваш собственный одиночный VPS реально защищает, а от чего нет. Этот гайд - про такую проверку: что ловит внешний healthcheck, что на самом деле умеет DNS-failover, где держать бэкапы, чтобы они пережили ваш хост, и когда второй провайдер действительно оправдан.

Честная отправная точка: один VPS - это одна точка отказа

Начните с ограничения, а не с маркетинга. SLA провайдера - это график возмещений, а не обещание доступности. DigitalOcean, например, гарантирует 99,99% месячного аптайма для каждого отдельного Droplet - и под недоступностью понимает потерю связи с Droplet по публичному, reserved или private IP, либо потерю чтения/записи к корневому диску, вызванную сбоем инфраструктуры DigitalOcean.[1] Это узко: ваше приложение, отдающее 500-е, - это не даунтайм провайдера, плановое обслуживание исключается, а SLA считается на Droplet, а не на аккаунт. Одиночный Droplet с вашим приложением может упасть по тысяче причин, ни одна из которых не даст кредит: ваш код, забитый диск, криво настроенный firewall, kernel panic, процесс, умерший в 3 часа ночи. Второй VPS у того же провайдера убирает отказ «одной машины», но оставляет отказы «одного провайдера» и «одного региона».

Значит, вопрос из заголовка распадается на три, и ответы у них разные:

  1. Можете ли вы быстро заметить аварию, извне провайдера?
  2. Можете ли вы переключить трафик на здоровую копию без ручного героизма?
  3. Можете ли вы собраться заново, если хост пропал целиком?

Большинство конфигураций с одним VPS проваливают минимум два из трёх. Чиним каждое.

1. Healthcheck-и: проверка обязана приходить извне

Самая частая ошибка - считать источником истины проверки с самого сервера. Если машина жива, но её сетевой путь в интернет сломан, проверка на этой машине видит, что всё в порядке: systemctl is-active nginx вернёт active, пока никто в интернете вас достать не может. Та же слепая зона у дашбордов аптайма, запущенных на том же VPS: они пишут «всё хорошо» ровно потому, что делят с вами отказ.

Healthcheck полезен, только если зонд пересекает сетевую границу, от которой зависит ваше приложение. Это значит - внешний монитор, либо healthcheck на уровне инфраструктуры перед приложением. Управляемые load balancer-ы DigitalOcean - самый наглядный пример: балансировщик опрашивает каждый бэкенд с настраиваемыми протоколом, портом, путём; интервалом проверки; таймаутом ответа; порогами healthy/unhealthy и отдаёт трафик только тем Droplet, которые проверку прошли - для HTTP/HTTPS успешный ответ это диапазон 200–399, а балансировщик помечает бэкенд нездоровым и перестаёт в него направлять трафик после заданного числа провалов подряд (в настройках кластера по умолчанию: интервал 3 секунды, таймаут 5 секунд, 3 провала до пометки unhealthy).[2][3] Это внешне, автоматически и быстро. Глобальный балансировщик умеет то же самое в разрезе нескольких регионов.[4]

Для простого одиночного VPS без балансировщика минимум - лёгкий внешний монитор, который ходит на ваш публичный endpoint (HTTP-зонд с хоста в другой сети, в идеале у другого провайдера) и не только алертит, но и запускает переключение DNS из раздела 2. Два бесплатных и официальных сигнала:

  • Страницы статуса провайдера. На статус-странице DigitalOcean компоненты отслеживаются по регионам (каждый дата-центр виден отдельно), Vultr отдаёт статус и как HTML, и как JSON-эндпоинты (status.json, alerts.json) для автоматизации, а у Hetzner есть своя статус-страница.[5][6][7] Они говорят, видит ли провайдер проблему на уровне региона, - это ровно тот отказ, который не ловит проверка на самой машине.
  • Ваш собственный внешний зонд. Статус-страница говорит, что провайдер считает регион живым; но не говорит, отвечает ли ваш инстанс. Опрашивайте свой IP/endpoint извне с коротким интервалом и храните историю не на той же машине, за которой следите.

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

2. DNS-failover: что DNS реально умеет и не умеет

DNS - самый дешёвый способ перенаправлять трафик и одновременно источник наибольших заблуждений. Мгновенно он не переключается и никогда не будет: мешает TTL-кэширование.

Механика в цифрах. На Cloudflare (а это репрезентативно для контролов любого серьёзного DNS-провайдера) proxied-запись по умолчанию имеет TTL 300 секунд - пять минут - и это значение нельзя уменьшить; записи DNS-only можно опустить до 60 секунд (не-Enterprise) или 30 (Enterprise), при этом Auto всё равно означает 300 секунд.[8] То есть самый быстрый реальный DNS-флип доходит до резолверов примерно за минуту для пользователей без кэшированного ответа, а те, кто уже держит в кэше A-запись, продолжают ходить на мёртвый IP, пока не истечёт их кэш. Пять минут даунтайма при TTL 300 секунд - это оптимистично: это верхняя граница жизни старого ответа. И это до того, как учесть, что резолвер может отдавать кэшированный ответ даже после истечения TTL у авторитетного сервера.

Зато DNS-failover умеет надёжно одну вещь - активно-пассивную маршрутизацию с healthcheck-ами, и это решённая документированная фича. Failover routing policy у AWS Route 53 - канонический пример: вы создаёте первичную запись с healthcheck-ом и вторичную, и Route 53 перестаёт отвечать первичной и начинает отвечать вторичной, когда healthcheck первичной падает.[9] Именно healthcheck превращает это в активно-пассивную схему, а не просто две записи. Без healthcheck DNS ничего не переключает - он просто отвечает, мёртв ты или жив.

Практический вывод для self-hosted деплоя:

  • Держите TTL записи низким (пол в 60 секунд у Cloudflare для не-Enterprise - разумная цель) - до того, как понадобится failover, потому что TTL зафиксирован в кэше резолверов пользователей именно тем значением.
  • Свяжите низкий TTL с настоящим healthcheck-ом, чтобы переключение срабатывало само, а не по пейджеру в 3 часа ночи.
  • Рассчитывайте на восстановление в десятки секунд - пару минут, а не в миллисекунды. Если приложению нужен failover за доли секунды - DNS не тот инструмент; нужен прокси/балансировщик или anycast/CDN-слой, а это уже другая архитектура, не «два VPS и DNS-запись».

И ещё одно, чего DNS не делает: он не делает взаимозаменяемыми два провайдера с разными стеками. Обе standby-копии должны крутить один и тот же деплой и быть доступны по одному и тому же пути зонда, иначе healthcheck, который переключает DNS, заодно переключит пользователей на сломанную standby.

3. Кросспровайдерные бэкапы: снапшот обязан пережить хост

Снапшоты провайдера - это ловушка. Снапшот, хранящийся у того же провайдера, что и приложение, годится для отката плохого деплоя, но это не disaster-recovery бэкап: если регион провайдера умер - или аккаунт исчез, или дата-центр, где лежал снапшот, и есть тот самый упавший, - точка восстановления ушла вместе с ним. У хранения снапшотов к тому же есть привычка незаметно стоить дороже ожидаемого. Реальные цифры на момент написания:

  • Снапшоты DigitalOcean: $0,06 за ГБ в месяц (та же ставка за GiB для volume), с плоским минимумом $0,01; автоматические бэкапы DO - это процент от стоимости Droplet: 20% за еженедельные, 30% за ежедневные на тарифах с плоской ценой.[10][11]
  • Снапшоты Vultr: $0,05 за ГБ в месяц.[12]
  • Снапшоты Hetzner: €0,0143 за ГБ в месяц - заметно дешевле за Гигабайт; автоматические бэкапы Hetzner - ежедневные копии, до семи слотов на сервер, привязаны к серверу и удаляются вместе с ним.[13][14]

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

  1. Собираемая заново конфигурация, а не только диски. Храните то, что делает машину воспроизводимой, в нейтральном к провайдеру месте с версионированием: код деплоя в git, IaC (Terraform, Ansible или простой скрипт, провижинящий VPS), окружение/секреты - в managed secret store. Только такой «конфиг как код» переживает смерть провайдера и работает на другом провайдере.
  2. Бэкап данных вне провайдера. Для изменяемого состояния (база, загруженные файлы) регулярно выносите его наружу - в объектное хранилище или на хост другого провайдера: например, ночной pg_dump, отправляемый в S3-совместимое хранилище в другом облаке. RPO должен определяться тем, сколько данных вы готовы потерять, а не расписанием снапшотов провайдера, на которое вы подписались.

Конкретную последовательность «снапшот провайдера A → восстановление у провайдера B» мы тестируем на реальных аккаунтах, а не приводим с цифрой - принцип прост, но кросспровайдерное восстановление это ровно тот шаг, который не хочется обнаруживать сломанным посреди инцидента.

4. Два региона одного провайдера - или два провайдера?

Это решение, к которому ведёт весь текст. Два VPS в разных регионах одного провайдера, или разнести по двум провайдерам?

Два региона, один провайдер - вариант дешевле и проще, и он закрывает самый частый сценарий отказа. Реалистичный отказ у всех трёх провайдеров ниже - это региональный или уровня дата-центра, а не «исчезла вся компания». У DigitalOcean 16 дата-центров в 13 регионах, Vultr маркирует 34 облачных региона, Hetzner держит шесть локаций в четырёх network-зонах (Фалькенштайн, Нюрнберг и Хельсинки в Европе, плюс Ашберн, Хиллсборо и Сингапур).[15][16][17] Второй регион того же провайдера переживает инцидент одного региона - а статус-страницы показывают ровно эту гранулярность: инциденты часто ложатся на один регион, пока остальные зелёные.[5] Уходит и общая зависимость от сети/контрол-плейна.

Два провайдера убирают класс отказа, который второй регион не закрывает: отказ в масштабе всего провайдера, перегруженный апстрим-канал, бьющий по всему футпринту одного вендора, или падение control-plane (например, отказы API/создания ресурсов), которые не дают поднять замену внутри того же вендора именно тогда, когда это нужнее всего. Плата - реальная операционная тяжесть: два биллинга, два дашборда/API и две среды, которые обязаны оставаться достаточно байт-совместимыми, чтобы одна здоровая копия взяла весь трафик, не сломавшись на полупереведённом коде.

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

Практический вердикт

Пройдите по списку на своей текущей конфигурации, прежде чем покупать вторую машину:

  • Внешняя проверка? Опрашивайте публичный endpoint извне провайдера. Не видите аварию снаружи - значит, мониторинга у вас нет.
  • DNS настроен на failover? Низкий TTL (пол 60 секунд у Cloudflare не-Enterprise), healthcheck, управляющий переключением, и настоящая standby - а не вторая A-запись, которую никогда не тестировали.
  • Бэкапы вне провайдера? Снапшоты - это откат, а не disaster recovery. Отказоустойчивость дают собираемый конфиг в git плюс копии данных вне провайдера.
  • Standby проверена? Standby, на которую вы ни разу не переключались, - это хобби, а не план. Проведите учения.

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

Если собираете сам деплой - наш гайд по запуску Next.js на VPS с Nginx и PM2 покрывает тот единый узел, что вы будете реплицировать, а история долгосрочного версионирования в апгрейде PostgreSQL до 19 показывает, как держать пересборку воспроизводимой. По ценам и регионам между типичными первыми кандидатами - наше сравнение DigitalOcean vs Linode vs Vultr, а для планов Hetzner Cloud в 2026 есть отдельный разбор каталога и выбора CX23 vs CAX11.

Источники

  1. DigitalOcean - CPU Droplet SLA (99,99% на инстанс; недоступность = потеря связи по публичному/reserved/private IP или доступа к корневому диску по вине инфраструктуры DO). https://www.digitalocean.com/sla/cpu-droplets - checked 2026-10-14
  2. DigitalOcean - Configure advanced load balancer settings in Kubernetes (healthcheck: протокол/порт/путь, интервал 3–300с по умолчанию 3, таймаут 3–300 по умолчанию 5, unhealthy-порог 2–10 по умолчанию 3). https://docs.digitalocean.com/products/kubernetes/how-to/configure-load-balancers - checked 2026-10-14
  3. DigitalOcean - How to Manage Global Load Balancers (healthcheck-и; трафик только к Droplet, прошедшим проверку; успех HTTP/HTTPS = 200–399). https://docs.digitalocean.com/products/networking/load-balancers/how-to/manage-global-load-balancers - checked 2026-10-14
  4. DigitalOcean - How to Manage Global Load Balancers (распределение бэкендов между регионами). https://docs.digitalocean.com/products/networking/load-balancers/how-to/manage-global-load-balancers - checked 2026-10-14
  5. DigitalOcean Status - статус компонентов и история инцидентов по регионам (напр., сетевой сбой BLR1, 2026-10-03). https://status.digitalocean.com - checked 2026-10-14
  6. Vultr - Server Status (HTML-статус и JSON-эндпоинты status.json / alerts.json). https://status.vultr.com и https://docs.vultr.com/vultr-server-status-json-endpoints - checked 2026-10-14
  7. Hetzner - Страница статуса. https://status.hetzner.com - checked 2026-10-14
  8. Cloudflare - Time to Live (TTL) (proxied Auto = 300с; DNS-only от 60с не-Enterprise / 30с Enterprise, до 1 дня). https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/ - checked 2026-10-14
  9. AWS Route 53 - Failover routing policy и health checks (активно-пассивный failover, управляемый healthcheck-ами). https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy-failover.html и https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-health-checks.html - checked 2026-10-14
  10. DigitalOcean - Snapshots pricing ($0,06/GB в месяц, $0,06/GiB для volume). https://docs.digitalocean.com/products/snapshots/details/pricing/ - checked 2026-10-14
  11. DigitalOcean - Backups pricing (Basic-тарифы: еженедельные 20%, ежедневные 30% от стоимости Droplet). https://docs.digitalocean.com/products/backups/details/pricing/ - checked 2026-10-14
  12. Vultr - Stored snapshots ($0,05/GB в месяц). https://docs.vultr.com/support/platform/billing/does-vultr-charge-for-stored-snapshots - checked 2026-10-14
  13. Hetzner - Cost-optimized cloud servers (снапшоты €0,0143 за ГБ в месяц). https://www.hetzner.com/cloud/cost-optimized/ - checked 2026-10-14
  14. Hetzner Docs - Backups & Snapshots FAQ (ежедневные бэкапы, до 7 слотов на сервер, удаляются с сервером). https://docs.hetzner.com/cloud/servers/backups-snapshots/overview - checked 2026-10-14
  15. DigitalOcean - Regional availability (16 дата-центров в 13 регионах). https://docs.digitalocean.com/platform/regional-availability/ - checked 2026-10-14
  16. Vultr - Datacenter regions (34 облачных региона). https://vultr.com/features/datacenter-regions/ - checked 2026-10-14
  17. Hetzner Docs - Locations (шесть локаций, четыре network-зоны; Фалькенштайн, Нюрнберг, Хельсинки - собственные, Ашберн/Хиллсборо/Сингапур - колокация). https://docs.hetzner.com/cloud/general/locations - checked 2026-10-14

Сигнал тренда (не источник факта): октябрьское 2026 обсуждение в сообществе инцидента с третьим дата-центром крупного облачного провайдера (news.ycombinator.com/item?id=50040547) и сообщения о паузе в строительстве дата-центров у одного провайдера. Приведено только как настроение сообщества, согласно нашей редакционной политике.