Immutable Backup Solutions in India: What Survives Ransomware

The backup you can't delete

A 180-person Bengaluru engineering firm lost its primary file server to ransomware in March 2026. They had backups. Veeam, running nightly to a Synology RS3621xs+, plus a second copy on a QNAP TS-873A. The attacker got domain admin through a phishing payload on a marketing laptop on a Tuesday. By Wednesday morning every backup job had been modified or deleted, the Veeam service account credentials were rotated by the attacker, and the QNAP was wiped because it was joined to the same AD. The company paid ₹38 lakh in recovery costs — data restoration, forensic investigation, overtime, and two weeks of lost billable work — because their backups were not immutable.

The backups were present. They were not survivable.

Immutable backups solve a very specific problem: making a copy of your data that even a domain admin cannot delete, encrypt, or corrupt before the retention period expires. It's not magic. It's not a product SKU you buy and forget. It's a configuration contract — object lock, WORM, or air-gapped media — and most Indian SMEs we audit have it either switched off, misconfigured, or switched on but untested.

If you manage IT for a 20-500 person company in India and you're evaluating immutable backup solutions, this article is for you. We'll cover what object lock and WORM actually do, what genuinely survives a domain-admin compromise, real 2026 pricing in rupees, and how to test the claim without staging a fake ransomware incident.

For the storage architecture side, our storage solutions practice handles the hardware and array configuration that immutable targets sit on.

What "immutable" actually means — and what it doesn't

Immutable backup is a copy of your data that cannot be modified or deleted by any user, including administrators, for a defined retention period. Three mainstream implementations exist today.

1. S3 Object Lock (Compliance and Governance modes)

Object Lock is an S3 API feature supported by AWS S3, Wasabi, Backblaze B2, MinIO, Cloudian HyperStore, Scality RING, and Dell ECS. When you write an object with a retention date and legal hold, the storage system refuses any delete or overwrite to that object until the date passes. In Compliance mode, not even the root account can remove the lock. In Governance mode, a user with s3:BypassGovernanceRetention can override — which is why Governance mode is almost useless against an attacker who has elevated privileges.

Compliance mode is what you want for ransomware defence. Governance mode is for test environments and internal policies.

2. WORM on NAS and tape

WORM (Write Once Read Many) has existed since the optical and tape era. Modern NAS appliances — Synology, QNAP, TrueNAS, Dell PowerScale — implement WORM at the filesystem or share level with a retention period. Tape libraries (LTO-8, LTO-9) are inherently offline once ejected, making them the original air-gap.

WORM on NAS is convenient but has a caveat: the WORM setting itself has to be enabled and protected. If an attacker has admin on the NAS, they can often disable WORM before the data is written, then write malware-laden "backups" that overwrite clean ones. Synology's implementation (Snapshot Replication with immutable snapshots) and QNAP's WORM share are reasonable, but neither survives a compromised NAS admin account the way S3 Object Lock Compliance mode survives a compromised AWS root.

3. Air-gapped copies

An air-gapped copy is physically or logically disconnected from your production network at all times except during the backup window. Examples: LTO tape ejected daily, a NAS powered off between jobs, a portable drive that lives in a safe, or a logically isolated backup VLAN with one-way firewall rules and no domain trust.

Air-gap is the strongest control. It's also the most operationally painful. Test restores are slower. Backup windows are rigid. Staff forget to plug things in.

The combination that actually works for most Indian SMEs: primary backup to a local hardened repository (immutable), a secondary immutable copy to an S3-compatible cloud with Object Lock Compliance enabled, and optionally a tape or offline disk for the truly paranoid or regulated workloads.

The threat model you are actually defending against

The industry keeps talking about "ransomware" as if it's a single threat. It isn't. You're defending against at least four distinct attack paths.

Attack path 1: Domain admin compromise

An attacker gets domain admin (via phishing, unpatched VPN, or helpdesk social engineering). They have full read/write to every Windows server, every NAS joined to the domain, every backup share with AD-based permissions. This is the most common path we see in Indian SMEs. Your defence cannot be AD permissions. It must be an external immutability control — Object Lock, WORM, or an air-gap — that has no trust relationship with AD.

