Server operations
Recover an unreachable server
Triage loss of access, protect recoverable data, and choose the least destructive operator-assisted recovery path.
On this page
Before you start
- The server name, region, current state, primary address, and time of the last successful access.
- A recent independent backup and an understanding of what data changed since that backup.
- The local SSH private key and any disk-encryption recovery material; never send private keys to support.
- A maintenance record for recent firewall, network, boot, storage, or OS changes.
Classify the failure before acting
First distinguish a account status problem from a connectivity problem. A PROVISIONING or SUSPENDED state, a Pending address, or a server past its paid-through time requires a different response from a reachable server that rejects SSH. Record the exact message rather than summarizing it as down.
Check from a second trusted network if practical, but do not run aggressive scans. If the address is reachable yet authentication fails, confirm the login name and matching private key. If the host key changed without an approved reinstall, stop and treat it as an identity problem.
| Symptom | Possible boundary | Least destructive next step |
|---|---|---|
| Server still provisioning | Delivery not completed | Ask the operator for provisioning status. |
| SSH timeout | Power, routing, firewall, or SSH service | Request KVM access before reinstalling. |
| Permission denied | Login or key mismatch | Verify account name and public/private key pairing. |
| Host key changed | Reinstall, reassignment, or interception | Verify the new fingerprint out of band. |
| Filesystem or boot error | Disk, RAID, or OS failure | Use read-only recovery first and preserve evidence. |
Choose the smallest action
Do not select Power off unless the operator has agreed on how the machine will be powered on again. The current client API does not expose a power-on action. Root-password rotation is also only a queued request and the API does not return a generated password, so it is not a self-service recovery path today.
- Capture the current server state and all visible identifiers before queueing anything.
- If the operating system may simply be hung, queue one Restart request and note its action suffix.
- If network or boot configuration is suspect, queue KVM and ask the operator to deliver console access.
- If rescue media is required, prepare a trusted custom ISO and checksum, then coordinate its mount with the operator.
- Use reinstall only when data recovery is complete or an independent backup has been verified.
Protect data during recovery
Prefer read-only inspection before repair. Identify disks, partitions, filesystems, and mount points before selecting a device. Names can differ after booting alternate media, especially on NVMe and multi-disk storage systems. If the failure may involve RAID or filesystem damage, capture diagnostics and consult a qualified operator before assembling arrays or running repair tools.
Never initialize a disk, create a new filesystem, rebuild an array, or reinstall merely to see whether it helps. Those operations can overwrite metadata needed for recovery. Keep recovered data off the affected server and verify it before destructive work.
lsblk --fs
ip -brief address
ip route show
ip -6 route showExpected result and escalation package
A successful recovery restores a verified administration path without unnecessary data loss, or produces a controlled plan to restore onto a clean system. Because queued actions have no client-visible completion state, maintain one timeline containing each action suffix and the operator’s confirmation.
When escalating, include the server and region, last-known-good time in UTC, visible state, source network, exact SSH or console error, recent changes, action references, and whether an off-server backup has been tested. Exclude passwords, private keys, recovery codes, and live console URLs. If the operator cannot restore safe access, agree on data capture and wipe boundaries before reinstalling.