Is Your wp-content/backup-db/ Folder Exposed to the Public?

If you search inurl:wp-content/backup-db/ on Google, the results are genuinely alarming. Thousands of real WordPress sites show their database backup folders to anyone who looks. Those folders contain raw SQL dump files packed with user emails, hashed passwords, and sometimes years of customer order data. The same problem hits inurl:wp-content/backups/, exposed wp config backup txt files, and unprotected All in One WP Migration archives sitting in publicly reachable directories. This article covers exactly where WordPress stores backup files, why those paths turn into serious security holes, how attackers find them with a single Google search, and every step you need to take to stop your site from showing up in those results.

What wp-content/backup-db/ Actually Is

WordPress does not come with a native backup solution built in. But certain older plugins, database management tools, and specific hosting configurations create a folder called backup-db inside your wp-content directory without asking. When a plugin runs a scheduled database dump or a user manually exports via phpMyAdmin and picks “save to server” instead of downloading locally, that file often ends up sitting right there. Most site owners never see it happen because there is no notification, no warning about public access, no prompt to move the file somewhere safer.

What makes this worse is that the folder doesn’t announce itself. You run a plugin once, it creates the directory, stores a backup, and that’s it. Six months later, that backup file is still there, still reachable, and Google has already indexed the directory.

How WordPress (And Some Plugins) Create This Directory Automatically

WordPress itself does not create the backup-db folder. That directory gets created by older database management plugins and legacy tools. Plugins like WP-DBManager were built to save SQL exports directly into wp-content/backup-db/ as their default behavior. Some scripts at the server level and cPanel backup tools also drop exported database files into this path when a user chooses the “save to server” option instead of downloading the file locally.

The result is a folder that builds up over time. Multiple backup files accumulate, each one containing a full copy of your database from a different date. Users who ran such a plugin years ago may still have four or five old SQL files sitting in that directory right now.

What Files You Will Typically Find Inside It

Inside a live wp-content/backup-db/ directory, you’ll usually find one or more .sql files or .sql.gz compressed archive files. These are full database export files, SQL export files created by either a plugin or a manual phpMyAdmin export. An SQL export file contains every table in your WordPress database, which means all user accounts, all posts and settings, every stored password hash, and depending on your setup, WooCommerce order data, customer emails, and billing details.

Some backup files also include the contents of your wp_options table. That table stores your site’s configuration, and it sometimes holds plugin settings, API keys stored by certain plugins, and serialized data that reveals details about how your site is built internally.

Why This Folder Ends Up Indexed By Google (Directory Listing Is On By Default)

On many hosting setups, Apache web servers have directory listing turned on by default. That means if there’s no index.php or index.html file inside a folder, and no rule blocking access, anyone who types the folder URL into a browser sees a full list of every file inside it. No login required. No warning. Just an open file browser.

Google’s crawlers work the same way any visitor does. They follow links, crawl URLs, and index what they find. If your wp-content/backup-db/ folder has directory listing on and no access restrictions, Google will index it. Once it’s indexed, it shows up when someone searches inurl:wp-content/backup-db/. That search is exactly what attackers and automated scanners run on a regular basis.

The Difference Between backup-db/ And A Full Site Backup

A full site backup covers two things: your WordPress files (themes, plugins, uploads, core files) and your database. The wp-content/backup-db/ folder stores only database exports. That means it does not contain your media files, your theme customizations, or your plugin files.

This distinction matters for two reasons. First, if you’re relying on these files as your only backup copy, a full site restoration will not be possible from them alone since you’d be missing the file system half. Second, from a security angle, a database export is arguably the most sensitive piece of the whole backup because it holds your actual user data. Attackers targeting this folder don’t care about your theme files. They want the database.

Other WordPress Backup Folder Locations You Need To Know

The wp-content/backup-db/ path is just one of several places where WordPress and its plugins leave backup files. Different plugins use different default paths, and most of them default to storing files inside the web root, which makes them potentially reachable from a browser unless you add explicit blocking rules.

This is a wider problem than most people realize. A site that looks secure on the surface can have three or four separate backup locations scattered across wp-content, every one of them reachable by a direct URL, and the site owner has no idea any of them exist. The table below shows how the most common plugins handle default storage.

wp-content/backups/ — Which Plugins Create It And What They Store There