Attack path 2: Backup infrastructure compromise

Attackers increasingly target Veeam, Commvault, Rubrik, and Cohesity management consoles directly using CVEs and default credentials. In 2024 and 2025, Veeam patched multiple RCE vulnerabilities in Backup & Replication. If your Veeam server is reachable from the internet, you have a problem. Immutable storage that the Veeam server writes to is fine — but only if the Veeam server cannot delete the immutability. With S3 Object Lock Compliance, it cannot.

Attack path 3: Insider threat

A disgruntled employee with backup admin rights deletes the backups after copying data out. WORM and Compliance mode neutralise this too, but they also mean you can't help when a legitimate admin needs to free up space. Plan quotas accordingly.

Attack path 4: Ransomware that encrypts backups in place

Some ransomware families now scan for backup repositories specifically. If the repo is a NAS share and the attacker hits it with an encryptor, the files are encrypted — immutability does not stop encryption on write. It stops deletion. This is why the immutable copy must be written to a WORM-protected share with unique object keys, or be on a storage system that only appends. Veeam's hardened repository (Linux XFS with immutability flag) is specifically designed to defeat this.

Object Lock vs WORM vs air-gap: which survives what

The table assumes object lock is applied correctly to every object on write. A common misconfiguration is applying immutability to the folder or bucket but not the individual objects, leaving them mutable via API.

Real 2026 pricing for Indian SMEs

Nobody in India will tell you what immutable backup actually costs. Here are honest 2026 figures, based on deployments we've done across Bengaluru, Pune, Chennai, and Hyderabad.

Notes on these numbers:

• Cloud storage egress and API costs are the silent killer. AWS S3 Intelligent-Tiering at ₹2.3-4.1 per GB per month in ap-south-1 (Mumbai), plus PUT/GET requests. A 15 TB repository restored once a year costs ₹40,000-70,000 in egress alone.
• Wasabi is ₹520-660 per TB per month with no egress fees — attractive if you restore frequently. Wasabi has an India-based region as of 2025, so latency and data residency are no longer blockers.
• Backblaze B2 is roughly half Wasabi's price but with limited Indian presence; data sits in the US or EU. Fine for non-regulated workloads if you're okay with cross-border transfer under DPDP rules.
• Dell ECS, Cloudian, or Scality on-prem object storage costs ₹18-40 lakh in capex plus 3-year support. Only sensible above 100 TB.

Anyone quoting you "immutable backup starting at ₹5,000/month" is not selling immutability. They're selling cloud backup with a snapshot retention policy.

Our managed storage services are priced as a monthly line item rather than capex, which suits SMEs that don't want to own the hardware.

The 3-2-1-1-0 rule, and why 3-2-1 is no longer enough

You've heard of 3-2-1: three copies, two media types, one offsite. It's insufficient against modern ransomware because it doesn't say anything about immutability.

The updated rule is 3-2-1-1-0: three copies, two media types, one offsite, one immutable or air-gapped, zero errors on restore verification.

Let's break down what "zero errors" means in practice. We've seen backup jobs report success for months while individual files inside the job were unreadable. Veeam's SureBackup feature, or a monthly test restore of a sample of files, is the only way to know. If you're not doing test restores, your backups are theoretical.

The "1 immutable" component is where most Indian SMEs fall down. They have the offsite copy. It's on a cloud bucket. It is completely mutable. A domain admin with cached S3 credentials can wipe it in four minutes.

Products we actually deploy — and where each one falls short

Veeam Backup & Replication v12.2

Veeam is the default for most Bangalore SMEs running VMware or Hyper-V. The Linux hardened repository — a Linux server with XFS formatted with the reflink and immutability flag — is the most cost-effective way to get fast, immutable on-prem backup. A Supermicro or Dell R360 with 4× 8TB SAS drives in RAID10 gives you a 15 TB usable hardened repo for around ₹2.8-3.6 lakh.

