…What Should You Be Asking this Week?

Irvine, CA – How do you know your most important functions of your network are working?  How do you manage technical people whose work you don’t fully understand?  This week I have seven simple questions to ask and I provide you some tips on what answers you should expect.

Backup and Disaster Recovery is one of the most important functions in Information Technology management to assure the future viability of your firm.  But backup and DR is a function you don’t really know is working until you really need it and that is not the time to find out it is not working as planned.  My recommendation is that you bring this topic up in your next meeting with your IT team.  Here are the questions I suggest you ask:

1.       How is our backup system running?  (Let your IT person talk.  Be patient and don’t interrupt.  Let them tell you all they can.)

2.       Are we getting any error messages from the backups? (Error messages are not uncommon, but you want to make sure your IT person knows about them and that he/she is dealing with them in a timely manner.)

3.       When did you last test the backup system and how did it work?  What problems did you encounter?  (Your IT team should be doing this quarterly and if they are they should be able to give you some tangible feedback.  You should assess whether you think it is real and tangible feedback or are they making it up.)

4.       Assess for me how you figure we will fare when the time comes and we need to recover from an IT disaster.  (Listen to what they say and make a determination as to whether they have really considered how they are going to recover your operation or when that event happens are they going to be figuring out what to do for the first time.)

5.       What documentation exists for recovering from a server, storage or database failure?  Have you tested that recovery plan?  What were the results?  (This is a carry-over of the previous question.  If they can produce documentation on the process and it appears current and they know the content you are in good hands.  If there is no documentation or it is old or they don’t appear to understand and know the content then you as a manager need to direct them to put together a good plan and test it.)

6.       When the next disaster happens, how long will we be down… how long until we are up and running again?  (This is known as RTO or Recovery Time Objective.  If you both don’t know what this time number is in hours and agree upon it, then you need to do some planning.  Come up with a recovery time that is acceptable and make sure your backup and disaster recovery system can support your business need.)

7.       When the next disaster happens and we recover, how much data will we lose in the process?  (This is known as RPO or Recovery Point Objective.  This is the number of hours of work your company will lose from the time the failure happened to the point of the last backup.  If you both don’t know what this time number is and agree upon it, then you need to do some planning.  Come up with a recovery point timeframe that is acceptable and make sure your backup and disaster recovery system can support your business need.)

If you do have this conversation with your IT team you will be doing well for you and your company.  Asking these questions will let your IT team know that backup and disaster recovery is important to you and hence it will be important to them.  If you are an IT professional, you need to be prepared to answer these questions from your management.  This simple 10 minute exercise will bring you tremendous peace-of-mind and it will go a long way to avoiding unimaginable potential grief in the future.

If you don’t know how to answer some of the questions or don’t know how to figure out what your RTO and RPO should be, write or call me.  I have a handy tool that can be used by IT pros and management to figure out where you are now and where you should be as far as your recovery times.  I can be reached at 949 428-5000 x213 or toli@alvaka.net.  

 

PS.  Stay tuned for the next article in this series on Software Patching.