On Thu, 2024-08-22 at 10:38 +0000, Eugen Block wrote:
I wonder if this could be a misunderstanding about the word "rescue". Maybe I'm the one who didn't understand it properly, but in the past we used the rescue mode to make instances bootable again if the bootloader hadn't been properly regenerated after an upgrade, or other issues. So we used 'openstack server rescue <UUID>' to get into a chroot environment and "rescue" the machine. Only the instance's root disk (ephemeral, not volume) is attached (+ optional config-drive) to the instance, the docs [1] contain this note:
Rescuing a volume-backed instance is not supported with this mode.
I never considered it as a method to restore an instance from backup. I assume OP is asking how to restore an instance from backup, but I'm not really sure.
rescue as you pointed out is not intendded for restoring form a backup its intened to be sued to boot form a resuce disk like Knoppix so that you can run fdisk or similar utils to fix the filesystem. rescuiing volume backed instance has been supported since ussuri https://specs.openstack.org/openstack/nova-specs/specs/ussuri/implemented/vi... i know at least one operator used that functionality to fix windows guests after the recent cloudstrink issues so that functionality does work. for libvirt configured with iamges_type=rbd rescue shoudl jsut work like any other "local" storage but ill admit i dothink think i have ever checked if addtional deata voluems are attach to the rescuded instace i thought they were but perhaps not.
[1] https://docs.openstack.org/nova/latest/user/rescue.html
Zitat von Metehan Cinar <meteccinar@gmail.com>:
Other Openstack users how to rescue their attached volume instances? What is the best practice this issue?
We are already rolling it back by creating new volume and new instance from volume snapshot/backup.
How to rollback by don't change instance?
Do you have any idea? If you have ideas, we wait your ideas.
Thanks for answer.