Acumatica Backup and Restore Strategy

An Acumatica backup that has never been restored is a hypothesis, not a backup. A working recovery plan for an on-premises or private-cloud Acumatica instance has three moving parts that must be captured as a set: the SQL Server database, the site's file storage, and the IIS/application configuration. Miss any one and the restore fails at the worst possible time. This is the strategy I actually use, and the drill that proves it.

The three things that make up an instance

Acumatica SaaS handles this for you; if you self-host, you own it. A complete instance is: the application database in SQL Server (all business data, customizations published into it, and the file blobs if you store attachments in the database); the file storage if you configured file attachments to go to disk instead of the DB; and the web.config plus the site folder, which hold the connection string, the instance version, and any hand-edited settings. If you restore only the database onto a fresh site of a different build number, it will not start — the database schema is tied to the exact Acumatica build.

Backing up the database

The database is the core. Use SQL Server's native backup — a full backup on a schedule plus transaction-log backups if you run in the full recovery model and need point-in-time recovery. A nightly full is the floor; if losing a day of transactions is unacceptable, add log backups every 15–30 minutes.

-- Nightly full backup, compressed, with checksum verification
BACKUP DATABASE [AcumaticaProd]
TO DISK = N'D:\Backups\AcumaticaProd_full.bak'
WITH COMPRESSION, CHECKSUM, INIT,
     NAME = N'AcumaticaProd-Full';

-- Log backup (only if database is in FULL recovery model)
BACKUP LOG [AcumaticaProd]
TO DISK = N'D:\Backups\AcumaticaProd_log.trn'
WITH COMPRESSION, CHECKSUM;

CHECKSUM makes SQL Server verify page integrity as it writes, so a corrupt backup fails loudly instead of silently. Ship the .bak files off the database server — to a file share, then to object storage or a second site — because a backup that lives only on the machine you are trying to recover from is not disaster recovery.

Setting RPO and RTO to real numbers

Two numbers drive every decision here. RPO (recovery point objective) is how much data you can afford to lose, measured in time — it sets your backup frequency. RTO (recovery time objective) is how long you can be down — it sets how much standby infrastructure you pay for. A distributor that can tolerate losing an hour of orders and being down for four hours needs hourly log backups and a documented restore runbook, not an expensive hot standby. Decide these with the business, not in IT, because they are business risk decisions with a cost attached.

File attachments and configuration

If attachments are stored on disk (not in the database), that folder needs its own backup on the same schedule as the database, and the two must be restorable to a consistent point — an invoice row that references a PDF the file backup does not have is a broken record. Simplest is to keep attachments in the database so a single SQL backup captures everything; it costs database size but removes an entire class of "the file is missing" support tickets. Also snapshot the site folder and web.config after every customization publish, since that is when the moving parts change.

The restore drill that proves it works

Schedule a restore, do not just hope for one. Quarterly, restore the latest full backup onto a spare or throwaway server, bring up the Acumatica site against it, log in, and confirm the data is current and the customizations are present. Time the whole thing — that stopwatch number is your real RTO, and it is almost always longer than people guess. The drill catches the failures that matter: a mismatched build number, a missing file share, an expired service-account password, a connection string pointing at the old server.

Wrapping up

A dependable Acumatica recovery plan is database plus files plus configuration, captured together, copied offsite, and restored on a schedule to prove it works. Pin the build number to every database backup, set RPO/RTO with the business rather than guessing, and treat the quarterly restore drill as the actual deliverable. If you are designing recovery for a self-hosted instance and want a second opinion, reach out or keep reading through the rest of the Acumatica blog.