How do I back up my business data against ransomware in India?

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

What does ransomware-proof backup actually mean?

It means a copy that the attacker's credentials cannot reach or destroy. A backup sitting on a file share, or in a cloud folder synchronised by the same domain account, fails that test, because that is exactly what the attacker will encrypt or delete first. The three properties to look for are isolation, immutability and offline status. Isolation means the backup is administered by a different account from production, ideally in a different cloud account with its own credentials. Immutability means the storage denies modification or deletion for a retention window, using object lock or write-once policies, so even a privileged attacker cannot erase it. Offline means a copy is physically separate, which is still worthwhile for the crown-jewel data, such as accounting records, payroll and customer master data, that you would be least able to reconstruct.

What should an Indian small business actually implement?

A three-tier arrangement that a small team can maintain. Tier one, a nightly snapshot of the file server, the accounting system and the customer database, sent to a separate cloud account with versioning locked and 30-day retention, which gives you a fast recovery point. Tier two, a weekly copy to an immutable or write-once bucket with 90 to 365 day retention, which survives a determined attacker who has a month of patience. Tier three, a monthly encrypted offline disk or drive, stored at a different physical location, holding the crown-jewel data only. Set the retention on each tier explicitly, and keep a printed copy of the recovery credentials somewhere physical and secure, because the admin for the backup account is one of the first things an attacker changes.

How do I test that the backup actually works?

Test on a schedule, not in the crisis. Once a quarter, restore one file, one folder and one database backup into a clean environment, and check the contents, the row counts and the hashes against the source. Record the date, the duration and the result in a log. Also test the full procedure, not just the data: the person who holds the credentials, the tool used, the order of steps, and how long it takes from a cold start to a working system, because the number that matters in a crisis is the hours to restore, not the hours to copy. A small business that has restored once under time pressure will be dramatically faster in a real incident than one that has only ever verified that a job succeeded.

What about cloud sync and shared drives?

Treat them as a risk, not a backup. Dropbox-style sync clients, OneDrive and Google Drive business sync replicate the attack, and when the file server is encrypted the sync client may push the encrypted or deleted state everywhere. The controls are to stop sync clients from running on servers, to exclude synced folders from the ransomware execution path, and to review the sync account's own credentials and MFA. Where a business genuinely needs shared access, keep the shared area on a segmented segment with restricted write access, and make sure the ransomware execution path cannot reach it. Separately, if you use a managed backup product, confirm in writing whether the product's own repository is immutable and whether the vendor requires MFA on the agent.

What are the frequently asked questions?