Pull to refresh

Comments 26

1.
Резервные копии рекомендуется сразу скачивать с сервера и сохранять в надежном месте, например, в нашем облачном хранилище.

А можно подключить удаленное хранилище к Proxmox и сразу на него лить бэкап.

2. При клонировании виртуальной машины что бы не играться со сменой айпи на исходной — есть возможность перед включением склонированной виртуальной машины — отключить у неё доступ к сети поставив в настройках сетевого интерфейса виратульной машины галочу Disconnect, загрузиться, через консоль зайти на нее и поменять на нужный iр и после этого вернуть свежей виртуальной машине доступ к сети.

3. С 6ой ветки есть возможность не мучаться с настройкой бэкапа для каждой виртуальной машины в отдельности, а делать бэкапы на основе пулов виртуальных машин, это намного удобней.
А можно подключить удаленное хранилище к Proxmox и сразу на него лить бэкап.
С точки зрения безопасности правильнее чтобы не резервируемый закачивал бэкапы на сервер, а сам сервер забирал бэкапы с резервируемого. В первом варианте в случае взлома (или банального rm -rf /, если речь про примонтированное в файловую систему хранилище) можно потерять всё сразу.
В общем то да, но все зависит от разных ситуаций.
А можно подключить удаленное хранилище к Proxmox и сразу на него лить бэкап.

Это оправдано, если удаленное хранилище быстрое. Или не слишком важно время простоя. Ведь в режиме snapshop производительность падает, а в suspend и stop вм вообще простаивает.

И в статье ни одного слова про qemu-guest-agent, который хотя бы попытается предупредить гостевую ОС и сервисы в ней о том, что вот прям сейчас нужно сохранить все данные из памяти на диск, иначе в конечном бэкапе может получиться немного каши с супом…
Начнем с того, что Proxmox имеет неплохой штатный инструментарий для создания резервных копий виртуальных машин.

Если VM маленькие и их мало — да, неплохой. Как только их размеры начинаются от сотен гигабайт (не говоря уже про терабайты) — то создание резервных копий напрочь убивает производительность (особенно если пытаться сделать дифференциальный бэкап), иногда от нескольких часов до суток.

А теперь возьмите узел с десятком нагруженных VM по 300-400 гиг в каждой, на обычых (не SSD) дисках, попробуйте делать ежедневные бэкапы и начинайте плакать глядя как всё тормозит.

Боюсь предположить, что в предложенном Вами сценарии иные гипервизоры тоже звёзд с неба хватать не будут.
Думаю логичным выходом при наличии таких вводных будет использование внешних хранилищ данных или чего-нибудь другого. Кстати proxmox очень неплохо дружит с ceph. (https://pve.proxmox.com/wiki/Ceph_Server)
Сабж очень хорош контейнерами lxc, а их нарастить до нескольких Тб надо постараться, а, в свою очередь, маленькие контейнеры резервировать описанными автором средствами одно удовольствие

Если использовать алтернативные методы бэкапа (не встроенные в гипервизоры) то можно значительно снизить затраты. К примеру те же restic/borg, работающие изнутри контейнеров/VM, существенно сокращают время за счёт локального кэша метаданных и отсутствия необходимости сравнивать всё со всем при каждом проходе.

Для Windows VM можно использовать средства которые отслеживают изменения в блоках устройств (Acronis/Macrium/etc), соответственно не пытаясь копировать всё каждый раз.

Проблема с vzdump именно в том что он «тупой» — копирует либо весь блочный файл (если это не Linux), либо сравнивает старый tar с текущим состоянием перед созданием инкрементального бэкапа.
Зачем автору поста переписывать всю wiki с официального сайта proxmox? Cуть поста в знакомстве пользователя с софтом, краткий обзор, его не стоит воспринимать как пошаговую инструкцию + как must have и никак иначе.

Когда речь заходит об windows — это совсем другая «парафия», где софт от MS и средства его бекапа заточены специально под них и в большинстве случаев за деньги. Потому человеку стоит всегда составить список "+" и "-" за тот или иной инструмент, а потом еще почитать опыт использования, что бы сложилось впечатление и сделать верный выбор.
Я просто отметил слабые места, не более того. Как показывает практика, люди часто даже не думают об альтернативах если есть «стандартные» средства, хотя далеко не всегда они самые эффективные.
Полностью согласен, оно еще и бэкапы в режиме снапшота делает со скоростью обычного копирования.

Proxmox Backup Server использовать не пробовали?

Самая большая проблема это отсутствие энкриментальных и отсутствие нормальной возможности достать один файл.
А раз в год бекап превращающийся в зомби с la 60- святое дело.....

На самом деле это выглядит как инструкция по установке MS Office (например): тысяча параметров, но всем интуитивно понятна.
Лучше б описали тонкости работы, это все же хабр. Например, развертывание ВМ с имеющегося образа, восстановление ВМ из бэкапа другого Proxmox, простейший кластер

восстановление не возможно при большой разнице в версиях, в первую очередь если попытаемся развернуться на старом кластере
Тонкостей нет, т/к прилично багов и нужно тупо разбираться, в конце года у меня группа серверов перегружалась переодически бессимптомно, аля ресет, на форуме кроме обновлений нашли подобное поведение изза ha, lacp и т/д и т/п
Ну и стоит ли говорить что даже без ha если не собрался кворум (короче вылетели 3 ноды) у вас виртуалки не подымутся
Ну и кучу ошибок у проксмокса закрывается фразой решено в следующих релизах, за 5 лет таких багов штук 20 было

Увы, но бекапить таким образом сервера баз данных не получится — данные из памяти будут записаны не полностью на диск.
Такие виртуалки приходится специальным образом приостанавливать.
Для mysql — переводить сервер в режим read-only.
Остальных — просто останавливать.
Плюс тупой бекап в текстовый SQL-файл.


Сам бекап делать в 2 прохода: первый rsync, приостановить БД, ВМ в suspend, второй rsync, ВМ в resume, отпустить БД.


Такое прокатывает с небольшими виртуалками на OpenVZ / LXC.
Как безопасно для данных сворачивать виртуалки в KVM, и тем более с Windows — пока не придумал.

А кто-нибудь знает, можно ли в штатном бэкапе Proxmox исключить какой-то диск из бэкапа виртуальной машины? Я, к примеру, почти никогда не делаю полные бэкапы виртуальных машин, потому что это неудобно. Обычно бэкаплю системные диски с настройками, а сами данные забираю другим способом (rsync, mysqldump и т.д. в зависимости от данных). В proxmox не понимаю, как применить этот подход, потому что он всегда пытается забэкапить всю виртуальную машину целиком.
В свойствах диска опция no backup.

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

Автор статьи забыл рассказать как ограничить количество резервных копий. Или это было в предыдущих статьях.

«Датацентр» ➜ «Хранилище»

image
А нельзя делать бекап первым способом (снимок), но так, что бы перед началом бекапа виртуальная машина скинула все кеши на диск и бекап был консистентным?
pve.proxmox.com/wiki/Qemu-guest-agent

Лично у меня стоит режим «Остановка». Не вижу в этом ничего плохого, а вот битые бэкапы в режиме «Снимок» уже были.

P.S. Мне кажется, что ссылки на официальную WiKi чуть более полезны.

Есть ли способ бекапа vm если на диске есть ошибки чтения? У меня бекап завершается с ошибкой io read error. Команда dd имеет опцию noerror а есть ли что тут подобное? Ошибки возникают только вовремя бекапа. На диске эти данные судя по всему несущественные так как при обычной работе вм ошибок нет

Sign up to leave a comment.