Skip to main content

Ransomware Recovery Tip: Don’t Restore Yet

  • July 23, 2026
  • 10 comments
  • 48 views

eblack
Forum|alt.badge.img+3

When ransomware hits, the pressure to restore starts almost immediately. People want systems back, and every minute of downtime hurts. The recovery team is expected to move fast. That pressure is real, but moving too fast is how bad recovery decisions get made.

My rule is simple: do not reconnect a restored workload to production until the recovery point has been validated in isolation.

The newest restore point is not automatically the right one. Encryption may be the first visible sign of an attack, but the attacker could have been in the environment for days or weeks. A successful backup tells us that Veeam captured the data. It does not tell us whether the workload is safe to reconnect.

Start with the incident timeline. Work with the security team to identify when the compromise may have started and select a candidate restore point from before that window. For Windows workloads, Veeam Secure Restore can then scan the restore point with Veeam Threat Hunter, supported antivirus software, or applicable YARA rules before the machine is returned to production.

The scan adds evidence. It doesn't prove the system is clean.

The next step is to start the workload in an isolated recovery environment. A Veeam Virtual Lab provides a fenced environment for SureBackup verification, an On-Demand Sandbox, or staged restore testing. This gives the recovery team time to confirm that the operating system boots, required services start, application dependencies work, and the recovered data is usable. It also gives the security team a place to look for remaining indicators of compromise without exposing production.

The recovery workflow looks like this:

  1. Contain the incident and preserve the available evidence.

  2. Establish the likely intrusion timeline.

  3. Select and scan a candidate restore point.

  4. Recover the workload into isolation.

  5. Validate the application, its dependencies, and the recovered data.

  6. Record approval from security and the application owner before reconnecting it.

No Veeam feature or green check mark can make the final decision by itself. The incident team still has to make the call.

Taking a little longer to validate a restore point is usually cheaper than reconnecting too early and bringing an attacker's persistence back into production.

Backups prove that you still have the data. Isolated recovery gives you a reason to trust it again.

10 comments

lukas.k
Forum|alt.badge.img+13
  • Influencer
  • July 23, 2026

I can only speak for Europe, but the biggest challenge with real-work incidents is that the legal site comes in first. From a legal perspective, the majority of customers are not allowed to touch their infected production systems at any level, so a restore is not possible.

Also networking equipment and firewalls might be “sealed” for further investigation.

Most customers who must follow such regulations by legal (police involvement etc.) will have to cover the restore to “dirty production” scenario with interims hardware - that’s the most challenging part imo.


eblack
Forum|alt.badge.img+3
  • Author
  • Influencer
  • July 23, 2026

I can only speak for Europe, but the biggest challenge with real-work incidents is that the legal site comes in first. From a legal perspective, the majority of customers are not allowed to touch their infected production systems at any level, so a restore is not possible.

Also networking equipment and firewalls might be “sealed” for further investigation.

Most customers who must follow such regulations by legal (police involvement etc.) will have to cover the restore to “dirty production” scenario with interims hardware - that’s the most challenging part imo.

 

Good point, Lukas. Most of my recovery work has been in the US, so I appreciate the European perspective. If the original environment is sealed, you're rebuilding somewhere else. That means having interim hardware lined up before you need it.


lukas.k
Forum|alt.badge.img+13
  • Influencer
  • July 23, 2026

Customers can also move to Azure - but this is often way more complicated to run “properly” then everyone expects. The interim solution will not only be in place for a few weeks, that’s the point.

Also, you want to keep in mind to merge stuff from the interim to the “new production” afterwards, that can be more difficult when you have to switch between technologies like on-prem an Azure.

 

Anyways - great writeup!


coolsport00
Forum|alt.badge.img+23
  • Veeam Legend
  • July 23, 2026

Performing a Scan Backup function without even the need to spin up a Lab, etc to do so is one of the best ones Veeam created since v12 release imo. 

Good points to keep in mind here Eric. Thanks for sharing!


eblack
Forum|alt.badge.img+3
  • Author
  • Influencer
  • July 23, 2026

Performing a Scan Backup function without even the need to spin up a Lab, etc to do so is one of the best ones Veeam created since v12 release imo. 

Good points to keep in mind here Eric. Thanks for sharing!

Yes! I love that Veeam has given us so many options to use in the last couple of releases. 


Iams3le
Forum|alt.badge.img+15
  • July 23, 2026

Hi ​@eblack,

Nice, and thank you very much for sharing 👍. But then, what if the recovery server itself is also compromised? 😁 More work, right?

By the way, to reiterate what ​@lukas.k mentioned. Seems there isn’t separation of duties and isn’t ransomware recovery a legal, regulatory, insurance, and forensic incident? Shouldn’t these stakeholders be involved early to ensure evidence is preserved and not unintentionally altered during recovery?


lukas.k
Forum|alt.badge.img+13
  • Influencer
  • July 23, 2026

Hi ​@eblack,

Nice, and thank you very much for sharing 👍. But then, what if the recovery server itself is also compromised? 😁 More work, right?

By the way, to reiterate what ​@lukas.k mentioned. Seems there isn’t separation of duties and isn’t ransomware recovery a legal, regulatory, insurance, and forensic incident? Shouldn’t these stakeholders be involved early to ensure evidence is preserved and not unintentionally altered during recovery?

I agree, this should be the case and they should be pulled in early. I also see it very often in the field that due to a lack of training, processes and documentation, these things often get forgotten and due to panic, customers start recovering random stuff to be able to earn money again.

Training should also include such communication and “organizational DR” drills imo.


eblack
Forum|alt.badge.img+3
  • Author
  • Influencer
  • July 23, 2026

Hi ​@eblack,

Nice, and thank you very much for sharing 👍. But then, what if the recovery server itself is also compromised? 😁

By the way, to reiterate what ​@lukas.k mentioned. Seems there isn’t separation of duties and isn’t ransomware recovery a legal, regulatory, insurance, and forensic incident? Shouldn’t these stakeholders be involved early to ensure evidence is preserved and not unintentionally altered during recovery?

Good questions, and thanks for reading it. If by recovery server you mean the Veeam backup server, I would treat it as untrusted and build a clean one before starting recovery. I would not use a compromised backup server to access the repositories or run restores.

I agree on bringing legal and forensics in early. Insurance or regulatory requirements can change the recovery sequence. Not every company is insured or has a retained incident response firm, though. With smaller companies, the first reaction is often to get everything back up as fast as possible. That's where bad recovery decisions can happen.

I was casting a broad net with the post and keeping it centered on the restore decision. I appreciate you adding that context.


Chris.Childerhose
Forum|alt.badge.img+22

This is where we would need to isolate that environment and never touch it, so forensics can look at it.  We would spin up a new environment for backups, then we would slowly restore what is required after all the checks and balances have been done.

Great post Eric!


eblack
Forum|alt.badge.img+3
  • Author
  • Influencer
  • July 23, 2026

This is where we would need to isolate that environment and never touch it, so forensics can look at it.  We would spin up a new environment for backups, then we would slowly restore what is required after all the checks and balances have been done.

Great post Eric!

100%, I’m glad this post generated such great points from everyone.