Cloud Tally & BUSY Data Backup Explained: Data Ownership, Backup Frequency, 7-Day Retention, Customer Responsibility and Long-Term Data Protection
Businesses increasingly use Tally Prime, BUSY Accounting Software and similar accounting applications on cloud or remote servers. Cloud hosting offers signif...
Businesses increasingly use Tally Prime, BUSY Accounting Software and similar accounting applications on cloud or remote servers. Cloud hosting offers significant advantages: employees can work remotely, multiple offices can access a common database, infrastructure can be centrally managed, and organisations do not need to maintain a powerful server at every location.
However, one important subject is frequently misunderstood:
Who is responsible for the accounting data, and how long should its backups be retained?
A customer may assume that because accounting software is running "on the cloud," every historical version of its data will automatically remain recoverable forever.
That assumption can be dangerous.
Cloud hosting, server availability, operational backup, disaster recovery and long-term data archival are related concepts, but they are not necessarily the same service.
The most important principle for every business to understand is:
Your business data is your asset. Know how it is being backed up, how long backups are retained, and whether that retention period meets your business requirements.
1. Your Accounting Data Is Your Business Asset
Whether accounting software runs:
- on a desktop computer,
- on an office server,
- through Remote Desktop,
- on a VPS,
- on a private cloud,
- through a managed Tally cloud service,
- through a BUSY cloud environment, or
- through another hosted accounting platform,
the accounting information fundamentally belongs to the organisation using it.
Examples include:
- company masters,
- ledgers,
- vouchers,
- sales invoices,
- purchase invoices,
- GST records,
- bank transactions,
- inventory,
- payroll information,
- outstanding receivables,
- outstanding payables,
- tax calculations,
- financial statements,
- audit information, and
- supporting accounting records.
The hosting provider supplies infrastructure and services around the data. That does not mean a business should stop taking an active interest in how its own information is protected.
2. Cloud Hosting Does Not Automatically Mean Permanent Backup
This is perhaps the biggest misconception surrounding cloud accounting.
A customer may think:
"My Tally is on cloud, so my data must always be recoverable."
Not necessarily.
Cloud hosting normally means that computing resources are being provided so that users can remotely run their accounting application and access their data.
Backup is a separate function.
Long-term archival is another function.
Therefore:
Cloud Hosting ≠ Unlimited Backup ≠ Permanent Archival
A server may be functioning perfectly while an old backup requested several months later is no longer available because it exceeded the backup system's configured retention period.
3. Understand Three Different Concepts
Customers should distinguish between the following.
A. Server Availability
This refers to whether the hosted server is available for users to connect and perform their work.
For example, users may connect using Remote Desktop and successfully run Tally Prime or BUSY.
B. Operational Backup
These are backup copies created periodically so that relatively recent data can potentially be restored after an incident.
For example, a provider may configure several backup jobs every day.
C. Long-Term Archival
This means retaining historical copies for extended periods such as:
- 30 days,
- 90 days,
- 6 months,
- 1 year,
- 3 years,
- 7 years, or
- another customer-defined period.
Long-term archival can require significantly more storage and a different backup strategy.
It should not automatically be assumed to be included with ordinary cloud hosting.
4. Example: Four Backups During a 24-Hour Day
Consider a hypothetical cloud accounting service where the backup system creates approximately four backup points every day.
If distributed evenly across 24 hours, this would mean approximately:
24 hours ÷ 4 backups = 6 hours
An illustrative schedule could therefore look like:
12:00 AM → Backup 1
6:00 AM → Backup 2
12:00 PM → Backup 3
6:00 PM → Backup 4
The actual schedule can be completely different depending upon the provider, technology and subscribed plan.
The important point is that backup frequency and backup retention are different things.
5. Backup Frequency Is Not Backup Retention
Suppose a cloud provider takes:
4 backups per day
and retains them for:
7 days
This does NOT mean that four backups per day will remain available permanently.
It means the backup system may maintain approximately:
4 × 7 = 28 restore points
during a rolling seven-day period, depending upon the actual backup architecture.
As new backups are created, older backups may expire, rotate or be overwritten.
This is commonly called a:
Rolling Backup Retention Policy
6. Example of a Seven-Day Rolling Backup
Consider the following simplified example.
A backup system retains data for seven days.
On 10 August, backups might be available approximately from:
4 August to 10 August
When 11 August backups are created, the oldest 4 August backup sets may begin expiring according to the configured retention policy.
After several weeks, a backup from 4 August may no longer exist.
This is normal behaviour for a backup system configured with seven-day retention.
It does not automatically mean that the backup system failed.
7. A Backup Can Work Correctly but an Old Version Can Still Be Unavailable
This distinction is extremely important.
Imagine that an employee discovers today that some accounting information is missing.
The employee says:
"We last remember seeing this information three months ago."
The company then asks its cloud provider:
"Please restore our backup from three months ago."
However, suppose the subscribed service only retains backups for seven days.
The requested three-month-old backup would already have expired long before the problem was reported.
This does not necessarily indicate a failure of the seven-day backup system.
It indicates a difference between the configured retention period and the historical recovery period now required by the customer.
8. Case Study: Data Discovered Missing Several Months Later
Consider a fictional accounting firm called ABC Accounts & Advisory.
The firm uses cloud-hosted accounting software.
It has five employees working on accounting data.
The cloud environment maintains four operational backups per day with seven-day retention.
One day, the firm discovers that records belonging to one company are incomplete.
After investigation, employees determine that the last known correct version may have existed several months earlier.
The firm requests the cloud provider to restore the database from that period.
However, the operational backup system only retains seven days of history.
Therefore, a backup from several months earlier is no longer available.
What is the lesson?
The key question is not simply:
"Were backups being taken?"
The more important questions are:
"How frequently were backups being taken?"
and
"How long were those backups retained?"
The backup system could have been operating correctly four times every day, but it still could not provide a backup from several months earlier if its retention period was only seven days.
9. Recovery Point Objective — RPO
Businesses using cloud accounting should understand the concept of Recovery Point Objective (RPO).
RPO essentially asks:
"How much recent work could the business afford to lose?"
For example, if backups occur every six hours, theoretically several hours of changes could fall between two backup points.
A business that cannot tolerate this may need a shorter RPO.
It might require:
- hourly backups,
- two-hourly backups,
- continuous replication,
- application-level backups, or
- another enhanced backup architecture.
The appropriate RPO depends upon how frequently the accounting data changes and how critical those changes are.
10. Recovery Time Objective — RTO
Another important concept is Recovery Time Objective (RTO).
RTO asks:
"How quickly does the business need its system or data restored after an incident?"
Some organisations can tolerate several hours.
Others may require much faster recovery.
RPO concerns how much data history can be lost.
RTO concerns how quickly operations need to resume.
Customers should discuss both requirements with their IT or cloud provider.
11. Retention Period Is Just as Important as Backup Frequency
Consider two backup plans.
Plan A
Backup frequency: Every 6 hours
Retention: 7 days
Plan B
Backup frequency: Once daily
Retention: 365 days
Plan A provides more frequent short-term recovery points.
Plan B provides fewer daily recovery points but much longer historical retention.
Neither is automatically "better."
They solve different business requirements.
A professional organisation may actually require both:
frequent operational backup + long-term archival backup
12. Customer Should Decide How Long Important Data Must Be Retained
A cloud provider cannot know every customer's business requirements automatically.
One organisation may need only seven days of operational recovery.
Another may require 30 days.
A Chartered Accountant, hospital, manufacturer, school, retailer or financial organisation may require substantially longer retention.
The customer should therefore determine:
How far back might we ever need to recover our accounting data?
Possible requirements could be:
- 7 days,
- 15 days,
- 30 days,
- 90 days,
- 180 days,
- 365 days,
- several financial years.
This decision should take into account business, audit, tax, compliance and operational requirements.
13. Multiple Users Introduce Another Important Risk
Cloud accounting systems commonly have multiple users.
For example:
- Accounts User 1
- Accounts User 2
- Accounts User 3
- Senior Accountant
- Manager
- Administrator
If several users have broad or full rights over accounting information, those users may be able to perform significant operations.
Depending on the application and permissions, users might:
- create data,
- modify data,
- delete data,
- alter vouchers,
- create companies,
- modify company information,
- import transactions,
- export information,
- move files,
- copy files,
- replace data,
- restore old data, or
- perform other application-level operations.
Therefore, backup is only one part of data protection.
User-access control is equally important.
14. Cloud Provider Cannot Supervise Every Accounting Transaction
A hosting provider normally manages infrastructure.
It does not sit beside every accountant and watch what the person does inside the accounting application.
If five employees have access to company data, the organisation itself should decide:
- who needs access,
- who needs full rights,
- who needs restricted rights,
- who can modify vouchers,
- who can delete information,
- who can export data,
- who can access the underlying data folder,
- and who should have administrative privileges.
This follows the principle of:
Least Privilege
Users should ideally receive only the permissions required for their work.
15. Do Not Give Full Rights to Everyone Unless Necessary
A common mistake is providing every cloud user with extensive access.
This creates operational and security risks.
For example, a junior accounts operator who only needs to enter sales and purchase vouchers may not necessarily require rights to:
- alter security settings,
- delete companies,
- manage other users,
- access system administration,
- manipulate data folders, or
- perform administrative operations.
Accounting-software permissions should therefore be reviewed independently from cloud-login permissions.
16. Who Deleted the Data?
When information goes missing, organisations often immediately ask:
"Who deleted it?"
Unfortunately, answering that question retrospectively may not always be easy.
Backup systems are not automatically forensic audit systems.
A backup system may know:
"Here is the data that existed at this backup time."
It may not necessarily know:
"Employee X deleted File Y at exactly 3:42:18 PM from this computer."
Detailed attribution may require additional technologies such as:
- application audit logs,
- Windows auditing,
- file-system auditing,
- Tally Edit Log,
- user-specific credentials,
- SIEM/logging systems,
- access logs,
- security monitoring, or
- specialised auditing solutions.
17. Backup and Audit Trail Are Not the Same
This is another common misunderstanding.
Backup answers:
"Can we recover an earlier copy?"
Audit trail answers:
"What changed, when did it change and possibly who changed it?"
These are different objectives.
A business requiring both should implement both.
18. Customer Should Maintain Independent Backups
Even when a cloud provider performs backups, maintaining an independent backup is a good risk-management practice for critical business information.
This follows a fundamental principle:
Do not depend upon only one copy of important data.
The customer could periodically export/download important data to:
- an office NAS,
- an encrypted external drive,
- another cloud storage platform,
- a dedicated cloud backup service,
- an off-site server, or
- another secure backup destination.
The exact method should be selected according to the sensitivity of the data.
19. Consider the 3-2-1 Backup Principle
A widely used backup strategy is the 3-2-1 principle.
Maintain:
3 copies of important data
on:
2 different types of storage
with:
1 copy maintained separately/off-site
For cloud accounting, an organisation might have:
Copy 1: Live production data on cloud server
Copy 2: Cloud provider's operational backup
Copy 3: Customer-controlled independent backup
This greatly reduces dependence on a single system.
20. An Independent Backup Gives the Customer More Control
Suppose a customer downloads a verified backup every week and retains it for one year.
Even if the cloud hosting provider maintains only seven days of operational backups, the customer now has its own historical archive.
Six months later, if old information is required, the organisation can refer to its independent archive.
This illustrates why backup retention should be driven by the value of the data rather than merely by the default configuration of the hosting package.
21. Backup Frequency Should Match Business Activity
There is no universal backup frequency suitable for every organisation.
Low transaction environment
A very small organisation might consider a daily independent backup sufficient.
Medium transaction environment
A company entering hundreds of vouchers daily may prefer several backup points per day.
High transaction environment
A highly active accounting environment may require:
- hourly backup,
- replication,
- snapshots,
- transaction-aware protection, or
- other advanced solutions.
The more frequently important data changes, the more carefully the backup interval should be evaluated.
22. Backup Retention Should Match Business Risk
Similarly, there is no universal retention period.
An organisation should ask:
"If we discover a problem 45 days later, will we need a 45-day-old version?"
If the answer is yes, seven-day retention is clearly insufficient for that organisation's requirements.
The solution is not simply to assume the standard backup will retain everything.
The solution is to implement a longer retention policy.
23. Consider a Dedicated Cloud Data Backup Service
Businesses with critical accounting information should consider a separate backup solution offering features such as:
- longer retention,
- configurable backup schedules,
- multiple historical versions,
- encryption,
- off-site storage,
- ransomware protection,
- immutable backups where appropriate,
- automated monitoring,
- backup verification,
- alerts,
- reporting, and
- controlled restoration.
Cloud hosting and cloud backup can therefore complement each other.
24. Example of a Better Backup Strategy
Consider a company operating Tally Prime on a hosted server.
It might design the following policy:
Operational backup:
4 times daily
Operational retention:
7 days
Independent daily backup:
1 backup every night
Daily backup retention:
30 days
Monthly archival backup:
12 months
Financial-year archive:
Several years according to business/legal requirements
This provides several layers of protection.
The exact periods should be determined according to the organisation's own requirements and applicable obligations.
25. Test Your Backups
A backup that has never been tested should not automatically be assumed to be recoverable.
Organisations should periodically verify:
- backup job completed successfully,
- backup file exists,
- file size appears reasonable,
- backup can be accessed,
- application data can be restored,
- restored data opens correctly,
- important companies are present,
- vouchers are visible, and
- expected accounting periods are available.
This is known as restore testing.
26. A Successful Backup Job Is Only Half the Job
Seeing:
Backup Successful
is reassuring, but the real objective is:
Successful Recovery
Backup management should therefore include:
Backup → Verify → Retain → Test → Restore
rather than merely:
Backup → Forget
27. Protect Backups From Ransomware
If the production data and all backups are continuously accessible from the same compromised account, ransomware or malicious activity may potentially affect both.
Important backups should therefore use suitable protection such as:
- separate credentials,
- restricted permissions,
- encryption,
- off-site storage,
- immutable storage where appropriate,
- multi-factor authentication,
- versioning, and
- isolated backup repositories.
28. What Customers Should Ask Before Buying Tally or BUSY Cloud Hosting
Before subscribing to any hosted accounting service, ask the provider:
- How frequently is my data backed up?
- How many backups are created every day?
- How long are backups retained?
- Is the retention rolling?
- What is the oldest backup normally available?
- Can I download my own backup?
- Is restoration chargeable?
- How long does restoration normally take?
- Are backups stored on the same server or separately?
- Is off-site backup included?
- Is long-term retention available?
- Is ransomware protection included?
- Are backups encrypted?
- Can individual files be restored?
- Can the complete accounting database be restored?
- Are snapshots used?
- Are user activities logged?
- How long are logs retained?
- Can different users receive different permissions?
- What happens to my data after service termination?
These questions should preferably be clarified before the service starts.
29. What Cloud Providers Should Explain Clearly
Cloud service providers can also reduce misunderstandings by clearly documenting:
- backup frequency,
- backup retention,
- recovery limitations,
- customer responsibilities,
- provider responsibilities,
- restoration process,
- extended-backup options,
- user-access responsibilities,
- termination/data-export process, and
- difference between hosting, backup and archival.
A simple statement such as:
"Four operational backups per day with seven-day rolling retention"
is much clearer than simply saying:
"Regular Backup Included."
30. The Most Important Lesson
The safest approach is shared responsibility.
Cloud/Hosting Provider
Depending on the subscribed service, the provider may be responsible for areas such as:
- hosting infrastructure,
- server availability,
- configured operational backups,
- technical maintenance,
- remote access infrastructure, and
- technical support.
Customer
The customer should take responsibility for:
- determining how valuable the data is,
- controlling authorised users,
- protecting credentials,
- deciding required backup frequency,
- deciding required historical retention,
- maintaining additional independent backups where necessary,
- reviewing accounting-user permissions,
- promptly reporting problems, and
- periodically verifying important data.
Cloud does not eliminate the customer's responsibility for data governance.
31. Practical Golden Rule
Every organisation using cloud accounting should be able to answer three questions immediately:
Question 1
How frequently is my accounting data backed up?
Question 2
How many days/months of historical backups can I recover?
Question 3
Where is my independent backup if the provider's retention period has already expired?
If management cannot answer these three questions, the organisation should review its backup policy.
32. Final Conclusion
Moving Tally Prime, BUSY or another accounting application to the cloud can significantly improve accessibility, collaboration and infrastructure management.
But cloud hosting should never create a false sense that business data will automatically remain recoverable forever.
A provider may take multiple backups every day while retaining them for only a limited number of days.
That system may work exactly as configured and still be unable to recover information requested several months later.
The correct approach is therefore:
Know your backup frequency.
Know your retention period.
Control your authorised users.
Maintain an independent copy of critical information.
Purchase longer retention when your business requires it.
Test recovery periodically.
Most importantly:
Your data is one of your organisation's most valuable assets. Cloud hosting gives you infrastructure; a proper backup and retention policy gives you resilience.
Frequently Asked Questions (FAQ)
1. Is my accounting data owned by the cloud provider?
Normally, the customer's business/accounting information remains the customer's data. Customers should confirm data-ownership provisions in their particular service agreement.
2. Does putting Tally on cloud automatically create permanent backups?
No. Cloud hosting and permanent archival are different concepts.
3. If four backups are taken daily, does that mean all backups remain forever?
No. Backup frequency and retention are separate settings.
4. What does four backups per day mean?
If evenly distributed, four backups in 24 hours would represent approximately one backup every six hours. Actual schedules vary by provider.
5. What is seven-day retention?
It generally means backup versions are maintained within an approximately seven-day rolling window according to the backup system's configuration.
6. Can I ask for a six-month-old backup if retention is seven days?
You can ask, but the backup may no longer exist unless a separate long-term copy or archival system was maintained.
7. Who decides how long my backups should be retained?
The organisation should determine its business requirement and select/configure a service capable of meeting it.
8. Can I keep my own backup even when using cloud Tally?
Where the service/application allows it, maintaining an independent customer-controlled backup is a sensible risk-management measure.
9. Should I take a backup every hour?
It depends upon how frequently your data changes and how much work your organisation can afford to lose.
10. What is RPO?
Recovery Point Objective describes how much recent data loss an organisation can tolerate.
11. What is RTO?
Recovery Time Objective describes how quickly systems/data need to be restored following an incident.
12. Are RPO and backup retention the same?
No. RPO primarily concerns recovery-point frequency, whereas retention concerns how long historical recovery points remain available.
13. Can employees accidentally modify accounting data?
Depending on their application permissions and access rights, authorised users may be able to modify significant accounting information.
14. Should every cloud user receive full rights?
Generally, no. Follow the least-privilege principle wherever practical.
15. Is a backup system the same as an audit system?
No. Backup is primarily for recovery; auditing is primarily for tracking activities and changes.
16. Can a backup tell exactly which employee deleted something?
Not necessarily. Detailed attribution normally requires suitable audit logging.
17. Should we use separate usernames for employees?
Yes, individual accounts generally improve access control and accountability.
18. Should we maintain an independent backup?
For critical business data, an independent backup is generally a strong risk-management practice.
19. What is the 3-2-1 backup rule?
Maintain three copies of important data, across two types/locations of storage, with at least one copy separately/off-site.
20. What happens if we discover missing information after several months?
Recovery depends upon whether a valid historical backup from that period still exists.
21. Does a missing old backup prove the backup system failed?
Not necessarily. The requested backup may simply fall outside the configured retention period.
22. Should backup retention be written in the service agreement?
Yes. Clear documentation helps both customers and providers understand the service scope.
23. What is rolling retention?
New backups are continually created while older backups expire according to the configured retention period.
24. Should backups be tested?
Yes. Periodic restore testing is an important part of backup management.
25. Is "backup successful" enough?
No. Ultimately, a backup is valuable only if usable data can be successfully recovered when required.
26. Can I retain backups for several years?
Yes, with suitable storage, archival software and a retention policy designed for that requirement.
27. Will longer retention cost more?
It often can because longer retention generally requires additional storage and backup resources. Pricing depends on the provider and architecture.
28. Should accounting firms have longer retention?
Organisations handling important financial records should assess their professional, contractual, operational and applicable regulatory requirements before deciding retention periods.
29. Can ransomware affect backups?
Yes, particularly if backup repositories are inadequately isolated or protected.
30. What is the best backup policy for Tally or BUSY?
There is no universal policy. It should reflect transaction volume, acceptable data loss, required recovery speed, historical retention requirements, security risks and applicable compliance obligations.
#TallyCloud #TallyOnCloud #TallyPrime #TallyBackup #TallyData #BusyAccounting #BusyCloud #CloudAccounting #CloudBackup #DataBackup #DataRecovery #DataProtection #DataSecurity #BackupPolicy #BackupRetention #DataRetention #SevenDayBackup #RollingBackup #CloudServer #CloudHosting #AccountingSoftware #AccountingData #FinancialData #BusinessData #DataOwnership #CustomerResponsibility #CloudSecurity #BackupStrategy #BackupBestPractices #DisasterRecovery #BusinessContinuity #RPO #RTO #321Backup #OffsiteBackup #IndependentBackup #RansomwareProtection #CyberSecurity #TallySecurity #TallyDataBackup #BusyDataBackup #AccountingBackup #CloudDataProtection #DataManagement #AccessControl #UserRights #AuditTrail #RestoreTesting #BackupAwareness #ITSecurity
Was this guide useful?
Your answer helps us keep BISONKB accurate and practical.