Definition
What is disaster recovery for ASP.NET Web Forms?
Disaster recovery for ASP.NET Web Forms is the set of systems and decisions that keep a Web Forms application serving users when its primary environment fails.
A traditional plan restores the application from a backup onto rebuilt infrastructure. That takes hours or days and loses everything since the last snapshot. A live replica approach keeps a second, current copy of the application running and isolated, so failover is a switch rather than a rebuild.
The two approaches answer different questions. A backup answers "can we get the data back?". A live replica answers "can users keep working while we deal with this?". For a Web Forms application the business depends on, the second question is the one that costs money every minute it stays unanswered.
Why now
Why Web Forms applications need disaster recovery now
Web Forms applications are the quiet backbone of a lot of businesses: order entry, claims processing, internal portals, customer self-service. They are stable, rarely touched and almost never rebuilt. That makes them fragile in a specific way. Nobody knows how to stand one up from scratch anymore, and the runtime under them only gets patched when Windows does.
The facts that matter for a Web Forms application today:
- .NET Framework 4.8 has no standalone end-of-support date. It is supported only as a component of the Windows version it ships with, which means its lifecycle is whatever Windows Server's is.
- ASP.NET Web Forms is not part of modern .NET and never will be. There is no migration path; Web Forms applications have to be rebuilt in Blazor, Razor Pages or MVC.
- The same is true of server-side WCF, .NET Remoting and AppDomains, which many Web Forms applications depend on.
- Microsoft's investment, tooling and hiring pool have all moved to modern .NET.
Failure modes
Where Web Forms applications actually fail
Disaster recovery planning tends to imagine fires and floods. Real Web Forms outages are more mundane and more frequent. The failure modes that a plan for ASP.NET Web Forms has to cover:
- A Windows Server or IIS patch that breaks the application, or the end of support for the Windows version it runs on.
- A vulnerability in a third-party control suite or library that no longer ships updates for .NET Framework.
- Ransomware moving through Active Directory to the application servers, SQL Server and the backup targets in one pass.
- The last developer who understands the code base leaving.
- The backup itself: stored on the same domain, encrypted alongside production, or restored with the intrusion still inside it.
The replica
Why a live replica beats restoring Web Forms from backup
Four things change when the application has a live, isolated copy instead of a snapshot on a shelf.
Zero recovery time, because nothing is recovered
The replica is already running. When the primary fails, users are switched to the copy in seconds. There is no rebuild, no restore window and no scramble to find the person who knows how the application was configured.
Zero data loss, because the copy is current
The replica follows the primary continuously rather than nightly. Changes made on the replica during an outage are captured and reconciled back when the primary returns.
Ransomware cannot follow
The replica is isolated from the primary's Active Directory domain, network and credentials. An attacker who owns production has no path into the copy, and you never restore from a snapshot that might carry the infection with it.
The vendor's outage is not your outage
When a hosting provider, a cloud region or a dependency fails, the replica sits outside that blast radius. Users keep working while someone else fixes their problem.
How it works
How the Jestr replica works for a Web Forms application
Jestr does not re-implement ASP.NET Web Forms. It runs a copy of your actual application, kept current and kept apart.
Jestr builds a live copy of the application
Jestr replicates the Web Forms application as it actually runs: the application, its data and its configuration, at the exact version and with the exact dependencies the primary uses. Nothing is re-implemented, so what users see on the replica is the application they know.
The copy stays current and stays isolated
The replica follows the primary continuously, at a known-good state, so an update that breaks production does not break the copy. It runs on Jestr's side of the outage with no shared credentials, network or identity, so a compromise of the primary stops at the primary.
When the primary fails, you switch
One action moves users to the replica. They open the same pages, sign in and keep working. Changes are captured on the replica. The switch works even when your own network is the thing that is down.
When the primary is back, you reconcile and switch back
Changes made on the replica are reconciled into the restored primary. You choose when to switch back. Nothing was lost and no backup was restored.
What the replica captures for ASP.NET Web Forms
- The IIS site, application pools, web.config and the exact .NET Framework version the application needs.
- The SQL Server database and any file shares, kept current with the primary.
- Authentication and integrations, so users can sign in and work on the replica rather than look at it.
- Isolation from the primary's Active Directory domain, network and credentials, so ransomware in the estate has no path to the copy.
Side by side
Backup and restore vs a live Web Forms replica
The same outage, handled two ways.
| Dimension | Traditional backup and restore | Live Jestr replica |
|---|---|---|
| Time until users are served again | Hours to days: provision, restore, reconfigure, test | Seconds: the replica is already running |
| Data lost | Everything since the last snapshot, often a full day | Nothing: the replica is current, and changes made during the outage are reconciled back |
| Ransomware | Backups often sit in the blast radius, and a restore can bring the infection back | The replica is isolated; you switch to it instead of restoring into the compromise |
| Vendor or hosting outage | You wait for the provider | The replica sits outside the provider's failure domain |
| Rehearsal | Rarely tested, because a full restore is disruptive and slow | Switching to the replica is routine and can be rehearsed any time |
| Who does the work at 3am | Your team, from a runbook that may be out of date | The switch is one action; the copy was built and kept current in advance |
FAQ
Frequently asked questions
We have VM snapshots. Is that not disaster recovery?
A snapshot is a copy of a disk at a moment in time. Restoring it means finding a host, restoring the image, restoring the database to a matching point, fixing the domain trust and hoping the snapshot predates the intrusion. A live replica is already running, already current and already isolated. There is nothing to restore.
Does Jestr replace our Web Forms backups?
No. Keep backups for archives, audits and long-term retention. Jestr replaces the part of the plan that backups are bad at: keeping the application available while the primary is down, without a restore window and without data loss.
Can users sign in and work on the replica, or is it a static copy?
It is the real Web Forms application, not a snapshot of its pages. Logins, forms and integrations work. Changes made during the outage are captured and reconciled when the primary returns.
How is ransomware kept out of the replica?
The replica shares nothing with the primary that an attacker could use: no credentials, no network path, no domain trust. Replication is one-way and validated, so an encrypted or tampered primary does not propagate. You switch to a clean copy instead of restoring into the compromise.
How fast is failover?
Seconds. The replica is already running and current, so failover is the act of pointing users at it. There is no provisioning, restoring or reconfiguring in the critical path.
Does this work with managed Web Forms hosting?
Yes. The replica sits outside the hosting provider, whoever it is. That is the point: when the host has a bad day, the application does not.