In conjunction with the first, second and third commandments … are you seeing a pattern here? By following each of these simple commandments, you are providing additional layers of defence against the evil doers. This is what security experts refer to as Defence-in-Depth. The more precautions you take, the more difficult it makes life for the bad guys, so they move on to easier targets than you. Anyway back to today’s commandment – Backups.

They are not sexy, but they are an absolute ESSENTIAL (note the amount of emphasis here) part of your protection. If you don’t have a backup of your data, you will lose some or all of it and you may not be able to recover from that loss. It is that simple. If your data is important to you, BACK IT UP!

You may have heard of this reasonably new phenomenon called Ransomware, which scrambles all your data and you have to pay good money to some bad guys to get the key to unscramble your data. Well guess what? If you have good backups, you can tell the bad guys to take a long walk off a short plank. You simply wipe the affected machines and reload from backups. Granted this takes time and money, but at least it’s not funding criminals. If you have bad or non-existent backups, then:

Anyway, backups – what do you need to do. First of all identify where all of your data is stored within your organisation. Then categorise it by how volatile it is (how often does it change) and how important it is to you. Next decide how long (of a time period) are you willing and able to suffer a loss of the data (e.g. can you restore from last night’s backup and re-key all of the day’s transactions from printed dockets). Finally decide how long you are willing to wait before the data is restored and you are back up and running.

With all of that noted, you can devise a backup plan that should suit your needs. I will cover the creation of a plan in a future article, but for now just make sure you are backing up everything and safely.

You also need to verify on a regular (quarterly/bi-annual) basis that the data you are backing up is usable. There is no point in backing up data that may be corrupted on the backup medium, such that when you need to restore it, that it is useless. So get in the habit of restoring your data and checking it is correct and accurate.

Just keep one thing in mind. Do you have to keep records of monthly or quarterly reports going back for a period of years? Are these stored on your main server and on backups? If so make sure that you have a separate set of backups for this data, that does not get overwritten on a regular basis. If you only have a set backup rotation that gets overwritten every few weeks or even every few months, then an accidental deletion of one of these monthly reports, may mean that within a few weeks/months the deleted report will vanish from the backups. So backup vital data separately.

That’s all there is to it. I will continue below with some details on the subject of backups. So if you are not interested in such particulars, just make sure your data is backed up and verified.

For a small business, your data is probably being backed up to a (Re)Writable-DVD, USB stick or External Hard Drive. 

For a medium business, if you’re using physical media, it is likely tape or disk cartridges.

These are all great physical media but here’s the thing – do you store these backups in the same building as where your data is currently stored (Desktop, Laptop or Server)? If so, then if a fire strikes, your data and all its backups could be lost. You will be up an unmentionable (this is a polite blog) creek without a paddle J.

The backups might be in a Fire Proof Safe, but these are only rated for a certain length of “burn-time” before they are no longer guaranteed to offer protection from flames. However the internal temperature of the safe may raise sufficiently within that burn-time to damage the media stored within. Can you take that chance?

You need to move your physical backup media off-site at the earliest possible time after it has been backed up to. Simple as.

Bigger Enterprises should have a well documented, maintained and tested backup and recovery process. You may have the greatest backup process in the world, but you do not want to be testing the recovery process under the duress of a disaster. So make sure you test the recovery process and backup media regularly.

One final consideration in respect to physical media – If your current infrastructure is destroyed and you have the backup media in your hands, have you got the required hardware and software also stored off-site or available at short notice to be able to read the media. For most of the above mentioned media, the physical side shouldn’t be an issue, but you might want a copy of any backup software that you use held off-site too. If you are dealing with Tapes (particularly) or some unusual disk cartridge unit, then you should ensure that you will also have a compatible drive available with which to insert the tape/disk cartridges. Bear in mind that these backup units change every few years, and while they do try to maintain backward compatibility, you might end up with tapes/disks that are no longer readable or even supported.

“I’m backed up in the cloud, so I’m safe from fires and floods.” 

Indeed you are, but are you backing up everything you need? Cloud services can be expensive for the amount of data they store, so you may only be backing up a subset of your data – hopefully it’s the important subset.

Perhaps you have splurged and you are backing up everything. Great – but how secure is that back-up? Is it encrypted on the storage provider’s servers? Is the data encrypted when it is en-route to the servers? With the mainstream providers (Apple, Google, Microsoft, DropBox, etc.), it should definitely be secure. You might want to check if you are as secure if you are using other providers.

How are your backups configured? Are you replicating/synchronising all changes made on your local data store to the cloud data store? What happens if somebody accidentally deletes a file? Sure it can be recovered from the recycle bin and possibly by a similar function on the cloud servers. But what if the file’s absence is not noticed for 3 or 4 months and it has now vanished from the recycle bins? This is where generational backups might come in to play (see below).

