OPERATIONS · 5 MIN READ
The useful question is not “did the backup job finish?” It is “could we restore what matters?”
Write down two limits.
How much recent work could you afford to lose? How long could your application be unavailable? These answers determine backup frequency and the recovery process. A backup schedule cannot promise recovery of every recent transaction.
Keep a copy outside the server.
A backup stored only on the same VPS can disappear with the same incident. Use a separate storage destination with suitable access controls. Protect backup credentials and consider encryption with keys you can recover independently.
Make the data consistent.
Use a database-supported backup method. Copying files during active writes may produce an unusable archive. Include application configuration, relevant uploaded files and the information needed to recreate the environment.
Restore somewhere safe.
- Create an isolated restore environment.
- Retrieve a selected backup without using the original server.
- Restore the data and application configuration.
- Verify integrity and a representative user journey.
- Record the time taken, missing steps and required credentials.
Keep the plan current.
Retest after major application changes. Check that failure alerts reach someone and that old backups expire according to your retention policy. Export needed data before a service cancellation or migration.
When enabled, the backup frequency, retention, price and restore process are configured by the operator and shown before checkout. Keep an independent copy of important data.
Understand service responsibilities