Ask whether an estate is backed up and the answer is almost always yes. Ask how long a full restore takes, measured, and who last did one, and the room usually goes quiet. The first question is about a job that runs every night. The second is about whether the business can get back on its feet, and only the second one matters on the bad day.

Illustrative: a diagram of the idea, not a reading from a customer system.

What a backup proves, and what it does not

Microsoft's SQL Server guidance does not stop at taking backups. It says to test your strategy by restoring a set of backups and then recovering the database, so you are ready to respond to a disaster.

There is a tempting shortcut. RESTORE VERIFYONLY checks that a backup set is complete and that the whole backup is readable, but it does not attempt to verify the structure of the data inside it. Backup checksums, enabled with the WITH CHECKSUM option, add a check as the backup is written. Both are worth having. Neither tells you whether the database comes back usable, how long it takes, or whether the application works afterwards.

Business Central online changes who does what

On Business Central online, Microsoft takes the backups, and an administrator can restore an environment to a point in time up to 28 days ago from the admin center. That removes the backup job from your list. It does not remove the questions: who decides to restore, what happens to the work done since that point, which extensions and integrations need attention afterwards, and how long the business waits. Microsoft's documentation lists caveats about what is and is not available in a restored environment; read them before you need them.

On SQL Server, whether on-premises or on Azure virtual machines, there is one more question: will the backups survive the failure they are meant to recover from? Microsoft's guidance pairs testing restores with keeping copies of backups in a safe, off-site location. A backup on the same disk, server or site as the database protects against a dropped table, not against losing the server.

Rehearse it like you mean it

A useful restore rehearsal, in our practice, answers four questions with numbers and names:

  • How long does a full restore take, measured from the decision to the moment users can work?
  • How much data would be lost, measured against the business's expectation rather than the backup schedule?
  • Who did it, and could someone else follow the runbook without them?
  • What did the business lose per hour while it ran, and is that acceptable?

Run it into a separate environment, never over production, and include the application, not just the database. A database that restores in twenty minutes is not a recovered system if the integrations take a day to reconnect.

What the business is actually asking

Two numbers decide whether a recovery plan is good enough, and neither is technical. How much work can the business afford to redo, measured in hours of transactions? And how long can it afford to be without the system, measured from the moment of failure to the moment people are working again? Engineers call these the recovery point and recovery time objectives; the business only needs to answer them in its own words.

Once those answers exist, the backup schedule, the restore method and the rehearsal can all be checked against them. Until they exist, every backup design is a guess about what the business would have said. In our experience the answers are often stricter for month-end and year-end than for an ordinary Tuesday, which is worth knowing before the bad day falls on one of them.

The traps

  • Treating a green backup job as a recovery plan.
  • Testing the restore of the database but not the steps after it: extensions, integrations, scheduled jobs, users.
  • A runbook that assumes a person who has since left.

Five checks for this week

  • Find the date of the last full restore test, and who ran it. If there is no date, that is the finding.
  • On SQL Server, confirm backups are taken with checksums, and stop treating VERIFYONLY as a restore test.
  • On Business Central online, read the restore documentation and write down who is allowed to restore and who decides.
  • Agree with the business how much data loss and how much downtime are acceptable, in hours, not adjectives.
  • Schedule a timed restore rehearsal into a non-production environment, including the application and integrations.

Veltheon is founder-led, based in Ontario, and works on Business Central and NAV, SQL Server and Azure. If one of these sounded like your estate, the first conversation is free and starts with the evidence you already have.

Sources and credits

  1. Back up and restore of SQL Server databases — Microsoft Learn: test your strategy by restoring and recovering
  2. RESTORE VERIFYONLY — Microsoft Learn: what verification does and does not check
  3. Enable or disable backup checksums — Microsoft Learn: WITH CHECKSUM
  4. Restoring an environment in the admin center — Microsoft Learn: Business Central online point-in-time restore, up to 28 days, and its caveats
  5. Creative Commons Attribution 4.0 (CC BY 4.0) — the documentation licence

Original Veltheon explanation. The films are illustrative artwork, not Microsoft or customer footage, and nothing here is a measured result from a customer system. Verify current documentation and your actual environment before changing anything.

Documentation references: Microsoft and contributors, Microsoft Learn (Business Central, SQL Server and Azure documentation), licensed CC BY 4.0. Concepts summarized by Veltheon; source wording and layout not reproduced.

Veltheon Field Notes is an independent publication, neither affiliated with nor authorized, sponsored or approved by Microsoft Corporation. Microsoft, Dynamics 365, Business Central, Dynamics NAV, SQL Server and Azure are trademarks of the Microsoft group of companies.

These are the personal views of Neeraj Kumar, based on about two decades of enterprise experience. General information, not advice for your environment.