What is rescue mode, and when do you need it

What this covers: This article explains rescue mode as a general concept, so you can tell when it is the right approach. The recovery paths documented for Worldstream servers are a reinstallation from Portal on a dedicated server, and installing from an ISO image on a Flexible VPS. If neither fits what you are trying to do, open a support ticket and describe what the server is doing.

What rescue mode actually is

Every server needs a working chain to boot: firmware finds a bootloader, the bootloader loads a kernel, the kernel mounts a root filesystem and starts the OS. See What happens when a server boots for the full sequence. Rescue mode exists for the moment that chain breaks on the server's own disk. Instead of trying to boot from the broken installation, the server is pointed at a separate, known-good minimal OS, network-booted or loaded from an external image, that boots independently of whatever is or isn't wrong with the installed system.

Once you're in, you have a working shell and, critically, access to the server's disks as data rather than as a boot target. You can mount them, look at what's on them, copy files off, edit a config file, rebuild a bootloader, or run filesystem repair tools, all without the broken OS needing to start first.

When rescue mode is the right tool

• A broken bootloader. GRUB or the Windows Boot Manager is misconfigured or missing, and the server never gets past the point where firmware hands off to it.
• A bad kernel update. A newly installed kernel fails to boot and there's no working older kernel entry to fall back on from the boot menu.
• A forgotten or locked-out root password. You can mount the disk from outside the OS and reset the credential file directly, without needing to already be logged in.
• Recovering files off a disk that won't boot. The OS is unusable but the data on disk is still intact, and you need to get files off before reinstalling or replacing anything.
• Checking or repairing a filesystem. Running fsck or an equivalent tool against a filesystem that's suspected of being corrupted generally shouldn't be done while that same filesystem is mounted and in active use, which rescue mode's separate boot environment lets you avoid.

When it isn't the right tool

Rescue mode solves problems with the boot chain and with a disk you can't otherwise reach. It doesn't solve problems that live inside a healthy, running OS. If the server boots normally and responds over SSH, but a website is throwing errors, a service has crashed, or an application is misbehaving, that's ordinary troubleshooting inside a normal session, not a rescue-mode scenario. Booting into rescue mode for a problem like that adds a step for no benefit: the OS that's actually misbehaving isn't even running while you're in there.

Disks come in unbooted, not unencrypted or unassembled

It's worth being precise about what rescue mode hands you: access to the physical disks in an unbooted state, not a ready-made view of your data. If the original OS used disk encryption, a software RAID array, or LVM, none of that gets assembled automatically just because you're now in a working shell. You still need to unlock the encrypted volume, assemble the RAID array, or activate the LVM volume group yourself before the filesystem underneath is something you can mount. Treating the raw block device as if it were a plain, single disk skips straight past whatever layer sits on top of it and won't get you anywhere. See Mounting a disk in Linux for how mounting works once you've identified the right layer to mount.

Rescue mode vs. reinstalling

Rescue mode and reinstalling solve different problems. Rescue mode gets you into a server whose data you still want, so you can repair, inspect, or recover it. Reinstalling wipes the disk and puts a fresh OS on it, which is the right call once you've decided the existing installation isn't worth saving, or once you've already recovered what you needed from it. See How to start a reinstallation for the supported reinstall path.