A recoverable HostBill backup contains more than a database export. It must preserve the application version, configuration, encryption information and customer files needed to interpret and use that database. Design backup and restore procedures together.
IN THIS ARTICLE
01 Define what must be protected
Include the HostBill database, application files, customised templates, enabled module files and the original includes/config.php. Include private attachments and downloads even when they have been moved outside the web directory. Record the actual storage paths, PHP requirements, licence details and scheduler configuration separately in a secure operations record.
The generated encryption hash in the configuration is especially important. Losing it can make stored passwords unreadable even when the database itself restores successfully. Treat the backup as sensitive customer and infrastructure information, with restricted access and encryption appropriate to your backup system.
02 Create and check backups
- Set an acceptable data-loss interval and recovery-time target for billing and support. Use those targets to choose backup frequency and the number of retained recovery points.
- Use a database backup method appropriate to your database engine and workload. Coordinate the database and file copy so you know what time period each represents. For a major change, pause writes when necessary to obtain a clear recovery point.
- Copy the application and private files to a protected destination outside the failure boundary of the production server. Preserve required ownership information and a record of the matching software version.
- Check the backup process's result and archive readability. Monitor failed or unexpectedly small backups; a scheduled task existing is not evidence that usable data was saved.
- Record the timestamp, application version, storage location and retention expiry. Keep credentials to the backup destination independent enough that a production compromise does not automatically expose every recovery copy.
03 Test a restoration
Restore a selected backup to a restricted test environment with live cron, queue processing, outgoing customer mail and provider actions disabled. Load the matching application files and original configuration, then change only the environment-specific connection and path values needed for the test.
Check representative client records, invoice totals, service-to-provider mappings and support attachments. Verify that authorised staff can use the restored system and that encrypted configuration remains usable. Record the elapsed recovery time and any missing dependencies, then fix the backup procedure that caused them.
Before a real production restore, identify payments, new orders and customer changes made after the recovery point. Decide how each will be reconstructed or reconciled. Restoring an earlier database does not reverse payments or service actions already completed by external providers.
Assign an owner to review failed backup alerts and confirm corrective work. An alert that reaches an unattended mailbox does not establish that the next recovery copy is usable.
Common questions
Is an application export a complete disaster-recovery backup?
No. Product or configuration exports are useful for their specific data, but they do not establish that all billing records, attachments, secrets and application dependencies can be recovered.
Does the HostBill updater take the backup for me?
The documented update procedure requires you to create your own file and database backup first. Confirm the behaviour of any additional backup plugin separately rather than assuming the updater provides protection.