The wp-content/backups/ path is created by several plugins, including older versions of BackWPup and certain other automated backup tools. Searching inurl:wp-content/backups/ on Google brings up real sites with this folder exposed. Files inside can be downloaded directly, giving an attacker a complete offline copy of your WordPress installation. Unlike the backup-db folder which only holds database dumps, the backups/ folder often stores full site backup packages, compressed archives containing themes, plugins, uploads, and the database all bundled into a single file. From that file, someone can extract your wp-config.php, read your database credentials, and if your database server allows remote connections, access your database directly.

ai1wm-backups/ — The Default Storage Path For All-in-One WP Migration

All-in-One WP Migration is one of the most downloaded WordPress migration plugins. Its default all in one wp migration file location is wp-content/ai1wm-backups/. That folder stores .wpress files, which are proprietary archive packages containing both your database and your website files.

The plugin creates this directory automatically when you run your first export. No setup step asks whether this location is safe. No warning explains that the folder will be inside your public web root. It just creates the directory and starts saving files. Because .wpress files are a documented format that everyone in the WordPress space knows about, anyone who downloads one can extract its contents without needing any special tools or knowledge.

wp-config-backup.txt — How It Gets Created And What It Contains

The wp config backup txt file appears when certain tools or manual processes create a copy of wp-config.php before editing it. Some migration plugins, hosting migration wizards, and manual site moves produce a file called wp-config-backup.txt, wp-config.bak, or something similar sitting in your WordPress root directory.

This file is extremely dangerous when publicly accessible. Your wp-config.php holds your database name, database username, database password, database host, and all of your WordPress secret keys and salts. If a wp-config-backup.txt file is sitting in your root directory without protection, any visitor who knows to look can read your database password in plain text directly from their browser. This happens regularly on real sites.

Backup Paths Created By UpdraftPlus, Duplicator, And WP-CLI Exports

UpdraftPlus stores backup files by default in wp-content/updraft/. Duplicator creates a folder like wp-content/backups-dup-lite/ depending on the version. WP-CLI, when you run wp db export without specifying an output path, saves the .sql file to your current working directory, which on many server setups is your public web root.

Every one of these paths shares the same core problem: they default to locations inside the web root, making files reachable unless you add explicit access rules. Most users install these plugins and run their first backup without ever checking whether the output location is open to the public.

Why So Many Of These Folders End Up Publicly Accessible

The core reason is a combination of default settings and missing server protections. Plugins choose paths inside wp-content because that’s the logical place to store plugin-related data inside WordPress. But there is a big difference between “logical for WordPress” and “safe from public access.” WordPress does include a basic .htaccess file in wp-content/uploads/ to block PHP execution, but it does nothing to block directory browsing or direct file access to backup archives. Unless your hosting provider, server configuration, or a dedicated security plugin adds blocking rules, these folders stay open.

The Real Security Risk When These Directories Are Public

Here is a scenario that plays out more often than it should. A site owner runs a small WooCommerce store. Automated backups have been running for two years, saving weekly database dumps to wp-content/backup-db/. One night, someone runs inurl:wp-content/backup-db/ on Google, finds the site in the results, downloads the most recent SQL file, and has a complete copy of every customer account, order, and stored credential on the site. The store owner finds out three weeks later when customers start reporting unauthorized charges on accounts they used to buy from that store.

That gap between exposure and discovery is what makes this type of security problem so damaging.

What An Attacker Can Pull From A Leaked Database Backup File

A WordPress database backup file contains every table from your MySQL database. For a standard WordPress installation, that includes the wp_users table, which holds every registered user’s username, email address, and hashed password. For WooCommerce sites, it also includes order tables with names, shipping addresses, phone numbers, and purchase histories.

Hashed passwords are not plain text, but they’re not fully safe either. Given enough time and the right tools, weak passwords can be cracked through brute force against the hash. More immediately, the email addresses from your user table can be sold, and your admin username gives an attacker half of the credentials they need for a brute force attack on your login page.

What Gets Exposed When wp-config-backup.txt Is Reachable

The database password stored in wp-config.php is the master key to your WordPress installation. If your database server allows remote connections, which many shared hosting setups do, an attacker with your database credentials can connect directly to your database, read every table, modify records, add admin user accounts, or delete everything without ever touching your WordPress site’s interface.

Even if your database blocks remote connections, the secret keys and salts in wp-config.php are used to secure your WordPress authentication cookies. With those values, someone can potentially forge authentication tokens and gain admin access without a password. The damage potential from a single exposed wp-config-backup.txt file is total.

