Backup & Disaster Recovery Best Practices

Why Backups Are Non-Negotiable

There are two kinds of businesses in Gwalior: those that have lost data, and those that will. The threats are well-documented. Ransomware now targets Indian SMBs aggressively — the average ransom demand in India has climbed sharply, and the Indian Computer Emergency Response Team (CERT-In) reported a steady rise in incidents through 2024. Beyond ransomware, hardware failure (every drive has a finite lifespan), accidental deletion (a misplaced SQL DELETE statement, a removed mailbox), insider actions, fire, flood, and theft all threaten business data.

What separates businesses that survive these events from those that close is not luck — it is backups. Specifically, backups that are recent, complete, immutable, off-site, and tested. Most Gwalior SMBs we audit have something they call a “backup” — usually an external USB drive plugged into the server — but on closer inspection it is none of the above. It is one copy (not multiple), on the same physical media type as the source, sitting next to the server (not off-site), never verified (not tested), and often writable by the same account that runs the production system (not immutable). When ransomware hits, that “backup” is encrypted along with everything else.

The cost of getting backups right is small — typically ₹2,000–₹8,000 per month for a 50-person business. The cost of getting them wrong is, in many cases, the business itself. Insurance doesn’t rebuild customer data; only a working backup does.

The 3-2-1 Backup Rule

The 3-2-1 rule, codified by photographer Peter Krogh in the 2000s and adopted across the IT industry, remains the gold-standard baseline for any backup strategy. It is simple, memorable and surprisingly under-applied:

• 3 copies of your data — the production copy plus two backups.
• 2 different media types — e.g., local disk plus cloud, or disk plus tape. The point is that a single failure mode (a bad batch of disks, a corrupted filesystem) cannot take down both backups at once.
• 1 copy stored off-site — ideally in a different city or region, so a fire, flood or break-in at your office cannot destroy everything.

For a Gwalior business with on-prem servers, a typical 3-2-1-1-0 implementation looks like this: production data on the server (copy 1), nightly backup to a local NAS or external drive (copy 2, media 1), continuous replication to cloud object storage like AWS S3 with Object Lock or Azure Blob with immutable containers (copy 3, media 2, off-site, immutable). Restore tests run automatically each quarter and report any errors.

On-Premise vs Cloud Backups

Both on-premise and cloud backups have a role in a robust strategy. They are complements, not substitutes:

• On-premise (NAS, external drive, tape) — fast restores (gigabytes per minute over a LAN), no recurring cloud egress costs, full physical control. Limitations: vulnerable to the same physical threats (fire, theft) as the source, and the same account compromise if not isolated.
• Cloud (AWS S3, Azure Blob, Backblaze B2, Google Cloud Storage) — inherently off-site, geo-redundant, supports immutability (Object Lock, WORM), scales without capex. Limitations: restore speed is bounded by your internet bandwidth, and egress charges can add up for large restores.

For most SMBs, the right architecture is hybrid: a local on-premise backup for fast day-to-day restores (accidental deletion, single-file recovery), and a cloud backup for disaster recovery (server loss, ransomware, site failure). Pure on-premise without cloud is a 2010 strategy; pure cloud without on-premise makes small restores painfully slow. Both have their place.

Pick cloud targets with an Indian region for low-latency uploads and data residency. AWS ap-south-1 (Mumbai) and Azure Central India (Pune) are the natural choices for Gwalior businesses; Backblaze B2 does not have an Indian region but is competitive for cold archive. See our article on AWS vs Azure in 2025 for more on platform choice.

Testing Your Backups

An untested backup is not a backup — it is a hope. The single most common point of failure in DR is restoring from a backup that has been silently corrupted for months, only to discover it during the crisis. The only way to know a backup works is to restore from it.

“An untested backup is just a hypothesis. The first time you try to restore should never be during a disaster.”

A credible testing cadence for an SMB:

• Weekly: automated verification that the backup job completed successfully, with a checksum comparison of source and backup. Alerts on any failure.
• Monthly: a single-file or single-mailbox restore to a test location, with a human confirming the file opens correctly.
• Quarterly: a full server restore to an isolated test environment, with key applications launched and a sample transaction processed end-to-end.
• Annually: a full DR drill — restore everything, switch users to the recovered environment, and time how long it takes.

