Print this page
Thursday, 21 May 2015 00:00

10 problems that may occur with data recovery plan

Rate this item
(0 votes)

b2ap3_thumbnail_Backup.jpgEven if the probability of problem is one in a million, everything would go wrong exactly when you expect it least. A bright example of such situation is a data recovery plan. Even a good data recovery plan can collapse due to a single small error. Below are the 10 problems and solutions you might face with data recovery plan.

1. Bad backups. There is nothing worse than to find out during the recovery that your backup cannot be read. When computers are used 24/7 it is difficult to make goo backups. Many apps do not work with backup software. Sometimes backups are stored inappropriately. There are problems with extra difficult backup applications that operate incorrectly. Plus hardware problems. The totality of these factors makes bad backups a reality. Only regular monitoring of the backup system and testing of backups can guarantee that backups are safe, readable and ready to use on demand. Bucking up should be on the top list of your IT requirements.

2. No recovery system. Backups are useless if you don’t have a way to start recovery system (for example, with live CD or any other way). You should face this problem while launching the recovery process. Recovery system should always be within easy reach.

3. No post-testing. Why recover the system if a day or two after you get the same problems? If the problem is associated with the system or applications, its reasons might be in backups (for example a virus). After performing backup you should check the operability of the system and applications as well as find out whether a specific issue, that pushed you to recover data, was eliminated. Initial testing should be carried out in advance, be clearly documented and its results should be saved. Second, as a rule, is done on the go and is determined depending on the situation.

4. No recovery equipment. Some think (or hope) that problems occur only with software (viruses, OS errors, etc.). That is why they simply do not keep backup equipment. However, when system recovery is not required, equipment replacement should suffice (if applicable). Optimal way out is to buy a set of servers to use one as a backup server that would be able to replace any other server as necessary. If equipment experiences problems that you will always be able to move it to a backup server. Yes, equipment is expensive and sometimes it is difficult to justify the purchase of an extra server. However, its cost is incomparable to the loss due to down time while waiting for the new equipment and parts to arrive.

5. No spare parts. Here are several main components that should always be at hand just in case:

  • network cables (long enough);
  • power cables;
  • hard disk drives (of required capacity and type);
  • RAM (of required capacity and type);
  • data cables;
  • disk controllers (if supplied separately from motherboards and servers);
  • additional keyboard, mouse and display.

6. No trial recovery run. Most popular but least used in practice tip: Test your recovery plan in advance. Most common cause why no one does it – lack of time. In reality, one does not need considerable efforts and time expenditure, especially if one has backup servers at hand. Make sure to allocate time and perform trial recovery run.

7. No possibility to recover data selectively. It is not at all convenient to run complete recovery process in order to dig out a single tiny file from a backup. In connection with shift towards backup of virtual machines but not file systems, this issue becomes even more common. Recovery plan shall provide for the possibility of selective recovery of separate files even if they are located on a virtual machine. Otherwise, you risk to lose more time than you have planned to.

8. «Shallow» backups. Not many companies posses sufficient budget to make all backups in a unique snapshot that is being constantly archived. One needs a schedule for performing backups of various depth and redundancy. A secondary backup can be performed every third day, secondary copies can be stored to the disk once a week and once a month one of such disks can be sent to remote storage. In addition, Exchange Server performs its own backup twice a day that is saved in the secondary system according to the same schedule. SQL Server performs its own backup once a day and its backup is also saved in the secondary system for 14 days. This will allow a company to restore quickly: recover all virtual machines from certainly good copies and then bring them to the virtual state with Exchange Server or SQL Server backups.

9. Too remote backup storage. If you use remote backup, you need some time to access data. But sometimes these data has to be acquired as soon as possible. Online backup is a convenient alternative to recording to physical media, but remember, to download a sizeable backup and extract several files from it you will need a geed internet connection. Make sure that you can easily access data from remote backups.

10. No printed documents. It is important to document the recovery process on paper. If your system fails you won’t be able to access files! Assume that you keep all documents on SharePoint web-site. But if SQL Server collapses, how will you access SharePoint? That is why you need to have printed paper copies of documents that may be required to facilitate the recovery process, preferably along with physical media (along with live CD and other materials). Hard copies should be kept updated. You can keep these materials in SharePoint, and then, by subscribing to RSS feed of documents list you will be notified in case some documents are changed.

Last modified on Thursday, 21 May 2015 13:54
Data Recovery Expert

Viktor S., Ph.D. (Electrical/Computer Engineering), was hired by DataRecoup, the international data recovery corporation, in 2012. Promoted to Engineering Senior Manager in 2010 and then to his current position, as C.I.O. of DataRecoup, in 2014. Responsible for the management of critical, high-priority RAID data recovery cases and the application of his expert, comprehensive knowledge in database data retrieval. He is also responsible for planning and implementing SEO/SEM and other internet-based marketing strategies. Currently, Viktor S., Ph.D., is focusing on the further development and expansion of DataRecoup’s major internet marketing campaign for their already successful proprietary software application “Data Recovery for Windows” (an application which he developed).