disaster recovery

Is anyone responsible for this at their current company?

I will be doing a lot of this soon and just looking for pointers.

I am going to focus at regular off site backups, some sort of quarterly, bi annual and yearly exercise, and regular restores for testing.

Any other advice, tools, theories etc would be appreciated.

Thanks ladies and gents

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

Devilsbane

Just make sure you test the backups. Having a closet full of blank tapes helps no one.

erpadmin

Another thing to keep in mind is do you have a secondary site in place in the event the main site is completely kaput due to some disaster (natural or manmade) that can keep the business going? (Hot site, cold site, warm site is what you want to look for...)

bighornsheep

The first thing you want to do is work with your senior management and executives to determine the financial implications and the business impact. This will give you two very important metrics: Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

RTO is how much time do you have to recover and RPO is how much data are you willing to lose. Based on the RTO/RPO values, you can determine your disaster recovery strategy, whether it's something more basic with just offsite backup and some sort of secondary facility with hot/cold equipment or something much higher end with replication and high availability clusters, etc.

This is a MS Exchange specific graph, but in the general sense, it applies to any other IT applications. On the slower end of the RTO (>72 hours), you're looking at traditional backups; on the higher end (<4 hours), you will be implementing highly available clusters with replicated disks.

http://i.technet.microsoft.com/cc137990.fig02_L%28en-us%29.gif

dynamik

Liven, it'd help if you'd provide a little more details. I've worked with organizations ranging from those that backup to a USB drive to others that have a fully redundant hot site. As BHS alluded to, any advice we can give will depend upon your goals and needs.

sidsanders

bighornsheep wrote: »

The first thing you want to do is work with your senior management and executives to determine the financial implications and the business impact. This will give you two very important metrics: Recovery Time Objective (RTO) and Recovery Point Objective (RPO).

RTO is how much time do you have to recover and RPO is how much data are you willing to lose. Based on the RTO/RPO values, you can determine your disaster recovery strategy, whether it's something more basic with just offsite backup and some sort of secondary facility with hot/cold equipment or something much higher end with replication and high availability clusters, etc.

This is a MS Exchange specific graph, but in the general sense, it applies to any other IT applications. On the slower end of the RTO (>72 hours), you're looking at traditional backups; on the higher end (<4 hours), you will be implementing highly available clusters with replicated disks.

http://i.technet.microsoft.com/cc137990.fig02_L%28en-us%29.gif

indeed... hard to implement dr without doing the above. i have seen folks bail once they see the costs to do what they claim they "need". many cant get past some of the leg work to get to the point of knowing what they need. too much political fighting and folks not really knowing what they even have... searching can lead to rolling over of rocks to see some messy things living under them at times.

just note as others have said, backups are only part of the equation... restoring a little used app/server before the critical items may not be good -- hard to prioritize restore routes if you dont know whats critical, how fast it needs to come back, etc (post quoted is $$$ on this point).

brad-

Make sure you take consideration for email if you have exchange, and databases.

Have an offsite to house your tapes or copy another backup.

Test your restore ability regularly.

Document it.