How Google Dorking With inurl: Finds These Paths — And Who Runs Those Searches

Google dorking means using advanced search operators to find specific types of publicly accessible content. The inurl: operator filters results to only show pages where the URL contains a specific string. Searching inurl:wp-content/backup-db/ returns a list of sites where that path exists in the URL, which means their directory listing is live and indexed.

Security researchers use this technique to find and report vulnerabilities responsibly. But the same technique is widely used by automated scanners that scrape lists of vulnerable URLs and hand them off to bad actors. Once your site appears in those search results, it stays there until the folder is locked down or removed from Google’s index. The exposure window can stay open for months or years without the site owner knowing.

Real Consequences: Credential Stuffing, Full Database Takeover, Site Defacement

Credential stuffing attacks take username and password combinations from one breach and try them against other services. If your leaked database backup includes customer accounts and any of those customers reuse passwords across sites, their accounts on banking platforms, email providers, and other services are now at risk too.

Full database takeover means an attacker can delete your content, replace it with spam, inject malicious links into posts, or use your site’s email system to send phishing messages to your subscribers. Site defacement is the most visible consequence since visitors see it immediately. But the quieter damage, the stolen credentials, compromised customer accounts, and admin access sold on underground forums, can cause problems long after you’ve cleaned your site.

How To Check If Your Backup Folders Are Publicly Accessible

Before fixing anything, you need to know whether you actually have this problem. Checking is fast and requires no special technical setup. You can do most of it from a browser tab in under five minutes.

Start with the most direct method and work through each path systematically. Don’t just check backup-db/. Check every backup folder you might have.

Testing It Directly In A Browser (What An Open Directory Listing Looks Like)

Open your browser and type your site’s URL followed by /wp-content/backup-db/. For example: https://yoursite.com/wp-content/backup-db/. If you see a plain list of filenames, dates, and sizes with no page styling, directory listing is on and that folder is publicly accessible.

Do the same for /wp-content/backups/, /wp-content/ai1wm-backups/, /wp-content/updraft/, and any other backup paths you might have set up. A 403 Forbidden or 404 Not Found response means the folder is either protected or doesn’t exist. A visible file list means it’s open.

Using Google Search To Check Your Own Domain

Open Google and search site:yoursite.com inurl:backup. Replace yoursite.com with your actual domain. This returns every URL on your site that Google has already indexed containing the word “backup” in the path.

Look through the results carefully. Paths like /wp-content/backup-db/, /wp-content/backups/, or any URL ending in .sql, .gz, or .wpress tell you Google has already indexed those locations. That means anyone else can find them the same way. Write down every URL that appears and treat each one as an active exposure you need to close.

Running A Quick Scan With Tools Like WPScan Or Sucuri SiteCheck

WPScan is a command line tool built for finding WordPress security issues. Running wpscan –url https://yoursite.com does a basic scan and can surface exposed directories, known vulnerable plugins, and other configuration problems. If you’re comfortable working in a terminal, it’s worth running.

Sucuri SiteCheck at sitecheck.sucuri.net is free and browser-based. It checks for malware, blacklist status, and some common configuration issues including exposed files. Wordfence’s built-in Site Health section inside WordPress also flags some common directory exposure issues. None of these tools catch everything, but they’re a solid starting point.

Checking Your Server Error And Access Logs For Suspicious GET Requests

Your hosting account’s access logs record every request made to your site. Inside your hosting control panel, look for access_log or access.log files and search them for GET requests to paths containing “backup”, “.sql”, “.gz”, or “.wpress”.

If you find requests to backup paths from IP addresses that aren’t yours, especially large volumes or requests from unexpected locations, someone has already found and attempted to access your backup files. This doesn’t confirm a successful download, but it tells you the exposure is real and was noticed by someone outside your organization.

How To Block Access To WordPress Backup Directories

Locking down your backup directories doesn’t require deep server knowledge or taking your site offline. Most of it comes down to adding a few lines to the right configuration files and moving files to better locations. Pick the methods that match your server type and work through them in order.

Start with moving the files out first if possible, then layer in configuration protections as a backup to the backup, so to speak.

Blocking Directory Access Via .htaccess On Apache — Exact Rules To Add

If your hosting runs Apache, which most shared hosting plans do, you can block access to specific backup folders by creating a .htaccess file directly inside each folder. Create a file called .htaccess inside wp-content/backup-db/ with this content:

