Reseller Hosting Backup and Restore Plan

A backup is only useful when you can restore the right customer data within the time you promised. For resellers, the challenge is larger than copying website files: each customer may have a different application, database, mailbox, DNS setup, and recovery priority. A written backup and restore plan turns scattered snapshots into a service your customers can trust.

Start with recovery goals

Define two simple targets for each hosting package. The recovery point objective (RPO) is how much recent data the customer can afford to lose. The recovery time objective (RTO) is how quickly the site should be usable again. A brochure site, an online shop, and a client portal may need different targets.

Be precise about what your reseller plan includes. WebyStrata provides the reseller hosting environment and infrastructure to the direct reseller customer; you decide what backup options, restoration assistance, and response times your own hosting plans promise to end customers.

Inventory what must be restored

For every customer account, record the components that make the service work:

• Website files and application code
• Databases and database users
• Uploaded media and scheduled jobs
• Email accounts, aliases, and forwarding rules
• DNS records and SSL configuration
• Application settings and environment secrets
• Customer-specific licenses or integrations

This inventory prevents the common mistake of restoring a database while forgetting uploads, mail, or a required configuration file.

Use more than one recovery layer

Keep a practical mix of short-term and longer-term recovery points. A recent copy helps with accidental deletion; an older copy helps when a problem is discovered days later. If every copy lives on the same system, a storage failure or account-level compromise can affect all of them.

Document where each copy lives, how long it is retained, who can access it, and whether it is encrypted. Do not describe a backup as “secure” without knowing how it is protected and restored.

Separate customer access from backup access

A customer should be able to manage their website without being able to delete every recovery point for the account. Use separate permissions for hosting administration and backup administration, and limit who can download sensitive copies.

Protect backup archives because they may contain databases, private uploads, configuration secrets, and email. Treat a backup as sensitive production data, not as an ordinary ZIP file.

Test restores on a schedule

The restore test is the part most often skipped. Choose representative accounts and perform a test restore into a safe location. Check that the site loads, the database connects, uploads open, forms work, scheduled tasks run, and the correct PHP or application version is available.

For email, verify whether the plan restores messages, mailbox structure, or only account configuration. For DNS and SSL, document which parts are automatic and which require a manual step after the site is restored.

Write a recovery runbook

When a customer reports a failure, the operator should not have to invent the process. Your runbook should include:

1. How to confirm the customer and affected account
2. How to identify the incident time and best restore point
3. How to preserve evidence before changing files
4. How to create a safe restore location
5. How to restore files, databases, mail, and settings
6. How to test the restored service
7. How to switch traffic back and communicate completion
8. How to record the cause and prevent a repeat

Define customer communication before an incident

Tell customers what information you need when they request a restore: domain, account, affected files or date, and whether they approve overwriting current data. Explain possible data loss and the difference between a full-account restore and a single-file recovery.

Keep restoration updates factual. If the issue is still being investigated, say what has been confirmed and when the next update will arrive. Clear communication is part of the recovery service.

Monthly backup and restore review

• Confirm backup jobs completed for active accounts.
• Review storage growth and retention capacity.
• Test at least one representative restore.
• Check that former customers’ data is handled according to your retention policy.
• Review administrator access and backup credentials.
• Update the runbook after every real restore.

Sell confidence, not an untested promise

Backup language should tell customers what is covered, how often copies are created, how long they are kept, and how restoration requests work. A smaller promise you can test is more valuable than “automatic backups” with no documented recovery path.

Use WebyStrata as the reseller infrastructure layer, then differentiate your own hosting plans with clear retention, restore, and communication policies.