The forgotten backup on your server that anyone can download

A backup is a good thing to have. The trouble starts when it sits in the wrong place.

The usual story goes like this. A developer moves your site to a new hosting company, or makes some larger changes. Just in case, they pack the whole site into backup.zip, export the database to database.sql and leave both in the website folder so they are close at hand. The job gets done, the site works, the files stay. A year later nobody remembers they exist.

The website folder, though, is public. Anything in it can be downloaded with an ordinary browser by anyone who knows the address, or guesses it.

What usually gets left behind

The most common finds look something like this:

• archives of the whole site, such as backup.zip, site.tar.gz or www-2023.zip,
• database dumps: dump.sql, database.sql, db_backup.sql,
• copies of the configuration file: wp-config.php.bak, wp-config.php.old, config.php~,
• entire old versions of the site in folders called old/, test/ or backup/,
• archives and installer files left behind by site migration plugins.

The most dangerous one is often the smallest: a copy of the configuration file. The server runs the original wp-config.php as a program, so nobody outside can read what is inside. But to the server, wp-config.php.bak is just a text file. It will hand it over in full, including the database name, username and password.

A database dump, on the other hand, holds everything your shop or forms have collected: names, addresses, phone numbers, order history, user accounts. And an old/ folder often contains a complete, working copy of the site from years ago, with plugins nobody updates. Your main site can be well looked after and still get broken into through the forgotten one next to it.

Why bots go looking for them

Nobody needs to know that you in particular have a backup on your server. Automated scanners roam the internet, and on every site they reach they try a list of common names: /backup.zip, /site.zip, /dump.sql, /wp-config.php.bak, /.env. It is cheap and fast, so they do it constantly.

If you ask your hosting company for the site's access logs, you will almost certainly see these attempts. On a tidy site every one of them ends with a 404, meaning the file is not there. On a site with a forgotten backup, one of them ends with a 200 and a download.

The second route is Google. If directory listing is switched on, visiting yourdomain.com/backup/ shows a plain list of files headed "Index of /backup". Pages like that sometimes end up in search results, and then anyone can find them without guessing at all.

What you can check yourself, without server access

A few things take five minutes:

1. Search Google for site:yourdomain.com intitle:"index of". No results is a good sign.
2. Type a few addresses into your browser, such as yourdomain.com/backup.zip, yourdomain.com/database.sql or yourdomain.com/old/. If a download starts or you see a list of files instead of an error page, you have your answer.
3. Run the site through a scanner such as ShieldWave, which tries the same common names from the outside that bots do. The difference is that the results come to you.

Guessing only goes so far, though. There are hundreds of possible names, and a developer could have called the file anything. The only reliable answer comes from someone who looks at the files on the server.

How to ask your developer or hosting company to check

You do not need the technical details. A short message asking for four things is enough:

• a check that the public website folder (usually called public_html, www or httpdocs) holds no .zip, .tar.gz, .sql, .bak or .old files, and no folders like old, backup or test,
• anything they find moved outside the public folder, or deleted,
• directory listing switched off, if it is on,
• a look through the server logs to see whether anyone downloaded those files.

That last point matters. If someone downloaded a copy of the configuration file, deleting it is not enough. The database password has to be changed, because someone may already have it written down.

If the downloaded file contained customer data, you are dealing with a personal data breach. Under Article 33 of the GDPR you then have 72 hours from becoming aware of it to report it to your data protection authority, unless the breach is unlikely to put the people concerned at risk. In the UK that authority is the ICO. Even when you do not report it, you are expected to keep a record of it.

Where backups should live

A good backup meets a few simple conditions:

• it sits outside the public website folder, and ideally on another server altogether or in a separate storage service,
• it runs by itself on a schedule, not whenever someone remembers,
• several older versions are kept, because an infection is often only discovered weeks later,
• someone has tried restoring the site from it at least once.

Be careful with WordPress backup plugins. Some of them save archives inside the website folder by default, for example somewhere in wp-content, and protect them with an .htaccess file. That protection works on Apache and LiteSpeed servers, but an nginx server does not read the file at all. The simplest fix is to set the plugin to send backups elsewhere and not keep a local copy.

System administrators talk about the 3-2-1 rule: three copies of your data, on two different kinds of storage, with one kept off site. A small business website can get by with a lighter version: a backup made by the hosting company plus a copy sent automatically somewhere else. Just never into a folder anyone can open in a browser.

If you only ask whoever looks after your site one question, make it this one: where are our backups, and who apart from us can download them?