Create a restore point before an update

A system, PHP or database update is when a server most often breaks. A restore point is not just a file copy: it is everything needed to return to a known state, configuration included. Prepare it beforehand, not during the incident.

Decide what must be recoverable

Not everything has the same value. Sort what you will back up:

• installed packages and their versions;
• configuration under /etc (Nginx, SSH, PHP, database, systemd units);
• application data in /var/www or /srv;
• databases;
• scheduled tasks, users and SSH keys;
• environment files and certificates.

The last two are often forgotten and are exactly what prevents a service from starting again.

Use the provider backup

If the dashboard offers a backup or snapshot for your VPS, take one before the operation and note its name and time. That kind of backup restores the whole container and overwrites the current state: handy for a global rollback, unsuitable for recovering a single table. Confirm it is marked as completed before you continue.

A provider backup does not replace your own export: it lives on the same platform and follows the same billing.

Export manually

Create a protected directory, then archive configuration and data separately so you can restore one without the other.

sudo install -d -m 700 /root/rollback
sudo tar -czpf /root/rollback/etc-$(date +%F).tar.gz -C / etc/nginx etc/ssh etc/systemd/system
sudo tar -czpf /root/rollback/www-$(date +%F).tar.gz -C /var/www .
sudo mysqldump --single-transaction --routines --triggers -u root -p --all-databases | gzip > /root/rollback/db-$(date +%F).sql.gz
dpkg --get-selections > /root/rollback/packages-$(date +%F).txt
sudo sha256sum /root/rollback/* > /root/rollback/SHA256SUMS

These files contain secrets: keep the directory at 700, never leave it in /var/www, and copy it off the VPS with scp. An archive that stays on the machine being upgraded protects nothing.

Checklist before you start

1. Free disk space is at least twice the size of the data to save.
2. You have read the release notes and identified breaking changes.
3. You know which command will verify the service afterwards.
4. You have a maintenance window, and you have warned users if the service is public.
5. You know how to roll back: Debian repositories do not keep old package versions.

For critical packages, download the .deb before the upgrade:

apt-get download critical-package

Roll back

If the service does not come back, restore configuration first and restart. If the problem is in the database, reimport the dump. For a package, reinstall the saved .deb with dpkg -i; dependencies may however block a downgrade. In that case, a clean reinstall with data restore is often faster than forcing a downgrade.

Write down what changed, what failed and the exact command that brought the service back: the next update will be easier.