Server OS Reinstall: Pre- and Post-Checklist

The server won't boot, or it boots but is so infected and messed up that fixing it costs more than a fresh install. You've decided to wipe the operating system and start from scratch. Before you hit the Reinstall button, know that the biggest risk isn't the installation itself; it's what you forget to back up and what you forget to rebuild afterward.

Before reinstalling the OS: what really needs to be backed up

Everyone remembers the site files. What usually gets left behind are the things that live outside /var/www and that nobody thinks of as "data."

• Databases with schema and data. A plain mysqldump isn't enough if you lose users, grants, and triggers. At minimum, run: mysqldump --single-transaction --routines --triggers --events -u root -p --all-databases > all.sql. For PostgreSQL, the equivalent is pg_dumpall -U postgres > all.sql.
• SSH keys. Grab /root/.ssh and /home/*/.ssh in full. If you don't preserve the host keys (/etc/ssh/ssh_host_*), after reinstall every client will get a REMOTE HOST IDENTIFICATION HAS CHANGED warning and will have to remove the relevant line from known_hosts.
• SSL certificates. If you use Let's Encrypt, regenerating them is easy. If you have purchased certificates, grab the .key and .crt files; reissuing costs money and time.
• Cron jobs and timers. The output of crontab -l -u root and the contents of /etc/cron.d/ and /etc/systemd/system/*.timer. Nobody backs these up because they're "configuration," not "data."
• Service configs. /etc/nginx, /etc/apache2, /etc/php, /etc/postfix, /etc/fail2ban. Even if you rewrite from scratch, seeing the previous version saves half an hour.
• Files outside standard paths. Anything you've placed somewhere yourself: backup scripts, env files, uploaded data whose paths you've hardcoded in code.

A quick way to find what you're forgetting: before reinstalling, run du -xh --max-depth=2 / | sort -h | tail -40 and pause on any path over 1 GB. If you can't clearly explain it, it's probably what you'll be missing later.

If you've lost access to the server

When the server won't boot, the usual approach is to bring it up in rescue mode from the panel and mount the disk. If this path is new to you, the guide Server reinstall and working with rescue mode; saving data when you've lost access walks through exactly this. A point I run into a lot in practice: in rescue mode, the main disk is usually at /dev/sda1 or /dev/vda1, but not always. Run lsblk -f first, then mount.

Settings you'll need again after installation

This is where the most time gets wasted, because a freshly installed server is technically healthy but functionally not yet the same server as before.

Basic security, before anything else

Order matters. First create a non-root user, then disable root login with password, then change the SSH port. If you reverse the order and get cut off mid-way, you may lock yourself out. The exact sshd_config options and which ones are actually worth changing are covered in SSH configuration: important security options in sshd_config. The minimum you should do: PermitRootLogin prohibit-password and PasswordAuthentication no.

Then the firewall. A simple rule that always works: any port not in the reference of common service ports and ports that shouldn't be open should be closed. Run ss -tulpn and see what's actually listening, rather than assuming only SSH and the web server are open.

Services and their dependencies

If you have a custom service, restore the unit file from backup and run systemctl daemon-reload. A common error after reinstall is a service that's active (running) but not working, because After= and Requires= aren't set correctly and it started before the database. Details on these sections are explained in The unit file in systemd: sections, restart, and dependencies. For quick debugging: systemctl status myservice then journalctl -u myservice -n 50 --no-pager.

Choosing a distro, if you want to get it right this time

A reinstall is a good opportunity to move away from a distro you were using only "because it was always there." If your team is more comfortable with apt, Debian is the most stable option. If you need newer kernel and package versions, Ubuntu LTS offers a better balance. See a more practical comparison in Choosing a server Linux distro: a practical, no-nonsense guide. My advice: if the server is running and the problem was purely software, don't change the distro. Changing distro at the same time as recovery swaps two variables at once and makes debugging harder.

Where people go wrong

The most common mistake I've seen: the admin takes a full backup, reinstalls, restores the backup, and then says "everything's there." Two days later they discover transactional emails aren't going out. The cause: DNS records like SPF, DKIM, and DMARC were in the external DNS panel, not on the server, and nobody touched them. But the DKIM private key was on the server and got wiped by the reinstall. Now the signature doesn't match the record published in DNS and recipients reject the email. And the symptom isn't in your server logs; it's in recipients' spam folders.

The second mistake is subtler: restoring /etc wholesale from backup. It's tempting because it's fast, but it plants configs from the previous distro version onto the new one. The result is a service that comes up but runs with strange warnings, or a service that won't start at all because the binary path changed in the new version. Restore configs manually and selectively, not all at once.

After installation, check these

1. Look at uptime and free -m. If load is abnormal after install and before restoring the site, the problem existed before and the reinstall didn't fix it.
2. Check every service with systemctl is-enabled to make sure it comes up on its own after reboot. A service that's running now but isn't enabled will surprise you on the first reboot.
3. Do an actual reboot and, after it comes up, test everything again. This is the only way to be sure dependencies are set up correctly.
4. Watch the logs for the first 24 hours. If load spikes, the guide Diagnosing the cause of high server load; a practical, step-by-step guide is a good starting point.

One real cost you have to accept: reinstalling the OS creates a downtime window you can't reduce to zero unless you already have a failover architecture. If your site has a strict SLA, the right move is to first bring up a new server alongside the current one, migrate the service, and then wipe the old server. If you have a virtual or cloud server, this is practically possible with no downtime; on a single-node dedicated server, it isn't.

And if your server is just a small site with low traffic, sometimes the right answer isn't a reinstall at all. If the problem is one specific service, fix that. A reinstall is for when the system is so infected or messed up that cleaning it costs more than starting from scratch. For small sites, a managed Linux hosting is usually less hassle than maintaining a full server, since tasks like updates and backups are taken off your hands.

Frequently asked questions

Does reinstalling the OS delete all files on the server?

Yes, in the usual case the entire OS partition is wiped and anything on that same disk is gone. If the server has a second disk and you don't touch it during the install process, its data remains, but don't assume this; before you start, know exactly which disk is being wiped.

How do I know I've backed up everything before reinstalling?

One practical way is to restore the backup on another machine and bring the site up. If the backup is only on the same server you're about to wipe, it isn't a backup. At minimum, keep the database, SSH keys, web server config, and cron jobs separately and somewhere else.

After reinstalling, why doesn't the site come up even though services are running?

It's usually one of three things: file permissions and directory ownership are wrong, the web server config points to an old path or PHP version, or the service didn't start properly due to a dependency and is only apparently active. Start with journalctl -u nginx -n 50 and tail -f /var/log/nginx/error.log.

Can I upgrade the OS without reinstalling?

In some cases yes, but on a server that's gone years without maintenance, an in-place upgrade is riskier than a fresh install. If you want to try, take a full snapshot first and know that rolling back isn't always possible. For old servers, a fresh install with selective config restoration is more predictable.