IT tips for SMBs

WordPress backups: the difference between having a copy and being able to restore

The dashboard says last night’s backup finished. That’s reassuring, but it isn’t yet proof that the site will come back properly after an outage, a failed update or a compromised account. A WordPress backup for SMBs only becomes useful when you know what to restore, where to do it and how long it takes.

Close-up of colourful HTML code on a dark screen

A WordPress backup for SMBs has to cover more than the pages

A WordPress site is made up of several pieces. The files contain the theme, plugins and media. The database holds, among other things, the pages, settings, accounts and, depending on the site, form submissions or orders. So copying only the images folder isn’t enough. Backing up only the database won’t let you rebuild the site exactly as it was either.

You also need to know which elements live elsewhere: the DNS configuration, the mailbox that receives form submissions, a plugin licence, the certificate, the registrar account and server settings. They don’t all need to be in the same archive, but where they are and who is responsible for them should be documented.

Start with a concrete question: if the server disappeared this morning, what files, access and information would you need to put the site back online in another environment? The answer quickly exposes the gaps in an automatic copy that’s too limited.

Choose the frequency based on what changes

The right frequency depends on how often the site actually changes. A brochure site updated a few times a month doesn’t have the same needs as an online store that takes orders every hour. Content, the database and files can also follow different schedules.

Decide how much work the business is willing to lose. If a day of quote requests would have to be re-entered, check whether forms are included and when the database is copied. If requests also arrive by email, confirm that this mailbox is covered by a separate strategy.

Also plan for retention long enough to go back to a point before a quiet problem started. A malicious plugin or a content error can go unnoticed for several days. Ten identical copies made after the incident won’t help you get back to a healthy state.

Keep a copy outside the same hosting account

An archive stored in the same account as the site can disappear with it. A suspension, an administrative error, a storage failure or compromised access can hit production and its backups in the same place. Keep at least one copy in a separate location, with separate, controlled access.

Separate doesn’t just mean another folder on the server. It can be independent cloud storage or a backup service managed separately. Encrypt copies when they contain sensitive information and limit who can delete them.

The page on web hosting at Infotech Canada outlines the support available to SMBs that want to clarify the maintenance, monitoring and continuity of their site.

Test the restore in an isolated environment

The most useful test isn’t done directly on the public site. Restore a copy to a temporary or staging environment, then open the important pages. Check navigation, images, login, forms and the features specific to your business. A form that says “sent” without delivering the email is still an incomplete restore.

Note the test date, the copy used, the time it took and any errors. Also check the PHP version, the database and dependencies: a valid archive can refuse to start in an environment that has become incompatible. After the test, cleanly delete the temporary environment so it doesn’t become a forgotten, exposed copy.

A realistic test often reveals small obstacles: the registrar account belongs to a former provider, multi-factor authentication depends on one person’s phone or nobody knows the licence key for an essential plugin. These details determine how long it really takes to get back online.

Assign responsibilities before the incident

Write down who monitors failures, who can start a restore and who authorizes the switchover. The site owner, the web agency and the host don’t always handle the same tasks. One precise sentence in the contract or procedure beats an assumption shared by three providers.

The file should state where the backups are, how long they’re kept, the contact information you’ll need and the priority steps. Don’t paste passwords into it: point instead to a business vault that authorized people can access. Review this information when an employee leaves, a domain is transferred or the hosting changes.

Finally, schedule the next test. For a WordPress backup for SMBs, the schedule, the off-site copy and the procedure don’t replace the restore exercise. That’s what turns a technical promise into an operational capability.

What to confirm

Files, database, media, forms, DNS, licences and recovery access.

What to separate

Production, off-site copies and the accounts that can modify or delete archives.

What to test

Key pages, forms, logins, media, technical dependencies and the real time needed to get back online.

Validate a restore before you need it

If you want to check your copies, access and restore procedure without touching the public site, Infotech Canada can help you prepare a controlled test and a short list of fixes.

Book a meeting

Have a specific question about your situation? Write to us.