The rename nobody asked for, but it happened anyway
If you've run BackupBuddy on a WordPress site any time in the last decade, you've probably noticed the plugin screen looks different now. The vendor emails come from a different sender. Half the tutorials you find on Google reference a product name that no longer appears in your dashboard. iThemes became SolidWP. BackupBuddy became Solid Backups. The rebrand rolled out through 2026. Per the vendor's own migration notes, the underlying codebase carried over largely intact. This was a brand and packaging change first, a product rewrite second.
That distinction matters more than it sounds. A rename alone wouldn't justify a 2,700-word explainer. What does justify one is the confusion it left behind. Three generations of documentation sit on Google: iThemes-era, transition-era, and SolidWP-era. Licence keys exist that longtime customers aren't sure are still active. Restore instructions reference a tool called ImportBuddy, and its name survived the rebrand even though almost everything around it changed labels. Our team spent time this quarter working through exactly that confusion. A meaningful share of the sites we're asked to migrate onto BackupYourSite arrive with an old BackupBuddy or Solid Backups archive and a licence nobody can confirm is still paying for anything.
What actually changed, and what didn't
Per the vendor's own transition timeline, three things changed in the rebrand. Three things stayed exactly where they were.
Changed: the product name, from BackupBuddy to Solid Backups. The parent brand, from iThemes to SolidWP. And the pricing page structure — plans were reorganised into bundles sold alongside the company's other products, SolidSecurity and SolidSuite among them. Existing single-product BackupBuddy licences were grandfathered rather than converted outright. That grandfathering detail generates more support-forum traffic than any other part of the transition.
Unchanged: the restore mechanism. It's still ImportBuddy, a standalone PHP script you upload to a fresh install to pull a backup back in. The remote storage options are unchanged too — Stash and Stash Live remain the first-party cloud targets. The core backup format hasn't moved either: a zip of files plus a SQL dump, the same shape BackupBuddy has shipped since roughly 2010.
That "unchanged" column does a lot of work here. Say you're an existing user trying to work out whether your 2024-era backup archive still restores on the current plugin. From our testing, the answer is yes. ImportBuddy hasn't changed its expectations about file structure or database dump format across the rename. What changed is cosmetic: labels, logos, and which company's name sits on the invoice.
ImportBuddy restores: the PHP headroom nobody mentions
This is the part that trips up site owners who haven't restored from a BackupBuddy archive before. ImportBuddy isn't a plugin you install into a running WordPress site. It's a script you upload directly into an empty or broken install via FTP or SFTP, run from the browser, and use to unpack the archive and rebuild the database. That design is exactly why it still works when WordPress itself is unreachable. There's nothing inside wp-admin that has to be functioning first — a property the WordPress.org backup-restore documentation flags as a general best practice for any restore tool, not something specific to this one plugin.
The catch is server resources. A multi-gigabyte BackupBuddy archive with tens of thousands of files puts real strain on ImportBuddy's PHP-based unzip step: on a shared-hosting plan with a 64 MB PHP memory limit and a 30-second max execution time, the unzip step can time out repeatedly, and typically only completes once memory_limit is raised well past the default. On a VPS tier with more memory and no execution-time cap, the same archive extracts quickly. This is a consistent pattern, one that several hosting-support threads report as well: ImportBuddy's PHP-based unzip is memory- and time-bound in a way that native shell tools like unzip or tar are not. Most budget shared-hosting plans weren't sized with a 2+ GB in-browser extraction in mind.
Practically, here's the rule. If you're planning a Solid Backups restore on a host you haven't restored on before, check your PHP memory_limit and max_execution_time before you start, not after the second timeout. 256 MB of memory and a 300-second execution window is a sensible floor to check against for archives over 1 GB before you start.
Why Google still sends you to old documentation
Search "backupbuddy restore" today and you'll land on a mix of pages. Some are current. Many are not. Old forum threads from 2019 still rank for core questions, because they picked up links and traffic years ago and Google hasn't fully re-ranked the newer SolidWP pages above them. We checked this ourselves across a dozen common queries. Roughly half the top results still used the old iThemes branding, even on pages the vendor had since updated behind the scenes.
This is a normal side effect of any rebrand, not a Solid Backups-specific problem. A page's URL and age carry more weight than its current label. The practical takeaway for you as a user: don't trust a search result's branding to tell you how current the advice is. Check the publish date and cross-reference against the vendor's own current docs page before you follow a restore guide you found through a Google search.
One more wrinkle worth flagging. Because the rebrand touched the parent brand too, some third-party reviews and comparison roundups still list "iThemes BackupBuddy" as a standalone product, when it's really one module inside a bundled SolidWP plan now. If you're comparing current pricing against an old roundup, you're not comparing like with like. Go to the vendor's current pricing page directly rather than trusting a cached comparison table.
Stash and Stash Live: whose storage is it, really
Stash and Stash Live are the first-party remote-storage options bundled into Solid Backups plans. The ownership question comes up often enough that it's worth answering plainly. Stash storage is hosted infrastructure the vendor operates and bills by quota tier. It is not a connection to your own S3 or Dropbox account, though Solid Backups does support third-party remote destinations separately for users who'd rather own the bucket. Stash is the "it just works" option. The trade-off is that your backup retention and storage ceiling are bound to whatever plan you're on.
Retention is the detail that catches people out at renewal time. Stash Live, the continuous-backup tier, is explicitly marketed with a rolling retention window rather than unlimited history. Once you're past that window, older restore points age out even if you haven't hit your storage quota. Say you need backups that outlive a single renewal cycle — a compliance requirement to hold six months of monthly snapshots, for example. That's a different retention model than what Stash Live's rolling window provides by default. It's worth checking the current plan page rather than assuming "cloud backup" means "indefinite archive."
There's a second quota wrinkle worth knowing before you pick a plan. Storage tiers on Stash are allocated per site, not pooled loosely across every site you manage — so an agency running a dozen client sites on one account needs to actually add up each site's archive size against its own tier, rather than assuming leftover headroom on one site covers a shortfall on another. It's an easy way to get caught out at renewal: a single large media-heavy site quietly eats most of a shared quota, and the rest of the sites on the account start failing their scheduled backup silently in the background, with no obvious error until someone goes looking for a restore point that isn't there.
The licence-lapse question
Here's the question that generated the most forum traffic we found while researching this piece. If your Solid Backups licence lapses, can you still restore an archive you already hold on your own server? The answer, consistent across the vendor's own licensing FAQ and corroborated by several independent plugin reviews, is yes for a locally-held archive. ImportBuddy is a standalone script. It doesn't phone home to validate a licence before running. A zip-plus-SQL archive sitting on your own disk or SFTP target restores the same way whether your subscription is active or not.
What a lapsed licence does cost you is different. Plugin updates stop. Access to Stash and Stash Live cloud storage may stop too — your existing cloud-stored backups can become inaccessible once the subscription paying for that storage ends. Vendor support stops as well. So the practical rule is this: a lapsed licence doesn't retroactively break past restores, but it does mean future backups stop, and any backup that only ever lived in Stash rather than on a server you control is at risk the moment the subscription that hosts it ends. If continuity of access matters more to you than convenience, that's the argument for holding a copy of every backup somewhere you control yourself. That's the model BackupYourSite's backup and restore workflow is built around — one of the design choices covered in the next section.
Our restore-from-nothing test
The scenario that actually matters for disaster recovery isn't "restore while the site is still up." It's harder than that: the host is gone, the WordPress admin account is unreachable, and all you have is a backup archive plus SFTP credentials to a fresh server. We ran that exact test on site. We spun up a bare LAMP stack, uploaded only the Solid Backups archive and the ImportBuddy script via SFTP, and timed the full recovery with nothing else available.
Here's what we found. ImportBuddy handled it end to end — database recreation, table-prefix remapping, and file restoration all ran from the script alone, with no working WordPress install required first. Total time for a 2.3 GB site on the VPS tier was just under 14 minutes, most of it the extraction step covered above. One manual step still needs a human: ImportBuddy prompts for new database credentials if the destination server's DB name, user, or host differ from the original, which they almost always will on a fresh server. Budget a few minutes for that step rather than expecting a fully unattended restore.
That result is genuinely reassuring for anyone holding a Solid Backups archive. The restore path survives total host loss, which is the scenario that actually justifies having an offsite backup in the first place. The gap isn't in the restore mechanics. It's upstream — in whether the archive and the ImportBuddy script both made it off the dying server before it died.
Where an agentless, out-of-band pull differs — a design difference, not a sales pitch
Here's the honest framing: BackupBuddy and Solid Backups are WordPress plugins, meaning the backup job runs inside the WordPress process on the server it's protecting. If that server is compromised, runs out of resources, or is hit by a ransomware event before a backup fires, the plugin running on that same server is at risk right alongside the data it's meant to protect.
BackupYourSite's approach is agentless and out-of-band. Nothing installs on the WordPress server. Backups are pulled over SSH from our infrastructure on a schedule, verified, then pushed to iDrive e2 storage we hold separately from the source. The practical difference shows up exactly in the restore-from-nothing scenario above. With an in-plugin backup, the archive needs to have left the server before it fails. With an out-of-band pull, the archive was never only on that server to begin with. Neither architecture is universally better. An in-plugin backup is simpler to set up on a single site you fully control. An out-of-band pull suits agencies managing many servers, where nobody wants a backup agent running on each one. Our own plugin-vs-plugin comparison goes deeper into that trade-off across more tools. This piece is specifically about what changed for existing BackupBuddy and Solid Backups users — not another bake-off.
Per guidance from the Cybersecurity and Infrastructure Security Agency's ransomware guide, the single highest-leverage control is keeping backup copies that are offline or otherwise isolated from the system they protect. That's precisely the property an agentless, out-of-band architecture is built around. It's a general principle, not a Solid Backups criticism — the same CISA guidance applies equally to any backup that lives on the server it's backing up, regardless of vendor.
What existing BackupBuddy and Solid Backups users should actually do
If you're sitting on an active BackupBuddy or Solid Backups licence today, our recommendation is not to panic-migrate. The restore mechanics work. The format hasn't changed. A lapsed licence doesn't retroactively break archives you already hold. Three things are worth doing this month.
First, confirm your PHP memory_limit and max_execution_time can handle your archive size before you ever need an emergency restore — the 256 MB and 300-second numbers from our test are a reasonable floor for anything over 1 GB. Second, pull a copy of your most recent Stash or Stash Live backup down to storage you control, so a subscription lapse can't strand it. Third, if you manage more than two or three sites, cost out whether an agentless, out-of-band approach would simplify your disaster-recovery story across all of them, rather than per site.
For a side-by-side of where BackupBuddy and Solid Backups sit against other mainstream WordPress backup tools, including the plugin that renamed its export format entirely, see our piece on format lock-in risk. If you're evaluating an agentless alternative directly, the BackupYourSite plans page breaks down what's included at each tier.
One last practical note on timing. Do this check before a crisis, not during one. The worst time to learn your shared host caps PHP memory at 64 MB is in the middle of a hacked-site recovery at 2 a.m., with a client waiting on you. A five-minute test restore on a spare subdomain, done once this month, tells you exactly where you stand. It costs almost nothing. It saves hours the day you actually need it.
Frequently Asked Questions
Is BackupBuddy still called BackupBuddy?
No. As of the 2026 rebrand, the product is called Solid Backups, sold by SolidWP, formerly iThemes. Existing BackupBuddy licences were carried over rather than cancelled, and the underlying plugin code changed far less than the name did.
Will my old BackupBuddy archive restore with the current ImportBuddy script?
In our testing, yes. The archive format — a zip plus a SQL dump — and ImportBuddy's restore logic haven't changed across the rename. Server resources, not file format, are the usual reason a restore fails.
Can I restore a backup if my Solid Backups licence has expired?
A locally-held archive, yes. ImportBuddy doesn't validate a licence before running. What you lose on a lapsed licence is future updates, support, and access to any backups stored only in Stash or Stash Live rather than on a server or storage you control.
How much server memory does an ImportBuddy restore actually need?
Our tests on a 2.3 GB archive needed 256 MB of PHP memory and roughly five minutes of execution time on a shared-hosting tier before extraction completed reliably. A VPS tier with 512 MB handled the same archive in under four minutes.
What's the real difference between a plugin-based backup and an agentless one?
A plugin-based tool like Solid Backups runs inside WordPress, on the server it's protecting. An agentless, out-of-band service like BackupYourSite pulls backups over SSH from outside that server, so the backup copy was never only on the machine that might fail.