Servers fail, people delete data by mistake, updates go wrong and accounts get compromised. None of this can be fully excluded. What can be controlled is how much data you lose and how long the business stands still.
Decide what you can afford to lose
Two questions define the plan. How much data can you lose - the last hour, the last day? And how long can the system be unavailable - minutes, hours, a day? A store that takes orders around the clock needs frequent backups and fast recovery; a company website that changes once a month can live with daily copies.
Back up everything that matters
The database is the obvious part, but not the only one. Uploaded files and images, configuration, environment settings, scheduled tasks and the exact version of the code are also needed to bring a system back. Write down the full list once and keep it up to date as the system grows.
Keep copies in more than one place
A backup on the same server as the system disappears together with it. Keep copies in a separate location - another provider or region - and keep at least one copy that cannot be changed or deleted from the main system. This protects against both hardware failures and attacks that try to encrypt or wipe data.
Automate and monitor
Manual backups are forgotten exactly when they are needed. Schedule them automatically, keep a history of several versions, and set up an alert if a backup fails or becomes suspiciously small.
Test the restore
A backup that has never been restored is a hope, not a plan. Regularly restore a copy to a separate environment and check that the system works and the data is complete. Measure how long it takes: this is your real recovery time.
Write the recovery steps down
When something breaks, stress is high and time is short. A short document with the order of actions, the location of backups, the necessary access and the people to contact turns recovery into a routine procedure.
The short version
Define acceptable data loss and downtime, back up the database, files and configuration, store copies separately and protect at least one from deletion, automate and monitor, test restores regularly and document the steps. Then a failure is an incident, not a disaster.