Открыть список
Как стать автором
Обновить

Комментарии 11

Спасибо за пост. Зачем бекапить облако вместо бекапа самих данных? Новые виртуалки создал, данные из бекапа восстановил. Быстрее и дешевле.

Про скорость очень спорный момент. Виртуалку надо не только создать, но и настроить, накатить патчики и только потом заливать туда данные. Довольно много мест получается, где что-то может пойти не по плану.
А имея образ машины целиком на выходе всегда гарантированный результат.
… на выходе всегда гарантированный результат
… если «машина» вообще существует и поддерживает консистентный бакап. )
Само собой )) Но вот сейчас есть тьма разных managed ХХХ сервисов, где у клиента нет выхода кроме как наслово верить провайдеру услуги, что у него всё адекватно бекапится и не будет восстанавливаться неделю. Далеко не всех устраивает такой подход, так что виртуалки завтра не умрут. И послезавтра тоже.
Согласен. Безумное следование за модой никогда ни к чему хорошему не приводило. Виртуалки на земле/ в Cloud IaaS живы и никуда не денутся в обозримом будущем.

При работе в облаках — нужно выкинуть из головы старые подходы. Вам не нужны бекапы виртуалок если у вас IaC. Ваше облако восстанавливается за минуты, несколькими командами терраформа. Остаётся только бекапить данные бекендов (DB, S3 в холодное хранилище и тд.)

Да, всё так. Осталось только повсеместно внедрить IaC и переписать два вагона легаси приложений, которые никуда сами собой не денутся. К сожалению, не все готовы вот так взять и по щелчку пальцев отказаться от виртуалок.

Зачем им тогда переезжать в облака? Виртуалки хетзнера дешевле облачных виртуалок амазона гугла и тд

Про преимущества облаков над традиционными инфраструктурами уже столько сказано, что обмусоливать это в миллионный раз никакого интереса.

IaC не хотим, но хотим облака, т.к. маркетинг, других аргументов пилить бюджеты бизнеса у нас нет

Похоже вы не очень хорошо умеете работать с AWS/GCloud/Azure.


Именно с помощью Terraform и ещё некоторых дополнительных инструментов, например, Packer, задача решается проще и правильнее всего. Можно Ansible и т.п. добавить по вкусу, но советую по возможности стараться обходиться без такого рода инструментов, ибо это уже несколько другой уровень. Зависит от проекта, конечно.
Далее накатываются бэкапы баз и т.п.
И это всего лишь один из вариантов.


Аргумент, что в IaC не все умеют не состоятелен. Мы же говорим про бизнес проекты, а не личные.
Особенно серьёзные проекты переезжающие в AWS/GCloud/Azure точно должны располагать бюджетом на DevOps или разовый консалтинг/outsourcing, чтобы всё настроить, рассказать и далее уже потихоньку самим это поддерживать.


Внутрь можете любое legacy напихать, не важно что там у вас внутри крутится.


Про Kubernetes (EKS) и бэкапы данных, например, с помощью Velero, наверное и упоминать не стоит?
То, что базы могут спокойно жить в RDS и т.п. managed сервисах и там бэкапы и недоступность целых зон тоже решена это ещё отдельная история.


По-поводу чёткого понимания расходов: в AWS/GCloud/Azure без этого вообще соваться не стоит. Для этого есть специально обученные люди, специальные инструменты, да целое направление FinOps есть и сколько раз я видел десятки тысяч долларов в месяц (!) экономии просто при переходе к использованию всяких endpoints + spots и т.п.

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

Информация

Дата основания
Местоположение
Швейцария
Сайт
veeam.com
Численность
1 001–5 000 человек
Дата регистрации
Представитель
Loxmatiy Mamont

Блог на Хабре