DRaaS works for all environments with servers getting fully replicated to a remote site. It is applicable for all environments whether file servers, applications or databases.

One example that I can think of and have worked closely on is a Hospital’s HIS system. The application is installed on a Windows server and works on an MS SQL database at the backend. The database is hosted on a separate server and is connected over the internal dedicated network. Both are virtual machines hosted on separate virtual servers.

Both the along with the online MS SQL databases are replicated on cloud synchronously. In the event of a hardware, network or software failure on the primary site, the secondary site gets activated. Users application interfaces are configured in such a way that the users automatically get connected to the remote cloud disaster recovery setup.

Users can continue to work on their day to day activities seamlessly on the remote site. The data punched in the remote site is replicated back to the primary site once the primary site is up & running. At any convenient time, failback to the primary site is performed and the secondary site is left back to be the DR site only.

In order to ensure smooth functioning in the event of a crisis, we perform regular recovery drills. During such periods, both primary and secondary sites are running for sometime and application & data can be verified on the secondary site.

In event of network failure between the two sites or during the failover testing, a catalogue of changes at primary are maintained and replicated to secondary once the network/testing is completed successfully.

1. Build your disaster recovery site without building a disaster recovery data centre. You can utilise the service provider’s resources as your data centre. Helps reduce the cost of data centre and hardware required for building the disaster recovery site.


2. Monitoring basic activities like online replication should be included in the service provider’s SLA. You do not need a monitoring team for monitoring these activities.


3. Your application and database team need not worry about rebuilding the application or restoring databases. With DRaaS you can leave multiple low cost incremental snapshots that can help restore back to an older point in time. Sometimes, it might be faster to rebuild a DR site than recovering from a backup to refer to an older version of data. DRaaS would be scalable & flexible so retaining multiple older versions would need huge storage investments.


4. Disaster Recovery Drills can be automated and DR sites can be left live even if the primary site is still working.

The primary purpose of building a disaster recovery site is to make sure your application & databases are available in the event of complete primary site failure. Regardless, in this case, primary site failure could even be an earthquake demolishing the entire primary data centre building.

However, a typical example of recovery in disaster management is recovery back to the latest database in event of primary database failure. Another good example is when you need to quickly check a suspected record deletion and want to refer to a few minutes or a few hours back data. You can initiate a DR test and check the data on the DR site database.

In one of the scenarios, we recovered the database on the DR site and linked the primary site application to read/write directly to the DR site database and it worked seamlessly.

1. Backups take time to complete and therefore there needs to be a time gap between two backup cycles v/s replication is online as explained above.
2. Backups are stored in the non-native format (Typically proprietary of the backup application) while replicated data (DR) is in the native format. Replicated data is always ready to use while backups need time to recover.
3. Backups need to be recovered with the same backup application whereas replicated data is readable in its native format with no dependency on any third party application.