How to plan backup for Tally and other business data

Backup5 August 20263 min readBy Digbijay Paul

In Surat, a large share of the businesses we work with run Tally or Busy on a small office server, with a few shared folders alongside. When that data goes, it cannot be rebuilt from anywhere except paper and memory.

Start with one question

If you restored from last night's copy, how much work would the team have to redo? For a trading business in a busy month, a full day of vouchers is painful. If the answer is uncomfortable, the backup should run more than once a day.

What to include

• The accounting data folder, from a state where files are not being written
• Shared documents, scans, designs and photos
• Email data, if mailboxes are stored locally rather than in Microsoft 365, Google Workspace or Zoho
• Licence details and installation files for the applications you would have to reinstall
• The server configuration itself — or the whole virtual machine, if the server is virtualized

The Tally-specific part

Copying a live data folder while users are posting entries can produce a copy that will not open cleanly. In practice, that means one of the following: run the backup at a time when nobody is in the application, use the application's own backup to produce a consistent file and then back that file up, or back up the whole virtual machine so the copy is taken at a consistent point.

Whichever route you take, the important part is checking the result rather than assuming it.

How long to keep copies

Daily copies for a few weeks and monthly copies for longer is a reasonable starting point for a small business. The reason to keep older copies is simple: some problems — a corrupted ledger, a mistake made three weeks ago — are only noticed later, and by then the recent copies all contain the problem.

Somebody has to be watching

Almost every failed backup we are called about failed quietly, weeks or months before anyone noticed. A Windows update changed a service, a disk filled up, a password expired. The job stopped, and nothing said so. Backup software can send an email or an alert on failure; someone then has to read it. Under an AMC this is part of the routine, but even without one, a weekly two-minute check of the last successful run is worth more than any amount of extra storage.

Restore time matters as much as backup time

If your server died this afternoon, how long until people can post entries again? Restoring a data folder onto a working machine is quick. Rebuilding a server from scratch — operating system, application, licences, printers, shares — is a day or two if everything goes well. That is the real argument for backing up whole virtual machines rather than only the data folder: the machine comes back as it was, rather than being reassembled from memory.

Common mistakes

• Backing up to a folder on the same server
• A USB drive that stays connected and writable at all times
• Nobody notices the job stopped running after a Windows update
• Copying the data folder while the application is open, and never testing the copy
• Year-end data archived to a single disk with no second copy

What to do this week

1. Find out when the last successful backup ran, and where it went.
2. Restore one file, or one company's data, into a test folder and open it.
3. Add a second destination if every copy is currently in the same room.
4. Set up a failure alert so a silent stop does not go unnoticed for months.