Order allow,deny

Deny from all

For Apache version 2.4 and above, use the newer syntax:

Require all denied

Apply the same file to wp-content/backups/, wp-content/ai1wm-backups/, and wp-content/updraft/. You can also add path-specific rules to your main wp-content/.htaccess file if you want to manage everything from one place.

Restricting Backup Folder Access In NGINX Configuration

On NGINX, .htaccess files don’t work. Access rules go into your server block configuration file, typically at /etc/nginx/sites-available/yoursite.conf or a similar path depending on your setup.

Add this block inside your server configuration to block direct access to backup folders:

nginx

location ~* /wp-content/(backup-db|backups|ai1wm-backups|updraft)/ {

    deny all;

    return 404;

}

After adding that block, test your NGINX configuration with nginx -t and reload the service with systemctl reload nginx. Returning a 404 instead of a 403 is a deliberate choice in many setups since it reveals less information about what’s actually stored there.

Disabling Directory Listing Entirely For Your WordPress Install

If you want to address the root cause rather than protecting individual folders one by one, disable directory listing for your entire WordPress installation. On Apache, add this line to your main .htaccess file in your WordPress root directory:

Options -Indexes

That single line turns off directory listing for every folder on your site that doesn’t have an index.php or index.html file. It removes the ability to browse folder contents from a browser. It doesn’t block file access if someone knows the exact filename, but it closes the most obvious entry point.

Moving Backup Folders Outside Your Public Web Root (Above public_html)

This is the most solid solution. Configure your backup plugin to store files in a directory that isn’t inside your web root at all. Your public web root is typically public_html or www. Any folder stored above that directory is not reachable via a browser URL.

On most shared hosting accounts, you can create a folder called wp-backups at the same level as public_html. The path would look like /home/yourusername/wp-backups/. Then point your backup plugin’s storage destination to that path. Files stored there cannot be accessed by anyone browsing your site, regardless of what server configuration rules are or aren’t in place.

Setting Correct File Permissions On Backup Directories

File permissions control who can read, write, or run files and folders on your server. For backup directories, the right permission settings are 750 for folders and 640 for files. On the folder, 750 means the owner can read, write, and execute, while the group can read and execute, and everyone else has no access. On files, 640 means the owner can read and write, the group can read, and everyone else has nothing.

Set these via SSH with the following commands, replacing the path with your actual backup folder location:

bash

chmod 750 /path/to/backup-folder/

