Most businesses discover the quality of their backups on the day something goes wrong.
A plugin update breaks the site. A file is deleted. Malware changes content slowly enough to enter recent backups. An account is closed before anyone downloads the data.
The goal of a backup strategy is not to create archives. It is to restore the website to a useful state within a timeframe the business can accept.
Define what must be recoverable
A website is more than its visible pages.
A complete recovery may require:
- Application files
- Uploaded images and documents
- Database content
- Configuration and environment settings
- DNS records
- Email routing settings
- SSL and third-party integration details
- Deployment scripts or custom source code
For WordPress, the database and wp-content directory are essential. The database contains posts, settings, users, orders, and many plugin records. wp-content contains themes, plugins, and uploaded media.
If email is hosted separately, website backups may not include mailboxes. Confirm that instead of assuming.
Choose a recovery point objective
The recovery point objective, or RPO, is the maximum amount of recent data the business can afford to lose.
A company website updated once a month may accept a daily backup. A store receiving orders every hour may need a much shorter interval or an additional way to protect transactional data.
Ask: if the site were restored right now, how much missing information would create a serious problem?
That answer determines backup frequency.
Choose a recovery time objective
The recovery time objective, or RTO, is how long the website can remain unavailable.
A backup stored in a slow archive may protect the data but fail the recovery-time requirement. A one-click hosting restore may be fast, while rebuilding a server and manually importing a large database can take much longer.
Set a realistic target:
- How quickly should someone notice the failure?
- Who decides to restore?
- Where are credentials stored?
- How long does the actual restore take?
- What must be tested before the site reopens?
Recovery time includes human decisions, not only file transfer speed.
Use more than one restore point
One recent backup can preserve the problem you are trying to remove.
Malware, data corruption, and unnoticed content errors may exist for days before discovery. Keep multiple points in time so you can restore from before the incident.
A practical retention pattern could include:
- Several recent daily points
- Weekly points for a longer period
- A monthly archive for important sites
The exact schedule depends on how often the site changes and how long problems might remain hidden.
Keep a copy outside the active hosting account
Hosting-level backups are convenient and should be part of the plan. They should not be the only plan.
An off-site copy protects against:
- Accidental hosting account deletion
- Account access loss
- A provider-level incident
- Billing or ownership disputes
- A mistake that affects both production and local snapshots
Store the independent copy in a controlled location with encryption and access restrictions. Cloud object storage is common, but a securely managed local archive can also serve the purpose for small sites.
Do not send database backups through casual email or leave them in a public uploads directory. They may contain customer records, password hashes, order data, and API configuration.
Follow the 3-2-1 principle
The traditional 3-2-1 backup principle is a useful baseline:
- Keep three copies of important data
- Use two different storage types or systems
- Keep one copy off-site
For a website, that might be:
- The live website
- Hosting timeline backups
- An encrypted export in independent storage
The copies should not all depend on the same account credentials.
Protect the backups
Backups are valuable targets because they contain a concentrated copy of business data.
Use:
- Multi-factor authentication
- Separate backup credentials
- Encryption in transit and at rest
- Limited retention access
- Activity logging
- A process for removing former team members
Where possible, use storage controls that prevent an attacker from immediately deleting every recovery point after compromising the main account.
Document who can restore, who can download, and who can permanently delete backups.
Test restoration
An untested backup is an assumption.
Schedule test restores to a staging or isolated environment. Confirm that:
- The archive can be read
- The database imports
- Media files load
- Login works
- Forms and core workflows operate
- Sensitive integrations are disabled in the test copy
Do not restore a production store into a public staging URL with live payment keys and customer email automation enabled. Protect the test environment and neutralize external side effects.
Record how long the test takes and any manual fixes. That becomes the first version of a recovery runbook.
Back up before risky changes
Automatic schedules may not align with maintenance work.
Create a fresh restore point before:
- WordPress core updates
- Major plugin or theme updates
- PHP version changes
- Database cleanup
- Search-and-replace operations
- Site migrations
- Large content imports
Label manual restore points when the platform allows it. “Before PHP upgrade” is more useful under pressure than an unexplained timestamp.
Separate backups from version control
Git and other version-control systems are excellent for custom code. They are not complete website backups.
Version control usually excludes:
- The production database
- Uploaded media
- Runtime configuration
- Customer-generated content
- External service state
Use version control for code history and deployment. Use backups for operational recovery. A mature process uses both.
Write a one-page recovery plan
Small businesses do not need a fifty-page disaster-recovery manual. They do need a clear page that answers:
- Where are the backups?
- Who has access?
- Which restore point should be used?
- How is the restore started?
- Which website functions must be tested?
- Who communicates with customers?
- When is normal operation declared restored?
Store this plan somewhere available when the website and hosting dashboard are not.
Review the strategy twice a year
Websites change. A brochure site becomes a store. A new agency takes over maintenance. Email moves to another provider. A compliance requirement appears.
Review backup scope, frequency, retention, access, and restore testing at least twice a year—and after any major architecture change.
VeyoHost includes timeline backups as part of every public hosting plan, but good recovery still combines platform protection with an independent business process. Review the plans or ask about recovering your current site.
Tell us what you are running. We’ll help you choose the practical next step.