Rescue mode starts an independent environment so you can inspect an unbootable Linux server. Begin with identification and read-only data preservation. The rescue environment's root filesystem is not automatically the installed server's root.
IN THIS ARTICLE
What you need before you begin
Confirm the correct server and authorized rescue access. Record the failure and any available console output. Identify encryption recovery keys and storage architecture, including LVM, RAID and separate boot partitions, before mounting anything.
01 Inspect an unbootable Linux server from rescue mode
- Boot the provider-approved rescue environment and inspect disks with
lsblk -fand available storage metadata. Distinguish the rescue media from the installed system disks. - Activate required storage layers through their supported read-only or recovery workflow where possible. Do not initialize an unfamiliar disk, assemble an ambiguous array with force options or recreate encryption metadata.
- Mount the identified filesystem at a separate inspection directory using the filesystem's appropriate read-only/no-replay options when evidence preservation matters. A simple read-only mount can still have filesystem-specific journal-replay implications.
- Inspect configuration, logs and critical data under that mount. Confirm the operating-system identity and fstab correspond to the intended server.
- Copy valuable readable data to independent storage before risky repair. If a controlled repair requires writes or a chroot, explicitly plan the additional mounts, boot mode and filesystem-check requirements first.
- Unmount cleanly when finished, disable rescue boot and use the console for the next normal startup.
Why does changing a file in rescue mode not affect the server?
You may have edited the rescue environment instead of the mounted installed system. Confirm the full target path and mounted source before changing configuration.
Confirm the expected result
Confirm the correct installed filesystem was inspected and any preserved files can be read from the independent destination. Record the exact device mapping and findings. If returning to normal boot, verify storage mounts and application integrity before reopening service.
Troubleshoot unexpected results
For I/O errors or corruption, avoid repeated aggressive scans on failing hardware and consider an image/recovery specialist. Do not run a filesystem repair while that filesystem is mounted in an unsafe state. Missing decryption keys or uncertain RAID membership need a recovery-specific plan rather than guessed commands.