Watch a server fail and keep working, from the user’s side.
A Linux or Windows server in your own server room. Someone is working on it when the hypervisor fails. The server starts in our data centre with the same IP address, the work continues, and in the evening everything moves back. This is what we do, step by step.
Your server roomHyper-V host HV-01
app0110.20.0.15 · VLAN 20runninghost downbeing repairedreceiving changesstopped
Immutec · AmsterdamDR host AMS-DR-03app0110.20.0.15 · VLAN 20standbystartingrunningsending changes- 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. 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. 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.
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.
Want to see it on your own environment?
We can run this scenario with one of your own servers in an isolated test, so you see the result before you sign anything.