Caveats: Veeam's Linux hardened repo immutability is set per-job (typically 14-30 days). It's not the same as S3 Object Lock Compliance — a sophisticated attacker against the Linux host itself could, in theory, gain root and remove the immutability flag before retention expires. Veeam has hardened the OS quite thoroughly as of v12.2 but this is not zero-trust.

Synology Active Backup for Business + immutable snapshots

Synology's DSM 7.2 supports immutable snapshots on Btrfs volumes. Snapshot Lock is enabled per snapshot and cannot be deleted through DSM until the retention window expires. Cost: a DS1823xs+ with 4× 16TB drives is roughly ₹3.2-4.1 lakh (2026 pricing), giving ~32 TB usable.

Caveats: Snapshot Lock is defeated by physical access. If someone walks out with the NAS, immutability is moot. Also, if the NAS is domain-joined, an attacker with root via AD can often disable the lock settings for future snapshots. Not a primary defence, but a good secondary layer.

Wasabi + Veeam SOBR (Scale-Out Backup Repository)

Wasabi Cloud with Object Lock Compliance enabled, fronted by a Veeam SOBR, gives you a clean immutable offsite copy. Veeam v12.2 supports S3-compatible object lock natively. Cost: ~₹580 per TB per month, no egress charges, plus the Veeam licence.

Caveats: Wasabi's Object Lock Compliance mode is genuinely immutable — you literally cannot delete the bucket before retention expires, even if you want to. This bites when you decommission equipment and want to close the account. Plan 12-month retention carefully. Legal hold should be applied sparingly.

Rubrik, Cohesity, Dell PowerProtect Data Manager

These are the enterprise tier — appliance-based backup with immutability baked in, plus ransomware detection and anomaly alerts. Entry cost is ₹18-35 lakh for the smallest appliance. If you're under 300 users, this is overkill. Rubrik is excellent; it's also ₹22 lakh before you restore a single byte.

Tape (LTO-9, Dell ML3, Quantum Scalar i3)

