Contact Sales

A few days ago, my smartphone froze and refused to restart even after a hard reboot that involved removing the battery. I had to send the thing for maintenance, and as expected, it came back wiped clean. For a minute I imagined how I would feel if all my contacts, notes and photos were lost. This would have been devastating. However, I soon remembered that I had performed a backup two weeks earlier and that although I probably lost some data, I did not lose it all.

Computer systems have not only become an integral part of our daily life, but they have also become the primary method for most organizations to process and store data. For those organizations, protecting data and systems is essential because failures and losses may be very costly. In the case of a disaster, the difference between survival and closure is the ability to recover since the disaster may lead to loss of business, low productivity or legal actions, and not to mention, the cost of re-creating data.

Yet despite the obvious benefits, we often neglect performing regular backups. Even worse, the majority of those who do take backups neglect to test them regularly to make sure that they are usable if needed. Having an untested backup will give a false sense of security that may lead to disaster.

RAID is not backup:

If you store your important data (like honeymoon photos) on a hard disk drive and it fails, you may lose them all. Putting your data on a Redundant Array of Independent Disks (RAID) can protect against a disk failure, which is a good and important thing to do. However, RAID is not really a backup because if someone deletes those folders by mistake, they will be removed from all disks in your array. If you do not have a backup you may not be able to get them back.

Putting your backups on another hard drive inside your system may also seem like a good idea, because if you lose the active data you will have another copy to restore from. However, if a virus corrupts your data, having your backup online inside the system makes it vulnerable. So you'd better have it somewhere else, but where?

Choose carefully where to store your backups:

A USB flash disk loses data with time if left on the shelf. They say that it takes up to 10 years, but I lost some info off of a USB after less than 5 years. In addition, UFDs are easy to lose altogether. My mother has lost a couple of those that had important data backed up to them.

Although optical disks tend to live twice as long, a friend of mine who was storing his in an unhealthy storage room showed me fungi eating a few of his younger CDs. After all, they are made of organic material and putting them in a moist, dark, warm place is a sure way to speed up the process of deterioration.

Tape, on the other hand, can live longer, can store a large volume of data and is removable. This makes it ideal for offsite backups and the ideal choice to back up your organization's data. I personally have a NAS device on my network, but away from my PC, to store backups. It may not have as much space as I would like, but it offers me the possibility to schedule online backups and perform fast restores if needed.

Storing your backups away from your live system is very important for disaster recovery since a fire, for example, can destroy your backup along with your active data if you were storing both in the same room! Offsite backup options need to be considered for all businesses. Even if you cannot ship your backups offsite, try at least to store them in another room in the building.

Backup Strategy:

The first step in putting a sound backup strategy is to understand your system requirements. Make sure to understand what needs to be backed up and how often you need to back it up. Recovery point objective (RPO), which describes how much data lose is tolerable in case of major incident, is an important thing to consider as it dictates how often you need to perform a backup and how often you need to ship them offsite. This, in addition to the amount of data you need to backup, will determine the size of your backups.

In light of your requirements, you can select the backup method most appropriate to satisfy them. You need to consider both hardware and software. Usability, scalability, compatibility, support and centralized administration are all important aspects to take into account when selecting the right backup methods for your needs.

You also need to have a documented backup policy describing how often to back up your data and what exactly to back up. The backup policy depends on the importance of the information and the acceptable risk to the data owner.

A simple backup policy usually revolves around one of the following backup types:

