Business Continuity
Keep your business running through unplanned outages, with your servers waiting in Nesnet's cloud
Your on-premises virtual servers replicate continuously to Nesnet's cloud, so if your server room goes down your systems come up on Nesnet without a second data center of your own.
Why now
- Friday evening the building's transformer burns out, and power won't be back before Monday. The backups sit on a disk array in the same room, with nowhere else to restore them. With an up-to-date copy of every server waiting elsewhere, the weekend becomes a switchover instead of an outage.
- A quote for a second data center is on the table: hardware, racks, circuits, licenses and someone to drive there when something breaks at night. Here the target is Nesnet's cloud and Nesnet runs the replication stack, so second-site hardware never enters your budget.
- The board asks where the servers come up, and how fast, if the primary site is lost, and the answer is an old document on a file share. With replication in place, the answer is a set of copies whose freshness is tracked one by one.
- A major customer's supplier audit wants your business continuity plan, and the contract renewal depends on it. Being able to show where the copies are and how they are watched answers the hardest question in the plan.
- Your site is in an earthquake zone, and both the insurer and management want a second copy. Having the servers wait, current, in Nesnet's cloud is the answer to that risk.
What changes
| Today | With Nesnet |
|---|---|
| If the server room goes, the backups go with it. | An up-to-date copy of your servers is ready in your resource area in Nesnet's cloud. |
| A second site means hardware, circuits and a team. | The target is Nesnet's cloud, and Nesnet builds and runs the replication stack. |
| Nobody knows how far behind each server is. | Every replication's recovery point (RPO) is tracked, and lagging servers raise an alert. |
| A dropped line restarts replication and floods the circuit for days. | No data is lost during an outage, and replication resumes where it left off. |
| The disaster plan is a document nobody has tested. | You bring copies up without touching production and see the plan work. |
From today to live: how it works
- 1
Protection workshop
With the Nesnet team you agree which servers to protect, the order they need to start in and how much data loss you can tolerate. You leave with the items that set the price and a clear picture of the bandwidth you need.
- 2
Target environment opens on Nesnet
The cloud organization and resource area that will receive the copies are created by Nesnet's automation in repeatable steps. The networks to be used in a disaster are prepared at the same time.
- 3
On-premises appliance deployed and paired
A replication appliance is deployed in your virtualization environment and paired with Nesnet's tunnel endpoint. Pairing completes when you approve the certificate fingerprint of Nesnet's side.
- 4
First copy, then continuous replication
The first full copy of the selected servers is written to your resource area's storage, after which only changes travel and replication runs continuously. From then on, each replication's recovery point is tracked on its own.
- 5
Test bring-up
Copies are brought up in Nesnet's cloud for testing without affecting production, and you check together that your applications start. Instead of a plan tried for the first time on the bad day, you have one you have seen work.
What you get
Continuous replication
Your on-premises virtual servers replicate continuously to Nesnet's cloud. Once the first full copy is written to your resource area's storage, only changes travel, and the cloud copy keeps pace with the current state of the source server.
Replicas in your own resource area
Replica data lives in your resource area's storage on Nesnet's cloud, not on the replication appliances. The space replicas use is tracked in the same place and the same portal view as the rest of your organization's resources.
See how current each server is
The replication software tracks the recovery point (RPO) of every replication separately. You see which servers are current and which are behind one by one, turning an unknown in your disaster plan into a measurement.
Lagging servers don't stay quiet
When a replication falls behind its target, an RPO violation alert is raised, and Nesnet also watches replication health on its side. Problems surface on the day they start, not on the day you need the copy.
No data loss when the line drops
If the link between your site and Nesnet goes down, replication pauses and the copies already made stay in place. When the link returns, replication resumes where it stopped, with no full re-copy and no circuit flooded for days.
A single entry point from outside
All traffic from your site comes in through the tunnel component alone, and the component that manages replication is never exposed to the internet. Your security team has one well-defined connection point to assess.
Redundant connection layer
The cloud-side tunnel layer is built redundant, runs active-active and sits behind a load balancer. If one tunnel appliance fails, the other keeps carrying traffic and your replication isn't interrupted.
Replication continues through maintenance
Several replicators run on the cloud side, with replications spread evenly across them. When one replicator goes into maintenance, its replications move to another, and your on-premises sources reconnect through the tunnel on their own.
Your pairing survives infrastructure renewals
When the cloud-side components were renewed, pairings stayed in place without being rebuilt. Your on-premises team had no extra work, no re-pairing and no full re-copy, so the infrastructure's life cycle never lands on your maintenance calendar.
Choose protection server by server
Replication and backup are chosen separately for every server. A critical database server can be both replicated and backed up, while a less critical one gets just one of the two, so cost follows the value of what you protect.
Bring systems up in Nesnet's cloud in a disaster
If your on-premises site becomes unusable, your servers start from their copies in Nesnet's cloud (failover). They come up in the same organization and the same portal as the other resources you already run on Nesnet.
Test without touching production
Bring copies up in an isolated network for testing (test failover) without disturbing ongoing replication, and confirm your applications start. When the test ends, the test servers are removed and replication carries on uninterrupted.
Return to your own site when it's over
Once your site is ready again, the changes made while running in Nesnet's cloud replicate back in the reverse direction and the servers move home (failback). When the crisis ends, the business returns to normal without leaving its data behind.
Start multi-server applications in order
Related servers are grouped in a recovery plan with a defined start-up order, for example database first, then application, then web servers. In a disaster, nobody has to remember which server comes up first.
Go back to an earlier point
A replica keeps not only the latest state but several recovery points saved at intervals. If corrupted data on the source has already reached the copy, you bring the system up from a point before the problem began.
Follow replication from the portal
You see the status, freshness and alerts of your replications on a management screen in your cloud portal. Finding out which servers are protected never means opening a ticket or waiting for a report.
The first step of a cloud migration
The same replication is also a safe way to move on-premises servers to Nesnet's cloud for good. Servers wait as copies, get tested, and are switched over to run on Nesnet in a planned window.
Operated and watched by Nesnet
With the managed service line on your invoice for every protected server, operating replication is Nesnet's responsibility. The Nesnet team watches the cloud-side components, replication health and RPO alerts.
Two layers of protection with Backup
Replication keeps a single current copy, so a deleted file or a bad change on the source soon reaches the copy too. Used with Backup on critical servers, you can go back to minutes ago and to last week.
Why Nesnet
Run by the team that built it
Nesnet's own team builds and runs the tunnel, replicator and management components on the cloud side, and renewed them through the API with every step measured. When something goes wrong, you reach Nesnet’s support team, and the cloud side is Nesnet's responsibility.
Infrastructure renewals don't break your pairing
When Nesnet renewed its cloud-side components, existing pairings were kept without being rebuilt. The on-premises team had nothing extra to do; replication simply carried on through the new components.
One door to the outside
All traffic from your site enters through the tunnel component alone. The component that manages replication is never exposed to the internet, which keeps the attack surface to a single point.
Your copy sits next to your other servers
Replicas don't live in a separate recovery environment; they sit in the same organization as the servers you already run on Nesnet's cloud. In a disaster, systems come up in the same portal, alongside their networks and your other resources.
Your data stays in Türkiye
Replicas are kept in your resource area's storage on Nesnet's cloud, in Türkiye. Nesnet's hardware, network and team are in the Equinix Istanbul (Dudullu) and Türk Telekom Ankara facilities.
A monthly invoice instead of a second data center
Invoices are issued as e-invoices or e-archive invoices. The upfront cost of a second data center becomes a monthly line per protected server.
Example scenarios
The server room floods
Situation
A manufacturer's ERP and file servers run in a single server room in the factory basement. One weekend, rainwater got in and the hardware became unusable.
Outcome
Current copies of the critical servers were ready in the resource area on Nesnet's cloud. The servers came up on Nesnet, staff connected to the same applications over VPN on Monday, and once new hardware arrived the systems moved back to their own site.
One consistent place for a multi-tier application
Situation
A service company's customer application is made of web, application and database tiers. In a failure, those servers need to be in one environment where they can reach each other, not scattered.
Outcome
All three tiers replicated to the same resource area on Nesnet's cloud, with a start-up order that brings the database up first. Because each server's freshness is tracked, it's clear which one is lagging.
Replication after a line outage
Situation
A branch office lost its internet line for a few hours during maintenance work. The IT team feared replication would start over and saturate the line for days once the link came back.
Outcome
Replication paused during the outage, and no data was lost. When the link returned, replication resumed where it left off with no full re-copy.
Evidence for a supplier audit
Situation
A logistics company was asked for concrete disaster evidence in its biggest customer's supplier audit. All it had was a document written years earlier.
Outcome
The company showed the copies of its critical servers on Nesnet's cloud and the freshness tracking for each. The copies were brought up in an isolated network for a test, and the result went into the audit file.
From disaster protection to cloud migration
Situation
A retail chain has been replicating its on-premises servers to Nesnet for several years. As the hardware warranty ran out, management decided to close the server room for good.
Outcome
The already-current copies were switched over to run on Nesnet during a planned weekend. No separate migration project was needed; the server room closed and the systems carried on in Nesnet's cloud.
Who does what
| Nesnet | You |
|---|---|
| Builds, runs and renews the cloud-side replication components (tunnel, replicator, management). | Keep your on-premises virtualization environment and its replication appliance running. |
| Keeps the tunnel layer redundant, active-active and behind a load balancer. | Decide which servers are replicated and which are also backed up. |
| Renews components without breaking your existing pairings. | Approve the certificate fingerprint of Nesnet's tunnel endpoint during pairing. |
| Monitors replication health and RPO compliance, and shares lagging replications with you. | Provide the internet line connecting your site to Nesnet. |
| Opens your target cloud organization, resource area and the networks used in a disaster. | Make the failover call in a disaster and join test bring-ups with your application team. |
Who it is for
Organizations with a single server room
Companies whose ERP, accounting and file servers all run in one server room in one building. If power, cooling or hardware fails there, an up-to-date copy of those servers is ready somewhere else, in Nesnet's cloud.
IT teams with no one to run a second site
Teams that can't fund hardware, circuits, licenses and a separate crew for a second data center. Nesnet builds, monitors and renews the tunnel, replicator and management components on the cloud side.
Organizations that need a written answer
Your board, an auditor or a major customer is asking what happens if the primary site is lost. You can show exactly which server is waiting where, and how current each copy is.
Teams with multi-tier applications
Teams protecting a system made of web, application and database servers together. Every replica lands in the same resource area in Nesnet's cloud, so in a disaster the pieces of the system stay together.
May not be the right fit
If your servers already run on Nesnet's cloud, this is the wrong tool; Backup covers your need to go back to earlier days.
Physical servers and environments other than the supported virtualization platform (listed under 'How it works') are out of scope. In that case, start by talking about moving those servers to Nesnet with the Cloud Migration solution.
Under the hood
Replication is handled by a replication platform connected to the cloud portal. It has three parts: a management service that runs the replications, the replicator that moves the data, and the tunnel that receives external connections. The replicator runs next to the virtualisation management it replicates into, and the replication appliance installed on your premises pairs with Nesnet's tunnel endpoint after its certificate thumbprint is approved. On the cloud side Nesnet built the tunnel layer redundant and active-active behind a load balancer, and load is balanced across the replicators too. Replica data does not live on the replication appliances; it sits in your resource allocation's storage, on Nesnet's platform built on a software-defined network and all-NVMe distributed storage. The RPO of each replication is tracked individually.
Building blocks
- Replication management
- manages replications and tracks RPO
- Replicator
- writes incoming changes to the target storage
- Replication tunnel
- the single entry point from outside; redundant, active-active
- Cloud portal and API
- the organisation where the replica lives and comes up
- Distributed NVMe storage
- your allocation's storage, where replica data is kept
- On-premises replication appliance
- installed in your virtualisation environment, pairs with Nesnet's tunnel endpoint
How it compares
| Option | When it is the right choice |
|---|---|
| Backup on its own | If your servers already run at Nesnet, or restoring a server from a backup copy after a failure is good enough for your business, Backup is the better and simpler choice. Backup keeps copies from past days; replication keeps a single current copy. |
| Cloud Migration | If the goal is not to keep two environments side by side but to leave your on-premises servers behind entirely, the Cloud Migration solution fits better. Live migration and replication tools are installed in Nesnet's management layer for migrations. |
| Build your own second data centre | If a regulation or company policy requires the second copy to sit in a building you own, this route is unavoidable. The hardware, circuits, licences and the team to run both sites then stay with you. |
Technical specifications
| Replication software | Hypervisor-level replication software |
|---|---|
| Components | Management service, replicator, tunnel |
| External access | Only through the tunnel; management component not exposed |
| Replicator placement | Next to the virtualisation management it replicates into, on the cloud side |
| Connection layer | Redundant, active-active, behind a load balancer |
| Target platform | Nesnet's cloud, with the replica in the same organisation as your other servers |
| Direction | On-premises virtualisation → Nesnet cloud |
|---|---|
| Pairing | On-premises replication appliance ↔ Nesnet tunnel endpoint, certificate thumbprint approval |
| Replica data | In the customer's allocation storage, not on replication appliances |
| RPO tracking | Per replication; RPO violation alerts |
| Connection loss | Replication pauses, no data loss; resumes where it stopped, no full re-copy |
| Relation to Backup | Selected separately per VM in a quote; neither replaces the other |
| Billing units | Replication licence per replicated VM + managed service per VM |
|---|
If something breaks
If a tunnel appliance goes down
The tunnel layer runs active-active, so the other appliance keeps carrying the traffic and replication continues through it.
If a replicator is taken down for maintenance
Its replications move to another replicator. On-premises sources reconnect through the tunnel on their own.
If the link between your site and Nesnet drops
Replication pauses while there is no connection, and no data is lost. When the link returns, it picks up where it left off without a full re-copy.
If your on-premises site becomes unusable
The replicas of your VMs are already in your allocation's storage at Nesnet. The VMs come up there, in the same cloud organisation as the other resources you use at Nesnet.
Frequently asked questions
Pricing and first steps
Pricing
Business Continuity is billed monthly per protected server: a replication software license for every replicated server plus a managed service line per server. The price is set by the number of protected servers and the items you choose, and Nesnet’s team prepares your quote.
What the price depends on
- Number of replicated VMs: the licence is counted for every protected VM.
- Managed service: running the replication is billed as a separate per-VM line.
- Adding Backup: if the same VM is also backed up, backup is added as a separate line from business continuity.
How to get started
- 1.Fill in the form or call 0800 606 1071.
- 2.We agree on servers and start-up order in one call and prepare a price.
- 3.Your target opens, the appliance pairs and the first copy starts.
Know exactly where your servers go if your main site does
Tell the Nesnet team which servers to protect and in what order they should start, and you'll hear back within the same business day. Without building a second data center, you end up with a disaster plan you have watched work.