Testing a restore from a Google Drive backup export means downloading the archive, unpacking it somewhere that is not your live site, and rebuilding the site from those files to confirm they actually work. The short version: download the archive, verify its size and checksum, extract it locally, import the database dump into a throwaway MySQL database, point a local WordPress install at those files, and load the homepage and a few admin screens. If any of those steps fails, the backup is not a backup.
Most WordPress backup plugins that offload to Google Drive report success when the upload finishes, not when the archive is proven restorable. Those are different claims. The only way to close the gap is to restore the archive yourself, on a schedule, somewhere harmless.
Table of Contents
- What is actually inside a Google Drive backup export
- Verify the download before you trust it
- Build a disposable restore target
- What to check once the site loads
- Turning one test into a routine
- Frequently Asked Questions
What is actually inside a Google Drive backup export
A WordPress backup is two things: the files and the database. The files are `wp-content` (themes, plugins, uploads) and usually the WordPress core and root config. The database is a `.sql` dump holding posts, pages, users, options, and plugin settings. A restore that has one but not the other gives you either a site with no content or content with no site. Plugins that push to Google Drive package these differently.
Some write a single `.zip` or `.tar.gz`; others split the job into separate archives per component — `db`, `plugins`, `themes`, `uploads`, `others` — sometimes chunked into multiple parts so each upload stays under a size limit. Before testing, open the Drive folder and confirm you have a complete set, not four of five parts. Note what is normally *not* in the archive: your web server configuration, PHP version and extensions, cron entries outside WordPress, mail configuration, and TLS certificates. A restore can succeed completely and the site can still behave differently on a host with a different PHP version. Record the PHP and MySQL/MariaDB versions the live site runs on, because your test environment should match them.
Verify the download before you trust it
A truncated download and a corrupt backup look identical until you try to extract them. Check the file size shown in Google Drive against the size on disk after downloading — they should match exactly. Google Drive's web interface can also silently refuse to virus-scan and repackage large files; downloading through `rclone` or the desktop client avoids the browser's handling.
Then test the archive's integrity without extracting it: That last check catches a specific and common failure: a plugin that hit an error mid-export and wrote a PHP warning or an HTML error page into the file instead of SQL. The file exists, it has a plausible size, and it is worthless. If your backups are encrypted or password-protected, test the passphrase now. A passphrase stored only in the head of someone who has left the company is the same as no backup.
- `unzip -t backup.zip` — reports CRC errors per file
- `gzip -t backup.tar.gz` or `tar -tzf backup.tar.gz > /dev/null` — fails loudly on a bad stream
- `shasum -a 256 backup.zip` — compare against the checksum your plugin recorded, if it records one
- `head -c 200 database.sql` — the dump should begin with SQL comments and `CREATE TABLE` or `DROP TABLE` statements, not HTML
Build a disposable restore target
Never test a restore over the live site, and never point a test restore at the live database. Use a local environment — Local, DDEV, Lando, `wp-env`, or a plain Docker Compose file with PHP, MySQL and nginx. Any of these gives you a throwaway MySQL server and a web root you can delete afterwards. A practical sequence for a single-archive backup: The `–dry-run` step matters because WordPress stores serialized PHP arrays in the options table, where string lengths are encoded alongside the strings.
A raw `sed` or SQL `REPLACE` across the dump breaks those arrays and produces settings that silently revert to defaults. WP-CLI's `search-replace` unserializes, replaces, and reserializes correctly. If your plugin ships its own restore routine, use that instead of manual extraction — but still run it into a disposable environment. The point is to exercise the tool you would reach for in a real emergency.
- Create an empty database and a user with full rights on it: `CREATE DATABASE restore_test;`
- Extract the archive into a clean directory, then confirm `wp-config.php` and `wp-content/` are where you expect
- Import the dump: `mysql -u root -p restore_test < database.sql`, or `wp db import database.sql` if WP-CLI is available
- Edit `wp-config.php` so `DB_NAME`, `DB_USER`, `DB_PASSWORD` and `DB_HOST` point at the test database, not production
- Fix the URLs for the test domain rather than editing the database by hand — `wp search-replace 'https://example.com' 'http://example.test' –all-tables –dry-run` first, then run it for real
What to check once the site loads
Loading the homepage is the beginning of the test, not the end. A restored site can render its front page from cache or a theme default while the underlying data is incomplete.
Work through a short checklist and write down the result each time: Missing uploads are the single most common finding. Many plugins exclude the uploads directory by default once it passes a size threshold, or fail partway through uploading it to Drive, and nothing in the success notification says so.
- Post and page counts match production (compare `wp post list –post_type=post –format=count` on both, or the counts in the admin list tables)
- A recent post loads at its permalink, with its featured image and any embedded media
- `/wp-admin/` loads and you can log in with a known account
- Plugins activate without fatal errors — check `wp plugin list` and the PHP error log
- Media files exist on disk, not just as database rows: open two or three uploads directly, including one from the newest month
Turning one test into a routine
A restore test that happens once proves the backup worked on one day. Schedule it — quarterly is a reasonable floor for a small business site, monthly if the site takes orders or bookings. Tie the schedule to change, too: test after a major WordPress version upgrade, after changing hosts, and after changing the backup plugin or its settings. Keep a written restore runbook alongside the site's other documentation, with the exact commands, the location of the Drive folder, who has access to that Google account, and where the encryption passphrase is stored. Record two numbers from each test: how long the restore took end to end, and how old the data was.
Those are your recovery time and recovery point in practice, rather than in theory. Watch the access side as carefully as the archives. If backups land in one person's personal Drive, that account's departure, password reset, or storage quota becomes a single point of failure — a shared drive owned by the organisation avoids it. Google Drive storage is also shared across Gmail and Photos on a consumer account, so a full quota can stop backup uploads without anyone noticing until the next restore test. Delete the test environment and drop the test database when you are done. A stale copy of production sitting on a laptop with real user data in it is a liability that outlives the test.
Frequently Asked Questions
Can I test a restore on a staging site instead of a local environment?
Yes, as long as the staging site is genuinely separate — its own database and its own files. Staging setups that share an uploads directory or a database prefix with production are not safe restore targets.
My archive is split into several parts. How do I recombine them?
Follow the plugin's own restore path, which knows the part naming. For generic multipart archives, `cat backup.tar.gz.* > backup.tar.gz` before extracting, and confirm every sequential part is present first.
Should the test site be visible to search engines?
No. Set the test to discourage indexing, keep it behind HTTP authentication or bound to localhost, and use a non-public hostname. A crawlable duplicate of the live site creates problems that outlast the test.
You Might Also Like
- WordPress Maintenance: SMTP Uses a Locked Google Account: How to Diagnose Missing Transactional Emails
- WordPress Maintenance: Google Login Stops Working During an Account Lockout: How to Check Existing Local Admin Access
- WordPress Maintenance: Backups Stored in Google Drive: What to Check When the Connected Account Becomes Unavailable
