Backup and restore basics for on-prem Business Central and LS Central installs

System admin · 9 min read

Most backup advice for Business Central is written for the online service, where Microsoft runs the backups for you. An on-prem install is the opposite arrangement: the database sits on your SQL Server, the LS Central components sit on your machines, and the backup job succeeds or fails on your schedule. This guide covers what actually needs backing up, the order a restore has to run in, how to test restores before an emergency tests them for you, and the mistakes that make a backup file worthless on the day it is needed.

On-prem is a different job from online

In Business Central online, databases are protected by automatic backups that Microsoft manages. Tenant administrators cannot directly access or manage those backups; they restore an environment to a point in time through the Business Central Admin Center, and LS Central's own documentation puts the online retention at 30 days. None of that machinery exists on-prem. There is no Admin Center restore button for your own server — there is only what your backup jobs captured, where they put it, and whether anyone has ever restored it.

That last row is where on-prem restores usually fall apart. The database is the biggest piece, but it is not the whole system.

What actually needs backing up

Work through this inventory for every install, head office and stores alike. If an item is not on the list, assume it is not being backed up — because it isn't.

• The SQL Server databases. This is the core: the Business Central database (or, in a multitenant layout, the tenant databases plus the separate application database). Everything transactional — sales, statements, inventory, general ledger — lives here, and every restore starts here.
• Server instance configuration. A restored database still needs a Business Central Server instance pointed at it, with the right settings. Keep an exported copy of each instance's configuration alongside the database backups, and note which instance serves which store or company.
• Extensions and application files. Keep the installable app files for every extension in production, matched to the version in the database. A database restore followed by "which app version were we running?" is a stall you can prevent with a folder and a naming habit.
• LS offline components. Where offline POS is in play, the footprint is wider than head office. LS documentation describes the Hybrid Component Server as Data Director, Update Service, and a template database called POSMaster, and an offline POS terminal itself runs a local SQL database, Service Tier, Data Director, and BC Client. Those local databases and configurations are part of the backup inventory, not an afterthought — LS is explicit that keeping those databases current is the operator's responsibility.
• Scheduler and replication setup. Distribution locations, Scheduler jobs, and Data Director configuration decide how data moves between head office and stores after a restore. Export or document them so a rebuilt server replicates the way the old one did.
• The small files everyone forgets. License file, certificates, and any integration files or file-exchange folders the setup depends on. None of them are large; all of them stop a reopening when missing.

Backup types and a workable schedule

Because Business Central runs on a SQL Server database, backups use SQL Server's built-in functionality — from SQL Server Management Studio (right-click the database, Tasks, Back Up) or scripted with PowerShell — and regular backups can be scheduled with SQL Server Agent jobs. Three backup types do the work:

• Full backup — the whole database. This is the base every restore starts from.
• Differential backup — changes since the last full backup. Restoring the most recent differential reduces the number of log backups that must be replayed afterwards.
• Transaction log backup — the log since the last log backup, under the full recovery model. Log backups are what make point-in-time restore possible: the database can be recovered to a specific point within a log backup.

A workable pattern for most retail installs is a nightly full backup, differentials during the day if the database is large, and frequent log backups on the head-office database — with the schedule written down, the destination off the database server itself, and backup failure alerts going to a person, not a mailbox nobody reads. Two cautions belong in the runbook. First, ad-hoc manual backups taken outside the schedule should use the CopyOnly option: a copy-only backup leaves the transaction log alone and does not disturb the automated backup chain. Second, keep more than one generation. A backup rotation that overwrites last night's file with tonight's broken one is not a rotation.

Restore order, step by step

Order is not a detail here — it is the procedure. A complete SQL Server restore under the full recovery model runs in this sequence, and the database stays offline for the duration of the restore:

1. Stop the traffic first. Stop the Business Central service tier (and store services) that use the database so nothing writes to it mid-restore.
2. Back up the tail of the log. If the failed database is still reachable, take a tail-log backup first — it captures the log since the last log backup. If the active log is unavailable, that portion of transactions is lost; know that before you promise a recovery point.
3. Restore the most recent full backup — with NORECOVERY, so the database stays in a restoring state ready for the next pieces.
4. Restore the most recent differential backup, also with NORECOVERY, if differentials are part of your schedule.
5. Restore the transaction log backups in sequence, each with NORECOVERY, starting with the first log backup taken after the full or differential you just restored — including the tail-log backup from step 2.
6. Recover the database with RECOVERY (this can be combined with the last log restore).
7. Restart the service tier against the restored database, then start the LS components — Scheduler, Data Director — and confirm replication jobs run and stores reconnect before declaring the system back.

For a narrower job — one company needs to come back, or data needs to move between databases — the .navdata route exists: Export-NAVData and Import-NAVData move company data, and optionally global data, application data, or application objects, between databases. That is a data-movement tool, not a substitute for database backups.

Test restores: the part everyone skips

An untested backup is a hope, not a backup. The standard test is a refresh of a test database from production, which doubles as proof the chain restores end to end:

1. Take (or take from the schedule) a CopyOnly full backup of production, so the test does not disturb the live backup chain.
2. Stop the test service tier.
3. Restore the backup over the test database (Restore-SqlDatabase with replace, or the SSMS equivalent).
4. Restart the test service tier and open the restored company.
5. Verify, don't just open. Check that recent transactions and statements are present up to the backup time, run a familiar report, and confirm users and permissions came across.
6. Time it and write it down. The elapsed time is your real recovery time. Record the date of the test, who ran it, and anything that failed — then fix the runbook, not just the test.

Run this on a schedule — quarterly is a sane floor for a system the business trades on — and after any change to the backup job, the SQL Server, or the LS setup.

Mistakes that make backups useless

• Restoring onto an older SQL Server. SQL Server does not support restoring a backup taken on a newer version into an older one — the restore simply fails. Check version compatibility between the backup source and any machine you might restore onto, especially the spare or test server, before the emergency.
• Backups that live only beside the database. A backup on the same server (or the same storage) as the database is lost in the same incident. At least one current copy belongs somewhere else.
• Breaking the log chain with good intentions. One manual full backup taken without CopyOnly, or a recovery-model change nobody documented, and the log sequence the restore depends on has a hole in it.
• Database restored, store still closed. The database came back but the instance configuration, the extension versions, or the offline POS pieces did not — see the inventory above. In LS Central, sales also depend on end-of-day processing; a restored system needs its statements checked, not just its login screen (see our end-of-day routine).
• Nobody ever restored one. Every other mistake on this list is discoverable in a calm test restore and expensive in a real one.

Which restore route when

What success looks like

• Every database on the inventory has a scheduled backup job, and the last successful run is recent enough that you would accept losing everything after it.
• At least one current backup copy exists off the database server.
• A test restore has been completed and timed within the last quarter, and the restore runbook — order, NORECOVERY sequence, service restarts, replication checks — is written down where someone besides the usual administrator can find it.
• The restore target's SQL Server version is known to accept your backups.

Backups for an on-prem retail system are not a feature you turn on; they are a routine you run and a restore you rehearse. Keep the routine boring, and the one bad day stays a bad day instead of a bad month. If your terminals also trade offline, make sure that side is covered too — see what happens in POS offline mode.