Quick answer: Isolate the machine, do not wipe it yet, and restore service on a fresh server from a backup made before the intrusion. Your clean offsite copies are the recovery path — never rebuild on top of a compromised system, and change every credential that machine ever held.
Overview
This article covers the recovery-from-backup side of an incident: choosing a safe restore point, rebuilding cleanly, and the credential hygiene around it. For the security investigation itself — detecting the breach, reading logs, hardening — see what to do if your server is hacked.
Before you start
- Confirm your backups are independent of the compromised machine — this is why backup access security matters before incidents.
- Have your DR plan and encryption passphrases at hand.
- Accept the timeline question: you need a backup from before the intrusion, which may be older than the freshest one.
Step-by-step guide
- Isolate: firewall the machine down to your admin IP (or power it off via the Client Area) — stop ongoing exfiltration without destroying evidence.
- Freeze the backups: pause prune jobs immediately so retention does not rotate away your last clean snapshot.
- Pick the restore point: estimate the intrusion date from logs and file timestamps, then choose the newest backup safely before it. When unsure, older is safer.
- Rebuild fresh: provision a new VPS (or reinstall the OS from the service page), harden it first — keys, firewall, updates — then restore data onto it. Restore data, not system binaries, from the backup.
- Rotate everything: passwords, API tokens, SSH keys, database and application secrets that lived on the old machine; assume all were read.
- Verify and switch: test the new server, move DNS/traffic, keep the old machine offline for a post-mortem, then destroy it.
Common issues
- Restoring the malware: a backup made after the intrusion faithfully preserves the backdoor — restore point choice is everything.
- Cleaning in place: rootkits survive amateur cleanup; a fresh install plus data restore is faster and provably clean.
- Backups already gone: if the attacker could delete them, they usually did — append-only layouts (see securing access) exist for exactly this day.
When to contact support
Open a ticket immediately: Cloud2Y can help isolate the machine, provision a replacement quickly, and check for abuse reports tied to your IP. Note that incident forensics on an unmanaged server is the customer's domain — support handles the platform side.
Frequently asked questions
Should I wipe a hacked server immediately?
No — isolate it first (firewall or power off) and keep it for analysis. You will want its logs to date the intrusion and choose a backup made before the attacker got in.
Which backup should I restore after a compromise?
The newest one made safely before the intrusion date. Anything after it may contain the backdoor, so when the date is uncertain, restoring an older snapshot is the safer call.
What credentials must be rotated after an incident?
Everything the machine held or could reach: system and database passwords, SSH keys, API tokens, application secrets and any reused credentials elsewhere. Assume all were read.
Related articles
- What to do if your server is hacked
- How to restore a website from backup
- How to secure backup access
- How to create a disaster recovery plan
Need a hand? Contact Cloud2Y support →
