Backups, Security, and Recovery

Hosting disasters fall into three categories that require different protective measures, and conflating them produces a backup strategy with gaps. Data loss — a database that is corrupted, a file system that fails, a migration that truncates a table — requires recent, verified backups stored off the origin server. Site compromise — malware installed through a vulnerable plugin, a brute-force attack on a weak admin password, a compromised FTP credential — requires both intrusion detection and a pre-compromise backup to restore from. Accidental deletion — a theme update that breaks layout, a content editor who deletes a product category — requires granular backups with point-in-time restore. The three categories overlap but are not identical, and a backup system that handles one well can fail at another.

The frequency and retention of backups determine their usefulness in a recovery scenario. Daily backups are the industry minimum. A daily backup taken at 2am means that a disaster that occurs at 1am the following day results in up to 23 hours of data loss — every order processed, every article published, every form submission received during that window. For a content site that publishes twice a week, this is acceptable. For an e-commerce site processing fifty orders per day, it is not. Hourly backups reduce maximum data loss to 59 minutes; real-time transaction logging (common in database-level solutions) reduces it further. Understanding which backup frequency your host provides — and at what plan tier — is the first question to ask before signing up.

Kinsta provides automatic daily backups with 14-day or 30-day retention (depending on plan tier), stored off-server on Google Cloud Storage. The one-click restore in MyKinsta is reliable and fast — a full restore of a medium-sized WordPress site typically completes in under ten minutes. Kinsta also offers a manual backup trigger, useful before running updates or making structural changes, and the Business plan and above include hourly backups as a configurable option. The malware scanning runs automatically across all sites and Kinsta’s security incident response includes a free malware clean-up as part of the hosting agreement — one of the few hosts where this is explicitly included rather than sold as an add-on. Kinsta’s infrastructure isolates sites in containers, which limits the blast radius of a compromise: a malware infection on one site does not spread across the server to others, a genuine risk on shared infrastructure.

SiteGround includes daily automated backups with 30-day retention on their GrowBig and GoGeek plans. The backup system is competent and the restore workflow in the SiteGround admin panel works well. The security tooling includes anti-bot AI at the server level, free SG Security plugin for WordPress (login protection, activity log, 2FA), and free Cloudflare CDN integration that includes basic DDoS mitigation. SiteGround does not include malware clean-up in the base hosting price — if a site is compromised, remediation is either DIY or available as a paid service. For small sites, SiteGround’s backup and security stack is adequate. The constraint is that shared infrastructure limits the restore granularity and the isolation guarantees.

Cloudways takes a different approach. It does not include application-level backup management by default — backups are configured at the server level, not per-application — and the default is daily automated server snapshots. Cloudways’ SafeUpdates add-on automates plugin updates with pre-update backups and regression testing, which is worth enabling for production WordPress sites. The security model depends partly on the underlying cloud provider’s infrastructure (DigitalOcean, AWS, GCP all have strong network-level security) and partly on your own configuration decisions: PHP version currency, user permissions, two-factor authentication on the Cloudways panel. The honest framing is that Cloudways requires more active security management than Kinsta but gives you more control over what that management looks like.

The measures you should implement regardless of host: daily automated backups stored in at least two locations (your host’s backup and a third-party service like BlogVault or UpdraftPlus pushing to external cloud storage), two-factor authentication on every admin login, a limit on login attempts (five failed attempts should trigger a lockout), HTTP security headers (Content-Security-Policy, X-Frame-Options, Referrer-Policy) configured at the server or CDN level, and a process for reviewing plugin updates before applying them to production. A staging environment — available at Kinsta, WP Engine, SiteGround, and Cloudways — is the most practical tool for catching update-induced breakages before they hit live traffic.

When to pick what: SiteGround for sites where budget is a constraint and traffic is modest — the included daily backups and security plugin are sufficient for a low-risk content site. Cloudways when you want configuration control and are prepared to actively manage the security stack, including setting backup frequency and enabling SafeUpdates. Kinsta when you want the most complete managed security and backup stack, including malware clean-up as an included service and hourly backup options — the correct choice for any site where downtime or data loss has a direct revenue cost.