Definition
What is disaster recovery for SharePoint Server 2016 and 2019?
Disaster recovery for SharePoint Server 2016 and 2019 is the set of systems and decisions that keep a SharePoint Server 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 SharePoint Server application the business depends on, the second question is the one that costs money every minute it stays unanswered.
Why now
Why SharePoint Server disaster recovery changed on July 14, 2026
On-premises SharePoint is where the organization's documents live, which is why attackers keep coming back to it. Since July 14, 2026 SharePoint 2016 and 2019 farms have been running without patches, and the next ToolShell-class exploit will find them. Disaster recovery for SharePoint is now about keeping people working while the farm is contained.
The facts that matter for a SharePoint Server application today:
- Extended support for SharePoint Server 2016 and SharePoint Server 2019 ended on July 14, 2026. Mainstream support ended in July 2021 and January 2024 respectively.
- After that date Microsoft provides no security fixes, no assisted support and no technical content updates for either version.
- SharePoint Server Subscription Edition is the only supported on-premises version, and Microsoft's investment is in SharePoint Online and Microsoft 365.
- SharePoint has been a repeated target of actively exploited vulnerabilities, including the ToolShell chain in 2025 that hit on-premises servers worldwide.
Failure modes
Where SharePoint Server applications actually fail
Disaster recovery planning tends to imagine fires and floods. Real SharePoint Server outages are more mundane and more frequent. The failure modes that a plan for SharePoint Server 2016 and 2019 has to cover:
- A newly exploited vulnerability in SharePoint 2016 or 2019 with no patch, on a server that holds the organization's documents.
- A SQL Server, search or web front end failure in a farm nobody has rebuilt in years.
- Ransomware moving through Active Directory to the farm, the content databases and the backups in one pass.
- Custom solutions, workflows and InfoPath forms that only run on the old version.
- 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 SharePoint Server 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.
Unpatched is survivable when it is not a single point of failure
SharePoint Server 2016 and 2019 will not receive another vendor fix. The replica does not change that, but it changes the cost of the next vulnerability: the exposed primary can be taken down to contain an incident while the isolated replica keeps users working.
How it works
How the Jestr replica works for a SharePoint Server application
Jestr does not re-implement SharePoint Server 2016 and 2019. It runs a copy of your actual application, kept current and kept apart.
Jestr builds a live copy of the application
Jestr replicates the SharePoint Server 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.
SS What the replica captures for SharePoint Server 2016 and 2019
- Site collections, libraries, lists, documents and the content databases behind them, so the intranet and document stores are intact on the replica.
- Search, permissions and authentication, so people can find and open what they need rather than browse a frozen copy.
- Custom solutions and workflows at a known-good state, kept current with the primary.
- Isolation from the primary's domain, network and credentials, so ransomware in the estate has no path to the copy.
Side by side
Backup and restore vs a live SharePoint Server 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 |
| Unpatched platform | Every new vulnerability is permanent and the only copy is exposed | The exposed primary can be contained while the isolated replica serves users |
| 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
Does the replica cover the content databases and search?
Yes. A SharePoint replica that cannot search or open documents is a screenshot. The Jestr replica keeps the content databases, permissions and search index current with the primary, so people can find and open what they need while the farm is down.
Does Jestr replace our SharePoint Server 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 SharePoint Server 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.
Is it safe to keep running SharePoint Server 2016 and 2019 at all now that end of extended support has passed?
Safer than it looks, if the exposure is managed. The replica does not patch the software, but it means the exposed primary is no longer the only copy. When a vulnerability is disclosed, the primary can be restricted or taken down to contain it while the isolated replica keeps users working. Unpatched is survivable when it is not also a single point of failure.