A backup plan should explain how you recover.

Find the actual source of your data

Ask where the POS application and database run: a counter computer, a local server or a cloud server. Record which machine holds the current records and which devices only connect to it. A copy of an application shortcut or installer is not necessarily a copy of the restaurant's data.

The reviewed desktop workflow includes a manual backup action, configurable automatic backups and a restore action. Ask the installer to show which controls apply to your installation and whether automatic backup is actually enabled. A desktop feature does not establish that a managed cloud backup service is included.

Check what is covered, not only the folder name

The reviewed desktop backup workflow exports database collections with a record of their contents. Ask the technical person to inspect that record for errors or missing collections. A new folder or a completion message alone does not prove that every required record was copied.

Make a separate inventory of anything needed to resume service: uploaded files, receipt layouts, printer configuration, application settings and installation requirements. Confirm where each is stored and how it will be recovered. Do not assume that a database export is a complete copy of the computer, its devices or every file used by the restaurant.

Decide how much recent work could be missing

Suppose the latest verified usable backup is from 2 PM and the counter fails at 6 PM. The four-hour gap identifies the period whose work needs investigation; it does not tell you how many bills are missing. Use the actual saved references and other approved records to establish what happened after 2 PM. Never re-enter payments solely because they are absent from a restored copy.

Agree how often backups should run and who checks them after a busy shift. The desktop scheduler runs within the application, so demonstrate the routine with your actual opening hours, machine power state and chosen destination. Verify the most recent usable copy after a shutdown or failed attempt instead of treating the scheduled time as proof of completion.

Assign responsibility and storage

Decide who checks that backups complete and who follows up when they fail. Discuss an appropriate copy outside the primary device, access restrictions and retention with the responsible technical person. Avoid keeping every copy on the same device whose failure you are planning for.

Protect backup files because restaurant records may contain business or customer information. Store access details securely and limit them to the people who need them. Keep a simple dated record of successful checks without putting passwords into the checklist.

Demonstrate a restore away from production

Ask for a controlled restoration into a separate test environment. Confirm that representative menu and order records can be read there. Do not overwrite the live database to find out whether a backup works, and do not test with customer service in progress.

Write down the observed result, the person responsible and the recovery contact. Repeat the review when the server location or backup method changes. A usable plan names the steps and their owner; it does not rely on the assumption that either local or cloud hosting makes recovery automatic.

Use known restaurant records as recovery evidence

Before the rehearsal, agree on a few anonymised records that should exist in the chosen backup. After the technical person restores it into the separate environment, have the restaurant operator check them. Keep test printers and external payment or messaging connections isolated so a rehearsal cannot trigger real kitchen work or customer communication.

Record recovery time and unresolved work

Use the downloadable recovery rehearsal worksheet to record the backup date, isolated environment, observed results and follow-up owner. It is an editable record, not a backup utility or automatic recovery assessment. Write down when the rehearsal began, when records became readable and when the full agreed checks were complete. If data loads after 20 minutes but the printer works only after 45, record both observations. Neither is a guaranteed recovery time for a future incident.

Keep the result with the backup date, test environment, responsible person, missing items and next action. Agree who authorises a real recovery and how the restaurant accounts for orders and payments recorded after the chosen backup. Bring this short record to your Chennai setup review; keep passwords and copies of customer records out of a shared checklist.

Reconcile the gap with three sample restaurant orders

Use this fictional exercise on paper before a supervised test restore. A verified backup was taken at 2 PM and the counter stopped at 6 PM. Keep the original records available to the responsible technician. The restored copy represents the earlier point in time; it is not a statement that later kitchen work or payments never happened.

Compare each order reference with the approved evidence from after 2 PM. Record what is known, what is still uncertain and who authorises the correction. Do not resolve every difference by entering a fresh sale: that could repeat a payment, create another kitchen instruction or count revenue twice.

Ask what protects the backup copy itself

A second folder on the counter computer shares that computer’s failure risk. Ask the technical owner to explain the separate storage, access controls and recovery credentials for your actual arrangement. A sales CSV is useful for checking figures, but it should not be treated as a complete restorable restaurant database.

CISA recommends offline, encrypted backups and regular recovery tests because reachable backups can also be damaged by ransomware. Discuss how that principle is implemented for your local or hosted setup. It is not a claim that DeccanPro includes managed off-site storage, encryption or immutable backups. Keep recovery keys out of shared worksheets and confirm that the authorised recovery person can obtain them when needed.