The question is not whether you have backups. It is whether you have ever restored one.
Immutable backup, tested disaster recovery and a continuity plan somebody other than the author can follow. Designed against how long you can afford to be down, not against a product brochure.
Ransomware goes after the backups first
The old picture of a ransomware attack, where files encrypt and you restore from last night, has not been accurate for years. A modern intrusion sits on the network quietly for weeks. It maps the environment, finds the backup server, and destroys or encrypts the repository. Only then does it encrypt production. By the time anyone notices, the thing that was supposed to save the business has already gone.
This is why a backup that your administrator account can delete is not a recovery plan. What turns it into one is immutability, so a copy cannot be altered for a fixed period even with full credentials, and separation, so the repository is not reachable from the network that gets compromised.
The second failure is quieter and more common. Backups run, the job reports success, nobody ever restores one, and the first real restore attempt happens on the worst day of the company's year. A backup is a claim. A tested restore is evidence.
Five steps, in this order
The order matters. Most failed recovery plans were designed around a product before anyone asked the business how much downtime it could survive.
Find out where you actually stand
What is backed up and what quietly is not. Where the copies live and who can reach them. When a restore was last tested, if ever. This is usually the uncomfortable part, and it is the part that matters.
Agree RTO and RPO with the business
Not with IT. The people who carry the cost of downtime decide how much downtime is survivable, and how much data loss is survivable. Everything downstream is arithmetic once those are set.
Design to those numbers, with costed options
You get more than one option, with the trade-off spelled out and a price against each. Faster recovery costs more. Sometimes the cheaper option is the right one and we will say so.
Implement and harden
Immutability enabled, credentials separated from the production domain, the repository placed where a compromised administrator account cannot reach it. Implementation is where most plans quietly fail.
Test, then keep testing
A timed restore drill into an isolated environment, documented, and repeated on a schedule. The plan is only as current as the last successful test.
Backup and recovery, covered properly
From immutable repositories to the continuity plan that says who does what at 3 AM.
Immutable Backup
Copies that cannot be altered or deleted for a fixed retention period, enforced by the storage rather than by permissions. Object-lock repositories and hardened Linux targets.
3-2-1-1-0 Design
Three copies, two media types, one offsite, one immutable or offline, and zero errors on a verified restore. The last two digits are the ones most plans are missing.
RTO and RPO Definition
How long you can be down, and how much data you can afford to lose. Agreed with the business first, because every technical decision and every rupee of cost follows from those two numbers.
Tested Restore Drills
A scheduled restore into an isolated environment, timed and documented. A backup job that reports success is not evidence that you can recover.
Cloud and Hybrid Replication
Offsite copies into Azure, AWS or a second site, sized so that the restore path is realistic on the bandwidth you actually have.
Business Continuity Planning
Which systems come back first, who decides, who does what, and how the business runs while they are down. Written so somebody other than the author can follow it.
Ransomware Readiness Review
Where the backups sit relative to the production network, which accounts can reach them, and what an attacker could destroy with the credentials most likely to be stolen.
Platform Selection
Veeam, the native tooling in Azure and AWS, or open-source, chosen against your RTO, your RPO and what your team can operate. Independent, so the recommendation is not the one that pays us most.
We pick the tool after we understand the problem
Veeam is the platform most often asked for, and for good reason: mature immutability support, strong virtualisation and Microsoft 365 coverage, and a large installed base in India. Where it fits, we implement and manage it.
Cloud-native tooling in Azure and AWS is often the cheaper and simpler answer for workloads already running there, and adding a third-party product on top can be cost without benefit.
Open-source options are genuinely viable for some environments, particularly Linux-heavy ones, and we will say so when they are.
We are independent, so none of the above is a sales position. The assessment comes first and the recommendation arrives with costed options and the trade-offs written down. If what you already own would do the job once it is configured properly, that is the recommendation you will get.
What buyers ask us first
We already take backups. Why is that not enough?
Because modern ransomware looks for the backups first. It sits on the network for weeks, finds the backup server, encrypts or deletes the repository, and only then encrypts production. A backup that the attacker can reach is not a recovery plan. What makes it one is immutability, so a copy cannot be altered or deleted for a fixed retention period, even by an administrator account, and an offline or air-gapped copy that is not reachable from the production network at all.
What is an immutable backup?
A copy that cannot be changed or deleted until a set period has passed, enforced by the storage rather than by permissions. Object-lock on S3-compatible storage and hardened Linux repositories are the two common implementations. The point is that compromising an administrator account is not enough to destroy the copy, which is the exact scenario ordinary backups fail.
How long would it actually take us to recover?
Most businesses do not know, and that is the finding worth having. Two numbers define it. RTO is how long you can be down before the damage is unacceptable. RPO is how much data you can afford to lose, measured in time. Once those are agreed the technical design follows from them, and the cost can be argued honestly. A four-hour RTO and a fifteen-minute RPO cost more than overnight tape, and sometimes overnight tape is the right answer.
Do you only work with one backup product?
No, and we would not recommend picking the product first. We work with Veeam, with the native tooling in Azure and AWS, and with open-source options where they genuinely fit. The right choice depends on what you are protecting, whether it is on-premise, cloud or both, your RTO and RPO, and what your team can realistically operate. We assess before we recommend, and the recommendation comes with costed options.
What does a business continuity plan actually contain?
Which systems matter and in what order they come back. Who decides to invoke it. Who does what while it runs. Where the data is, and how it is restored. How you operate while systems are down. And the date of the last test. A plan that has never been tested is a document, not a plan, which is why we run restore drills rather than checking that a backup job reported success.
Is this only for large companies?
The opposite. A large company has a team that already does this. A fifty-person manufacturer usually has one person who also handles everything else, and is the one that cannot absorb two weeks of downtime. The design scales down: the same principles apply, with fewer moving parts and a smaller bill.
Find out whether you could actually recover
A recovery assessment tells you what is protected, what is not, where the backups sit relative to an attacker, and how long a real restore would take. You get the findings in plain language with costed options, whether or not you do the work with us.