Include the full database, application version and custom code, configuration.php, private attachments and downloads, cron configuration and necessary server settings. Keep a record of PHP and ionCube requirements. Where storage is remote, confirm its own versioning and recovery arrangements instead of assuming it is included in the database export.

Protect backups as sensitive customer data. Restrict access, encrypt transfers and stored copies where your backup system supports it, and choose retention according to the business's approved policy. Keep a recovery copy outside the server being protected.

1. Open System Settings and Database Backups. Choose a destination suitable for the installation and its data size.
2. For an SFTP destination, enter the correct host, port, credentials and destination directory. Confirm the directory is interpreted relative to the remote login location as required by the interface.
3. Use Test Connection and resolve authentication or directory errors. Then use Save and Activate for the chosen method.
4. Confirm the system cron is running because scheduled backup activity depends on automation.
5. Inspect the resulting remote file and its timestamp. A saved configuration or successful connection test does not prove that a complete database backup was produced.

WHMCS also provides a manual database download through Utilities, System and Database Status. For larger databases, use a properly managed database backup process if application time or memory limits prevent reliable exports. Avoid sending unencrypted database copies to an ordinary shared mailbox.

1. Create a private recovery environment with compatible software and appropriate licensing. Disable outgoing mail, production provisioning and payment activity before allowing background tasks to run.
2. Restore the database and matching application files. Restore the original encryption hash, then adjust destination database credentials and absolute paths without replacing that hash.
3. Restore private files and confirm that the application can read them using the intended filesystem owner.
4. Compare record counts and the most recent order, invoice and transaction timestamps with the backup inventory.
5. Open representative client, service and billing records. Test a private attachment and verify that encrypted configuration can be read without exposing its values.

Record the backup's exact recovery point and any orders, payments or support changes that occurred after it. Those changes require reconciliation from gateway records, logs or other authoritative evidence. Restoring an older database can otherwise make settled invoices appear unpaid or cause a provisioning action to run again.

During a real recovery, nominate one active installation and one owner for restarting cron. Verify URLs, licence, mail and external allowlists before enabling normal operations. Measure the time needed to restore and compare it with the recovery target. Correct failures while the exercise is still controlled, then retain a brief report showing what was actually recovered.

• Build a WHMCS staging copy without sending live charges or emails
• Move a self-hosted WHMCS installation to another server
• Move WHMCS writable directories outside the public web root
• Run and document a hosting backup restore exercise
• Prepare a dedicated database for WHMCS

• WHMCS database backups
• WHMCS: configuration.php
• WHMCS: set up a test environment
• WHMCS: move to a new server