What happens if the provider has a significant outage (Google Drive was offline for 3.5 hours at a peak business time), or worse suddenly closes down (MegaUpload servers were seized by the FBI. While there was no doubt a lot of illegal material on those servers, there was much more genuine business data which was suddenly completely inaccessible by its owners)? Are you ready to cope with such a possibility?

“I have multiple sites and am replicating/synchronising my data between two (or more) locations.” 

This is good position to be in, as all the elements of it are within your control. The same issues that affect the cloud backup would also be at play here.

Site-to-Site replication introduces some other risks though:

How close to each other are these sites? 

In situations where there are typically no devastating storms or floods, I would suggest that sites should be at a minimum of 10 miles/15 kilometres apart to help avoid the impact of localised problems. In areas affected by Hurricanes, Tornadoes, Earthquakes or Floods I would suggest that sites should be several hundred miles/kilometres apart and not prone to being affected by similar disasters. 

Are any of the sites prone to flooding or storm damage?

If so, these should not be used to store the data of any other sites. Rather the data of such sites should be stored at more secure/stable locations.

Are they close to a government office, Airport, Military base, Explosives or Chemical factory?

This list could go on, but essentially what you need to determine is whether your site is close to “something” that might attract a situation (e.g.- extensive rioting) or may cause a localised disaster (e.g.- fire at an explosives plant). Whatever the situation, you need to consider the affect it might have on your operations (e.g.- will the police cordon off an area for an extended period of time).

“My IT guru says we don’t need backups, as our servers have this thing called RAID which protects them from data loss.”

RAID is a good thing to have, but I’m afraid that person is no guru. RAID is not a backup. All it does is introduce a level of resiliency in your data storage which reduces the impact of a hard disk failure. There are different types of RAID, some can tolerate the loss of only a single hard disk and others the loss of two hard disks.

You still need to have backups even with a RAID set-up.

These are typically from the era of Tape backups, but a lot of modern backup software still implements these methods even in disk and cloud type backups.

There is an easy way to think of a generational backup is Grandfather-Father-Son or GFS (the female equivalent is also valid J). This is a three generation backup. You can have a two generation backup too (Father-Son) or more than three (whatever number you want really). When you do your backups, you rotate through the three sets of backups, overwriting the oldest backup with the newest data.

So in the simplest set-up, say you want to set-up a daily backup of all data using the GFS method. You therefore have three sets of media, one for each day. This is from the start of the backup series, for a five-day week:

With this set-up though, you need to consider that if somebody deleted a file from the data store on Thursday, then after the following Monday’s backup is run (overwriting Wednesday’s backup), the deleted file will no longer be recoverable.

So you need to define a generational backup that will suit your business needs. This could be a combination of generational backups. You might have Monday-Thursday daily backups run over a three rotation (3 Mondays, 3 Tuesdays, etc.), then have Friday full backups stretching back for 12 weeks. Supplementing this, if you have special Monthly reporting a separate archival backup (i.e.- one that is not overwritten) is taken of that monthly data and stored safely. It’s whatever your business determines that it needs.

Again, from the era of tape backups, where a full backup might take a very long time to run, comes the notion of Incremental and Differential backups.

So Full backups does what it says on the tin. A full backup is made of all of the data in the data store, regardless of whether it has been added or changed since the last backup. This may take a long time to run depending on the amount of data and the speed at which it can be written to the backup media.

Both Incremental and Differential Backups need to be based on a Full Backup having been run at least once.

An Incremental Backup is a backup of data that has been added, changed or deleted since the previous backup (no matter what type that was). This will always be the quickest backup.

A Differential Backup is a backup of data that has been added, changed or deleted since the last Full backup. This will gradually get slower and slower until a new Full Backup is run.

So typically these are implemented by way of taking a full backup at some point in the day/week and running an incremental or differential backup for the remainder of the day/week. 

In previous employments, I usually took the Full backup of a Friday night (as the backups might run long into Saturday). Then on Monday through Thursday I would take an Incremental or Differential backup.

As mentioned above, incremental backups would always be the fastest and Differentials would gradually get slower. The trade-off with regards to this though is when it comes to restoration. The Differential could be much faster, depending on when the restore is needed from.

So using an example of a disaster happening on a Thursday morning and you need to restore all of your data from Wednesday night:

Incremental:

Differential:

So in the Differential scenario you just needed to restore from two backups as opposed to four backups in the Incremental scenario.

If you can do a Full backup of your data every day of the week, that would be the best, but if it impacts on daily operations in any way, then chose a method that suits your business.

If you have any comments, suggestions or questions on the above, please leave a comment below.

Do you have a Commandment for Cyber Security to add or any thoughts on those that I have listed, if so please let me know and I will do a follow up after I have completed the run through.