Server Admin Авторский блог системного администратора
Здравствуйте. Заниматься proxmox только начал. Поставили задачу снятия бэкапа с именно системы (не с ВМ или контейнеров). Чтобы потом, "если что", можно было снова развернуть гипервизор со всеми настройками (при условии, что с ВМ и контейнерами всё в порядке). Всё работает на lvm. ВМ, контейнеры и их образа установочные, лежат на сториджах в виде отдельных дисков (подключались как директории). Тушить систему - нельзя. Иначе бы тупо снял имидж с диска тем же dd.
Принцип работ себе представляю. Но - образно. =(( Снять снапшот с рабочей системы. Примонтировать внешний диск. Упаковать и перекинуть на внешний диск. Отмонтировать диск. Удалить снапшот. Это - только как сделать бэкап. А, вот, как потом его развернуть, увы...
Понимаю, что, если, мы меняем диск системный, то меняется uuid диска. Соответственно, нужно будет подсунуть системе старый uuid при разворачивании бэкапа. А так же, настраивать загрузочный сектор.
За рабочую методику с разъяснениями готов поощрить финансово. По договорённости. Возможно, здесь это не принято. Но, своими силами этот вопрос я не решу. А всё, что находил в сети, мало понятно. Спасибо.
Получилось у вас задуманное сделать?
У меня ситуация немного хуже. Умер 1сник который на proxmox в виртуалку поставил win2008 server. Я к этому отношения до этого не имел, но теперь пытаюсь все ниточки собрать воедино.
Сделал подобное у себя натдомашнтх компах, но нормально вин2008 сервер не могу оттуда вытянуть. Пароль получилось достать только на proxmox, но система еще не отключалась. Так при отключении сделал бы бэкап жесткого и пробовал добраться до админа вин2008
Здравствуйте.
Как Вам уже ответил хозяин форума, по факту имеем дебиан, который тупо можно копировать файлами. Или вообще сделать dd диска. Но, у меня была задача от руководителя. =) А задачи - не обсуждаются. =))) Кто девушку заказывает - тот ее и танцует. =)))
Всё решение состоит из 2 частей. Общий бэкап системы (делается 1 раз). И, ежедневный бэкап папок с настройками гипервизора (его здесь не указываю, делается архивированием папок /etc и /root через скрипт, и задание потом в cron).
1.
1.1 Тушим proxmox, грузимся с образа clonezilla (в принципе, можно любой никс-загрузочный образ. Но, этот выбран был из-за скорости работы и его уже изначальной наполненности программами. Пытались сделать бэкап по пошаговому мастеру - вышло очень коряво. А предлагаемый хозяином форума Veeam у нас не завёлся сразу, разбираться не стали). В процессе загрузки последовательно по меню уходим в терминал.
# sudo su (Все действия под рутом.)
1.2 Смотрим, какое имя у диска, который будем монтировать под бэкап
# lsblk -l (список дисков в системе. Proxmox, скорее всего, будет на sda)
1.3 Монтируем диск в удобную папку.
1.4 Копируем всё sda, упаковываем архиватором и кладём по нужному пути примонтированного диска для бэкапов (здесь в папку /mnt. Имена сами придумаете для файлов. В настройках 7zip, здесь это 7za, ключ -р это пароль. В данном случае пароль 1234):
# partclone.dd -s /dev/sda1 | 7za -si -p1234 a /mnt/pack-sda1.7z
# partclone.dd -s /dev/sda2 | 7za -si -p1234 a /mnt/pack-sda2.7z
# partclone.dd -s /dev/pve/root | 7za -si -p1234 a /mnt/pack-root.7z
Т.к., всё это собиралось уже пол года назад, немного не уверен в последней команде. Кажется, /dev/pve/root находится на sda3. В принципе, можно целиком его заархивировать. Требует проверки, давно делал.
1.5 Снимаем информацию по структуре диска sda и его разделов и кладём в файл, который потом можно легко просмотреть:
# sfdisk -d /dev/sda > /mnt/bckp-pve.struct
---
2. При выходе из строя диска с гипервизором - подсовываем новый и разворачиваем наши архивы в обратной последовательности на пустой диск, так же загрузившись с clonezilla или с любого live-DVD от дебиан-подобного дистра. Все действия под root.
# sfdisk -f /dev/sda < /mnt/backup/bckp-pve.struct (воссоздаём структуру диска)
# 7za -so -p12341 x /mnt/pck-sda1.7z | partclone.dd -o /dev/sda1
# 7za -so -p1234 x /mnt/pck-sda2.7z | partclone.dd -o /dev/sda2
# 7za -so -p1234 x /mnt/pck-root.7z | partclone.dd -o /dev/pve/root
При попытке загрузиться с нового диска, скорее всего, будет ошибка: отсутствует медиа-устройство для запуска.
Тогда грузимся либо с деб-лив-двд, либо с установочного дистра proxmox (здесь в Rescue boot). И выполняем две команды:
# update-grub
# grub-install /dev/sda
Перегружаемся. (Взято отсюда: pve.proxmox.com/wiki/Recover_From_Grub_Failure)
---
Вопрос целесообразности подобного действа - риторический. Спрашивал у импортных пользователей, кто уже давно на proxmox-е "съел собаку" - так же ставили квадратные глаза "а зачем?" Как было объяснено мне (повторюсь: обсуждать подобное было, не то что бы, нельзя. Но - бессмысленно), подобный процесс защищает от выхода из строя гипервизора, который "лежит" в забугорье. Мол, кто их там знает, как быстро они там среагируют на проблему, и, вообще, не известно, как у них реализована поддержка пользователей (бэкапирование, зеркалирование). А у нас уже есть готовый набор для разворачивания. В целом же, да. Можно просто сохранить настройки гипера и сами виртуалки с контейнерами. А потом накатить новый гипер и восстановить настройки с ВМ.
@spoonlight неслабо заморочились. По сути это инструкция по бэкапу железного сервера. Пока не появилась виртуализация, я активно занимался подобным. Вот похожая инструкция для freebsd - https://serveradmin.ru/vosstanovlenie-ili-perenos-servera-freebsd-za-30-minut/
Вообще, обычно гипервизоры не бэкапят. К ним такой подход - гипервизор можно легко заменить, перенеся все виртуалки на новое место. По большому счету, что там бэкапить? Сетевые настройки? Подключенные сторейджи? Все это хранится в конфиг файлах или xml. Достаточно сохранить только то, что нужно. Я не вижу смысла бэкапить сам гипервизор. Никогда не видел таких задач.
В общем случае, подход должен быть такой же, как к любой линукс системе, каковой и является сервер виртуализации proxmox. Там обычный debian под капотом. Можно тем же Veeam agent for Linux забэкапить, если очень хочется.
@zerox Здравствуйте, уважаемый.) Большое спасибо за ответ.)
Да, я в курсе, что непосредственно систему гипервизора не бэкапят.) Самому подобное странно решать. Но - вот такое задание. Относительно слива папок с настройками (в принципе, да, там всё прозрачно, тупо можно скачать папки с конфигами, а потом залить их на переустановленную систему) делать пробовал: проблема как раз с uuid дисков, которые остались от storage старой системы. Т.е., их потом нужно бы подмонтировать. При этом, система начинает видеть, какие ВМ и контейнеры ей подпихнули, но сами storage, понятно, она не видит.
Может, не совсем понимаю. Но, как решается вопрос, когда несколько десятков ВМ/контейнеров, и "падает" сам гипервизор? Или, может, попытаться решить этот вопрос по-другому? Отбэкапить пару тестовых ВМ и развернуть их на вновь поднятом гипервизоре? Как быстро восстановить работу proxmox, если не сливом/разворачиванием снятого ранее образа?
@spoonlight я всегда делаю так. В обязательном порядке есть подменный сервер, на котором либо уже стоит гипервизор, либо его туда можно быстро установить.
Делается бэкап виртуальных машин. Они в обязательном порядке восстанавливаются на запасном гипервизоре, чтобы была уверенность, что с ними все в порядке и они корректно разворачиваются. К сожалению, бывает так, что при восстановлении из бэкапа появляется какая-то ошибка. Сталкивался с этим многократно сам, плюс привлекался к таким задачам со стороны других организаций, которые не смогли восстановиться из бэкапов после аварии. Бэкапы вроде и делали, но не проверяли. А когда все сломалось, оказалось, что восстановиться не получается.
Исходя из принципа, что всегда должен быть запасной, подменный гипервизор, бэкапить основной нет смысла. Горячая замена должна быть наготове здесь и сейчас. Без нее банально нельзя убедиться в том, что бэкапы рабочие.
Думаю, вам стоит донести эту мысль до руководства и просто смоделировать выход из строя основного сервера. Продумать все варианты действий и время, которое уйдет на восстановление. Например, вы сейчас разработаете схему бэкапа гипервизора. А как вы тестировать эти бэкапы будете, если нет запасного? А если есть запасной, зачем бэкап гипервизора?
В общем, работа системного администратора это не только выполнение пожеланий сверху, но и своя голова на плечах. Нужно доносить правильные идеи до руководства. Объяснять, как лучше поступать, чтобы гарантировать максимальную доступность обслуживаемых сервисов.
@zerox В целом, я с Вами согласен. )) Но, в любом вопросе может быть своё "но". В данной ситуации, боевой сервер находится не в стране. Гарантировать порядочность хостера тоже нет возможности (рассказали одну страшилку, что когда были на одном хостинге, и вдруг упал диск с гипервизором, хостер только развёл руками, сказав, что никто от этого не застрахован. =) Т.е., хостер за состоянием своего железа не следил от слова совсем.)
Второй дубль-сервер фирма позволить себе не может. Есть только личный, старенький hp dl360 g5, на котором пытаюсь отрабатывать вот такие "неполадки".
@spoonlight если арендуется выделенный сервер, то хостер действительно за ним не будет следить. Когда что-то сломается, он по вашей заявке починит, не более. Так что следить за железом вам надо самим. Как минимум, мониторинг дисков настроить.
В данном случае тем более нет смысла бэкапить гипервизор. Судя по всему, там одиночный сервер с локальными дисками. Бэкапить там просто нечего. Главное настроить бэкап виртуальных машин.
