On Wed, 2024-08-21 at 12:48 +0000, meteccinar@gmail.com wrote:
Should I understand this? We can return to the snapshot with Rescue without recreating the same VM Instance. So is this reliable? How is it different from Volume Backup?
volume backup is a way of automating backups to happen on a regular basis https://docs.openstack.org/cinder/latest/admin/volume-backups.html rescuse is a nova api action that allows you to use optionally a diffent image to boot form a different os temporarily to try and fix filesytem and other problems that prevent booting. https://docs.openstack.org/api-ref/compute/#rescue-server-rescue-action rescue and backup are entirety unrelated concepts.
The reason why we create a new instance is to go back to the backup of the broken VM that was taken at time t before it broke down. In our scenario, it is necessary to perform inspections on the corrupted VM.
this can be done via rescue but if its needed for a protracted period of time and you need to restore the failed instnace in the meantime replaciign the instnace with a new one makes sense. i would not consider that to be a restore from backup in a normal sense as the port/vollumem uuids will change and that may be visabel to the applciation since the disk serial number will change and the port mac/ip will change a normal expection of restoring form a backup would not result in those changes.
In fact, for this reason, we want the instance to have a backup. Because it will contain metadata. When we run the instance backup without touching the main VM without re-entering additional information such as network, flavor, etc., we want to create the backups of all volumes as volumes and actually turn them into a copy at time t.
But as we mentioned, in this scenario, we create a volume backup, and when we connect the new volume created from this volume backup to the instance backup of the instance in the image section that we know belongs to that backup, the image is automatically connected to the snapshot taken snapshot while the image was created. This issue is confusing us. Could you please explain in more detail what strategy we should follow?
as documented in the create image api ref in the Asynchronous Postconditions section https://docs.openstack.org/api-ref/compute/#create-image-createimage-action """ in the volume-backed server case, volume snapshots will be created for all volumes attached to the server and then those will be represented with a block_device_mapping image property in the resulting snapshot image in the Image service. If that snapshot image is used later to create a new server, it will result in a volume-backed server where the root volume is created from the snapshot of the original root volume. The volumes created from the snapshots of the original other volumes will be attached to the server. """ so if you use the Create Image instnace action on a boot from volume instanec it will take a snapshot of the root volume and a snapshot of all the attached data voluems if you boot a new vm form that snapshot image it will also duplicate the data volumes form the volume snapshots. the restore api in nova is called rebuild, with microversion 2.93, we support rebuilding volume backed instances. https://docs.openstack.org/api-ref/compute/#rebuild-server-rebuild-action so if you want to restore in place then you can rebuild the instnace with the snapshot image. i would personally exepc that to reimage both the reootdisk adn roolback the volumes to the relevent volujme snapshot althoguh our api ref does not say one way or another. looking at the nova spec. https://specs.openstack.org/openstack/nova-specs/specs/zed/implemented/volum... that does not really cover this case either so you might need to seperatly role back the volume snaphost using https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=deta... or https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=deta...
Thank you for your answer in advance.