What Should a Website Backup Include?

A website backup should be more than a simple copy of files. For a site hosted on a managed hosting platform, it needs to capture everything required to restore the website to a working state after a mistake, update failure, security incident, or server issue. If one part is missing, recovery can become incomplete, time-consuming, or impossible.

In practice, a reliable backup should include website files, the database, configuration settings, email data when relevant, and enough version information to match the restore point you need. For websites managed through a control panel such as Plesk, this often means backing up the full subscription or selected domains together with their settings, rather than only the web root.

For websites serving users across Europe, backup planning should also account for data protection, restore speed, and retention needs. A good backup strategy is not just about storage space. It is about making sure the backup can be restored quickly, safely, and with minimal data loss.

What a website backup should include

A complete website backup usually contains the parts listed below. Depending on the platform and website type, some items may be optional, but the more complete the backup, the safer the recovery.

Website files

Website files are the core content of the site. They typically include:

  • HTML, CSS, JavaScript and image files
  • Application files for CMS platforms such as WordPress, Joomla or Drupal
  • Uploaded media files
  • The public_html or web root directory
  • Custom scripts, templates and themes
  • Plugin or extension files

If you are restoring a dynamic website, files alone are usually not enough. They must match the database and configuration from the same backup point.

Database

Most modern websites depend on a database to store content, user accounts, product data, settings and form submissions. A backup should include the full database dump for every active site or application database.

For example, a WordPress site usually needs the MySQL or MariaDB database plus the site files. Without the database, posts, pages, comments and settings may be lost even if the files are intact.

Configuration files

Configuration files define how the site and server components behave. These may include:

  • wp-config.php for WordPress
  • Application-specific configuration files
  • .htaccess rules for Apache
  • PHP settings or runtime configuration where supported
  • Environment files such as .env
  • Rewrite rules, redirects and security rules

These files are often overlooked, yet they can be critical during restore. A missing database connection setting, wrong rewrite rule or lost redirect can make a site appear broken even when the main files are restored.

Email data, if the website uses hosted mailboxes

If your hosting plan includes email accounts tied to the domain, consider whether the backup should include mailboxes, messages, filters, forwarding rules and mailbox settings. This is especially important for business websites that rely on domain email for enquiries, support or invoicing.

In a managed hosting or Plesk environment, mail data may be stored separately from website files and databases. If you need full recovery after accidental deletion or migration, include it in the backup scope.

DNS and domain-related settings

While DNS records are not always part of a file-level backup, they are essential for restoring service quickly. Useful items to document or export include:

  • A records and AAAA records
  • CNAME records
  • MX records
  • TXT records for verification and email protection
  • Nameserver assignments
  • Subdomain mappings

If your hosting platform supports exporting zone files or DNS templates, that can significantly reduce recovery time after a change or outage.

SSL/TLS certificate details

A website backup should not usually contain private certificate keys unless your security policy allows it, but it should at least include enough information to reissue or reapply the correct SSL/TLS certificate quickly. Track:

  • Certificate type
  • Expiration date
  • Domain names covered
  • Certificate provider or automation method

If Let’s Encrypt or another automated certificate tool is used, make sure you know how to renew or re-create the certificate after restore.

Scheduled tasks and automation

Many websites depend on cron jobs or scheduled tasks for updates, imports, cleanup routines, backups or background processing. If these are not included or documented, the site may restore visually but fail operationally.

Back up or document:

  • Cron job definitions
  • Scheduled maintenance scripts
  • Queue workers or background task configuration
  • Custom automation tied to the hosting account

Access and account settings

For managed hosting, it is useful to record the access setup around the website, even if it is not part of the technical backup archive itself. This may include:

  • Control panel user roles
  • SFTP or SSH access details
  • Database user mappings
  • Application secrets or API keys stored securely
  • Deployment settings used by CI/CD tools

These items help avoid delays when a restore must be completed urgently.

What should be excluded from a backup

Not everything on a hosting account should necessarily be backed up. Excluding unnecessary or sensitive items can keep backups smaller, faster and safer to store.

Temporary and cache files

Temporary files, cache folders, build artifacts and session files usually do not need to be backed up. Examples may include:

  • Cache directories created by plugins or frameworks
  • Log files that are only useful for short-term troubleshooting
  • Compiled assets that can be regenerated from source
  • Temporary upload or processing folders

However, if you are diagnosing a specific incident, a one-time backup of logs may be helpful before excluding them from regular backups.

Duplicate or regenerable content

Assets that can be rebuilt should usually not be included in every routine backup unless there is a clear recovery reason. This may apply to:

  • Static build outputs
  • Dependency folders that can be restored through package managers
  • Generated thumbnails or cache-based image sizes

The decision depends on your restore goals and the time required to rebuild content after a failure.

Sensitive data that should be handled separately

API keys, private keys, export files and personal data may need special protection. If they are part of the backup set, make sure they are encrypted and access-controlled. If they do not need to be restored regularly, consider storing them in a secure secrets manager instead of inside routine backups.

How to define the right backup scope

The right backup scope depends on the kind of site you run and how often it changes. A brochure website, a WooCommerce shop and a custom web application have very different backup needs.

Static website

A static site often needs only the site files, deployment configuration and DNS documentation. If it uses forms, newsletters or third-party integrations, record those settings as well.

CMS-based website