Still the cheapest per terabyte at rest (₹1,500-2,200 per TB for LTO-9 media, one-time). Tape is inherently offline when ejected from the library. The operational overhead is real — a tape rotation schedule, an offsite courier, and someone to load tapes for weekly restores. For companies under 100 users, tape is usually a waste of effort. For companies with regulatory retention (RBI's 8-year mandates for financial records, for example), tape remains the cost-effective cold store.

A domain-admin compromise, retold properly

Let me give you the details that matter, because the abstract version doesn't help you test your own environment.

The Bengaluru engineering firm I mentioned at the top — let's call them Company A — ran this stack in early 2026:

• Windows Server 2019 domain, single DC (already a problem)
• 180 endpoints, CrowdStrike Falcon on 140 of them (40 were contractor laptops with no EDR)
• Veeam Backup & Replication v12.1 on a Windows Server 2022 VM
• Veeam target: a Synology RS3621xs+ on the same VLAN, joined to the domain, with a service account that had Domain Admin (they'd granted it during setup and never removed it)
• Second copy: QNAP TS-873A, also domain-joined, credentials in the same password manager
• No cloud copy. No tape. No immutability.

March 4, a contractor laptop opened a malicious PDF. By March 6, the attacker had moved laterally to the DC using cached credentials, created a new domain admin, and started encrypting servers. They also enumerated backup repositories. The Veeam console was accessible from a helpdesk workstation because it used the same admin password as the DC. The Synology was wiped. The QNAP was wiped. The attacker left a ransom note asking for ₹22 lakh in BTC.

Company A called us on March 6 at 6:40 pm. By then:

• Primary file server encrypted
• Exchange mailbox database corrupted
• Veeam config database corrupted
• Both NAS targets formatted

We restored from a third copy the client had forgotten about — a monthly USB drive they had physically given to their CA on February 27, four workdays of data loss — and rebuilt from there. Total recovery cost, including forensic firm (₹8.5 lakh), overtime, lost productivity, and hardware replacement: ₹38 lakh. No ransom paid.

If Company A had done three things differently, the figure would have been under ₹4 lakh.

1. S3 Object Lock Compliance on a cloud copy. A Wasabi or AWS bucket holding the nightly Veeam jobs for 12 months of retention would have survived everything. The domain admin has no credentials to Wasabi. The Veeam console credentials do not grant S3 delete rights under Compliance mode.
2. Separate credentials for the backup service account. Removing Domain Admin from the Veeam service account would not have stopped the wipe entirely, but it would have slowed lateral movement and prevented the DC compromise from automatically escalating.
3. Non-domain-joined target. Synology and QNAP devices joined to AD are convenient and dangerous. Local NAS admin credentials, not shared with AD, plus a firewall rule that allows only the Veeam server's IP to reach the NAS, would have bought hours.

The fix we implemented cost ₹5.8 lakh in capex and ₹24,000/month for immutable cloud storage at 6 TB. That's less than one month's worth of what Company A lost.

How to test that your immutability claim is true

This is where most IT teams skip the work. They enable object lock, pat themselves on the back, and never verify.

You need to test immutability with the same tools an attacker would use. Here's the procedure.

Test 1: Attempt delete as a domain admin

Log in as an AD admin (not the S3 admin). From a workstation, use AWS CLI or Cyberduck with credentials from the same password manager the admin team uses. Try to delete a specific backup object. If the system allows deletion, your object lock is configured wrong. If it returns an access-denied error, you're correct — but now try it from the backup server itself, which may have different credentials.

Test 2: Attempt delete using the backup application's own credentials

Log in to Veeam or your backup tool with admin rights, find a specific restore point, try to delete it. If the backup tool's credentials are correctly scoped, this should fail with an immutability error. If it succeeds, your backup tool has bypass permissions — a serious flaw.

Test 3: Attempt retention reduction

The API for reducing retention on a locked object should be refused. Almost every S3-compatible system allows you to extend retention but not shorten it under Compliance mode. Verify this. Some non-AWS implementations have bugs here.

Test 4: Air-gap verification

For a tape or offline disk, verify the connection is actually broken outside the backup window. Ping the device when it's supposed to be offline. Check firewall rules. Confirm the backup software cannot reach it during business hours.

Test 5: Restore verification

Quarterly, restore three random files from a date at least 90 days old. Confirm the files open correctly and the data matches the source system (compare hashes if possible). This is where the "0" in 3-2-1-1-0 comes from.

Test 6: Red team it

Once a year, hire a penetration tester to specifically attack your backup infrastructure. Give them domain admin as a starting condition. Ask them to delete backups. If they succeed, you have work to do.

We run these tests as part of our standard SLA for clients on our storage and backup services. The first test alone catches misconfiguration in about 60% of environments we audit.

Common misconfigurations we find in India

After auditing hundreds of backup environments across Indian SMEs, these are the recurring problems.

Object lock applied at the bucket level, not object level

Some systems let you enable object lock on a bucket, but individual objects written afterwards are only locked if the write request includes the retention header. Veeam does this correctly. Custom scripts often don't. Verify by checking that every object in your bucket has a RetainUntilDate in its metadata.

Governance mode mistaken for Compliance mode

Governance mode can be overridden by any principal with s3:BypassGovernanceRetention. In many deployments, the backup admin has this permission — defeating the purpose. Compliance mode cannot be bypassed by anyone. If you're defending against ransomware, use Compliance.

Immutability set shorter than ransomware dwell time

Modern ransomware dwells 10-21 days on average before encryption. If your immutable retention is 7 days, the attacker waits it out. Set retention to 30 days minimum for on-prem, 12 months for cloud.

Cloud bucket reachable with the same credentials as production

If your backup admin credentials to AWS are the same as your dev-team credentials, the attacker who popped a developer laptop has your backups. Use separate AWS accounts, or better, separate providers, with different credentials for the backup path.

Air-gap tape library that's actually on the network

We've seen "air-gapped" Quantum libraries that are actually connected to a backup server 24×7. Ejecting tapes daily is real air-gap. A library on the LAN with a firewall rule that's supposed to block outside the backup window is not — because firewall rules get changed, and the backup software is already trusted.

No immutability on Veeam configuration database

Attackers can restore your backup catalog if they get the Veeam config database. Enable Veeam's configuration backup and store those configs immutably too — otherwise you restore the data but cannot find the files in the catalog.

DPDP, CERT-In, and what Indian regulators actually require

A question we get regularly: does Indian regulation force immutable backups?

DPDP Act 2023

The Digital Personal Data Protection Act requires reasonable security safeguards. It does not mandate immutable backups by name, but the rules notified in early 2025 place a heavy emphasis on breach notification and on preventing unauthorised access. If a ransomware event compromises personal data and you cannot demonstrate that you took reasonable steps — like immutable backups — the penalty exposure under DPDP can reach ₹250 crore for a significant breach. Reasonable steps are the operative phrase. Immutable backup is now the standard of care.

CERT-In directions (April 2022, still in force 2026)

CERT-In requires reporting of specified cyber incidents within six hours of discovery, and maintenance of logs for 180 days within India. For regulated entities (financial services, telecom, government-linked), backups of critical logs and systems must be maintained — but CERT-In does not specifically mandate immutability. What it does mandate is that incident reports include "recovery steps taken," which is far easier to write if you can say backups were untouched.

RBI cybersecurity framework

RBI's Cyber Security Framework for banks (and, via extension, many NBFCs) requires offline backups for critical systems. The language goes back to 2016 but was reinforced in 2024 with specific mention of ransomware resilience. This effectively mandates air-gapped or immutable backups for regulated financial entities.

IRDAI

Similar approach for insurers. Requires periodic testing of backups and maintenance of an offsite copy with controlled access, which in practice means immutable or air-gapped.

If you're a non-regulated SME, the regulatory floor is low. The commercial reality is higher. Immutable backup is now what a competent IT team deploys. It's what your cyber-insurance underwriter will ask about. It's what your customer's vendor security questionnaire will query. Missing it will cost you on more than one front.

On-premise, cloud, or hybrid: choosing the right model for India

A 2026 reality check: latency to Indian cloud regions is fine (10-30 ms to AWS Mumbai or Wasabi India), so cloud immutable repositories are viable for most SMEs. But there are Indian constraints worth knowing.

Bangalore realities:

• ISP lead times: Airtel and Jio enterprise fibre at 100 Mbps symmetric typically take 7-21 days to provision in most Bangalore business parks. Tata Tele and ACT are similar. If you're relying on cloud-only immutable backups, you need redundant ISPs or a 4G/5G failover — otherwise a single ISP outage prevents nightly backup completion.
• Power: Grid reliability in most Bangalore business districts is fine (99%+ uptime), but a monthly power event is not unusual. Your immutable on-prem target should be on UPS with graceful shutdown, not just a surge protector. Brownouts corrupting a Btrfs filesystem in the middle of a snapshot write is a real failure we've seen twice in 2025.
• Monsoon: Water ingress in basement racks and cabling damage are genuine risks June through October. If your backup NAS is in a basement closet, move it. We've replaced three NAS units in Bangalore after water damage in the last two monsoons.
• GST: Indian cloud providers charge 18% GST. Wasabi's India offering bills in INR with GST. AWS Mumbai bills in USD but GST-registered customers can claim input credit. Factor this into TCO comparisons; an 18% line item is not trivial at ₹50,000/month.

What immutable backup costs — the honest TCO view over 3 years

For a 50-user Bangalore SME with 4 TB of live data, growing 20% per year, here's the three-year TCO comparison of three real-world architectures.

The local-NAS-only path is the cheapest and also the one that fails the threat model. It's what most Indian SMEs have today. The 3-year gap between "no immutability" and "hybrid immutability" is ₹8.6 lakh. A single ransomware incident, based on our client data, averages ₹18-42 lakh in direct costs for SMEs. The insurance claim is slower than you think and may be denied if immutability was absent and the underwriter's questionnaire asked about it.

Cloud-only is tempting for companies without infrastructure appetite, but be careful: cloud-only fails when the ISP is down. For a Bangalore SME without a redundant link, that's a real risk. Hybrid is the answer for most companies that actually care.

Design decisions that will bite you later

A few non-obvious choices you make now that will cost you in year two or three.

Retention period vs storage growth

If you set 12-month immutable retention on 4 TB of data growing 20% annually, your year-end storage is not 4 TB — it's the sum of every daily backup since day one. Depending on your change rate, a 30-day daily-retention policy on 4 TB of live data can consume 20-60 TB of immutable target. Plan accordingly, and prefer incremental-forever with periodic synthetic fulls.

Object lock bucket naming

Once you enable Object Lock on an S3 bucket, you cannot disable it. You also cannot rename the bucket. If you set the wrong retention default at bucket creation, you're stuck with it. Wasabi and AWS will let you create a new bucket, but migrating existing locked objects requires waiting out the retention. Get the bucket settings right on day one.

Legal hold pitfalls

Legal hold is a separate metadata flag that keeps objects beyond their retention date. It's useful for litigation holds. It's dangerous if applied broadly by an attacker who wants to balloon your storage bill. Restrict the s3:PutObjectLegalHold permission to a very small set of identities.

Cross-region replication

For truly critical workloads, replicate your immutable bucket to a second region (e.g., AWS ap-south-1 to ap-southeast-1). Adds 30-40% to cloud storage cost. Useful for regulated entities and for companies whose DR strategy assumes a region-level event. For most Indian SMEs, this is optional.

Monitoring immutability itself

Your monitoring system should alert if the count of locked objects in your bucket drops between two days, or if retention dates on new writes are shorter than expected. A silent misconfiguration is more dangerous than an obvious failure.

Where we'd tell you not to do this

We sell immutable backup services. We also turn away work where it's not the right answer.

• Companies under 10 users with no regulatory exposure. The overhead — configuring, testing, monitoring — exceeds the risk. A simple nightly cloud backup with 30-day retention at ₹3,000-5,000/month is fine for most sub-10-user firms. Immutability is protective but not proportionate.
• Companies that will never test restores. If you're not going to open the console once a quarter and restore something, paying for immutability is theatre. Fix the discipline first.
• Companies that won't separate privileged accounts. Immutability helps, but if the domain admin's password is also the S3 root password, you've gained nothing. Get the identity hygiene right in parallel.
• Companies running entirely on SaaS with vendor-managed retention. If your only data is Google Workspace or Zoho, the backup question is partly answered by vendors. Get a SaaS backup tool (Veeam Backup for Microsoft 365, Druva, or Backupify) with its own immutable storage, but you don't need on-prem infrastructure.

A practical rollout sequence for a 50-person company

If you're starting today, this is the sequence we'd follow.

1. Week 1: Document current backup architecture. Identify primary targets, retention, and which AD accounts have write access to backup targets. Get this on paper.
2. Week 2: Remove domain join from any NAS used only as a backup target. Reset admin credentials to unique strong passwords in a separate password manager.
3. Week 3: Enable OS-level immutability (Synology Snapshot Lock, or Veeam Linux Hardened Repo). Set retention to 30 days minimum.
4. Week 4: Provision an S3 Object Lock Compliance bucket at Wasabi India or AWS Mumbai. Point Veeam at it as a SOBR secondary. Retention 12 months. Legal hold disabled.
5. Week 5: Run tests 1, 2, and 3 from this article. Document results. Fix what fails.
6. Week 6: Run a full test restore from the cloud copy. Measure time to first usable file and full restore.
7. Week 7: Build monitoring for locked object counts and retention dates. Alert on anomalies.
8. Week 8: Write the incident response playbook that says "if ransomware, follow these steps to restore from immutable copy" — and rehearse it once.

Total project timeline: 8 weeks. Total capex: ₹4-6 lakh for a 50-user environment. Total monthly: ₹22,000-35,000 including cloud storage and Veeam licences.

FAQ

What is an immutable backup in simple terms?

An immutable backup is a copy of your data that cannot be modified or deleted by anyone — including administrators — for a set retention period. It's typically implemented using S3 Object Lock, WORM settings on NAS or tape, or physical air-gapping. It exists specifically to survive ransomware and insider attacks that would otherwise delete your backups before encrypting production data.

Does S3 Object Lock Compliance mode work in India?

Yes. AWS S3 ap-south-1 (Mumbai), Wasabi India, and Backblaze B2 all support S3 Object Lock Compliance mode as of 2026. Compliance mode is genuinely immutable and cannot be overridden by the account root user. Costs vary: roughly ₹520-660 per TB per month at Wasabi India, ₹2,300-4,100 per TB per month at AWS S3 Intelligent-Tiering.

How much does an immutable backup solution cost for a 50-user Indian company?

Expect ₹4.5-6.5 lakh one-time for on-prem hardware (hardened Linux server plus a NAS target) and ₹18,000-28,000 per month for cloud immutable storage at 4 TB with 12-month retention. This assumes Veeam Backup & Replication v12.2 as the backup engine and either Wasabi India or AWS Mumbai as the cloud tier. Cloud-only solutions start lower — around ₹1.4 lakh year one — but fail if your ISP goes down.

What retention period should I set for immutable backups in India?

30 days minimum for on-prem immutable storage, 12 months for cloud immutable storage. Modern ransomware dwells 10-21 days on average before triggering encryption — if your retention is shorter than that, the attacker simply waits you out. For regulated entities (RBI, IRDAI, certain DPDP-covered entities), align retention with your regulatory record-keeping mandate, which is usually 5-8 years.

Can a domain administrator delete my immutable backups?

Not if they're configured correctly. S3 Object Lock in Compliance mode cannot be overridden even by the AWS root account. Veeam Linux Hardened Repository immutability cannot be removed by the Veeam service account. WORM on NAS survives unless the attacker has root on the NAS itself. The one caveat: if the domain admin also controls the credentials to your cloud provider, and you've enabled Governance mode instead of Compliance mode, they can bypass the lock. Use Compliance mode and separate credentials.

How do I test if my backups are actually immutable?

Four tests: (1) Try to delete a backup object as a domain admin — should fail. (2) Try to delete a restore point from within the backup console — should fail. (3) Try to reduce the retention period on a locked object — should be refused. (4) Physically verify any air-gapped target is disconnected outside its backup window. Do all four quarterly and document the results. If any succeed, your immutability is not real.

Is immutable backup mandatory under Indian law?

The DPDP Act 2023 doesn't name it explicitly but its "reasonable security safeguards" language makes immutable backup the standard of care for any organisation holding personal data. RBI and IRDAI frameworks effectively require it for regulated entities. CERT-In directions require incident reporting within six hours and 180-day log retention in India, which is far easier to satisfy with immutable copies. For everyone else it's not legally mandatory but is increasingly a contractual and insurance requirement.

Can I use my existing Synology or QNAP NAS as an immutable backup target?

Partly. Synology DSM 7.x supports immutable snapshots (Snapshot Lock) on Btrfs volumes, and QNAP has WORM shares. Both give you protection against accidental deletion and low-sophistication attacks. Neither is as strong as S3 Object Lock Compliance, because a sufficiently privileged attacker with root on the NAS can disable the lock settings for future writes. Use them as a secondary immutability layer, not as the primary defence against domain-admin compromise.

What to do this week

Pick one day this week — Wednesday, say — and log in to your backup infrastructure. Find a restore point from 45 days ago. Try to delete it. Then try to delete it again from a different admin account. Document what happened.

If the delete succeeded, you don't have immutable backups. You have backups that will survive a disk failure and nothing else. Every hour you leave that gap open is a bet against an attack that has already taken down dozens of companies in your city this year.

The next step is choosing whether to fix this yourself or bring in someone who's done it before. Immutability misconfiguration is subtle — a single wrong flag at bucket creation permanently prevents Compliance mode, and you won't discover it until the day you need it. If you'd rather not find out the hard way, get in touch and we'll walk through your current backup architecture, run the four immutability tests on your environment, and give you a written report of what survives what. No obligation, no vendor demo, just the test results.