I inherited responsibility for a handful of VPS instances after a coworker left. The current setup relies heavily on undocumented cron jobs and tribal knowledge, and I want to make backups, firewall rules, access management, monitoring, and configuration consistent across all the servers. What baseline checklist would you recommend, and what should I prioritize first?
3 Answers
I would prioritize the work in this order: verify a restorable backup, identify every account and credential with access, document what each machine does and who owns the service, then lock down the firewall and establish patching. Move firewall rules, cron entries, and other configuration into Git or automation so the server is not the only place they exist. Add off-host log collection and alerts for failed jobs, full disks, unavailable hosts, and expiring certificates. A simple monthly maintenance cycle that you actually keep is better than an ambitious weekly process that gets abandoned.
Start with an inventory before changing anything: document what each server runs, where its data lives, who depends on it, and what jobs or services are active. Then handle access and recovery first. Give every person an individual account with sudo, use SSH keys, disable password and root SSH access, and rotate any keys or credentials the former administrator may have known. For backups, use encrypted copies stored outside the VPS provider with sensible retention, then restore one to a scratch machine. A backup you have never restored is only an assumption. After that, add a default-deny firewall, keep databases and admin services on localhost or private interfaces, establish a patching schedule, centralize logs, monitor disk space and certificate expiry, and put configuration and scheduled jobs in version control. The real test is whether you can rebuild a server without relying on undocumented knowledge.
When auditing scheduled work, do not check only the current user’s crontab. Also inspect /etc/cron.d, the periodic cron directories, and systemd timers with `systemctl list-timers --all`. Inherited systems often have forgotten jobs quietly consuming disk or failing without anyone noticing.
For a small environment, a lightweight patch-management or remote-monitoring tool can help track offline machines and missing security updates, but it should support—not replace—the fundamentals. Keep an inventory of exposed ports and review it against the services that are meant to be public. Be especially careful with container platforms: publishing a container port on all interfaces can expose it even when you thought your host firewall rules covered the service.
Also write down who should be contacted when each service fails. Sometimes the most important discovery is that nobody is responsible for a supposedly critical server.