Яндекс Облако - держитесь подальше⁠⁠

Просто держишь рабочий сайт поднятым еще в одном месте доступным для белого списка ip. Mysql на нем в слейве, с бинлогом не позднее последнего бекапа базы, лучше еще в паре версий, с задержкой репликации и нет. Если все очень плохо - быстрее перекинуть всех на уже поднятый резерв, чем ждать, пока бекап раскатается.

Зависит что на фронте/бэке.
Если фронт - обычный SPA (Angular/React/Vue) - держим его на CDN. Бэкапить его смысла нет, если пользоваться например Gitlab, то даже если текущий CDN забанит роском##зор, сменить адрес заливки и перебилдить - недолго, пара минут.
С базой интересней и сложней - для базы всегда имеет смысл держать readonly-реплику в режиме standby, и несмотря на это не забывать о бэкапе, и главное о проверке сделанного бэкапа (проверять хотя бы раз в месяц, раскатывая бэкап на новую машину). Мониторинг должен быть и мастера и реплики. Если мастер сдох (редко, но бывает), то переводим реплику в режим мастера. Это опять же недолго, не забываем делать внутренние dns короткоживущими. Если это все сложно, можно просто воспользоваться например сервисами AWS RDS - там это все упростили, но стоит дороже DO и товарищей, для пет-проекта не очень.

Бэкенд сервера имеет смысл держать на docker swarm или kubernetes. Есть нюанс "не протерять кворум", вот тогда может быть действительно больно. Но в большей части случаев теряется один сервер, и это не критично - кворум сохраняется, потеря быстро восполняется.

Выше