Hedge Fund Disaster Recovery Requirements: Part One
Hedge funds have known for some time the importance of effective disaster recovery, and regulation increasingly enforces this as a requirement. For any system to be effective, however, there are a number of factors which need to be considered prior to implementation. Eze Castle’s Managing Director Bob Guilbert recently sat down with HFMWeek to talk about the importance of disaster recovery plans for investment firms. Following is an excerpt of the article.
HFMWEEK (HFM): What are some of the key factors driving the increasing call for sound disaster recovery solutions in the investment industry?
BOB GUILBERT (BG): The increasing call is driven by regulation as well as the desire by the investment community to see best practices in operation. They want to ensure that hedge funds have robust business practices surrounding disaster recovery and business continuity planning in the event of some type of failure, whether it is a major disaster or something as simple as a broken pipe.
Factors like operational due diligence and regulatory areas are driving the overall need for robust disaster recovery solutions. Investor operational due diligence drives the need to see best practices deployed by the hedge funds themselves to ensure there is ongoing business operations in the event of some type of outage or disaster. Hedge fund regulations have always had recommendations for ensuring that people provide back-up and business continuity plans.
HFM: What are RPO and RTO and what is their significance as it relates to disaster recovery?
BG: Recovery time objective (RTO) relates to the amount of time are you willing to wait in order to recover your data. Typically this is described in terms of tape back-ups. If you want to recover data from a back-up tape, that could take anywhere from one or two hours to much longer to recover that data. You would have to retrieve the tape from its storage location, put it onto the servers and make sure that the data is out, all of which can take an enormous amount of time.
The recovery point objective (RPO) is how old the data can be. We can use the tape analogy to illustrate this as well. A tape back-up occurs every 24 hours, which means the recovery point is at least 24 hours old. If you were doing periodic snapshots, for example every four hours, this means your recovery point is at least four hours old. When making a choice in terms of disaster recovery, the lower the RPO and the lower the RTO is typically mandated by how much you are willing to spend on your solution. That is a very significant component in terms of what are you willing, as a company, to have as the minimum level of RPO and RTO. There are various technologies that can be deployed to achieve the different RPOs and RTOs, and typically the lower both of those are, the more expensive it becomes.
HFM: What technology is required as part of a disaster recovery solution?
BG: It depends on your RPOs and RTOs, but there are different degrees to which the technology selection is made. It ranges from baseline tape back-up to a concept called digital archiving, which we recommend. This involves not using tape but using digital storage instead, utilising disk drives to take snap-shots or copies of your data, which is either stored locally or in a remote location.
We provide a solution that enables our clients to have their data and applications captured in a real-time perspective and stored in a remote location. Most funds who want to be able to continue operating in the event of their primary or production data centre going down would have to deploy technology at a secondary site, which would have a copy of all of their data, as well as instances of their applications available to be re-started. With a local copy of data and a local copy of the applications, we can swiftly bring those applications back up online and enable the fund to continue operating as usual.
Disaster Recovery Resources:
Report: Establishing Disaster Recovery & Business Continuity Plans (20 pages)
Photo Credit: Commons Wikimedia