POS recovery guide

Protect POS data with a backup you have restored

A green backup status proves that a job wrote something. It does not prove that the file contains the right records, that another machine can read it, or that staff can recover before the shop must reopen.

RPO acceptable data loss RTO acceptable downtime Separate copy away from till Restore drill with checks

What Posnic v1.3.0 actually restored

On 17 August 2026, a publisher verifier used the published Windows portable v1.3.0 build and a disposable shop profile. All figures below describe that small synthetic dataset, not production performance, customer recovery or independent review.

Reproduced backup, mutation and restore result
StageObserved resultWhy it matters
BackupVersion-2 EJSON; 20 collections, 53 documents, 13,308 data bytes; 183 ms.The manifest counted records and stored per-collection hashes plus a whole-data SHA-256.
Known mutationAdded Post-backup Item; catalog increased from 25 to 26.A restore check needs a change that should disappear, not only record counts before and after.
Drop-existing restore20 collections and 53 documents returned in 197 ms.The restore replaced current collection contents instead of merging the later item.
Post-restore checksCatalog returned to 25; later item disappeared; original item and sale S-O2MA-000001 remained.Business-level assertions caught both unwanted retention and unwanted loss.
Path controls14/14 source tests passed.Tests covered traversal, sibling paths, configured roots and explicitly selected restore folders.

Pinned source: b531ef4 · Whole-data test hash: faa00177...e39301

Choose the schedule from loss and recovery limits

Recovery point objective (RPO)

RPO is the point in time you need to recover to. In shop terms: how many minutes or hours of sales, payments and stock movement can disappear after a failure?

If the answer is one hour, a daily backup cannot meet it. Choose a frequency that is shorter than the accepted loss window and verify the job runs during real opening hours.

Recovery time objective (RTO)

RTO is how long the business can tolerate the POS being unavailable. Include replacement hardware, application installation, copying the backup, restore time, validation and printer setup.

A ten-minute database restore does not create a ten-minute RTO if buying a replacement computer takes a day.

Current recovery guidance

NIST SP 800-34 Rev. 1 ties backup frequency to recovery objectives and includes restoration in contingency testing. NIST's June 2026 OT Backup Quick Start Guide says effective backup management includes regular creation, testing and review during recovery exercises. The newer guide addresses operational technology; it is useful process guidance, not a Posnic, retail or security certification.

Use copies with different failure paths

1. Working data

The live database on the till. It is optimized for daily operation, not recovery from disk failure or theft.

2. Fast local recovery

A dated backup can reverse an accidental import or deletion quickly. If it sits on the same disk, treat it as convenience, not disaster recovery.

3. Protected separate copy

Keep another copy on a disconnected drive, separately protected system or appropriately configured backup service. Restrict who can alter or delete it.

Ransomware changes the storage decision

CISA recommends offline, encrypted backups of critical data and regular availability and integrity tests because accessible backups may be encrypted or deleted with the live system. A permanently attached USB drive is still accessible storage.

Run a restore drill without risking live data

  1. Record the source machine, POS release, backup timestamp, file or folder size and expected latest sale.
  2. Use a spare computer or disposable profile. Never overwrite the live shop to prove a test backup.
  3. Install the same supported release and complete the minimum local setup needed to provide a database.
  4. Copy the backup into the approved restore location and preserve the original copy unchanged.
  5. Restore, restart when requested, sign in and record elapsed recovery time.
  6. Check users, branches, item count, one known item, one known sale, tax totals, stock movement and the newest record date.
  7. Run a new test sale in the restored environment to prove it is writable, then discard the environment securely.
  8. Record the result, gap and next drill date. A failed drill is useful evidence when it leads to a correction.

Posnic local-backup boundaries

Default timing

The documented default is daily at 22:00 while Posnic is running. Hourly, daily and weekly schedules are configurable. A separate Windows scheduled-task path is needed when the application is closed.

Default location

The default is Documents\Posnic-Backups. This is usually on the same disk as the database, so configure an off-machine copy rather than assuming the default survives hardware loss.

Format and integrity

v1.3.0 writes compressed EJSON collections and a manifest with counts and SHA-256 hashes. Compression is not encryption; protect the storage because backups can contain customer and business data.

Restore consequence

A drop-existing restore replaces current data with the selected backup. Records created after that backup are intentionally lost. Read the timestamp and confirmation before proceeding.

Pinned backup policy · Pinned disaster-recovery guide

Keep a one-page recovery record

The blank record keeps business targets separate from observed evidence. Its result, owner, reviewer, issue, action and next-test fields are intentionally empty; downloading it does not prove a backup or restore passed.

Minimum evidence to retain after each drill
RecordExample of useful evidence
Backup identityTimestamp, release, size, manifest hash and storage location.
Expected dataLatest known sale number, item count, branch count and newest record date.
Recovery timingStart, database restored, login successful and counter ready timestamps.
AssertionsCounts matched, known records opened, totals agreed and a new test sale completed.
OwnershipPerson who ran the drill, reviewer, failure notes, corrective action and next date.

Questions

How often should a POS database be backed up?

Choose the frequency from the maximum amount of sales data the business can afford to lose. If losing one hour is unacceptable, a daily backup is not enough. Confirm the schedule also runs when the till is closed.

Is a backup on the POS computer enough?

No. A same-disk copy can help with accidental changes, but it does not survive disk failure, theft or ransomware that reaches the folder. Keep a protected copy away from the till.

What proves a POS backup works?

A controlled restore followed by checks of users, items, sales, stock, totals and record dates. A file existing or a backup job reporting success is not a restore test.