“We have backups” is a reassuring sentence. It is also missing several useful details.
Before a broken update or accidental deletion makes recovery urgent, ask what those backups contain, how far back they go and who can restore them. The goal is a practical recovery plan for your website, not a collection of reassuring dashboard icons.
These six questions help you have that conversation with your hosting or website provider. The answers depend on the site and the service agreement; do not assume every hosting plan handles recovery the same way.
1. What exactly is being backed up?
A WordPress website has both files and a database. Files can include themes, plugins and uploaded images. The database holds information such as posts, pages and settings. WordPress’s backup guidance explains why both parts matter.
Ask whether the backup covers the complete site or only selected components. Then ask about anything outside WordPress: email, a separate booking service, externally stored media or another connected system. A website backup does not automatically contain everything your business uses online.
Write down the exclusions. They are much easier to plan around when nobody is waiting for the site to come back.
2. How much recent work could be lost?
The latest usable backup represents a point in time. Content or transactions created after that point may need separate recovery or reconciliation.
Match the discussion to how your business uses the site. A brochure site changed once a month and a site receiving bookings throughout the day have different recovery concerns. Ask how often backups run, whether important changes prompt an additional backup, and how failures are noticed.
Consider a fictional business that publishes a new service page after its last backup. Restoring that earlier version could remove the new page. If the same site stores incoming requests, the consequences could extend beyond missing copy. Identify what changes and where that information is stored before choosing a recovery approach.
3. How far back can we go?
A problem may not be discovered immediately. Ask how many restore points are retained and whether older versions remain available long enough for the problems your team is likely to notice.
Keep the distinction between backup frequency and retention clear. Frequent copies do not necessarily mean a long history. Also ask whether failed or corrupted versions can replace older useful copies, and what checks the provider uses.
You do not need to prescribe a universal number of days. You need a retention arrangement that fits the site’s activity, risks and agreed service scope.
4. Who can reach the backup if the website is unavailable?
Confirm where backups are stored and how an authorized person accesses them. If the only recovery instructions live inside the broken website, the filing system needs another look.
Ask whether a separate copy or storage location is available and how access works if the main hosting account is unavailable. Record the provider’s support route and the person in your business who can authorize recovery.
Keep passwords and recovery credentials in an appropriate secure system, not in an ordinary planning document or email thread. The recovery plan can identify where authorized access is managed without containing the secrets themselves.
5. Who performs the restore, and what happens first?
Clarify responsibility before an incident. Does your provider perform restores, or is it self-service? What approval is needed? Are there costs, availability limits or exclusions you should understand?
Before replacing the live site, someone needs to assess the current state and the consequences of returning to an older version. That may include preserving newer content, orders or requests, identifying the right restore point, and deciding whether recovery can first be checked in a separate environment.
A restore should not become an experiment on the only working copy. Ask the provider to explain its process in plain language and record any unanswered questions.
6. How will we know recovery worked?
A successful completion message does not prove every customer task works. Agree what will be checked after a restore: important pages, images, navigation, forms, booking links and any business-critical integrations.
Where safe restore testing is available, ask what was tested and when. A test should use controlled information and avoid creating real orders, appointments or customer messages. Your team may need to help confirm that the restored content is the correct version.
WordPress includes backups as part of ongoing site maintenance. Your own recovery checks should reflect the functions and information your business depends on.
Keep the answers in one place
A short recovery record can list backup scope, frequency, retention, access owner, restore contact, approval process and verification checks. Add the date the answers were confirmed. Review it when the website, hosting arrangement or business workflow changes.
Imbark offers managed hosting with maintenance and backups, alongside ongoing website support. Send us your website and current hosting questions to discuss the scope your site needs. Backup details and recovery responsibilities should be agreed, not guessed.
