A downloaded backup is a copy of website, database, email, or hosting data saved outside the hosting environment. Backups are useful for recovery, but they can also contain sensitive information that should not be exposed.
This article explains why downloaded backups need to be stored securely, what risks they can create, and what to check before sharing, uploading, or keeping backup files long term.
Table of Contents
What a backup may contain
A hosting backup can include more than website files.
Depending on how it was created, a backup may contain:
- website files
- databases
- uploaded media
- configuration files
- email data
- usernames
- hashed passwords
- API keys
- SMTP credentials
- database credentials
- customer or user information
- order data
- form submissions
- logs
- private documents
Even if the website itself is public, the backup may contain data that was never meant to be visible online.
Why backups are sensitive
A backup can give someone a detailed copy of your website or hosting account.
If the backup includes configuration files, it may reveal database access details, application secrets, or integration keys. If it includes a database, it may contain user accounts, email addresses, orders, messages, or other private records.
Because of this, a backup should be treated as sensitive data. It should not be stored casually, shared through public links, or left inside folders that can be accessed from the browser.
Public backup files are a security risk
A common mistake is downloading a backup and then uploading it back into a public website folder.
If a backup archive is placed inside a public web directory, it may become downloadable from a URL.
For example, files such as these should not be publicly accessible:
backup.zip
website-backup.tar.gz
database.sql
public_html-backup.zip
old-site.zip
If someone can download the backup, they may be able to inspect the website code, database content, credentials, and private data inside it.
Backups can expose passwords and secrets
Some backups include files that contain credentials or application secrets.
Examples include:
wp-config.php
.env
configuration.php
config.php
database.sql
These files may contain database names, database users, passwords, salts, API keys, SMTP settings, or other values used by the application.
If a backup containing these files is exposed, changing only the website password may not be enough. Any exposed secret should be replaced.
Downloaded backups can become outdated
A backup is a snapshot from a specific moment.
Keeping old backups can be useful, but they may also contain outdated software, old credentials, or data that should no longer be retained. If old backups are stored without review, they can increase security and privacy risk over time.
Backups should be kept only as long as they are useful and should be deleted securely when no longer needed.
Where backups should be stored
Downloaded backups should be stored in a location that is not publicly accessible.
Suitable storage options may include:
- an encrypted local drive
- a secure external drive
- a private cloud storage account
- a backup service with access control
- a protected internal storage location
The important point is that access should be limited to people who actually need it.
How to store backups more safely
Use a careful process when handling downloaded backups.
- Store backups outside public website folders.
- Use strong passwords for storage accounts.
- Enable two-factor authentication where available.
- Encrypt backup files when possible.
- Limit who can access the backup.
- Avoid sharing backups through public links.
- Remove backups from temporary locations after use.
- Keep only the backups you still need.
- Delete old backups securely.
- Rotate credentials if a backup was exposed.
These steps reduce the chance that a recovery file becomes a new security problem.
Be careful when sharing backups
Sometimes a backup needs to be shared with a developer, agency, or support team.
Before sharing it, confirm what data is included and whether the recipient needs the full backup. In some cases, a specific file, error log, or database table may be enough.
If a full backup must be shared, use a private transfer method and remove access after the work is complete. Avoid public download links that remain active indefinitely.
Backup archives and search engines
If a backup file is placed in a public folder, search engines or automated scanners may discover it.
Even if the link is not published on a page, the file may still be found through predictable filenames, directory listings, logs, or automated scans.
A file should not be considered private only because the URL is not widely known.
What to do if a backup was public
If a backup file was publicly accessible, treat it as a possible security incident.
Recommended actions include:
- Remove the public backup file immediately.
- Check whether similar backup files are also public.
- Review access logs if available.
- Change database passwords included in the backup.
- Rotate API keys, SMTP passwords, and application secrets.
- Review website users and administrator accounts.
- Check whether the database contains sensitive user data.
- Monitor the website for suspicious activity.
The correct response depends on what the backup contained and how long it may have been accessible.
Practical meaning for users
Backups are important because they help restore a website after mistakes, failed updates, malware, or data loss. The same backup can also create risk if it is stored in the wrong place.
A downloaded backup should be handled like a private copy of your hosting account. Store it securely, limit access, and remove it when it is no longer needed.
Summary
Downloaded backups should be stored securely because they may contain website files, databases, credentials, user data, email data, and private configuration details.
A backup should never be left in a public website folder or shared through an unrestricted link. Secure storage, limited access, encryption, and careful cleanup help keep backups useful without creating unnecessary risk.