Document every test in a log: date, what was tested, who tested it, what was found, what was fixed. This log is also your evidence for auditors, insurers and regulators (including under the DPDP Act’s security-safeguards obligation — see our DPDP compliance primer).

Disaster Recovery Planning

Backups get your data back; disaster recovery gets your business back. A DR plan is the documented, rehearsed procedure for restoring operations after a defined disruption. For most Gwalior SMBs it does not need to be a 200-page document — a 5–10 page plan that covers the essentials is enough.

The minimum content of a credible DR plan:

• Inventory of critical systems ranked by recovery priority — what do we restore first, second, third?
• Recovery procedures for each system — step-by-step, with screenshots where helpful, written so a non-expert can follow them under stress.
• Communication tree — who declares a disaster, who notifies staff, customers, vendors, regulators; with phone numbers and alternate contact paths.
• Vendor and partner contacts — your IT support company, cloud provider, ISP, hardware vendor, cyber-insurer.
• Alternative working arrangements — if the office is inaccessible, where do staff work from? What laptops, internet, VPN access do they need?
• Insurance and financial — cyber-insurance policy number, claims process, cash reserves to cover 2–4 weeks of disruption.

Store the DR plan somewhere accessible even if your primary systems are down — typically a printed copy at the office, a PDF in a personal cloud account of the owner, and a copy with your IT partner. A DR plan that lives only on the server you are trying to recover is not a plan.

RTO and RPO Explained

Two numbers anchor every DR discussion: RTO and RPO. Knowing them — and committing to specific values — turns a vague “we’ll recover” into a measurable commitment.

• RPO (Recovery Point Objective) — the maximum amount of data you are willing to lose, measured in time. An RPO of 4 hours means you can lose up to 4 hours of transactions; backups must therefore run at least every 4 hours. An RPO of 0 means zero data loss, which requires synchronous replication.
• RTO (Recovery Time Objective) — the maximum time to restore operations after a disaster. An RTO of 8 hours means your business commits to being back online within 8 hours of the disruption. Tighter RTOs require faster recovery infrastructure — typically warm standby systems in the cloud.

Different systems need different RTO/RPO. Your financial and customer data deserves a tight RPO (15 minutes to 1 hour) and a tight RTO (2–4 hours). Internal file shares can tolerate a daily backup (RPO 24 hours) and a 1–2 day RTO. Setting these values deliberately lets you spend your DR budget where it matters — not over-protecting low-value systems or under-protecting high-value ones.

Common Backup Mistakes

The mistakes we see most often in Gwalior SMBs, and how to avoid them:

• Single-copy backups on the same device. An external drive plugged into the server is one copy on one media type. When ransomware encrypts the server, it encrypts the drive too. Fix: implement 3-2-1.
• Backups in the same admin account as production. If a single admin account controls both, a compromised account deletes both. Fix: use a separate backup-only account with distinct credentials and multi-factor authentication.
• No immutability. A backup that anyone (or any malware running as anyone) can delete is not a defence against ransomware. Fix: enable Object Lock / WORM on cloud backups, or use offline tape.
• Never tested. Untested backups fail in ways you cannot predict — corrupted files, missing dependencies, expired credentials. Fix: scheduled restore tests, quarterly drills.
• Backing up the wrong things. Many businesses back up the file server but forget the Microsoft 365 mailboxes, the database, the configuration of the firewall, or the licences list. Fix: maintain a backup coverage matrix and review it every six months.
• Retention too short. A 7-day retention means you cannot recover a file deleted two weeks ago — and ransomware often lurks undetected for 30+ days before activation. Fix: keep at least 30 days of daily backups, plus monthly archives for 6–12 months.
• No off-site copy. A fire, flood, or theft at your Aditya Puram office destroys everything in the same room. Fix: a cloud copy or a physical off-site rotation.

Backups and disaster recovery are not glamorous. They are insurance — invisible when everything goes right, priceless when something goes wrong. The businesses that invest a few thousand rupees a month and a quarterly test in this discipline sleep well at night; the ones that don’t, eventually find out why they should have.