Recovery Reboot

Booting an SSD VPS into recovery mode starts your virtual server from a separate Ubuntu recovery image instead of your installed operating system. Your server’s disk is left untouched and is available to mount from within the recovery environment, allowing you to troubleshoot and repair your system. Recovery mode is useful for tasks such as:

• Fixing boot errors or a broken /etc/fstab
• Regaining access after losing an SSH key or breaking your SSH or firewall configuration
• Resetting a user’s password
• Copying important data off the server

How to log in to the recovery image

There are two ways to log in to the recovery image:

User	Credential	Available for
ubuntu	Your server’s SSH key	Servers deployed with an SSH key
root	A temporary password created for the recovery image	All servers, including servers deployed without an SSH key

You can use either login over SSH, or from the Console tab on your server’s page. The temporary password is shown on your server’s page while it is in recovery mode.

The temporary password only works for the recovery image

A new temporary password is created each time you perform a Recovery Reboot. It only works for the recovery image and stops working when you leave recovery mode. It does not change the root password of your installed operating system.

Step 1: Boot into recovery mode

Console

1. To perform a Recovery Reboot on a server, navigate to the relevant server page, select Server Actions and choose Recovery Reboot.

2. You will be presented with a confirmation dialogue. Select Recovery Reboot again to confirm the action.

3. Once complete, a green pop-up message will confirm the success of the action.

4. On the server’s Server Information tab, a recovery mode box shows how to log in, including the temporary password. Select the eye icon to reveal it, or the copy icon to copy it.

API

Get Server ID and Location ID

curl --request GET \
--url https://api.ingenuitycloudservices.com/rest-api/ssd-vps/servers \
--header 'Accept: application/json' \
--header 'X-Api-Token: API_KEY'

Recovery Reboot

curl --request POST \
  --url https://api.ingenuitycloudservices.com/rest-api/ssd-vps/locations/{location_id}/servers/{server_id}/power/recovery-reboot \
  --header 'Accept: application/json' \
  --header 'X-Api-Token: API_KEY'

Get the temporary password

Once the server is in recovery mode, the server details include the temporary password in the rescue_password field. The field is empty when the server is not in recovery mode.

curl --request GET \
--url https://api.ingenuitycloudservices.com/rest-api/ssd-vps/locations/{location_id}/servers/{server_id} \
--header 'Accept: application/json' \
--header 'X-Api-Token: API_KEY'

Step 2: Connect to the recovery image

Once the server has booted into recovery mode, connect over SSH using your server’s public IP address. The examples below use 203.0.113.10 as the server IP.

With your SSH key, connect as the ubuntu user:

ssh ubuntu@203.0.113.10

If your key is not in the default location, specify it with -i:

ssh -i ~/.ssh/my_key ubuntu@203.0.113.10

The ubuntu user has sudo privileges. Switch to a root shell to carry out recovery tasks:

sudo -i

With the temporary password, connect as root and enter the password when prompted:

ssh root@203.0.113.10

SSH uses port 22, so make sure your server’s firewall allows it from where you connect. If you can’t connect over SSH, log in from the Console tab on your server’s page instead.

Host key warning

The recovery image has a different SSH host key to your normal operating system, so your SSH client may show a REMOTE HOST IDENTIFICATION HAS CHANGED warning and refuse to connect. This is expected. Remove the old entry and connect again:

ssh-keygen -R 203.0.113.10

You will need to do this again when you return to your normal operating system.

Step 3: Mount your server’s disk

Your server’s disk is attached to the recovery image as a second disk, usually /dev/vdb. It is not mounted automatically. First, identify it:

lsblk -f

The output lists each disk and its partitions along with their filesystem types. Your server’s root filesystem is usually the largest ext4 or xfs partition on vdb. The device names below (such as /dev/vdb1) are examples, so use the names shown in your own lsblk output.

Mount the root partition:

mount /dev/vdb1 /mnt

AlmaLinux, CentOS Stream and Rocky Linux

These operating systems may use LVM, in which case lsblk -f shows a partition of type LVM2_member. Activate the volume group and mount the root logical volume instead:

vgchange -ay
lvs                      # list logical volumes to find the root volume
mount /dev/VOLUME_GROUP/root /mnt

Your server’s files are now available under /mnt.

Step 4: Fix the problem

The examples below cover common recovery tasks.

Add a new SSH key

If you have lost the private key for your server, or your server was deployed without one, add a public key to the authorized_keys file on your server’s disk.

For the root user:

mkdir -p /mnt/root/.ssh
echo "ssh-ed25519 AAAAC3Nza... you@example.com" >> /mnt/root/.ssh/authorized_keys
chmod 700 /mnt/root/.ssh
chmod 600 /mnt/root/.ssh/authorized_keys

For your server’s default user, replace ubuntu with its username (for example debian):

mkdir -p /mnt/home/ubuntu/.ssh
echo "ssh-ed25519 AAAAC3Nza... you@example.com" >> /mnt/home/ubuntu/.ssh/authorized_keys
chmod 700 /mnt/home/ubuntu/.ssh
chmod 600 /mnt/home/ubuntu/.ssh/authorized_keys

If you created the .ssh directory, give it to the user. Use the numeric user and group IDs from /mnt/etc/passwd, because the recovery image has different users to your server:

grep ubuntu /mnt/etc/passwd         # e.g. ubuntu:x:1000:1000:...
chown -R 1000:1000 /mnt/home/ubuntu/.ssh

AlmaLinux, CentOS Stream and Rocky Linux

These operating systems use SELinux. Files written from the recovery image may have the wrong security labels, which stops SSH from reading them. Make your server relabel its files on the next boot:

touch /mnt/.autorelabel

Run commands inside your installed system (chroot)

To run commands as if you were logged in to your normal operating system, for example to reset a password or reinstall a package, chroot into the mounted disk:

for d in dev proc sys; do mount --bind /$d /mnt/$d; done
chroot /mnt

# Examples:
passwd root             # reset your server's root password
passwd ubuntu           # reset a user's password
nano /etc/fstab         # fix a broken fstab entry

exit                    # leave the chroot when finished

Copy data off the server

From your local computer, use scp or rsync to download files from the mounted disk. Logging in as root with the temporary password lets you copy any file:

scp -r root@203.0.113.10:/mnt/home/ubuntu/important-data ./

If you copy as the ubuntu user instead, files only readable by root may need to be copied to a location the ubuntu user can read first, or have their permissions adjusted, before downloading.

Step 5: Return to your normal operating system

When you have finished, unmount the disk:

umount -R /mnt

Then perform a normal Reboot from the control panel or API to boot back into your installed operating system. See Power Actions. The temporary password stops working at this point.

Once the server is back online, log in as usual. If you see a host key warning, run ssh-keygen -R <server-ip> as described above.

If you are unable to recover your server, please contact our support team.