A while back, a routine plugin update took down a client’s store on a Friday afternoon. White screen, no admin, checkout gone. The kind of moment that ruins a weekend. Twenty minutes later the store was back online, and the only reason is a habit so boring I almost never talk about it: real backups, tested ones, taken automatically.
What “real backups” means
Lots of site owners believe they have backups because their hosting plan mentioned the word. Then the day comes and it turns out backups were weekly, kept for seven days, stored on the same server that just failed, or behind a support ticket with a two-day response time. A backup you can’t restore quickly, yourself, is a rumor, not a backup.
- Automatic and scheduled — daily for stores, weekly for static sites
- Stored off the server, so a server problem can’t take both
- Covering both the files and the database, because half a site is no site
- Kept in versions going back weeks, not just yesterday’s copy
- Actually restored, on purpose, at least once — before the emergency
That last point is the one almost nobody does. The first time you restore a backup should not be the day everything is on fire. I test-restore to a staging copy when I first set up a site, so I know the process and I know the backup is complete.
The habit around the habit
Backups also run manually before anything risky: plugin updates on a store, theme changes, bulk imports. It adds two minutes to the job. On that Friday, the pre-update backup was four minutes old when the update went wrong. Restoring it meant losing nothing at all.
There’s no dramatic lesson here, and that’s the point. The difference between a twenty-minute problem and a lost weekend — or a lost store — is a checkbox in a backup plugin and the discipline to test it once. It’s the cheapest insurance in this entire business.
