Website Files vs Database: What Actually Needs to Be Backed Up?

---

When people talk about backing up a website, they often say, “Make sure your website is backed up.”

But what exactly does that mean?

A website can contain many different types of information. Some of it lives in files, while other information may be stored in a database.

Understanding the difference matters because backing up website files and backing up a database are not the same thing.

If you don’t know what your backup actually includes, you may discover that something you expected to recover isn’t part of the backup at all.

What are website files?

Website files are the individual files that make up or support your website.

Depending on your website and platform, these might include:

• Images and other media.
• CSS stylesheets.
• JavaScript files.
• PHP files.
• Theme files.
• Plugin files.
• Configuration files.
• Fonts and other website assets.

For example, a website might contain a structure such as:

/images/logo.png

/css/style.css

/js/scripts.js

/themes/my-theme/

These are website files.

When you change one of these files, the file itself has changed.

This is the type of website content that a file-based backup can preserve.

What is a database?

A database is different.

Many websites use a database to store information that changes independently of the website’s files.

Depending on the platform, a database may contain things such as:

• Website settings.
• Posts and pages.
• User information.
• Comments.
• Product information.
• Orders.
• Other application data.

The exact information depends on how the website is built.

For example, changing the text of a blog post may update information stored in the database without changing the PHP or CSS files that run the website.

That distinction is important when thinking about backups.

Website files and databases work together

For many websites, the files and database are both important.

Think of a typical content management system.

The files provide the software, themes, plugins, images, and other assets.

The database stores much of the site’s dynamic content and settings.

You need both parts for the complete website experience.

That’s why asking only “Do I have a website backup?” isn’t enough.

A better question is:

“What exactly does my backup include?”

A simple example

Imagine you run a website with 5 GB of website files and a database containing your posts, settings, and users.

You make a backup of the website files.

Later, one of your theme files is accidentally overwritten.

Your file backup can help you recover the previous version of that theme file.

But if a blog post was deleted from the database, a file backup alone won’t necessarily contain that database record.

The two situations are different because the information is stored in different places.

What does WebsiteSave back up?

WebsiteSave focuses on website files.

That includes the files that make up your website and its file-based content, such as images, scripts, stylesheets, themes, plugins, and other website assets within the backup scope.

WebsiteSave’s backup history lets you look back at previous backup points and recover the files you need.

For example, you can:

• Restore an individual file.
• Recover files that were changed.
• Recover deleted files.
• Use an earlier backup point when you need to recover website files.

You can learn more about these options in WebsiteSave Restore Options: What Can You Restore?.

WebsiteSave does not provide database backup

This distinction is important.

WebsiteSave’s backup service is focused on website files, not database backup and restoration.

If your website depends on a database, you should have a separate strategy for protecting that database.

That doesn’t make file backups less important.

It means you should understand that different parts of your website may require different backup solutions.

For example, a website owner might use WebsiteSave for website file backups while maintaining a separate database backup process.

Knowing this before an incident is much better than discovering it during one.

Why website files still matter

It can be easy to focus heavily on database content because that’s where posts, users, products, and other dynamic information may be stored.

But website files are equally important.

Your files may contain:

• Your website’s visual design.
• Custom code.
• Themes.
• Plugins.
• Images.
• JavaScript.
• CSS.
• Uploaded assets.
• Configuration and application files.

A lost or modified file can cause pages to look wrong, functionality to stop working, or unexpected behaviour to appear.

That’s why file backup should be treated as an important part of your overall website recovery strategy.

What happens when a file changes?

Imagine that a developer changes a theme file.

The website works normally before the change.

After the update, something breaks.

If you have backup history, you can look at an earlier backup point and recover the previous version of the affected file.

This is one of the advantages of having file-level backup history rather than simply keeping one old copy of the website.

You can go back to the point you need and recover the relevant files.

For more on this, see Full vs Incremental Backups: What’s the Difference?.

What happens when a file is deleted?

The same principle applies to deleted files.

Suppose someone accidentally removes an important image from your website.

If that image existed in an earlier backup, you can use the backup history to recover it.

You don’t necessarily need to replace every other website file.

You can restore the file that is actually missing.

This is one reason granular recovery options are useful.

What happens when database content is lost?

Database content is a different situation.

If a post, user, product, or other database record is deleted, recovering the website files alone won’t recreate that database information.

You need a database backup or another appropriate recovery mechanism for that data.

This is why website owners should understand the difference between file recovery and database recovery.

They solve different problems.

Don’t assume your hosting backup covers everything

Your hosting provider may offer backups, but you should still check exactly what is included.

Ask:

• Are website files backed up?
• Is the database backed up?
• How frequently are backups created?
• How long are they retained?
• Can you access older backup points?
• Can you restore individual files?
• Where are the backups stored?
• What happens if you lose access to the hosting account?

The answers can vary significantly between hosting providers.

A backup feature isn’t useful if you don’t understand what it actually protects.

Think about backups by type of data

Instead of thinking about your website as one large thing, it can help to divide it into categories.

Website files

Images, themes, plugins, scripts, stylesheets, custom code, and other file-based content.

Database

Posts, users, settings, products, comments, and other information stored in the database.

External services

Some websites also depend on third-party services for things such as email, payments, analytics, or other functionality.

Each category may have its own backup or recovery requirements.

The more you understand these dependencies, the easier it becomes to build a sensible recovery plan.

Your backup strategy should match your website

A simple brochure website may have relatively few files and little dynamic content.

A large online store may have thousands of products, customer accounts, orders, media files, and other information.

They shouldn’t necessarily have the exact same backup strategy.

The important thing is to identify what information your website depends on and make sure each important part has an appropriate recovery method.

WebsiteSave can form the website file backup part of that strategy.

You can learn more about WebsiteSave’s features or explore WebsiteSave plans.

Backup is about knowing what you can recover

A backup isn’t just a checkbox saying “protected.”

It’s important to know what is actually available when something goes wrong.

If your file backup contains your website’s files, you should know how to recover those files.

If your database is important, you should know how that database is backed up and restored.

And if your website relies on external services, you should understand how those dependencies would be handled during recovery.

The more clearly you understand these pieces before an incident, the less likely you are to discover an unexpected gap afterward.

The takeaway

Website files and databases are different parts of a website.

Website files can include images, themes, plugins, scripts, stylesheets, custom code, and other file-based content.

Databases can contain posts, users, settings, products, comments, and other dynamic information.

Both can be important, but they require different backup approaches.

WebsiteSave focuses on backing up website files, giving you backup history and practical options for restoring individual, changed, or deleted files.

If your website relies on a database, make sure you have a separate strategy for protecting that data.

The most important thing is knowing exactly what your backup protects — before you need to use it.