Home / Tools / Set up automated backups with offsite storage and test restoration

Exposed Files · Scan Check Guide

Set up automated backups with offsite storage and test restoration

20 min Impact: high Effort: medium ✓ Scan-verified — no manual checkbox

Backup files (.bak, .old, .zip, .sql, ~ files left by editors) are sometimes accidentally left in a site's public folder during development or migration — these often contain full database dumps or complete site copies that bypass every access control your live site has.

Backup files (wp-config.bak, database.sql, site.zip) often contain plaintext credentials. They're frequently left in web roots during migrations and never removed.

How to fix it

1

Search your public web root for common backup patterns

Look for files ending in .bak, .old, .zip, .tar.gz, .sql, or trailing ~ characters.
2

Remove anything found

Delete backup files from the public web root entirely — store backups outside the publicly served directory, or in dedicated backup storage.
3

Block common backup extensions at the server level

Add a rule denying direct access to .bak, .sql, .zip and similar extensions as a safety net against future accidents.

Common mistakes

These are almost always created by accident — a developer running 'cp index.php index.php.bak' directly on the production server during a quick edit is a classic cause.

How you'll know it's done

No backup-pattern files are accessible via direct URL request, and a server-level rule blocks the common extensions as a backstop.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →

Set up automated backups with offsite storage and test restoration

How to fix it

Common mistakes

How you'll know it's done

Related checks

H.I.V.E. checks this automatically