How to check your website for exposed database backups

Run a Disk scan in FTP by Zaweba and look at the web-server lens. It flags database dumps sitting in web-accessible folders and backup archives as security problems, lists them before anything else, and explains each one in plain words. From there you can download them, move them out of the public folder or send them to the trash.

A database dump left inside public_html is one of the easiest ways for a site to leak. If someone guesses or finds its address, they can download every customer record, every email address and every password hash in one go. Backup archives of the whole site are almost as bad, because they often contain configuration files with database passwords in them.

How these files get there

Usually by accident. A developer exports the database before a migration and saves it next to the site. A plugin or a hosting tool makes a backup archive in the web root. Someone zips the site before an update and forgets the zip. None of these is unusual, which is why it is worth checking every site you look after now and then.

Running the check

Connect to the site and open Disk from the toolbar or the Site menu. Let the scan finish; on shared hosting keep the scan connections at the safe setting of 3, which is a per-site option in Site Manager.

Switch the list to lens results. Security items come first, and the ones to look for here are database dumps in web-accessible folders and backup archives. Each row says why it is listed, with its size and location. The lens also points out world-writable files and folders, which are another security problem worth fixing while you are there.

If nothing is flagged, that is good news. If something is, don't panic and don't delete it in a hurry: first decide whether you need it.

Dealing with what you find

If the file is a backup you want to keep, download it to your PC. Disk can download tagged files, and once you have a copy you can remove it from the server. If it needs to stay on the server, move it to a folder that is not served to the web; Disk can move files, and your host's folder above public_html is the usual place.

If it is old and you have no use for it, tag it and send it to the trash. The trash is on the server too, so for a security problem, finish the job: open the Trash window and use Delete ticked permanently once you are sure. You will be asked to type the number of files, and it can download a backup first.

Protected paths such as wp-config.php, .env and .htaccess are never moved or deleted by Disk unless you have changed the site option that allows it. That keeps a hurried clean up from taking the site down.

Afterwards

Think about how the file got there and stop it happening again. If a backup tool writes into the web root, change its settings. If people on your team make exports by hand, agree a folder outside public_html for them.

Export the list as shown to CSV from Disk before and after the clean up, so you have a record. The operations log keeps what Disk did, batch by batch, and can undo a batch of moves or trashing if you removed the wrong thing.

If a dump was exposed for a long time on a site with customer data, removing it is the first step, not the last. Changing the database password and any passwords inside the dump is sensible, and depending on what it held you may have obligations to the people whose data it was.

Why a scan beats a quick look

You could browse the server pane folder by folder looking for .sql or .zip files, and on a tiny site that might work. On a site with years of uploads, a scan that reads every folder and sorts the risky items to the top finds the file you would have missed. FTP by Zaweba does it with the same connection you use to edit and upload, so checking takes a few minutes rather than an afternoon.