The Backup Add-Ons Compared: Backup Storage, WordPress Backup/Restore, Database Backup/Restore and the Corruption Diagnostic

The marketplace has four packages whose names contain backup or something close to it, and a manager new to the platform can reasonably ask which one they need. The answer is usually more than one, because they are not alternatives: one is a place, two are jobs, and one is a check. This post follows a hosting manager fitting them together for a fleet of WordPress sites on MassiveGRID PaaS, which is built on Virtuozzo Application Platform, formerly Jelastic.

The manager runs 40 client WordPress sites for an agency we will call Wren & Co, each on its own environment, plus a handful of non-WordPress databases. The packages are Backup Storage, WordPress Backup/Restore, Database Backup/Restore and the Database Corruption Diagnostic.

One place, two jobs, one check

Start with the place

Nothing else works without a destination, so the manager installs Backup Storage first: one node per region where the agency has sites, in standalone mode, because the platform's own storage redundancy is sufficient for a backup repository and the cluster mode's GlusterFS replication is for cases where the storage itself must survive a node. Each node gets a disk sized for the agency's retention (30 days of nightly archives for 40 sites of a few gigabytes each, comfortably under a terabyte) and a disk load alert at 80%. The node is reachable from every environment in the region over the internal network via NFS, which is how the add-ons write to it, and over SFTP, which is how the manager's weekly rclone job copies the archives to the agency's off-platform object storage. Two copies in two places is the agency's policy, and the second copy is what the SFTP access is for.

WordPress sites get the WordPress job

For a WordPress site, a database dump alone is half a backup: the theme, plugins, uploads and configuration are files. The WordPress Backup/Restore add-on archives the application root directory and the database together, compressed and timestamped, on a cron schedule in the timezone you set, and copies the archive to the selected Backup Storage node. Restore is one click from the dashboard, choosing files, database or both. The manager installs it on all 40 sites with a nightly schedule and a two-week retention, and tests restore on the first three by restoring into a cloned environment, which is also how the agency now builds staging copies of client sites: restore last night's backup into a clone.

The agency's restore log for the first quarter: two sites restored after a plugin update broke the front end, one after a client deleted a page and its media, and one after a compromised admin account defaced a homepage. Each restore took minutes and none required a support ticket to anyone.

Everything else gets the database job

The agency also runs a few non-WordPress systems: a Laravel client portal on MariaDB, an internal Redmine on PostgreSQL, a Redis for the portal's sessions. These get the generic Database Backup/Restore add-on, which dumps with the engine's native tool using consistency options so writes are not locked, prefers a replica in clusters, and restores to the original or another environment from the dashboard. The manager also installs it on two WordPress sites whose owners asked for hourly database backups on top of the nightly full archive, because an e-commerce order table has a tighter recovery point than a theme. The two add-ons coexist on one environment without conflict; they write to different folders on the same storage node.

The check, which is not a backup

The Database Corruption Diagnostic does not back anything up. It reads every table, runs CHECK TABLE and InnoDB consistency checks, compares checksums between nodes in a cluster, inspects replication metadata and cluster state files, and produces a report. The manager uses it in two ways. Before a migration or major upgrade of a client site, to know the database is clean before touching it. And on a monthly schedule against the client portal's MariaDB replica, because the scariest data loss is silent corruption that is faithfully backed up for thirty days until someone notices. Because table checks read every row, the diagnostic runs on a replica or in a low-traffic window, never on a busy primary at noon. When it does find something, the remedy is the engine's repair tools or a restore from the backup add-ons, which is why the check and the jobs belong together.

What it costs, and what it saved

Two Backup Storage nodes at about 600 GB each are the main line, billed on disk plus a few cloudlets while transfers run; the add-ons themselves are free and the jobs consume cloudlets for a few minutes a night on each site. At MassiveGRID's published $0.003372 per cloudlet-hour the compute side is a low two-figure monthly sum before discounts; the disk is what the agency pays for, and it is the price of 40 restorable sites. The four restores in the first quarter each replaced what would have been an hour or more of a developer rebuilding a site from whatever the client had, which is the number the manager put in the review.

Frequently Asked Questions

Can the Backup Storage node be in a different region from the sites?

Yes, and that gives geographic separation for disaster recovery; transfers then cross regions and count as external traffic. Wren keeps a node per region for the nightly jobs and uses the SFTP copy off-platform as the geographically separate copy.

Do the add-ons back up environment configuration, such as topology and variables?

No; they back up application files and databases. The platform's environment export captures the topology and settings, and a clone is a complete copy. For disaster recovery, keep an export of each environment alongside the data backups.

How do I restore a WordPress backup to a new environment?

Install the WordPress package (or clone the original), attach the WordPress Backup/Restore add-on pointed at the same Backup Storage node, choose the archive and restore both files and database. Update the site URL if the domain differs. This is also the staging-from-backup pattern.