A website backup is useful only if it contains the right information, remains available when the live site fails and can be restored within a timeframe the business can tolerate. Simply seeing “backup complete” in a hosting panel does not prove that recovery will work.
This website backup checklist for Malta businesses helps owners define what must be protected, where copies should be stored, who controls them and how restoration should be tested. It is designed for WordPress websites, but most of the planning principles also apply to other platforms.
1. Identify what the website supports
Start by listing the business activities that depend on the site. A brochure website may mainly support enquiries, while an ecommerce or booking website may hold orders, customer accounts, availability and payment references. Recovery priorities should reflect the consequence of losing each function.
- Lead and contact-form submissions
- Orders, bookings, memberships and customer accounts
- Product, service and pricing information
- Blog posts, landing pages and uploaded media
- Integrations with CRM, email, payment and analytics systems
2. Define acceptable data loss and downtime
Agree two practical recovery targets. The recovery point objective describes how much recent data the business can afford to lose. The recovery time objective describes how long the service can remain unavailable before the impact becomes unacceptable.
A site that receives occasional enquiries may tolerate a different schedule from a busy shop or reservation system. Set the targets from business needs, then select backup frequency and recovery arrangements that can realistically meet them.
3. Back up both files and the database
A complete WordPress recovery normally needs both site files and the database. WordPress guidance distinguishes the database, which stores much of the site’s content and configuration, from files such as themes, plugins, uploads and configuration files.
- Database: posts, pages, users, settings, orders and plugin data, depending on the site.
- Uploads: images, documents and other media.
- Themes and custom code: design files, child themes and bespoke functionality.
- Plugins: extensions and relevant configuration files.
- Server files: items such as
wp-config.phpand.htaccesswhere applicable.
Check whether important data also lives outside WordPress, such as CRM records, payment-provider data, booking platforms, email inboxes or automation tools. Those systems need their own continuity arrangements.
4. Match backup frequency to website changes
Frequency should reflect how often data changes and the agreed recovery point. A static company site may not need the same database schedule as an online shop receiving orders throughout the day. Files and databases may also justify different schedules.
Include a fresh backup before significant updates, migrations, redesign launches or integration changes. WordPress documentation recommends backing up before updates so the previous working state can be restored if something goes wrong.
5. Keep an independent copy
A backup stored only inside the same hosting account can be affected by the same account compromise, deletion, billing issue or infrastructure failure as the live site. The UK National Cyber Security Centre advises organisations not to rely solely on a service’s built-in recovery mechanisms and to keep an independent copy in another safe place or service.
- Separate the backup destination from the production hosting account.
- Use a business-controlled account rather than a developer’s personal storage.
- Protect the destination with strong authentication and limited access.
- Record who can delete backups or change retention.
- Consider a copy that cannot be altered immediately after creation.
6. Protect backups from destructive access
Attackers may target backups to make recovery harder. NCSC guidance on ransomware-resistant backups recommends resilience against deletion or alteration, the ability to restore an earlier version if newer copies are corrupted, robust key management and alerts for significant changes or privileged actions.
Do not give every website administrator access to the backup vault. Separate routine website editing from backup administration and remove access promptly when staff or suppliers change.
7. Encrypt and handle personal data appropriately
A backup can contain customer details, form entries, user accounts and confidential business information. Apply suitable access controls and encryption in transit and at rest. Include backup locations, suppliers and retention in the website’s privacy and security review.
The website privacy and cookie checklist explains how to map personal data, suppliers, retention and security responsibilities across the wider site.
8. Set a documented retention policy
Decide how many recent, weekly and longer-term versions are retained. Keeping only the newest copy can be risky because corruption or malicious changes may go unnoticed until several backups have captured the same problem.
Retention should balance recovery needs, legal or contractual obligations, privacy requirements and storage cost. Document when old copies are removed and how deletion is verified.
9. Monitor backup jobs and capacity
Automatic jobs can fail because credentials expire, storage fills, file permissions change or a hosting process times out. Alerts should reach a named person who understands what to do next.
- Check the most recent successful database and file backup.
- Review failed or incomplete jobs.
- Monitor storage capacity and retention behaviour.
- Confirm backup files have plausible sizes.
- Escalate repeated warnings rather than simply clearing them.
10. Test restoration, not just download
A successful backup notification does not prove that the archive is complete or usable. Restore a selected copy into a safe test environment and check that the site loads, administrators can sign in, forms work, media appears and critical data is present.
WordPress guidance describes restoring files and importing the database as separate parts of recovery. A practical test should confirm both, along with any configuration changes needed for the test environment.
11. Test business functions after restoration
Technical access is only the first checkpoint. Test the functions the business depends on, including enquiry notifications, checkout, bookings, search, account access and key integrations. Use safe test transactions and avoid contacting real customers unintentionally.
Include restoration scenarios in the broader website testing checklist, especially after major platform, hosting or integration changes.
12. Create a recovery runbook
The runbook should be clear enough for an authorised substitute to follow during an incident. It should cover assessment, containment, selection of a clean recovery point, restoration, validation, DNS or hosting actions, communication and final approval.
- Who has authority to start a restore?
- Where are credentials and clean backup copies held?
- Which systems must be restored first?
- How is a compromised site isolated before recovery?
- Who confirms that customer-facing functions are working?
- Who communicates with customers, suppliers and internal teams?
13. Avoid restoring the original problem
If malware or unauthorised changes caused the incident, restoring without addressing the entry point can recreate the problem. Identify the likely cause, select a suitable recovery point, update vulnerable components, rotate affected credentials and validate the clean environment before reopening access.
NCSC guidance notes that malware may persist in backups and recommends reducing reinfection risk when restoring. Recovery therefore needs security review as well as a technical restore.
14. Clarify responsibilities with suppliers
Document what the host, website developer, maintenance provider and business each control. Ask whether hosting backups are included, how often they run, where they are stored, how long they are retained, whether they cover files and databases and how a restore is requested.
Include these responsibilities in the website development contract checklist and ensure account access is transferred through the website handover process.
15. Review recovery arrangements after change
Reassess backups when the site adds ecommerce, memberships, bookings, new integrations, custom code or a different hosting environment. Confirm that new database tables, uploads and external systems are included where required.
Add backup monitoring and periodic restore testing to the website maintenance checklist. Record the date, backup used, environment restored, checks completed, issues found and corrective actions.
Questions to ask before approving a backup plan
- What business data and website components are included?
- How much recent data could be lost?
- How quickly could the priority service be restored?
- Is there an independent, protected copy?
- Who receives failure alerts and owns corrective action?
- When was a full restoration last tested?
- Does the runbook cover compromise as well as accidental deletion?
Build recovery into the website project
Backup and recovery requirements should be agreed before launch, not discovered during an outage. Digital Consulting Pros can include hosting, ownership, handover and recovery requirements in a structured web design and development project. Contact us to discuss the website and the level of continuity your business needs.
Official guidance
