How to Reinstall the OS or Upgrade Your Plan Without Downtime

An in-place OS reinstall wipes the server's disk, so it always takes that server offline. To avoid downtime, build and test the new system on a second server, or schedule the reinstall during a short maintenance window with a full off-server backup ready to restore. Then switch DNS only after the new setup passes testing, and keep the old server running until the DNS TTL has expired. CPU, RAM and disk upgrades on an existing Cloudesta VPS are applied by our team on request and need only a short reboot.

This guide covers preparation, how to request a reinstall or rescue mode, the correct restore order, testing with the hosts file, and plan upgrades. It applies to Cloud VPS and dedicated servers running Ubuntu 24.04 or 22.04.

Prerequisites

• Root or sudo SSH access to the server.
• Access to your domain's DNS zone, at your registrar or DNS provider.
• Storage outside the server for backups, such as your PC, another server or object storage.
• At least 24 hours of lead time before the planned switch.

When does reinstalling the OS make sense?

Reinstall when you want to move to a newer Ubuntu LTS on a clean base, recover from a compromise, or start fresh after configuration drift you can no longer untangle. If the system will not boot or SSH is broken, ask for rescue mode first. Rescue mode often lets you copy data off or fix the problem without a reinstall.

1. How do I prepare a server before a reinstall?

Lower the DNS TTL 24 hours ahead

Check the current TTL. The second column of the output is the TTL in seconds.

dig +noall +answer example.com A
dig +noall +answer www.example.com A

In your DNS zone, set the A and AAAA records to 300 (5 minutes). Do this at least 24 hours before the switch, or longer if the old TTL was longer than a day.

Export databases, cron jobs and the package list

sudo mkdir -p /root/migration && cd /root/migration

# MySQL/MariaDB: one dump per application database
sudo mysqldump --single-transaction --routines --triggers --events --databases appdb > appdb.sql

# PostgreSQL (if used)
sudo -u postgres pg_dumpall > postgres.sql

# Packages you installed and extra APT sources
apt-mark showmanual > manual-packages.txt
sudo cp -a /etc/apt/sources.list.d ./apt-sources

# Cron jobs and systemd timers
sudo cp -a /var/spool/cron/crontabs ./crontabs
systemctl list-timers --all > timers.txt

# Configuration and web files
sudo tar -czpf etc.tar.gz /etc
sudo tar -czpf www.tar.gz /var/www

Write down your database users and their privileges as well. A per-database dump does not include them. On an n8n hosting VPS, also back up the n8n Docker volume and the N8N_ENCRYPTION_KEY. Without that key, the restored n8n instance cannot decrypt your saved credentials.

Copy everything off the server

# Run this on your PC or backup host
rsync -avz root@203.0.113.10:/root/migration/ ./server-backup/

2. How do I request an OS reinstall or rescue mode?

Cloudesta staff carry out OS reinstalls and rescue mode. Open a ticket at https://cloudesta.com/submitticket.php and include:

• The server hostname and IP address.
• The OS you want, for example Ubuntu 24.04 LTS, or "rescue mode" if you need it instead.
• Your preferred date and time window, with the timezone.
• Confirmation that you have an off-server backup and accept that the disk will be wiped.

3. In what order should I restore after the reinstall?

After the reinstall, the server's SSH host key changes. Remove the old key on your PC before you connect:

ssh-keygen -R 203.0.113.10

Copy server-backup/ back to /root/migration on the server. Then restore in this order.

Packages. If you used PPAs, re-add them first. Then install your package list:

sudo apt update && sudo apt upgrade -y
xargs -a /root/migration/manual-packages.txt sudo apt install -y

If you are moving between Ubuntu releases, some package names differ. For example, PHP is 8.1 on 22.04 and 8.3 on 24.04. Remove any names apt rejects from the list and install their equivalents.

Configs. Extract the /etc archive to a separate folder and copy back only what you need. Do not overwrite the whole new /etc.

sudo mkdir -p /root/restore
sudo tar -xzpf /root/migration/etc.tar.gz -C /root/restore
sudo cp -a /root/restore/etc/nginx/sites-available/. /etc/nginx/sites-available/
sudo cp -a /root/restore/etc/cron.d/. /etc/cron.d/
sudo cp -a /root/migration/crontabs/. /var/spool/cron/crontabs/

After copying the site configs, recreate the symlinks in sites-enabled.

