Guide: Rescue and Recovery: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 6: | Line 6: | ||
| style="vertical-align:middle;" | '''⚠️ Note:''' The steps described below are '''emergency recovery procedures'''. This workaround is quite cumbersome but can help you recover access or retrieve your data. ''To prevent situations like this, always store and manage your SSH keys securely.'' | | style="vertical-align:middle;" | '''⚠️ Note:''' The steps described below are '''emergency recovery procedures'''. This workaround is quite cumbersome but can help you recover access or retrieve your data. ''To prevent situations like this, always store and manage your SSH keys securely.'' | ||
|} | |} | ||
Before proceeding, make sure the issue is '''not caused by network problems''' (e.g., security group misconfiguration or floating IP changes). If you have confirmed that it is not a network issue, follow the steps below. These steps can be carried out via the '''[https://bw-cloud.org/ | Before proceeding, make sure the issue is '''not caused by network problems''' (e.g., security group misconfiguration or floating IP changes). If you have confirmed that it is not a network issue, follow the steps below. These steps can be carried out via the '''[https://portal.bw-cloud.org/ Dashboard]''' or the '''[[Programmatic Access and Automation#OpenStack Client|CLI]]'''. | ||
=== Recovery Procedure === | === Recovery Procedure === | ||
Latest revision as of 18:36, 10 November 2025
Restore Access to VM
In some cases, you may lose access to a running virtual machine (VM) — for example, if your SSH key is missing. This guide explains how to recover your data or restore access to the instance.
Before proceeding, make sure the issue is not caused by network problems (e.g., security group misconfiguration or floating IP changes). If you have confirmed that it is not a network issue, follow the steps below. These steps can be carried out via the Dashboard or the CLI.
Recovery Procedure
- Stop the affected VM (e.g.,
foo1_vm). - Ceate a snapshot image of the instance and name it (e.g.,
foo1_img). - Use
foo1_imgto create a new volume, e.g.,foo1_vol. - Launch a fresh VM (e.g.,
foo2_vm) using a known working key pair. - Attach
foo1_voltofoo2_vmand mount its file system (this contains the original VM’s disk).
At this point you can recover your data from the mounted volume.
Optionally: Restore the Original Instance
- Copy a new SSH public key into the original VM's authorized_keys file.
- Reverse the procedure above to rebuild the original instance.