Home »

Бэкап и восстановле...
 

Бэкап и восстановление гипервизора  


spoonlight
Сообщения: 3
(@spoonlight)
Эникей
Присоединился: 4 месяца назад

Здравствуйте. Заниматься proxmox только начал. Поставили задачу снятия бэкапа с именно системы (не с ВМ или контейнеров). Чтобы потом, "если что", можно было снова развернуть гипервизор со всеми настройками (при условии, что с ВМ и контейнерами всё в порядке). Всё работает на lvm. ВМ, контейнеры и их образа установочные, лежат на сториджах в виде отдельных дисков (подключались как директории). Тушить систему - нельзя. Иначе бы тупо снял имидж с диска тем же dd.

Принцип работ себе представляю. Но - образно. =(( Снять снапшот с рабочей системы. Примонтировать внешний диск. Упаковать и перекинуть на внешний диск. Отмонтировать диск. Удалить снапшот. Это - только как сделать бэкап. А, вот, как потом его развернуть, увы...

Понимаю, что, если, мы меняем диск системный, то меняется uuid диска. Соответственно, нужно будет подсунуть системе старый uuid при разворачивании бэкапа. А так же, настраивать загрузочный сектор.

За рабочую методику с разъяснениями готов поощрить финансово. По договорённости. Возможно, здесь это не принято. Но, своими силами этот вопрос я не решу. А всё, что находил в сети, мало понятно. Спасибо.

Ответить
Метки темы
5 Ответов
Zerox
Сообщения: 581
Admin
(@zerox)
Honorable Member
Присоединился: 7 лет назад

Вообще, обычно гипервизоры не бэкапят. К ним такой подход - гипервизор можно легко заменить, перенеся все виртуалки на новое место. По большому счету, что там бэкапить? Сетевые настройки? Подключенные сторейджи? Все это хранится в конфиг файлах или xml. Достаточно сохранить только то, что нужно. Я не вижу смысла бэкапить сам гипервизор. Никогда не видел таких задач.

В общем случае, подход должен быть такой же, как к любой линукс системе, каковой и является сервер виртуализации proxmox. Там обычный debian под капотом. Можно тем же Veeam agent for Linux забэкапить, если очень хочется.

Ответить
4 Ответы
spoonlight
(@spoonlight)
Присоединился: 4 месяца назад

Эникей
Сообщения: 3

@zerox Здравствуйте, уважаемый.) Большое спасибо за ответ.)

Да, я в курсе, что непосредственно систему гипервизора не бэкапят.) Самому подобное странно решать. Но - вот такое задание. Относительно слива папок с настройками (в принципе, да, там всё прозрачно, тупо можно скачать папки с конфигами, а потом залить их на переустановленную систему) делать пробовал: проблема как раз с uuid дисков, которые остались от storage старой системы. Т.е., их потом нужно бы подмонтировать. При этом, система начинает видеть, какие ВМ и контейнеры ей подпихнули, но сами storage, понятно, она не видит.

Может, не совсем понимаю. Но, как решается вопрос, когда несколько десятков ВМ/контейнеров, и "падает" сам гипервизор? Или, может, попытаться решить этот вопрос по-другому? Отбэкапить пару тестовых ВМ и развернуть их на вновь поднятом гипервизоре? Как быстро восстановить работу proxmox, если не сливом/разворачиванием снятого ранее образа?

Ответить
Zerox
Admin
(@zerox)
Присоединился: 7 лет назад

Honorable Member
Сообщения: 581

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

Делается бэкап виртуальных машин. Они в обязательном порядке восстанавливаются на запасном гипервизоре, чтобы была уверенность, что с ними все в порядке и они корректно разворачиваются. К сожалению, бывает так, что при восстановлении из бэкапа появляется какая-то ошибка. Сталкивался с этим многократно сам, плюс привлекался к таким задачам  со стороны других организаций, которые не смогли восстановиться из бэкапов после аварии. Бэкапы вроде и делали, но не проверяли. А когда все сломалось, оказалось, что восстановиться не получается.

Исходя из принципа, что всегда должен быть запасной, подменный гипервизор, бэкапить основной нет смысла. Горячая замена должна быть наготове здесь и сейчас. Без нее банально нельзя убедиться в том, что бэкапы рабочие.

Думаю, вам стоит донести эту мысль до руководства и просто смоделировать выход из строя основного сервера. Продумать все варианты действий и время, которое уйдет на восстановление. Например, вы сейчас разработаете схему бэкапа гипервизора. А как вы тестировать эти бэкапы будете, если нет запасного? А если есть запасной, зачем бэкап гипервизора?

В общем, работа системного администратора это не только выполнение пожеланий сверху, но и своя голова на плечах. Нужно доносить правильные идеи до руководства. Объяснять, как лучше поступать, чтобы гарантировать максимальную доступность обслуживаемых сервисов.

Ответить
spoonlight
(@spoonlight)
Присоединился: 4 месяца назад

Эникей
Сообщения: 3

@zerox В целом, я с Вами согласен. )) Но, в любом вопросе может быть своё "но". В данной ситуации, боевой сервер находится не в стране. Гарантировать порядочность хостера тоже нет возможности (рассказали одну страшилку, что когда были на одном хостинге, и вдруг упал диск с гипервизором, хостер только развёл руками, сказав, что никто от этого не застрахован. =) Т.е., хостер за состоянием своего железа не следил от слова совсем.)

Второй дубль-сервер фирма позволить себе не может. Есть только личный, старенький hp dl360 g5, на котором пытаюсь отрабатывать вот такие "неполадки".

Ответить
Zerox
Admin
(@zerox)
Присоединился: 7 лет назад

Honorable Member
Сообщения: 581

@spoonlight если арендуется выделенный сервер, то хостер действительно за ним не будет следить. Когда что-то сломается, он по вашей заявке починит, не более. Так что следить за железом вам надо самим. Как минимум, мониторинг дисков настроить.

В данном случае тем более нет смысла бэкапить гипервизор. Судя по всему, там одиночный сервер с локальными дисками. Бэкапить там просто нечего. Главное настроить бэкап виртуальных машин.

Ответить