Server operations
Prepare and request a server reinstall
Protect your data, record the intended target, queue the destructive reinstall request, and verify the machine after operator completion.
On this page
Before you start
- A verified backup stored outside the server, including the data, configuration, keys, and recovery material you need.
- A successful restore test or another concrete way to verify that the backup is usable.
- The server name, region, current operating system, desired operating system, and required boot layout.
- A retained local copy of the SSH private key; only its public counterpart belongs on the server.
Treat reinstall as destructive
A reinstall can overwrite partitions, boot loaders, encryption headers, operating-system configuration, application data, and host keys. A snapshot or backup located only on the same physical server is not sufficient protection. Copy required material to independent storage and test that you can read it before requesting the action.
Record which disks contain customer data and which disks are intended for the new system. Storage-server configurations may expose many devices, and names can change between installers. Do not rely on an old /dev/sdX name alone. Capture serial numbers and the current layout from your own tooling if the server is still reachable.
Record the intended outcome
The current dashboard does not collect these choices with the reinstall request. Send them to the operator through the approved support workflow before or immediately after queueing. The operating system selected on the original order remains recorded, but the action payload contains no replacement OS selection.
- Server name, region, and order reference.
- Desired OS edition and architecture, plus your licence source where applicable.
- Expected disk or RAID layout and which devices may be erased.
- The SSH public key to install; keep the private key local and secret.
- Any required network settings and the maintenance window.
Queue the reinstall
The expected immediate result is QUEUED, not a completed reinstall. No action-status endpoint exists, and the account service does not provide a root password. Do not interpret a page refresh or an unchanged server state as proof of success or failure.
- Open Account > Servers and match the server name and region against your maintenance record.
- Stop application writes using your own administration process and take the final off-server backup.
- Select Reinstall OS and read the destructive-action confirmation carefully.
- Confirm once, then copy the shortened queued action reference shown on the button.
- Ask the operator to correlate that action with your desired OS and disk-layout instructions.
- Wait for explicit completion and a new host-key fingerprint before attempting SSH.
Verify after completion
Compare the new host-key fingerprint with the value delivered by the operator before accepting it. Then verify the OS, addresses, routes, and disks before restoring data. The old fingerprint is expected to change after reimaging, but a change is safe only when you can tie it to this completed maintenance event.
If the server does not boot, the wrong OS appears, disks are missing, or SSH rejects the intended key, stop restoration. Preserve console errors and contact the operator with the queued action reference. Do not repeat the reinstall request: another destructive pass can remove evidence and complicate recovery.
ssh -i ~/.ssh/id_ed25519 root@SERVER_IP
cat /etc/os-release
ip -brief address
ip route show
ip -6 route show
lsblk --fs