Business Central backup and restore, set up and rehearsed

How Business Central backup and restore works online

In Business Central online, Microsoft takes database backups automatically. That covers every production and sandbox environment. You do not schedule them, and you cannot switch them off. Microsoft keeps backups for a limited period. So you can restore only to a moment inside that window. It is simple.

An internal or delegated administrator starts a restore from the admin center. You pick a date and time. The service then builds a new environment from that moment and leaves the original alone. People check the restored data. Only then does anyone decide which environment carries on as production.

Database exports you keep yourself

Some companies want a copy outside Microsoft's service. The reason may be an auditor, a legal hold or plain peace of mind. You can export a production environment from the admin center as a BACPAC file. It lands in an Azure storage container that you own. The export needs a specific permission and a paid subscription.

A BACPAC is a snapshot for safekeeping or analysis. You cannot load it back into Business Central online. So it does not replace the built-in restore. We set up the storage account and agree how often exports run. We also agree who holds the access keys. Then we write down what each export is for. Keep it safe.

Business Central backup and restore for on-premises systems

When Business Central runs on your own servers, nothing is backed up unless you arrange it. The data lives in SQL Server. So full, differential and transaction log backups need a schedule. They also need a destination away from the server. And someone must read the job results each morning.

We also look past the database. License files, extension packages, server instance settings, report layouts and integration credentials are all needed to rebuild a working system. Our consultants record where each one lives. Then we run a trial rebuild on a separate machine. That way, the steps are proven, not assumed.

Undoing a mistake without a full restore

Most Business Central backup and restore requests are not disasters. Someone ran a batch job against the wrong filter. Or they imported a bad price list or deleted a set of records. A full restore would throw away everybody else's work since that moment. So it is rarely the right first move. A narrow fix is better.

Instead, we restore to a separate environment. We find the affected records there and bring only those back. Tools for this include configuration packages, Edit in Excel or a small script. For posted entries, we use reversing entries, which keep the ledger history honest. A sandbox copy taken before risky work avoids the problem entirely.

A recovery runbook your team has practiced

A plan that nobody has tried is a guess. So we write a short runbook. It names who may start a restore and who must be told. It also says how to keep users out while data is checked. And it says how to pause integrations, job queues and bank feeds so that nothing posts twice.

Then we rehearse it with your administrators in a sandbox. Each step must work. Every instruction must also be clear to someone who reads it under pressure. Any gap we find goes straight into the document. After that, a restore is a procedure that people follow calmly, not an improvisation.

Business Central backup and restore questions

Does Microsoft handle Business Central backup and restore online?

Yes. The service backs up every online environment without any setup from you. Microsoft keeps backups for a limited period. An administrator can restore an environment to a chosen moment inside that period from the Business Central admin center. We check who holds that right in your tenant, so the right people can act fast in an incident. That is the plan.

Can we restore a single company or a single table?

The built-in restore works on a whole environment, not on one company or table. To recover part of the data, we restore into a separate environment. Then we copy the needed records back into production. We use configuration packages or a small extension for that. We also check the copied records against the ledger before users go on.

Does a restore overwrite our live environment?

No. A point-in-time restore creates a new environment beside the original. You check the restored data. Then you decide whether to rename it and make it production, or to copy records across. The original stays available until you choose to remove it. So you can change your mind without losing anything. Nothing is lost.

Can we download our own Business Central backup and restore file?

You can export a production database as a BACPAC file to your own Azure storage. You need the right permission and a paid subscription. The file is useful for archiving and analysis. But you cannot import it back into the online service. We set up the export and explain what it can and cannot do, so nobody counts on it as a restore.

What happens to integrations after a restore?

Job queue entries and outside connections need attention after a restore. They may be paused, or they may point at the wrong environment. So we go through each integration and confirm where it should connect. Then we restart them in a planned order once the data has been checked. That prevents double posting.

Related Business Central services

Recovery planning sits beside environment administration and security. These pages cover the admin center, permissions, sandbox environments and on-premises hosting. All of them shape how a restore works in practice. For a rehearsed Business Central backup and restore plan, use the contact page to start the talk. For the product detail, see Restoring an environment in the admin center, Microsoft Learn.