Creating a backup plan you can actually restore

List website files, databases, mailbox contents, configuration, DNS records and any files stored outside the hosting account. For an online store, decide how much recent order data the business could afford to lose and how quickly checkout must return. These requirements determine backup frequency and recovery arrangements.

1. Check the backup tools and retention available on your exact plan. Record the last successful backup, not merely the existence of a backup menu.
2. Maintain a separate copy of important data under your control. Store it away from the live account and protect the storage account with strong authentication.
3. Keep files and databases from compatible points in time. Restoring an old database with incompatible new application code can leave the website unusable.
4. Include changing data that automated website backups may omit, such as external object storage, payment records or third-party application settings.
5. Test a restoration into a separate location where practical. Verify files open, the application starts and representative records are present.
6. Record who can request recovery, where the copies are stored and what access is needed if the production account is unavailable.

Preserve the current state and identify changes created after the proposed restore point. A database restore can overwrite newer orders, messages or customer details. Agree a recovery point and any necessary reconciliation before proceeding.

Suppose a store has a verified backup from 09:00 and develops a serious problem at 14:00. Restoring that backup would return the protected files and database to the selected point. First identify the orders, customer records and content created between 09:00 and 14:00.

1. Preserve the current state and the evidence needed to identify those later changes.
2. Test the 09:00 backup in an isolated location and confirm that the store opens and its recorded orders are readable.
3. Agree which later business records must be reconciled before using the recovered database in production.
4. Record the chosen backup, the components being restored and the person responsible for checking the recovered store.

The times are illustrative. The correct recovery point depends on the backups that actually exist and the business data the owner needs to preserve.

Provide the service, affected data, incident time and desired recovery date. Ask which restore points actually exist and what the operation replaces. A full cPanel account restore can require provider access even when you can download a backup yourself.

Our terms place responsibility on customers to maintain their own backups. A courtesy or included backup is useful protection, but it should not be your only verified copy of information essential to the business.

• Connecting a website and database to CodeGuard backups
• Restoring website files or a database with CodeGuard
• Using server snapshots alongside independent backups
• Creating Web Hosting backups and planning a restore

• Nabtech Terms
• Cpanel Backup