Runbook — Restore the whole VPS from a Hostinger snapshot¶
Use when: the VPS is unrecoverable, has been compromised, or a multi-hour mistake needs to be rolled back across many subsystems.
Cost¶
This is disruptive: - Every container stops while the snapshot restores - Any data written since the snapshot is lost - The restore takes 15–45 minutes depending on snapshot size
Do not use this for single-DB issues — use restore-postgres.md instead.
Prerequisites¶
- Hostinger account access (joaobrazao login)
- An agreed downtime window — notify
@DownRabbitbotfirst - Knowledge of which snapshot to restore
Steps¶
-
Notify in
@DownRabbitbot:VPS restore from snapshot starting now. Expect 15–45 min downtime.
-
Decide the target snapshot
- Go to
https://hpanel.hostinger.com/vps/1345342/backups - Pick the most recent snapshot before the bad event
-
Note its timestamp — you will use it in the post-mortem
-
Trigger the restore in hPanel
- Click the snapshot → Restore
- Confirm with the warning prompt
-
Hostinger queues the restore; the VPS reboots when it starts
-
Wait for the VPS to come back
- Watch
ping 76.13.44.83 -
When SSH responds:
ssh vps -
Verify base services
-
Check nginx
-
Spot-check critical apps
https://brain.joaoluisbrazao.com— should loadhttps://gamine.org— should load-
https://admin.joaoluisbrazao.cloud/docs/— should load -
Announce in
@DownRabbitbot:VPS restored from snapshot
. Lost writes: from to now. Post-mortem to follow. -
Re-apply lost writes if known — manual work, depends on what was lost.
-
Post-mortem within 24h in
runbooks/post-mortems/.
When NOT to use snapshot restore¶
- Single-DB corruption → restore-postgres.md
- Single-volume corruption → restore-volume.md
- Cert renewal failure → just rerun certbot
- A single container crashed →
docker restart <name>first
Escalation¶
If snapshot restore fails (Hostinger error, VPS doesn't come back): contact João immediately. Do not retry destructively.