When a WordPress site's Google Drive backup connection stops working, the first thing to check is whether the backup files still exist in Drive — not whether the plugin still shows a green "connected" status. The account behind that connection owns the files, so if it was suspended, deleted, or had its access revoked, the archives can disappear even though the plugin keeps reporting success from its cached settings.
Most WordPress backup plugins that offer Google Drive storage — UpdraftPlus, BackWPup, Duplicator and similar tools — connect through OAuth, an authorisation system where Google issues the plugin a token to act on one account's behalf. That token is tied to a single Google identity. Understanding which identity, and what happened to it, determines whether this is a five-minute reconnection or a recovery problem.
Table of Contents
- Work out whether it's the token, the account, or the storage quota
- Who actually owns the backup files
- Confirming you still have something you could restore from
- Reconnecting the plugin cleanly
- Removing the single point of failure
- If the archives are gone
- Frequently Asked Questions
Work out whether it's the token, the account, or the storage quota
Three different failures look identical from the WordPress dashboard: an expired or revoked token, a disabled account, and a full Drive. Each needs a different fix, so separate them before touching anything. Start with the plugin's own log rather than its settings page. Backup plugins record the upload step separately from the archive-creation step, and a run that says "backup complete" may mean the zip file was created locally and never left the server.
Look for the specific error text next to the remote-storage step — Google's API returns distinguishable messages for invalid credentials, insufficient permission, and quota exceeded. Then check the account directly by signing into it. If you can sign in and see the backup folder, the problem is almost certainly the token, and reconnecting will fix it. If sign-in fails or the account is suspended, you have an ownership problem instead. If sign-in works but Drive reports no space, remember that Google storage is pooled across Drive, Gmail and Photos — a mailbox that filled up will stop backup uploads without any change to the backup setup at all.
Who actually owns the backup files
Files a plugin uploads through OAuth are owned by the connected Google account, not by your site or your agency. This is the detail that turns a routine account change into data loss, and it is worth checking before there is a problem. In a Google Workspace organisation, a departing employee's account is often suspended and later deleted. Files stored in that person's My Drive go with the account unless an administrator transfers ownership first. Workspace admins have a transfer tool in the Admin console for exactly this, but the window to use it after deletion is limited, so the practical rule is to check for backup folders before deleting any account that was ever used for site maintenance.
Shared drives behave differently. A shared drive's files are owned by the organisation rather than an individual, so they survive the removal of any single member. If your backups sit in a personal My Drive folder belonging to a contractor or a former staff member, that is a structural risk regardless of whether anything has broken yet. Consumer Gmail accounts have their own version of this: Google's Inactive Account Manager and its inactivity policies can affect accounts that go unused for long periods. A backup destination nobody signs into is, by definition, an account nobody uses.
Confirming you still have something you could restore from
A backup you have not restored is a hypothesis. Before deciding how urgent the situation is, establish what you can actually recover, in this order: If backups are missing and the account is recoverable, check Drive's trash before anything else. Deleted files sit there for a period before permanent removal, and a plugin's retention setting that "deletes old backups" deletes them to trash first.
- Check the WordPress server itself for local copies. Many plugins keep a configurable number of archives in `wp-content` and prune them after a successful upload; if uploads have been failing, local copies may have accumulated instead.
- Check whether the archive set is complete. A full restore needs the database dump and the files — plugins, themes, and uploads. A folder containing only database archives will not rebuild a site.
- Check the date of the newest complete set, not the newest file. Silent upload failures often mean your real recovery point is older than the folder's modified timestamp suggests.
- Check your host's own backups, which are independent of the Google connection. Many managed WordPress hosts keep daily snapshots with their own retention window.
- Download one archive and open it. A truncated upload produces a zip that lists in Drive but will not extract.
Reconnecting the plugin cleanly
Reconnecting means running the plugin's Google Drive authorisation flow again and granting access from an account that can reach the backup folder. The plugin then stores a fresh token. Two things commonly go wrong at this step. The first is authorising the wrong account. If you are signed into several Google accounts in the same browser, the consent screen will offer a chooser, and picking the wrong one produces a working connection pointed at an empty folder. Use a private window and sign in deliberately.
The second affects anyone using their own Google Cloud project credentials rather than the plugin vendor's built-in app — an option some plugins offer for sites that want their own API client. A Google Cloud OAuth client left in "Testing" publishing status issues refresh tokens with a short life, so the connection breaks again within days no matter how carefully you reconnect. If you configured a client ID and secret yourself, check that project's OAuth consent screen status and its list of test users. After reconnecting, do not wait for the next scheduled run. Trigger a manual backup and confirm the file appears in the Drive folder at the expected size. The upload step is the one that was failing, so it is the one to verify.
Removing the single point of failure
The underlying design problem is that one personal account stood between the site and every copy of its data. A few changes make the next account change uneventful. Move the destination to a shared drive owned by the organisation, or to a dedicated backup account that no individual uses for email and that is documented alongside the site's other credentials. Where the plugin supports a service account — a non-human Google identity belonging to a project rather than a person — that removes the dependency on any human's login entirely. Keep at least one copy outside Google.
The widely used 3-2-1 approach is three copies, on two kinds of media, with one off-site; a Drive folder plus your host's snapshots plus a periodic download to local storage satisfies the spirit of it. The point is that no single provider outage or account action takes out everything. Finally, make failure noisy. Turn on the plugin's email report for failed runs, send it to a shared inbox rather than one person, and add a calendar reminder to open the Drive folder and check the newest file date. Backup systems fail quietly and are usually discovered at the worst possible moment, so a monthly two-minute check is worth more than any amount of configuration.
If the archives are gone
When the account is unrecoverable and the files went with it, rebuild the recovery position from whatever remains rather than trying to reconstruct the old one. Take a fresh backup immediately to a destination you control, before doing any other maintenance on the site. A site with no backup should not receive plugin updates, theme changes, or a PHP version bump, because those are precisely the operations that need a rollback path.
Then check what independent copies exist: your host's snapshots, any staging environment that was cloned from production, and any local development copy. A staging site from three months ago is a poor backup but a real starting point for recovering content that would otherwise be retyped. For published content specifically, search engine caches and the Internet Archive's Wayback Machine sometimes hold page text that can be pasted back into rebuilt posts. Document the new destination, its owning account, and who has access, in the same place your team keeps hosting credentials — the reason this situation arises is almost always that nobody knew which account the backups were going to.
Frequently Asked Questions
The plugin still shows "connected" but no new files appear in Drive. Why?
Plugins display connection status from stored settings, which do not change when Google revokes a token or the destination folder is deleted. Read the run log for the remote-upload step instead, and confirm by checking the folder itself.
Can a Google Workspace administrator recover backups from a deleted user account?
Admins can transfer a departing user's Drive files to another account, and Workspace provides restore options for recently deleted accounts and files. Both operate within limited windows, so raise it with the admin as soon as you identify the account rather than after further investigation.
Does changing the Google account password break the backup connection?
A password change alone does not necessarily invalidate an OAuth token, but revoking the app under the account's third-party access settings does, and security events can trigger revocation. Treat any credential change on the backup account as a prompt to run a manual test backup.
You Might Also Like
- WordPress Maintenance: Google Login Stops Working During an Account Lockout: How to Check Existing Local Admin Access
- WordPress Maintenance: Google Calendar Embeds During an Account Outage: How to Check Public and Private Access Separately
- WordPress Maintenance: Google Sheets Integrations After Account Restoration: How to Test Permissions Before Resuming Sync
