Define what you need to recover
A Joomla website is more than its public files. Content, accounts, extension settings and orders can live in the database. Images, templates and other assets live on disk. Your recovery plan needs both, along with configuration and enough information to recreate the server environment.
Decide how much recent activity you can afford to lose and how quickly you need to return. A frequently changing shop needs a different backup schedule from an occasional brochure-site update.
Make a consistent backup
Use a Joomla-compatible backup tool or a documented files-and-database process. Follow its instructions for your exact software version. For a database that is changing, a simple copy of its raw storage files may not be a valid backup.
Record the backup time, Joomla version, PHP/database versions and any files stored outside the main website directory. If extensions use external storage or services, include those dependencies in the plan. Protect backup files because they can contain personal data, credentials and private content.
Keep at least one recoverable copy away from the live instance. A backup stored only in the same writable website directory can be lost in the same incident as the site itself.
Know what an instance backup includes
Vultr offers optional automatic instance backups. Its documentation says these cover the instance’s active filesystem and do not include attached block storage. Review your selected product’s current retention and restore process.
An instance-level backup does not, by itself, demonstrate that your particular Joomla database was captured consistently. Keep an application-aware backup and prove that the combination you intend to rely on actually restores.
Run an isolated restore drill
- Choose an isolated destination with compatible PHP and database versions. Use a new database rather than overwriting production.
- Protect the destination with authentication or network restrictions before placing customer data on it. Disable indexing as an additional measure.
- Stop the restored copy from sending real emails, charging customers, running production jobs or writing to shared services.
- Restore the files and database using the tool’s documented process. Adjust credentials and environment-specific paths.
- Check administrator login, representative pages, images, extension settings and a harmless test form.
- Confirm that the data matches the expected point in time. Note missing orders, files or changes.
- Record how long the restore took and anything you needed that was absent from the backup.
This is a procedure to perform, not a claim that we have restored your site or tested a backup product on your behalf.
Plan an actual incident
Keep restore instructions and provider access somewhere available when the website is down. If the incident involves a compromise, investigate the cause before restoring into the same vulnerable configuration. A clean, patched environment may be necessary.
Before reverting a transactional site, account for activity since the backup. Restoring yesterday’s database can remove today’s orders. Agree who decides on data recovery, customer communication and the point at which the replacement becomes live.
Keep checking
Monitor backup completion, available storage and retention. Revisit the drill after major Joomla, extension or infrastructure changes. A successful backup notification is a useful signal; an observed, usable restore is the evidence you need.
Read our staging guide for isolation checks and migration guide for a controlled cutover.
Sources: Vultr automatic backup scope and Vultr backup management. Check your application backup tool’s own restore documentation before use.