Home›Guides›DRP and BCP

DRP and BCP

How do you keep a business application available during an outage?

A business application remains available during an outage if a second instance, already up to date and already reachable from workstations, takes over without each user having to change a setting. If the standby exists but nobody knows how to connect to it, the application is technically “saved” and in practice down.

Updated in October 20263 min read4 sources cited

Key points

  • Four conditions: consistent data, a properly sized standby, a network path ready to use, a business check.
  • The database must be backed up using a method that understands it (transaction log, quiescing), not as plain files.
  • Keeping the same IP address is more transparent than a DNS change, but requires equipment still working on site.
  • Check the software licence on the standby environment before the outage.
  • If the four conditions are not met, call it a DRP and write down the degraded mode.

The four conditions

The data is consistent. The application and its database must be copied together, in a state the database engine is willing to open. A file copy taken in the middle of a write may start on a database that the vendor will consider corrupt. The backup or replication tool must understand the database (quiescing, transaction log), not just the disk. For SQL Server, Microsoft also recommends storing backups on a physical location separate from the database files, and points out that you do not have a restore strategy until you have restored a copy on a test system and checked its integrity.

The standby is sized for real work, not just to “show that it starts”. An instance too small for ten concurrent users creates a software outage in place of the hardware outage.

The network path is ready. Two common techniques:

  • keep the same IP address as seen by workstations, thanks to on-site equipment that redirects to the standby;
  • change a DNS name, accepting the propagation delay and workstation caches.

The first is more transparent. It requires an agent or appliance still working on site. If the entire site is destroyed (fire), there is no local agent any more: remote users then go through a standby public address, provided it has been reserved and tested. A site-level BCP and a single-server BCP are not prepared in the same way.

Someone checks the application, not just the system. Opening the login screen is not enough. An authorised user performs a usual task: look up a case file, issue a document, print.

Comparing the two network paths

Same IP address via on-site equipmentDNS name change
Action on workstationsNoneSometimes clearing the cache or restarting
Failover timeShortDepends on the lifetime (TTL) of DNS records
Works if the site is destroyedNoYes, if remote access is ready
Point to watchThe on-site equipment must surviveAddresses hard-coded in software

Before the outage: the checklist

  • The database backup method is documented and has already produced a successful restore.
  • The standby size has been validated against the expected number of users.
  • The network path has been tested from an ordinary workstation, not from the administrator’s workstation.
  • The licence works on the standby.
  • A business user performed a real task on the standby during the last test. See How do you test a DRP?.

Degraded mode

If the four conditions are not met, the honest approach is to call it a DRP (recovery after an interruption) and to write down the degraded mode: which tasks can wait, which are noted on paper, who re-enters them afterwards. An “essential” application whose degraded mode can last half a day does not necessarily need a standby running all year round. The ANSSI, France’s national cybersecurity agency, recommends planning these workarounds in advance, because a cyber-related crisis can last several weeks.

Licences and software vendors

Some business software ties the licence to a hardware identifier, or prohibits external hosting. Check this before the outage. A standby that starts and then shuts down for lack of a licence is not a standby.

At WeDoBack

The BCP is designed for this case: cloud instances running permanently, an agent on the customer’s network, an IPsec VPN link, and takeover with no change of IP address. It therefore keeps the application reachable from on-site workstations as long as the agent and the local network exist. For the application database to be up to date on the instance, and for data entered during the outage to return to the repaired server, a specific replication or synchronisation process is needed: it is not built in, and WeDoBack can set it up on quotation. Instances start at 50.22 € excl. VAT per month, storage at 8.75 € excl. VAT per month for 50 GB. If the building is destroyed, this local mechanism is no longer enough: public addresses and remote access are needed, which fall rather under the DRP with public IP addresses (0.54 € excl. VAT per address per month). WeDoBack backs up SQL Server, Exchange and business software, and restores the server and the application if they were backed up consistently. It does not fix a database that was copied haphazardly: the database backup method is part of the implementation and must be tested beforehand.

Frequently asked questions

Can database files be copied like any other files?

That is not enough. A copy taken in the middle of a write can produce a database that the engine will refuse to open. You need a backup that understands the database (native backup, transaction log or quiescing). Microsoft also points out that a restore strategy only exists once the backups have been tested on a test system.

Does the standby need to be as powerful as the production server?

It must handle the number of concurrent users expected during the outage. An undersized standby turns a hardware failure into a performance failure. A somewhat more modest standby can be acceptable if the degraded mode reduces the number of users, provided this has been measured.

What happens if the whole building is destroyed?

Mechanisms that rely on on-site equipment (agent, appliance) disappear with the site. Users must then reach the standby from outside, through a public address and remote access reserved and tested in advance. This is a different scenario from a single server failure.

Planning a backup, DRP or BCP project?

More than 20 years of experience protecting business data.

Request a quote+33 9 72 50 78 28

Protect your data with WeDoBack

Encrypted offsite backup, immutable storage, DRP and BCP: tell us about your servers and we will recommend the right combination.