• Full Backup, which as the name implies takes a backup of all data. Since all data is being backed up together this means that restoring it will be much easier, however this also means that it may take a long time to execute and the data taken each time may not be very different from the backups taken previously, as most files rarely change.  Yet the major disadvantage of full backups is that because they are relatively large, they tend to take a long time to perform. This makes performing them often impractical and you will have considerable gaps between full backups taken. Those gaps are generally filled by one of the following two methods.
• Differential backup only takes a backup of what has been changed since the last full backup. This means that if you take a full backup on Sunday, on Monday you only need to backup the data that changed during Monday. Similarly, on Tuesday, you will have to take a backup of data changed in both Monday and Tuesday. Same on Wednesday. When restoring a file that is lost on Thursday, you need the full backup taken on Sunday and the differential backup taken on Wednesday. This can be a good compromise, but the size of differential backup will increase each day during the cycle until the cycle is restarted by taken another full backup.
• Incremental backup is a bit different from differential backup in that only changes made that day are backed up. Like with differential, if you take a full backup on Sunday, on Monday you only need to backup the data that changed during Monday. However in contrast with a differential backup, on Tuesday you only need to backup the data changed on Tuesday and on Wednesday you only need to backup the data changed on Wednesday … etc. This has the obvious advantage of reducing the size of the backup taken each day and the time needed to take it. However, the price you have to pay is that if you need to restore a file lost on Thursday, you will need, in addition to the full backup taken on Sunday, the incremental backups taken on Saturday, Monday, Tuesday and Wednesday.

Now that we have our backups, are we done?

Unfortunately, many in the industry tend to think so, or at least act as if they think so. There's more to this behavior than simple laziness. Many admins tend to provide support in a fire fighting mentality and believe in crossing a bridge when reaching it. They may justify that by saying “If it is not broken, do not fix it” since restoring backups just to test them can be a daunting task that requires time and resources.

However, a good backup strategy must also include the following three important best practices.

Test your backups:

There is a myth that wiser older admins tell younger admins that goes like this: Once upon a time, an admin convinced his management to invest in a backup strategy. He bought the tapes, the tape drive and put a backup schedule. He followed the schedule strictly and he even took the tapes with him each day to store at his home safe vault where he felt that they would be secure offsite if anything happened.

One day something broke and he was eager to show his management the benefit of the backups he had been performing for so long. He got the most recent tape, but he found nothing on it. He got the previous one and there was nothing there. Actually, none of his backups had any usable data! It turned out that his vault was using a magnetic lock that had been erasing his tapes all this time.

Although, I seriously doubt that this has actually happened, the moral of the story is that if he had tested his backups much earlier, he would have caught this unexpected effect and he would have known not to put those backups in his “tape-eraser,” thinking that they would be safer and more secure there.

A more realistic scenario I've seen happen often is people failing to take backup to all the needed folders or not knowing what to do when the time comes to restore it. This also can be limited by testing the backups as you need to be prepared to restore the data.

Rehearse your restore procedure:

When something wrong happens to your data or systems, you will be under great pressure to restore it as soon as possible. Do not put yourself in a position where you do not know how to do it right. Making sure recovery steps are documented and making sure that everything will work as it should after you perform them is a key to any good backup strategy. Performing a test restore regularly not only ensures that you can pull it up when needed; but it also ensures that the backups themselves are functional.

I knew an admin once that was responsible for his enterprise website. He had automated jobs setup by the vendor to take the needed backups 4 times a day. One day, he needed to restore the website after a catastrophic loss, but he did not know what needed to be done so he called the vendor. Only then did he find out that he needed to install MySQL, PHP and a number of third party tools and configure them before restoring the backup. Once that was done, he had to rebuild the site; The PHP rebuild alone took more than an hour to complete. For a large enterprise that sells online, losing its website for seven hours was unthinkable, and resulted in the admin choosing a different profession!

Do not build your strategy around one person:

Best practice also dictates letting someone other than the one who wrote the restore procedure test it. An ideal candidate to test procedure is a person that has the needed IT skills but is not directly involved with the system. If you are the only one that can do it, then you have not documented it well. Also, keep in mind that we all tend to do some steps by default, and more often than not, those steps tend to be neglected when writing procedures. The problem with that is that someone else following the documents may not be able to predict the steps that seem so second nature to you. Even worse, sometime later you may change your habits and find it hard to follow the procedure that you once were able to.

I am sure that no admin likes to be dragged to the office from a vacation whenever a restore is needed. I am also sure that no employer likes the idea of business survival depending on one person being available 24/7, 365 days a year. So make sure that all IT procedures are well documented; restore procedures are not an exception.

Want to improve your IT skills? Sign up for a 3-day free trial to access TrainSignal's entire training library.