For a CMS site, include the full file structure, the database, configuration files, themes, plugins and any upload directories. This is the most common backup model on hosting platforms and in control panels such as Plesk.

E-commerce website

An e-commerce site should be backed up more carefully because it changes frequently and contains transactional data. Include:

  • Product catalog database
  • Order history
  • Customer accounts
  • Payment-related integrations
  • Inventory and shipping configuration
  • Tax rules and store settings

For these sites, a backup taken after a major order spike may be more valuable than one taken hours earlier.

Custom application

For a custom web app, the backup should reflect the application architecture. That usually includes source code, database, environment variables, file storage, background job settings and any uploaded user content.

Backup frequency and retention

Knowing what to include is only part of the plan. You also need the right frequency and retention policy.

A good backup plan answers three questions:

  • How much data can you afford to lose?
  • How quickly must you be able to recover?
  • How far back might you need to restore?

For websites that change rarely, daily or weekly backups may be enough. For active blogs, membership sites or online stores, more frequent backups are usually needed. If the content changes throughout the day, consider backup points that are taken multiple times per day or before important operations such as updates, deployments or migrations.

Retention matters as much as frequency. Keep multiple restore points so you can recover from problems that were not discovered immediately, such as a broken update that was only noticed later.

Recommended backup checklist for hosting accounts

Use the checklist below to verify whether a website backup is complete enough for practical restore.

  • All website files are included
  • All active databases are included
  • Configuration files are included
  • Media uploads are included
  • Email data is included if needed
  • DNS settings are documented or exported
  • SSL/TLS certificate details are recorded
  • Cron jobs and scheduled tasks are documented
  • Restore point date and time are clear
  • Backup format is compatible with your control panel or restore process
  • Backups are stored securely and separately from the live site
  • Restore testing has been performed

How Plesk and similar control panels help

In a control panel environment, backup management is usually easier because the panel can collect multiple components into one restore package. In Plesk, for example, you may be able to back up a full subscription, a single domain, selected databases or mail accounts depending on the permissions and configuration.

This is useful because it reduces the risk of missing a part of the site. Instead of remembering file paths manually, the panel can preserve the web root, databases, mail settings and service configuration together. It also makes scheduled backups and restore points easier to manage from one place.

Even so, you should still verify what the panel includes by default. Some backup jobs may exclude remote storage, specific mail data or certain server-level settings. Always review the backup scope before relying on it for disaster recovery.

Common mistakes when creating website backups

Many restore failures happen because the backup was incomplete, outdated or never tested. The most common mistakes are:

  • Backing up only files and forgetting the database
  • Saving the database but missing custom configuration files
  • Ignoring email accounts and mailbox content
  • Not including subdomains or add-on sites
  • Using one backup copy stored only on the same server
  • Keeping backups too long without verifying integrity
  • Never testing a restore before an incident happens
  • Assuming plugin or panel backups include everything automatically

A backup is only useful if it can be restored. If possible, test restore procedures in a staging environment or a separate directory before you need them in production.

Best practice: use the 3-2-1 backup rule

A practical way to protect a website is the 3-2-1 rule:

  • 3 copies of your data
  • 2 different storage types or locations
  • 1 copy kept offsite

This approach reduces the risk of losing backups to accidental deletion, hardware failure, ransomware or a platform-level issue. For European hosting environments, storing one copy in a separate, secure location is especially useful for business continuity and recovery planning.

Step-by-step: what to do before and after a backup

Before the backup

  • Check which sites and databases are active
  • Identify recent changes such as updates or content imports
  • Confirm whether email data must be included
  • Review storage space and retention rules
  • Pause or note any scheduled tasks that may affect consistency

During the backup

  • Capture files and database from the same restore point
  • Verify that configuration files are included
  • Use a backup method supported by the hosting platform or panel
  • Prefer encrypted storage when available

After the backup

  • Confirm the archive completed successfully
  • Check file size and timestamp
  • Test extraction or restoration on a non-production copy
  • Record where the backup is stored
  • Set a review date for the next backup cycle

FAQ

Is a backup of website files enough?

No. For most dynamic websites, you also need the database and configuration files. Without them, the site may not function correctly after restore.

Should email be included in a website backup?

If the domain email is business-critical or hosted with the same provider, yes. At minimum, document how mailbox data can be restored separately.

Do I need DNS settings in a backup?

DNS records are often not part of the archive itself, but they should be documented or exported. They are important for bringing the site back online quickly.

How often should I back up a website?

It depends on how often the site changes. Static sites may need less frequent backups, while e-commerce sites and active content sites usually need more frequent restore points.

What should I test in a backup restore?

Test that the site loads, the database is connected, forms work, logins function, media is present, and scheduled tasks behave as expected.

Can I rely on automatic backups from my hosting control panel?

Automatic backups are helpful, but you should still check what they include, how long they are kept, and whether you can restore them without support assistance.

Conclusion

A website backup should include everything needed to restore the site to a usable state: files, database, configuration, and any supporting data such as email or DNS settings when relevant. For websites managed through a hosting platform or control panel, the best backup is one that matches the structure of the site and can be restored quickly without guesswork.

When you define the correct scope, keep multiple restore points, and test the restore process regularly, backup planning becomes a practical safeguard rather than a technical formality. That is the safest way to handle updates, migrations and unexpected incidents on any hosting account.

  • 0 Users Found This Useful
Was this answer helpful?