chmod 640 /path/to/backup-folder/*.sql

Correct permissions alone won’t stop web server access since the server process often runs as the owner or group. Combined with .htaccess rules or NGINX config blocks though, they add a meaningful extra layer that covers gaps in server configuration.

How To Back Up WordPress Correctly Using WP-CLI

WP-CLI is the command line interface for WordPress. If you have SSH access to your server, WP-CLI lets you manage nearly everything about your WordPress installation directly from a terminal, including creating database exports, running updates, managing plugins, and setting backup schedules, all without touching a web browser.

Using wp cli backup tools this way gives you far more control over where files land compared to most plugins, which makes it straightforward to keep everything out of public locations from the start.

What WP-CLI Is And How To Install It On Your Server

WP-CLI is a free, open source tool maintained by the WordPress community. Many managed WordPress hosting providers install it by default. To check if it’s already available on your server, connect via SSH and run:

bash

wp –info

If you see version information printed back, it’s already installed. If not, install it with:

bash

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

chmod +x wp-cli.phar

sudo mv wp-cli.phar /usr/local/bin/wp

Run wp –info again after that to confirm the installation worked.

Exporting Your Database With wp db export — Options And Output Path Control

The wp db export command creates a full SQL export of your WordPress database. The basic command, run from your WordPress installation directory, is:

bash

wp db export

By default, that saves a file named something like database-2025-06-24.sql in your current working directory. If you’re inside public_html when you run it, the SQL export file lands there and becomes publicly accessible. Always specify a full path outside your web root:

bash

wp db export /home/yourusername/private-backups/db-export.sql

The –add-drop-table flag makes restoration easier by adding drop statements before each create statement. The –no-tablespaces flag avoids permission issues on certain hosting environments where the database user doesn’t have tablespace permissions.

Compressing Your WordPress Files Into A Single Archive For A Full Backup

After exporting your database, compress your WordPress file system into a single archive. Navigate above your web root first, then run:

bash

cd /home/yourusername/

tar -czf private-backups/wp-files-$(date +%Y%m%d).tar.gz public_html/

That command creates a compressed .tar.gz archive of your entire public_html directory and saves it to your private-backups folder, which sits outside the web root. Combined with your database export, this gives you a full site backup that no one can reach through a browser URL.

The –path Flag And Why It Matters For Saving Exports In A Non-Public Location

The –path flag tells WP-CLI where your WordPress installation is located. This is useful when you’re running commands from outside your web root or from a non-standard working directory.

For example, if you’re in your home directory and want to run a database export directly to a private folder:

bash

wp db export /home/yourusername/private-backups/backup.sql –path=/home/yourusername/public_html/

This setup lets you write backup scripts that run entirely from a safe location, pull the database export, and save it outside the web root, all in a single command.

Automating WP-CLI Backups With A Cron Job

To schedule automatic backups using WP-CLI, add a cron job to your server. Run crontab -e to open your cron table and add a line like this:

bash

0 2 * * * wp db export /home/yourusername/private-backups/db-$(date +\%Y\%m\%d).sql –path=/home/yourusername/public_html/ –quiet

That runs a database export every night at 2am and saves the file with a date stamp in the filename. The –quiet flag stops WP-CLI from generating output, which keeps your server’s mail system clean. Add a second cron entry to run the file archive command on the same schedule for a full site backup routine.

Transferring Your Backup Off The Server (SCP, rsync, Or Cloud Upload)

A backup stored on the same server it’s protecting is only half a solution. If your server goes down, gets compromised, or gets wiped, the backup disappears with it. Transfer your backups to a separate location after each backup run.

SCP copies files securely over SSH from one server to another. rsync is better for incremental transfers and keeps remote copies in sync efficiently. For cloud-based offsite backup storage, a tool called rclone works with Google Drive, Amazon S3, Dropbox, and most major cloud storage services. Configure it once and add a transfer command at the end of your backup script. That way every backup automatically ends up in cloud storage without any manual steps.

Where All-in-One WP Migration Stores Its Files (And How To Change It)

All-in-One WP Migration is genuinely one of the most convenient tools available for moving a WordPress site between servers. The plugin packages your entire installation into a single .wpress file that you can import to another host in minutes. But its default file storage behavior is a security problem that most users never address, and the plugin doesn’t make it obvious that any problem exists.

Understanding the all in one wp migration file location and knowing how to change it are things every user of this plugin should do before running their first export.

The Default File Location — Inside wp-content/ai1wm-backups/

When you export your site, All-in-One WP Migration saves the resulting .wpress file to wp-content/ai1wm-backups/. This directory is created automatically on your first export. No setup prompt asks whether this location is appropriate. No warning mentions that you’re saving a complete copy of your site to a web-accessible folder.

A .wpress file is a complete backup of your WordPress installation. It contains your database, your files, your theme customizations, and your wp-config.php. Downloading one file hands over everything someone would need to replicate or compromise your site entirely.

Why This Path Is Publicly Accessible By Default And What That Means

All-in-One WP Migration includes a .htaccess file and an index.php inside the ai1wm-backups directory to prevent direct browsing. On Apache servers, this provides some protection against directory listing. On NGINX servers, .htaccess files are not processed at all, which means the default protection does nothing. The directory and its contents are fully open.

Even on Apache setups, the plugin’s built-in protection blocks directory listing but may not block direct file downloads if someone knows or guesses the exact filename. On some hosting configurations, the .htaccess rules don’t apply correctly depending on how the server is set up.

Step By Step: How To Change The Storage Path Using The constants.php File

All-in-One WP Migration lets you change the default storage path by editing or creating a file called constants.php inside the plugin folder. Here is exactly how to do it:

1. Connect to your server via FTP or use your hosting file manager.
2. Navigate to wp-content/plugins/all-in-one-wp-migration/.
3. Look for a file called constants.php. If it doesn’t exist, create it.
4. Add the following code:

php

<?php

define( ‘AI1WM_BACKUPS_PATH’, ‘/home/yourusername/private-backups/ai1wm/’ );

5. Replace /home/yourusername/private-backups/ai1wm/ with the actual path to a directory outside your web root.
6. Save the file and create the destination directory before running your next export.

Creating And Configuring A New Directory Outside The Web Root

Before the path change takes effect, create the destination directory on your server. If you have SSH access, run:

bash

mkdir -p /home/yourusername/private-backups/ai1wm/

chmod 750 /home/yourusername/private-backups/ai1wm/

If you only have FTP access, create the folder using your hosting file manager at the level above public_html. Run a test export after saving the constants.php change and confirm the .wpress file appears in the new location. Once confirmed, delete any existing .wpress files still sitting in the old wp-content/ai1wm-backups/ directory.

Blocking Direct Access To ai1wm-backups/ If You Keep The Default Location

If changing the storage path is not an option right now, add an explicit access block to the ai1wm-backups directory at a minimum. On Apache, create or modify .htaccess inside wp-content/ai1wm-backups/ to include:

Order allow,deny

Deny from all

On NGINX, add a location block to your server configuration:

nginx

location ~* /wp-content/ai1wm-backups/ {

    deny all;

    return 404;

}

Also delete .wpress files from that folder immediately after generating them if you’re keeping backups elsewhere. Leaving old archives in a web-accessible folder, even one with access restrictions, is a risk that has no upside.

Best Practices For Managing WordPress Backup Files Safely

Having a backup system that actually works comes down to four things: where you store the files, how often you make new ones, how long you keep them, and whether you’ve ever verified that one of them actually restores correctly. Most sites get two out of four right. The gaps show up at the worst possible time.

None of this has to be complicated. A consistent approach that you follow beats a sophisticated setup that nobody remembers to check.

Never Store Backup Files Inside Your Public Web Root — Treat This As A Hard Rule

Every backup you create should land outside public_html or wherever your web root is. No exceptions. If your backup plugin doesn’t support a storage path outside the web root, either change the plugin or configure cloud storage as the destination so files never sit on your server in a reachable location at all.

This single rule closes the most common backup exposure problem. Configuration rules and file permissions help, but they can be overwritten, misconfigured, or simply fail. Moving files outside the web root removes that dependency entirely. There is no web server rule that can accidentally expose a file that isn’t behind a URL in the first place.

Use Cloud Storage Destinations Instead Of Your Server (Google Drive, S3, Dropbox)

Plugins like UpdraftPlus, BackupBuddy, and WPvivid all support direct upload to cloud storage destinations including Google Drive, Amazon S3, and Dropbox. Configure your plugin to send files to cloud storage after creating them, and optionally delete the local copy after a successful transfer.

Cloud backup storage gives you offsite backup that’s completely separate from your server. If the server is compromised, wiped, or physically fails, the backups survive. Enable two factor authentication on the cloud storage account itself for backup security. A stolen cloud login that can delete your backup copies would turn a recoverable problem into an unrecoverable one.

Set A Backup Retention Policy — How Many Copies To Keep And For How Long

Storing every backup you’ve ever created wastes storage space and creates unnecessary exposure. Set a backup retention policy that matches your actual needs. For most sites, keeping seven daily backups and four weekly backups gives you enough history to recover from almost any problem, including problems you don’t notice right away.

Most plugins let you set the retained backup count directly in their settings. Set that number, confirm old backups are actually being deleted when new ones are created, and review the count periodically. A plugin set to retain ten backups that has been running for three years may have accumulated far more files than expected due to a settings change or plugin bug.

Schedule Automatic Backups Based On How Often Your Content Changes

Backup frequency should match how often your content changes. A WooCommerce store processing orders daily should run at least daily full site backups and possibly more frequent database snapshots during peak periods. A blog that publishes twice a month can reasonably run weekly full backups and daily database backups.

Automatic backup scheduling removes the human element from the process. You won’t forget to back up before a major update. You won’t realize you haven’t backed up in a month only after something goes wrong. Set your backup schedule once, confirm it’s working by checking backup file timestamps after a few days, and then review periodically to make sure new files are still being created on schedule.

Actually Test A Restore — A Backup You’ve Never Restored Isn’t A Backup You Can Trust

This is the step almost everyone skips. Running a backup verification means taking an actual backup file and restoring it to a test environment to confirm your site comes back up correctly. It doesn’t have to be complicated. A local WordPress installation using LocalWP or a staging environment from your hosting provider works fine.

If you’ve never tested a restore, you don’t actually know whether your backups work. Backup files can be corrupted, incomplete, or created by a misconfigured plugin that silently skips important files. Discovering that your backup doesn’t restore correctly when you actually need it is one of the most avoidable problems in WordPress site management. Test at least once every three months.