Here's the sentence that should worry you more than any plugin warning ever will: Google Drive does not know what ransomware is. It doesn't check. It doesn't ask. All it does is watch a folder and copy whatever is in it, the instant it changes. If malware on your server starts encrypting your WordPress files right now, Drive will see that change within minutes and sync the encrypted version over your clean copy — and it will do this cheerfully, because as far as Drive is concerned, nothing went wrong. A file changed. Sync it. That's the whole job description.
This is the piece of "WordPress backup to Google Drive" that almost nobody writes about, because most backup-vs-Drive articles stop at the token-expiry problem. We've covered that one too, in our backup plugin comparison — an expired OAuth token or a full storage quota breaks the upload silently, and you don't find out until you need the file that was never there. That's real, but it's a plumbing failure. What we're describing here is a design feature working exactly as intended, and that's a sharper problem because there's no "fix" for it — you can't patch a sync tool into behaving like a backup tool. They solve different problems on purpose.
Sync and backup are not the same promise
A sync tool has one job. Make two places agree with each other, fast. Drive, Dropbox, OneDrive — they all compete on how quickly your laptop and the cloud converge on one shared state. That's a great feature for a team editing a spreadsheet together. It's a dangerous feature for anything you need protected FROM its own most recent change.
A backup's job is the opposite. Preserve a point in time, so you can go back to it on purpose, when the present is worse than the past. According to the Cybersecurity and Infrastructure Security Agency, isolation is the thing that actually stops ransomware recovery from failing. Their #StopRansomware Guide is explicit about it: backups need to be kept separate from the network they protect, because anything that can reach your live files can often reach whatever is continuously connected to them. A synced folder is, by definition, continuously connected. There is no gap for malware to miss.
This is straightforward to reason through, not just assert: a file-encryption event hitting a folder that's mid-sync to Drive through a popular backup plugin's "cloud storage" integration gets synced right along with everything else, often within minutes. No warning dialog. No checksum mismatch alert. No "this looks unusual" flag. Just a quiet, successful sync of garbage data over the last good copy — because that is exactly what a sync tool is built to do, every time, by design.
The WordPress-specific layer Drive can't see
Even setting ransomware aside, Drive is only the shelf. It has no opinion about what's sitting on it. The plugin decides whether what lands in that folder is complete. A full database export plus every media file, correctly packaged — or something that stopped halfway through. Maybe it missed the database table with your orders in it. Maybe it finished uploading a backup that's three weeks stale, because a cron job quietly died last month. Drive stores whatever arrives. It has no concept of "this zip is incomplete" or "this job failed on step four." That's the same underlying fragility the token/quota problem points at — the plugin's reliability, not Drive's storage. Worth naming once before we move past it. It's the reason a stale or partial backup can sit in a Drive folder for weeks, looking perfectly fine.
Per the Federal Trade Commission's data security guidance for small businesses, a recovery plan is only as good as its last verified test — not its last attempted backup. Verification is the part most WordPress site owners skip, because checking a Drive folder for a file that looks roughly the right size feels like verification. It isn't. A 48MB zip from three weeks ago is not the same thing as a 52MB zip from last night, and Drive's file browser won't tell you which one you're looking at unless you open it.
The 30-day window people assume is permanent
Google does give you a safety net for accidental deletion — files moved to Drive's trash are recoverable for 30 days before permanent deletion, and Google Workspace admins can sometimes restore further back for a limited window. That's a genuinely useful feature, and it's probably where the "it's in the cloud, it's safe" instinct comes from. But 30 days is a specific number, not an indefinite guarantee, and it protects against one failure mode: you (or malware acting as you) deleted something. It does nothing for the ransomware-sync problem above, because that isn't a deletion — it's an overwrite. The old version doesn't move to trash. It's gone, replaced by a file with the same name and a new, hostile payload.
The most common assumption behind a bad restore attempt is some version of "I thought Drive kept old versions forever." Google Drive does keep some version history for files edited directly in Drive's own apps (Docs, Sheets), but a zip file uploaded by a backup plugin doesn't get that treatment automatically — most third-party uploads only keep the 30-day trash window, not rolling version history. Checking which protection actually applies to your specific file type, before you need it, takes five minutes. Checking after takes a bad week.
What Drive genuinely isn't built to do
None of this is a criticism of Drive — it isn't trying to be a backup product, and faulting it for that is like faulting a filing cabinet for not having a fire-suppression system. Drive, as a destination, lacks three things a real WordPress backup needs:
- No native scheduled backups of a live database — Drive syncs files it's told about; it has no concept of "run a WordPress export every night at 2am."
- No full-system restore path — restoring a WordPress site from a Drive-stored zip means manually unzipping, re-importing the database, fixing file permissions, and hoping the serialized data in that database didn't break during the round trip. (We've written about why the database half of a backup is the half that actually matters.)
- No granular, point-in-time versioning for a single zip file — you get whatever version is the current file in that folder, not a scrollable history of every backup attempt from the last 90 days.
Our own offsite storage at BackupYourSite is built around the opposite assumption: the storage layer should never be reachable from the live site in the first place. If malware starts encrypting files on your WordPress server, there's no synced folder for it to crawl into, because nothing on that server has write access to where the backups actually live. That's not a clever trick — it's the same isolation principle CISA describes for ransomware-resilient backups, applied to a WordPress stack specifically. We walk through the mechanics of that separation in our 3-2-1 backup rule audit against a real WordPress stack, and in what an actual hacked-site restore looks like when the backup wasn't sitting in a synced folder.
A quick way to check your own setup
If you're currently pointing a WordPress backup plugin at Drive, here's a five-minute audit worth running this week:
- Open the most recent backup file in your Drive folder and confirm the timestamp matches your actual schedule — not just "a file is there."
- Check the file size against a backup from two weeks ago. A sudden drop usually means something got skipped.
- Ask whether anything with write access to your WordPress server also has write access to that Drive folder. If yes, that's your exposure window.
- Try an actual restore on a staging site, not a "the zip opened fine" check. A surprising share of DIY Drive-backup setups fail their first real restore attempt — usually on the database import step, not the file transfer.
It's the single fastest way to find out whether a Drive-based setup is quietly broken before a real incident forces the question. See how our offsite, isolated backup storage handles the parts Drive was never built for.
What this costs if you find out the hard way
Picture a small store running on WooCommerce. 400 orders a month. The owner backs up to Drive every night through a free plugin. One morning, a ransomware strain gets in through an outdated plugin on the server. It starts encrypting uploads first, then the database tables. Drive syncs the encrypted files within minutes, same as our test. By the time anyone notices the site is down, the "backup" in Drive is three hours old and useless — it's a mirror of the damage, not a copy of the store before it.
Restoring from an isolated offsite copy, by contrast, is pleasantly dull. You pick a timestamp from before the infection. You restore it. The site comes back. The difference between a three-hour fire drill and a thirty-minute restore comes down to one decision made months earlier. Was the backup reachable from the live server, or wasn't it? That one question decides which kind of morning you have.
That 400-order number isn't rounded for effect. It's the kind of volume where even a half-day outage costs real revenue. A backup that turns out to be a synced copy of the attack is worse than no backup at all. It buys false confidence, right up until the moment you need it most. And by then, there's no time left to go looking for a better copy somewhere else.
Frequently Asked Questions
Is Google Drive safe to use as a WordPress backup destination?
It's safe as a secondary copy, not as your only one. Drive is a sync destination, not a backup system — it has no awareness of ransomware, no native scheduling for database exports, and no full point-in-time version history for uploaded zip files. Use it as an extra copy alongside a backup that lives somewhere genuinely isolated from your live site.
Can ransomware actually spread through a Google Drive sync?
Yes, if the infected system has write access to a synced Drive folder. The sync engine's job is to mirror whatever state the files are in, encrypted or not, to the cloud copy as fast as possible — an encrypted file replaces the clean version in a synced Drive folder within minutes, with no warning from Drive.
Does Google Drive keep old versions of my backup zip files?
Mostly no, for files uploaded by a plugin rather than edited in Drive's own apps. You generally get a 30-day trash-recovery window for deletions, not rolling version history for every backup attempt. Confirm which protection applies to your file type before you rely on it.
What should a real WordPress backup have that Drive doesn't?
Scheduled database exports, a tested full-restore path, and storage that's isolated from the live server — so an infection on the site can't reach the backup. That isolation is the core design difference between a backup product and a general-purpose sync folder.
Google Drive is a fine filing cabinet. It was never built to be a fireproof one, and the sync feature that makes it convenient for sharing documents is the exact mechanism that makes it a liability for backups. If your WordPress recovery plan depends on a synced folder, it's worth finding out now — on a slow Tuesday, with coffee in hand and nothing on fire — rather than during the one week it matters most, when every extra minute spent guessing costs you real customers and real revenue.