A place to run
Recovery VMs start on the local backup server or in our data centre.
When your servers are down, they start in our data centre.
Your critical systems get somewhere to run when your own environment can’t be used. Our engineers start them from your backups, keep the network addresses the same, and move everything back when your environment is ready.
Your productionHyper-V, VMware, physical servers
runningbackup every night
Recovery pointsImmutable, in Amsterdam
lockedoutage: start here
DR environmentSame IP addresses and VLANs
standbyafterwards: changes go back
Your server room goes dark at 07:42. This is what happens next.
An example day: a Hyper-V cluster fails, the business keeps working from our data centre in Amsterdam, and in the evening everything moves back.
01 / 05
The site goes down
Both Hyper-V hosts stop responding and the ERP system, file shares and web application go with them. Our on-call engineer starts the DR plan and lets you know what happens next.
02 / 05
Start in our data centre
We pick the last clean recovery point and start the VMs from it in our data centre, domain controller first, then the database, then the rest. A VM from VMware can be started on Hyper-V; we check that combination with you beforehand.
03 / 05
Keep the same network
A tunnel extends your VLANs to the DR environment, so SQL01 is still 10.20.0.15. Laptops, printers and integrations don't need new settings. Once a test order goes through, people get back to work.
04 / 05
Run while the site is rebuilt
Your business runs from Amsterdam for as long as it takes. Everything people change is backed up there too, while your own servers are repaired or replaced.
05 / 05
Move back
In a cutover window we shut down the DR VMs, make a final backup and sync only the blocks that changed since the outage back to your site. Production starts again, we check it with you, and DR goes back to standby.
When your own servers stop, your business has a place to keep working and a team that does the recovery. Coming back is part of the plan, not an afterthought.
Technical detail
- Recovery starts from a backup, not continuous replication: the backup interval sets your potential data loss (RPO).
- Network continuity by extending the required VLANs; recovered VMs keep their IP addresses. Source and target hypervisor combinations are checked during onboarding.
- Failback is planned: final DR backup, sync of changed blocks to the prepared source, startup and validation, with a short planned interruption.
Example scenario. Which systems, boot order, capacity and network setup apply is determined per customer. How much data you could lose depends on how often you back up.
See it from the user’s side.
Sanne is working on a server in your own server room when the hypervisor fails. Click a chapter, or let it play from start to finish.
10.20.0.15 - Remote Desktop Connectionconnected · HV-01no connectionconnected · Amsterdamconnected · HV-01This PC
orders.xlsxorders.xlsx● · ExcelHomeInsertFormulasDataView
A1fx
| A | B | C | D | E | F | |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | ||||||
| 3 | ||||||
| 4 | ||||||
| 5 | ||||||
| 6 | ||||||
| 7 | ||||||
| 8 | ||||||
| 9 | ||||||
| 10 |
ReadySaving…Saved to D:\OrdersD:\Orders\orders.xlsx
APP0110:02Connecting to 10.20.0.15…Remote Desktop Connection
Reconnecting…The connection to the remote computer was lost. Attempt 1 of 20
Remote Desktop can’t connect to the remote computerThe computer is not reachable on the network. Try again later or contact your administrator.OK
Your Remote Desktop session has endedThe remote computer is being moved back. Connect again in a few minutes.OK
Time10:02
app01 · 10.20.0.15 runs onHV-01, your own server roomnowhere: host is downImmutec, AmsterdamHV-01, your own server room
Interruption00:00
Sanne’s laptopOffice · Sittardconnected to 10.20.0.15connection lost
Your server roomHyper-V host HV-01
app0110.20.0.15 · VLAN 20runninghost downbeing repairedreceiving changesstoppedImmutec · AmsterdamDR host AMS-DR-03app0110.20.0.15 · VLAN 20standbystartingrunningsending changesRecovery pointsrp-1005 · locked
- recovery point rp-1005 written · locked
- HV-01 unreachable · on-call engineer alerted
- customer approves start in DR
- app01 boots from rp-1005 on AMS-DR-03
- VLAN 20 extended through tunnel · 10.20.0.15 online
- HV-01 repaired · final sync started
- app01 stopped in DR · last changes copied
- app01 started on HV-01 · back home
Monday morning. Sanne works on app01, a server in your own server room. She installs a web server and records an order.Over Remote Desktop she enters an order in Excel and saves it. At 10:05 our backup takes a recovery point and locks it.
At 10:11 the Hyper-V host fails. Her session freezes, the server no longer answers. Our monitoring sees it too, and our on-call engineer calls you.
You give the go-ahead. We start app01 from the last recovery point in our data centre in Amsterdam and extend VLAN 20 through the tunnel, so the server keeps its address.
Sanne connects to the same address as always. Her web server and the order are there, and she just carries on.Her Excel file and the order are there, and she just carries on. Nothing changes on her laptop.
In the evening your own host is repaired. We copy only what changed in Amsterdam during the day, stop the DR copy and start app01 on your own host again.
The next morning Sanne logs in on your own server. The order from before the failure and the one she entered in Amsterdam are both there.
Example scenario with illustrative times. How quickly a server runs in our data centre depends on your service (standard DR or hot standby), the size of the server and the checks you want. Work done after the last recovery point is not in it, so the backup frequency determines how much you could lose.
What you just saw.
Want to see it with one of your own servers? We can run this scenario in an isolated test, before you sign anything.
For the business
A short interruption instead of a day without your systems. The timings in this demo are an example; what fits you depends on your service.
The user changes nothing
Same IP address, same VLAN, same name. Laptops, printers and integrations keep pointing at the same server.
Data up to the last recovery point
The server starts from the last locked recovery point. Work after that point is not in it, so we set the backup frequency to what you can afford to lose.
Work done during the outage comes back
Changes made while the server runs in our data centre are copied back when your own host is ready. Only the changes travel, not the whole server.
One team does all of it
Our engineers watch the alerts, start the server after your go-ahead, keep the network working and move everything back.
Having a backup is not the same as having somewhere to run.
Restoring a VM is one part of the job. You also need capacity, network connectivity, application dependencies and people who coordinate the work.
The same network
Recovered systems keep their IP addresses and VLANs, so users and applications can find them.
A way back
Syncing changes and moving back to production are part of the plan.
Two levels: standard DR or hot standby.
Both start your servers from your locked backups and both include the way back. The difference is how much is ready before anything goes wrong.
Standard DR
We build the recovery environment when it is needed, from your backups and the plan we made together. Suited to systems that can be down for a while.
Hot standby
The recovery environment is kept ready at all times and the network is already prepared. For the systems your business can’t do without.
What we agree for both
Which systems, in what order, how much capacity, who gives the go-ahead and how you test it. What is realistic for each system goes into the recovery plan.
We plan the way back at the start.
When your own environment is ready, we make a final backup in DR, shut the DR systems down, sync the changes back to your environment and start the systems there. You decide when the switch happens and you check the result.
Recovery starts from an available backup. How much data is lost and how long it takes depends on backup frequency, start-up time, dependencies, capacity and the kind of incident.
Backup, DR and failback explainedFor management
The business keeps working during an outage, and you decide in advance which systems come back first.
For IT partners
Offer disaster recovery without building a recovery environment yourself.
How the partnership works“Working with IMMUTEC feels like a partnership, not just a supplier relationship. We can always turn to them, and they go that extra step to help us.”
Questions we get a lot
Something else? Call us on +31 (0)85 482 3400.
Is this continuous replication or zero data loss?
No. Recovery starts from your backups, so the backup frequency determines how much data you could lose. We don’t sell backup-based recovery as zero data loss.
Is recovery as quick as starting a VM?
Starting the VM is one step. Picking the recovery point, capacity, network, application dependencies and checks all affect when people can work again. We plan for all of it.
Can we test without affecting production?
Yes. We agree a test scenario in an isolated environment, with the scope, network and success criteria set in advance.
Is there a faster option?
Yes, hot standby. We keep the recovery environment ready at all times, so starting your systems takes less time than with standard DR, where we build the environment when it is needed. Data up to the last backup comes back in both cases.
Which three systems have to run first?
That’s where we start. We work out with you where they run during an outage, with what capacity, and how they come back.