Web root. Restore the files and reset their ownership:

sudo tar -xzpf /root/migration/www.tar.gz -C /
sudo chown -R www-data:www-data /var/www/example.com

Databases. Import the dump, then recreate the application user:

sudo mysql < /root/migration/appdb.sql
sudo mysql -e "CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'yourpassword'; GRANT ALL PRIVILEGES ON appdb.* TO 'appuser'@'localhost';"

SSL. Restore your Let's Encrypt certificates so HTTPS works before DNS points at the server. Then test the web server config and reload it:

sudo apt install -y certbot python3-certbot-nginx
sudo cp -a /root/restore/etc/letsencrypt /etc/
sudo nginx -t && sudo systemctl reload nginx

4. How do I test the site before switching DNS?

Point only your own computer at the new IP. Add this line to /etc/hosts on Linux or macOS. On Windows, edit C:\Windows\System32\drivers\etc\hosts in Notepad opened as Administrator.

203.0.113.10 example.com www.example.com

Now browse the site, log in, and submit a form. You can also check HTTPS without editing the hosts file:

curl -I --resolve example.com:443:203.0.113.10 https://example.com

When testing is finished, remove the hosts entry.

5. How do I upgrade my plan without downtime?

Resource upgrades on the same server. To add CPU, RAM or disk, open a ticket naming the server and the target plan. Cloudesta applies the change, which needs one short reboot. Schedule it for a quiet hour. After the reboot, check nproc, free -h, lsblk and df -h. If lsblk shows the larger disk but df -h does not, mention it in the same ticket.

Moving to a new server. This is the zero-downtime path. Order the new Cloud VPS, install packages and configs as in section 3, then sync the data from the old server:

# Run on the OLD server, as root
rsync -aHAX --info=progress2 -e ssh /var/www/ root@203.0.113.20:/var/www/

Test the new server with the hosts file. Then do the final cutover:

1. Briefly stop writes on the old server, for example with maintenance mode.
2. Re-run rsync with --delete.
3. Dump the databases again and import them on the new server.
4. Update the DNS A records to the new IP.

Keep the old server running for at least the old TTL, ideally 24 to 48 hours, before you cancel it.

Pre-switch checklist

• TTL lowered at least 24 hours ago.
• Backup copied off the server and verified.
• Packages, configs, web root, databases and SSL restored.
• Cron jobs and timers present.
• Site tested through the hosts file.
• Old server kept online until the TTL has expired.

Verify it works

Run these checks after the switch:

dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8
systemctl --failed
sudo crontab -l
curl -I https://example.com
sudo tail -n 50 /var/log/nginx/error.log

Both resolvers should return the new IP, and there should be no failed units. Once you are confident, raise the TTL back to 3600 or your usual value.

Common problems

• Some visitors still reach the old server: resolvers are still caching the old record. Wait out the old TTL and keep the old server serving traffic until then. Use dig against several resolvers to check how the change is spreading.
• Blank page or "Call to undefined function" errors: PHP extensions are missing. Compare php -m output on the old and new servers, then install what is missing, for example sudo apt install php8.3-mysql php8.3-gd php8.3-mbstring.
• 403 errors or "permission denied" after rsync: the files were copied without -a or not as root, or a missing trailing slash created a nested folder. Fix ownership with sudo chown -R www-data:www-data /var/www/example.com, then reset modes with find /var/www/example.com -type d -exec chmod 755 {} + and find /var/www/example.com -type f -exec chmod 644 {} +.
• "Access denied for user": the database users were not recreated. Run the CREATE USER and GRANT statements from section 3.
• SSH warns "REMOTE HOST IDENTIFICATION HAS CHANGED": this is expected after a reinstall. Run ssh-keygen -R 203.0.113.10 on your PC.

Frequently asked questions

Does an OS reinstall delete all my data?

Yes. Everything on the server's disk is erased, including websites, databases and configuration. Only an off-server backup survives.

How long is my server offline during a resource upgrade?

Only for the reboot needed to apply the new CPU, RAM or disk allocation. You can choose the time window in your ticket.

Will I keep my IP address?

An in-place reinstall or resource upgrade keeps the same IP. A move to a new server normally means a new IP, which is why you switch DNS. Any IP changes are handled by support through a ticket.

Need help? To request a reinstall, rescue mode or plan upgrade, or for help with a migration, open a ticket at https://cloudesta.com/submitticket.php.