Why we built our own backup plugin instead of using UpdraftPlus
We used UpdraftPlus on every site we managed. It was the obvious choice -- popular, free tier, easy to configure. Then a client's site got compromised. Nothing dramatic, just a quiet malware injection that lived in the codebase for about three weeks before anyone noticed. We went to restore from backup. The backup existed. The restore failed.
That failure cost us a week of reconstructed work and a client relationship that never fully recovered.
What actually went wrong
UpdraftPlus had been backing up to the client's own server. Classic mistake -- a backup on the same machine as the site. When the hosting environment was compromised, the backup files were in the same compromised space. We had tested the backup process but never tested the restore process on a clean environment. Those are two entirely different things.
The second problem was notification. UpdraftPlus sent success emails that were going to a shared inbox nobody checked regularly. Three weeks of successful backups to a folder that was itself corrupted. We were confident because we had no reason not to be.
What we built instead
We spent about six weeks building a lightweight backup system. Nothing fancy -- a cron-triggered PHP script that packages core files and a database dump, then pushes to an offsite S3 bucket we control. The critical difference is that we test restores on a staging environment every two weeks. Automated. Logged. A Slack notification tells us whether the restore succeeded or failed.
We added a second layer: a read-only offsite copy that the primary server cannot write to or delete from. Even if the site gets fully owned, the attacker cannot touch those backups.
Is it as feature-rich as UpdraftPlus? No. Does it do the one job that actually matters -- getting a site back up after something goes wrong? Yes. We have run four successful restores from it since we deployed it. Three were drills. One was real.
What this changed about how we work
We stopped treating backup configuration as a setup step and started treating restore testing as an ongoing operation. Every site we manage now has a documented restore procedure, a secondary offsite location, and a scheduled restore test. When we onboard new clients, we do a restore test in week one.
The honest version of this story is that we were overconfident. UpdraftPlus is a good plugin. Our process was the problem. But building our own system forced us to understand every step at a level we never would have reached just by configuring someone else's tool.
If you are managing WordPress sites for clients and you have not tested a restore from scratch on a clean environment, do that before you do anything else today.