Traditionally, DR consideration was mainly to protect from hardware failures. So using an internal DR approach would take into account failure of the production hardware/software to an extent that you would have to take action but not if a plane would crash your site.
Such an incident would be considered when using an external DR site. But nowadays the much more likely incident is ransomware. Encrypting your production equipment so that you might have to restore everything from scratch.
Still, ransomware does not invalidate any previous assumptions or scenarios. You should think of scenarios you might encounter and perhaps a few you do not expect to happen but COULD happen.
Then you should evaluate the approaches (internal vs external) and mark what is sufficiently covered with each to have your very own solution.
Every company has specific needs and ways-to-do-things, so it has to fit your company.
Management should then be presented with the solutions you came up with, what's in each of them prior to stating the costs. Costs should be not the primary factor for this decision. You must be able to afford it, of course. Back to the DR site question: the cloud is a convenient possibility these days, but consider the costs for restoring everything. This is often overlooked and leads to immense spending. Given the probability, you could even do internal AND external sites.
See https://www.rubrik.com/blog/pr... for an example of how to respond to a hurricane warning. I am sure you could accomplish this with other solutions too. You just have to have the idea to do so.
In my experience, the two major factors to consider are:
1 - Capital vs Operating budget
2 - Internal staffing
Internal Pros:
- you have a lot more control over the infrastructure and how you use it.
- Operating expenses are generally lower than external and only moderately higher than not having a DR site. Maintaining two sites does not double your budget, and doesn't rquire double the staff, depending on how you use the DR site.
- You can use the DR site for testing and development, within reason, without compromising your recovery capabilities. We found that many vendors won't charge a full license for DR and testing.
Internal Cons:
- Capital expenses are a lot higher - you now have two sites to maintain and keep in synch. The biggest trap is to skimp on upgrading your DR site and then finding out some back level piece of hardware stops a major application from running.
- you have a lot more control over how you use the DR resources. This is both a pro and a con. One organization I worked for hurt themselves because they (we) felt we needed to use this equipment that was "just sitting there" sucking up money, so they found uses for it that ended up causing conflicts when needed for DR. Fortunately, we discovered this during testing and scaled back on how we used the site.
External Pros:
- Should be almost no CapEx. The vendor should be responsible for maintaining the infrastructure, but you need to factor that into the contract and your primary site refresh cycle. Too often and the vendor will expect you to pay extra and too long, you will risk getting out of synch.
- Don't need the staffing for two sites. While not usually doubled for Internal, you should be able to fully run the external DR with the same staff.
External Cons:
- Higher Operating Expenses. Can be even higher than factoring in CapEx for Internal, but shouldn't be. Of course, when the disaster hits, expenses will increase, plus you are dealing with trying to recover from the disaster at you primary site.
- More of a risk than a con, but you can easily forget about the DR site when you upgrade your infrastructure and/or apps and don't keep the DR contract up-to-date.
There are more on both sides, but in the interest of time and space, I will leave it at these.
System Analyst at a financial services firm with 501-1,000 employees
Real User
May 26, 2020
I think the most important things a business should consider first is the importance of the system in question. If it is mission critical then consider an offsite DR location. Money would need to be spent on the application performing the backup and the bandwidth to the DR site considering it should be able to run the system. If the system in question is not mission critical then a local backup would be more cost effective. So the main decision that needs to be made is the criticality of the system to be backed up. Money is, of course, a consideration, but should not be the first consideration. I am able to control out offsite backups as if they were onsite. This is made possible with using our own servers and have a lot of bandwidth. There is a cost factor using your own equipment so that needs to be taken into consideration. There are pros and cons to both but I believe it should start with how important are the things you need to back up as this sets the stage for future decisions.
Choosing an Internal DR site as a backup has three main benefits, which are cost, control and communication Quality of Service (QoS). By placing the DR site internally, you'll have full control of its operation. In addition, the communication infrastructure between production and DR site is typically done through robust LAN networks, which offer very high QoS. Since all infrastructure reside internally, cost is typically reasonably under control. The disadvantages of hosting the DR site internally, is that this setup mainly protects you against human and infrastructure errors. It does not offer protection against "force majeure" events such as power outages, fires, storms, etc. Hosting the DR site externally also protects you against human and infrastructure errors, plus you have the added advantage of geographical redundancy, which adds additional protection against major calamities at the home site. Of course hosting the DR externally has its disadvantages, which are mainly related to the added costs for implementing the external communication links and the hosting of the DR infrastructure in a remote site. Further more you may experience a decrease in control and communication QoS that comes with hosting the DR site externally. At the end of the day it boils down to: "How critical is my data and how much can I afford to protect it."
Disaster Recovery (DR) Software ensures business continuity by facilitating data recovery and infrastructure restoration after unexpected failures. These solutions minimize downtime and protect against data loss, offering strategic advantages for operational resilience.These software solutions provide critical functionalities for rapid recovery, integrating seamlessly with IT environments to maintain data integrity and system availability. A range of configurations and features supports the...
Traditionally, DR consideration was mainly to protect from hardware failures. So using an internal DR approach would take into account failure of the production hardware/software to an extent that you would have to take action but not if a plane would crash your site.
Such an incident would be considered when using an external DR site.
But nowadays the much more likely incident is ransomware. Encrypting your production equipment so that you might have to restore everything from scratch.
Still, ransomware does not invalidate any previous assumptions or scenarios.
You should think of scenarios you might encounter and perhaps a few you do not expect to happen but COULD happen.
Then you should evaluate the approaches (internal vs external) and mark what is sufficiently covered with each to have your very own solution.
Every company has specific needs and ways-to-do-things, so it has to fit your company.
Management should then be presented with the solutions you came up with, what's in each of them prior to stating the costs. Costs should be not the primary factor for this decision. You must be able to afford it, of course.
Back to the DR site question: the cloud is a convenient possibility these days, but consider the costs for restoring everything. This is often overlooked and leads to immense spending.
Given the probability, you could even do internal AND external sites.
See https://www.rubrik.com/blog/pr... for an example of how to respond to a hurricane warning. I am sure you could accomplish this with other solutions too. You just have to have the idea to do so.
In my experience, the two major factors to consider are:
1 - Capital vs Operating budget
2 - Internal staffing
Internal Pros:
- you have a lot more control over the infrastructure and how you use it.
- Operating expenses are generally lower than external and only moderately higher than not having a DR site. Maintaining two sites does not double your budget, and doesn't rquire double the staff, depending on how you use the DR site.
- You can use the DR site for testing and development, within reason, without compromising your recovery capabilities. We found that many vendors won't charge a full license for DR and testing.
Internal Cons:
- Capital expenses are a lot higher - you now have two sites to maintain and keep in synch. The biggest trap is to skimp on upgrading your DR site and then finding out some back level piece of hardware stops a major application from running.
- you have a lot more control over how you use the DR resources. This is both a pro and a con. One organization I worked for hurt themselves because they (we) felt we needed to use this equipment that was "just sitting there" sucking up money, so they found uses for it that ended up causing conflicts when needed for DR. Fortunately, we discovered this during testing and scaled back on how we used the site.
External Pros:
- Should be almost no CapEx. The vendor should be responsible for maintaining the infrastructure, but you need to factor that into the contract and your primary site refresh cycle. Too often and the vendor will expect you to pay extra and too long, you will risk getting out of synch.
- Don't need the staffing for two sites. While not usually doubled for Internal, you should be able to fully run the external DR with the same staff.
External Cons:
- Higher Operating Expenses. Can be even higher than factoring in CapEx for Internal, but shouldn't be. Of course, when the disaster hits, expenses will increase, plus you are dealing with trying to recover from the disaster at you primary site.
- More of a risk than a con, but you can easily forget about the DR site when you upgrade your infrastructure and/or apps and don't keep the DR contract up-to-date.
There are more on both sides, but in the interest of time and space, I will leave it at these.
I hope this helps.
I think the most important things a business should consider first is the importance of the system in question. If it is mission critical then consider an offsite DR location. Money would need to be spent on the application performing the backup and the bandwidth to the DR site considering it should be able to run the system. If the system in question is not mission critical then a local backup would be more cost effective. So the main decision that needs to be made is the criticality of the system to be backed up. Money is, of course, a consideration, but should not be the first consideration. I am able to control out offsite backups as if they were onsite. This is made possible with using our own servers and have a lot of bandwidth. There is a cost factor using your own equipment so that needs to be taken into consideration. There are pros and cons to both but I believe it should start with how important are the things you need to back up as this sets the stage for future decisions.
Choosing an Internal DR site as a backup has three main benefits, which are cost, control and communication Quality of Service (QoS). By placing the DR site internally, you'll have full control of its operation. In addition, the communication infrastructure between production and DR site is typically done through robust LAN networks, which offer very high QoS. Since all infrastructure reside internally, cost is typically reasonably under control. The disadvantages of hosting the DR site internally, is that this setup mainly protects you against human and infrastructure errors. It does not offer protection against "force majeure" events such as power outages, fires, storms, etc. Hosting the DR site externally also protects you against human and infrastructure errors, plus you have the added advantage of geographical redundancy, which adds additional protection against major calamities at the home site. Of course hosting the DR externally has its disadvantages, which are mainly related to the added costs for implementing the external communication links and the hosting of the DR infrastructure in a remote site. Further more you may experience a decrease in control and communication QoS that comes with hosting the DR site externally. At the end of the day it boils down to: "How critical is my data and how much can I afford to protect it."