A question worth asking before you need the answer: if the vendor's own software disappeared tomorrow, could you still get your site out of the backup file sitting in storage?
The question nobody asks until the restore button doesn't work
Most people choose a WordPress backup tool based on how easy it is to set up and how it behaves when everything is working: does the dashboard look clean, does the schedule run, does the restore button do something reassuring when you click it. Almost nobody asks the harder question up front, which is what the backup file itself actually is — what format it's stored in, and whether anything other than the tool that created it can read it.
That question only becomes urgent at the worst possible time: when the plugin that made the backup is broken, abandoned, incompatible with your current PHP version, or simply unavailable because the site it lived on is the thing that's down. At that point, "my backup exists" and "my backup is usable" turn out to be two different claims, and the gap between them is entirely explained by file format.
Two very different ideas of what a "backup" is
Strip away the branding and dashboards, and WordPress backup tools fall into roughly two camps based on what they actually write to disk.
Plain, open formats
Some tools produce output that is, underneath any wrapper, standard and widely understood: a SQL dump of the database — the same kind of file produced by mysqldump, documented in the MySQL reference manual — plus a tarball or zip archive of the wp-content directory and the rest of the WordPress file tree. Anyone with basic command-line familiarity, or frankly a text editor and a decompression tool, can open these files and see exactly what's in them. You don't need the original backup plugin installed, running, or even to still exist as a company. A SQL dump is readable by any MySQL or MariaDB-compatible database; a tar.gz is readable by any archive utility on any operating system built in the last twenty years.
Proprietary containers
Other tools wrap the same underlying data — database tables, files — inside a custom archive format specific to that plugin or service: a proprietary manifest describing what's inside, sometimes with structure or metadata the tool needs in order to know how to put the pieces back together correctly. Some of this is legitimate engineering — a well-designed container format can make incremental backups and partial restores faster and more reliable than working with raw file dumps. The complication isn't that the format exists; it's that the backup becomes functionally unreadable to anything except the specific tool, and often the specific version of that tool, that wrote it.
That second category is where lock-in happens. If the vendor goes out of business, discontinues the product, or you simply want to move away from it, you're not holding a WordPress backup — you're holding a file only their software understands. If the only working copy of the "restore" logic for that container format lives inside the vendor's own app or hosted service, you have, in effect, outsourced your ability to ever read your own data again. If you're trying to weigh several WordPress backup plugins against each other on exactly this point, backupyoursite has put together a side-by-side comparison that looks specifically at output format alongside the more commonly advertised features.
Where this actually bites, in practice
- The restore service goes away. A plugin gets deprecated, a company shuts down, or a hosted backup service sunsets a product line. Existing backup files that depend on that company's active infrastructure to decode can become permanently unreadable, even though the bytes are still sitting on a drive somewhere.
- You're migrating platforms. You want to move from one backup tool to another — maybe you're switching hosts, maybe you've simply found something better — and discover the new tool has no way to ingest the old one's archive format. The "backup history" you thought you were carrying forward turns out to only be readable going backward, by the tool that's about to be retired.
- A version mismatch breaks the reader. Some proprietary formats change across major versions of the plugin that produces them. An archive made by version 3 may not open cleanly in version 6 of the same tool, which means even staying with the same vendor doesn't guarantee your older backups remain usable.
- You need to hand the data to someone else. A developer, an auditor, or a new agency taking over a site asks for "the database" and you hand them a container file their tooling has never heard of, instead of a SQL dump or export they can open immediately.
None of these scenarios require anything to have gone wrong with the backup itself. The data can be perfectly intact and perfectly useless, simultaneously, purely because of the format it's locked into.
Testing portability by hand — a 15-minute exercise
You don't need to take a vendor's word for whether their format is open or proprietary. You can check directly, and it's worth doing with whatever tool you currently use, before you ever need the answer under pressure.
- Download a recent backup file from your current tool, outside of its own dashboard — to your own computer, not just viewed inside the plugin's UI.
- Try opening it without the plugin. If it's a .zip or .tar.gz, any standard archive utility should open it and show you recognizable files — PHP source, images, a .sql file. If it's a custom extension the OS doesn't recognize, or opens into unlabelled binary chunks, that's the lock-in signal.
- Look for a plain SQL file inside. Open it in a text editor. You should see readable
CREATE TABLEandINSERT INTOstatements — the kind of output WP-CLI's own export command or a standard mysqldump produces. If what you find instead is an opaque binary blob with no human-readable structure, the database half of your backup is also locked to the tool. - Ask, explicitly, whether the vendor documents their format. A tool confident in its own portability will usually say so, somewhere in its documentation — "standard WordPress export," "plain SQL dump," "readable with any archive tool." Silence on the question is itself informative.
This is a reasonable thing to check before you commit to a backup product, not only after you've already been using one for years. "Exportable in a standard, documented format" belongs on the same requirements checklist as retention length and restore speed — it just gets overlooked because it only matters on a day most people assume will never come. If you want a longer look at how this specific failure mode plays out with one widely used all-in-one migration plugin, this piece on backup format lock-in walks through a concrete case.
Why this is really a contingency-planning question, not a technical nitpick
It's tempting to file format portability under "nice to have" rather than "actually matters," since in the normal course of events you never open the raw backup file yourself — you click restore, and the tool handles the rest. But the entire point of a backup is to function as a contingency plan for scenarios where the normal path is unavailable: the tool is gone, the vendor's service is down, the account is locked, or you need the data moved somewhere the original tool can't reach. NIST's contingency planning guidance treats the ability to actually recover data independent of any single piece of software as a baseline property of a real recovery plan, not an edge case — which is exactly the property a proprietary, single-vendor backup container fails to guarantee.
This is also where backupyoursite's approach is worth naming directly as a point of contrast: an agentless, SSH-pulled backup built around plain, standard outputs rather than a custom container avoids the lock-in question from the start, because there's no proprietary reader to depend on in the first place. That doesn't make every open-format backup automatically well-run — retention, verification, and storage independence still matter separately — but it removes one specific failure mode that a lot of site owners never think to test for until the one day they need to.
What to actually require, going forward
If you're evaluating a backup tool — your own site's, or on behalf of a client — add format portability as an explicit line item rather than assuming it's covered by "has a restore button." Concretely: ask whether the file is a standard database dump plus a standard archive, or a proprietary container; ask whether the vendor documents the format publicly; and if you can, actually download and open a backup file yourself rather than trusting a sales page's description of it. None of this takes long, and it's the kind of check that costs nothing when everything is working and becomes the single most important question you didn't ask on the day it isn't.
FAQ
What's the difference between a "plain" backup format and a "proprietary" one?
A plain format uses standard, documented structures — typically a SQL dump of the database and a tar/zip archive of the files — that any compatible database or archive tool can read. A proprietary format wraps the same underlying data in a custom container specific to one plugin or service, which usually requires that same tool to decode.
How do I check which kind of format my current backup tool uses?
Download a backup file directly, outside the plugin's dashboard, and try opening it with a standard archive utility and text editor. If you see recognizable file structures and a readable SQL file inside, it's a plain format. If you get an unrecognized file type or opaque binary data, it's likely proprietary.
Is a proprietary backup format always a problem?
Not automatically — some container formats exist for legitimate performance reasons, like faster incremental backups. The problem is specifically when the format can only be decoded by the vendor's own active software, with no documented standard fallback.
What happens to a proprietary-format backup if the vendor shuts down?
In many cases, the archive becomes effectively unreadable, because the logic needed to reconstruct the database and files from the container lived inside the vendor's software or hosted service, not in the file itself.
Does a standard format backup still need to be checked for anything else?
Yes — format portability solves one specific risk. Retention length, storage independence from the hosting account, and whether a restore has actually been tested are separate questions that a plain SQL/tarball format doesn't answer on its own.
Can I convert a proprietary backup into a plain format after the fact?
Sometimes, if the original tool is still available and functioning — you can often use it to perform a restore into a working site and then take a fresh, plain-format export of that site. Once the original tool is gone, converting an already-opaque archive is usually not possible.
Where should I ask about a backup tool's format before committing to it?
Check the vendor's own documentation first — a tool confident in its portability usually states this directly. If it's not documented, ask support the direct question, and treat an unclear or evasive answer as a signal in itself.
Conclusion
A backup is only as useful as your ability to actually read it, and that ability depends entirely on file format — a detail that almost never comes up until the normal restore path is unavailable. Plain, standard formats like a SQL dump plus a file archive stay readable independent of any one vendor's software staying alive; proprietary containers tie your data's usability to that vendor continuing to exist and function exactly as it does today. Testing this by hand, on whatever tool you currently use, takes about fifteen minutes and costs nothing — and it's a far better time to find out than the day the vendor's restore service is the only thing standing between you and your own data.