Guide: Rescue and Recovery: Difference between revisions

From bwCloud-OS
Jump to navigation Jump to search
Admin (talk | contribs)
Created page with "== Restore Access to VM == {| class="mw-message-box mw-message-box-warning" | style="vertical-align:middle;" | '''⚠️ Please Note:''' The steps described here are an emergency measure. You should secure your SSH keys well to avoid such situations. |} Can you rule out that this is not a network problem? If so, please refer to the following instructions. The procedure described there can be carried out via the [https://portal.bw-cloud.org/auth/login/?next=/ Dashboard]..."
 
No edit summary
Line 1: Line 1:
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.
== Restore Access to VM ==   
== Restore Access to VM ==   
{| class="mw-message-box mw-message-box-warning"
{| class="mw-message-box mw-message-box-warning"
| style="vertical-align:middle;" | '''⚠️ Please Note:''' The steps described here are an emergency measure. You should secure your SSH keys well to avoid such situations.
| style="vertical-align:middle;" | '''⚠️ Note:''' The steps described below are '''emergency recovery procedures'''. This workaround is cumbersome but can help you recover access or retrieve your data. ''To prevent situations like this, always store and manage your SSH keys securely.''
|}
|}
Can you rule out that this is not a network problem? If so, please refer to the following instructions. The procedure described there can be carried out via the [https://portal.bw-cloud.org/auth/login/?next=/ Dashboard] or the [[Programmatic Access and Automation|CLI]].
Before proceeding, make sure the issue is '''not caused by network problems''' (e.g., security group misconfiguration or floating IP changes). If you've confirmed that it's 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., <code>foo1_vm</code>).
# Ceate a snapshot image of the instance and name it (e.g., <code>foo1_img</code>).
# Use <code>foo1_img</code> to create a new volume, e.g., <code>foo1_vol</code>.
# Launch a fresh VM (e.g., <code>foo2_vm</code>) using a known working key pair.
#  Attach <code>foo1_vol</code> to <code>foo2_vm</code> and mount its file system (this contains the original VM’s disk).


Unfortunately, the solution is somewhat cumbersome.
At this point you can '''recover your data''' from the mounted volume.
----


Proceed as follows:
=== Optionally: Restore the Original Instance ===
# Stop the instance <code>foo1_vm</code> with the ID <code>vm-uuid</code>. 
# Create a backup/image <code>foo1_img</code> of the instance. 
# From the image <code>foo1_img</code>, create the volume <code>foo1_vol</code>. 
# Create a new instance <code>foo2_vm</code>. 
# Attach the volume <code>foo1_vol</code> to the instance <code>foo2_vm</code> and mount the filesystem of the original instance <code>foo1_vm</code>. 


With the volume <code>foo1_vol</code> at hand, you have several options: 
* Copy a new SSH public key into the original VM's authorized_keys file.
* Copy your data. 
* Reverse the procedure above to rebuild the original instance.
* Copy an SSH key to the volume.
* Reverse steps 1–5 to restore the original instance <code>foo1_vm</code>.

Revision as of 17:26, 21 October 2025

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.


Restore Access to VM

⚠️ Note: The steps described below are emergency recovery procedures. This workaround is 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've confirmed that it's not a network issue, follow the steps below. These steps can be carried out via the Dashboard or the CLI.

Recovery Procedure

  1. Stop the affected VM (e.g., foo1_vm).
  2. Ceate a snapshot image of the instance and name it (e.g., foo1_img).
  3. Use foo1_img to create a new volume, e.g., foo1_vol.
  4. Launch a fresh VM (e.g., foo2_vm) using a known working key pair.
  5. Attach foo1_vol to foo2_vm and 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.