- Have the server reference ready.
- Identify the data that must survive.
- Check the last usable backup.
Begin with the narrowest failure
Check platform status and server power. If SSH fails on a running machine, review SSH and the firewall through the console. If SSH works but the app fails, investigate the app and dependencies first.
Record the original error and time. Many unrelated changes erase the trail you need to diagnose the cause.
Use the console as another path
Inspect boot messages, services and disk space. Console access is still privileged access, so protect passwords and screenshots just as carefully as an SSH session.
After repairing access, test a fresh external connection while keeping the console open.
Select a restore for its contents
Choose the point containing the data you need, preserve newer data and confirm the target server. Isolate duplicated schedules and integrations until validation is complete.
Check the entire application flow rather than only the newest recovery timestamp.
Reinstall with a clear boundary
A reinstall replaces the selected server’s OS. Confirm the hostname, image and independent recovery copy. Preserve essential files and database exports first. Typed confirmation is the last opportunity to verify the machine.
Verify the new host-key fingerprint, rebuild access and firewall rules, then restore the application in a controlled sequence.
Close the incident
Run deployment acceptance checks, remove temporary rules, rotate exposed credentials and verify the backup schedule. Record the cause and the smallest change that would have prevented the problem.