This is Part 1 of a common topic of discussion to achieve greater recovery point objective (RPO). This part will cover how backups can achieve your RPO requirements. The next part will cover how snapshots and point-in-time (PIT) copies can further achieve your RPO requirements.
Let’s keep things simple.
If you are reading this you may fall into 3 main categories:
- You are proactive and are looking at ways to avoid a data loss disaster.
- You have experienced a computer disaster and NEVER want to experience that again.
- You have just experienced a computer disaster and don’t even know where to start.
If you are one of the first 2 above, then I commend you. You are on your way to live stress-free computing.
If you are last on the list then I feel for you. This guide will not relieve the immediate pain you are experiencing but I would refer you to other locations on this web site to get assistance. At worst you are now equipped to avoid this experience in the future.
Computer disasters such as hard disk crash (aka “crashes”), DO occur. Do not be fooled. It is not IF but WHEN they occur.
You will never, NEVER stop a disk from failing. The aim is to minimise the impact that the failure will have on you and your business WHEN it occurs.
So why are computer disk failures called a ‘disaster’? Because they are!
Computer disasters, such as a hard disk crash, can cause all sorts of stress and anxiety.
The value or cost of data, in many circumstances, cannot be measured. Cost can be personal or in dollar terms. For instance:
- If you are a mum, how much are your baby photos worth?
- If you are a doctor, how much are your patients’ medical records worth?
- If you are an accountant, how much are your customers’ financial records worth?
- If you are a business owner, how much is the loss of orders and invoicing going to disrupt your operation or even your ongoing existence?
If it was YOUR data, what will it cost YOU if it was not available?
More on Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) on another post. Stay tuned.
Computer Disasters in General
A computer disaster (computer system, mobile phone, tablet, camera – anything that can store data) occurs when the data is unavailable or lost.
The disaster is measured in terms of the cost associated with the data been offline or completely lost.
Data Offline = Disaster
Data Loss = Greater Disaster
There are many causes that can lead to a computer systems disaster.
- hardware failure
- software failure
- data corruption (bad code, bad update, power fluctuations)
- accidental removal or deletion of data
- malicious acts (including ransomware)
- environmental (fire, flood, earth quake)
Here’s how to get started:
Step 1: Back Up, Back Up, Back Up.
Back up, back up, BACK UP!
This means that you need to actually do it. Sounds obvious but the common situation is people concentrate on the type of computer and storage systems (or other devices such as mobile phones, cameras, etc) and overlook to how to back up what you’re going to store and run on it.
Let’s elaborate things first. When we refer to backing up a computer, we can apply this discipline to any computerised device that stores data. This does not just refer to a laptop. It includes larger servers, mobile phones, digital cameras, memory sticks, etc.
In fact, BEFORE you begin to use the computer (or device) as production (ie run your business or personal information on it) you should have thought about how and when that device will be backed up.
‘A’ backup is better than ‘NO’ backup.
There are many backup applications and utilities available from a multitude of vendors. All operating systems (computer, mobile phone, etc) even come with copy or basic backup utilities that assist with this process. So, use them. There are far too many for us to cover points on all of them here especially when so much is already available from the vendor and the net. But start here: http://en.wikipedia.org/wiki/List_of_backup_software
Step 2: Back Up Everything.
What do I back up”?
The question then arises, “what do I back up”? If in doubt back up everything!
‘A’ backup is better than ‘NO’ backup.
If you know your data intimately ie the data structures, data dynamics, data characteristics and data flows of the applications running, then you can make more informed decisions. These include knowing what data is stored in what directory, what data is changed daily / weekly / monthly, what folders store the binaries or executables versus the actual more valuable data, etc. By having this advanced knowledge, you can determine what critical data MUST be backed up daily such as invoices versus what can be recovered by more readily available means such as an operating system.
Your backup plan or design must consider all potential hardware and software faults. Therefore, your recovery or restore must be tested against these sorts of problems.
If your laptop had a faulty screen it’s unlikely that you’ll run for your backup unless you need to recover to a new laptop. However, if you’ve experienced a fire in your office and all your data is lost, you’ll want that backup somewhere off-site and readily available to recover to new systems.
I can see why hardware can fail, but what about software? Can software fail?
Yes, it can. Not meaning to be critical of bad coding or updates but they do occur.
Or worse what if your data was accidentally delete by a wrong procedure? ie you meant to purge the financial records from July 2007 not 2017?
Or worse still if your data was encrypted by ransomware?
What do I back up to?
Wow, there are so many options there is no excuse not to back up.
Options (and not limited to):
- shared storage
- another laptop
- another phone
- other external non-disk media
- CDROM, DVD, WORM
We will be posting content on many of these topics soon. For now, feel free to contact-us. There’s also plenty of great information on the internet that cover the workings of all of these technologies.
We tend to favour hardware independence when it comes to backup mediums. This means that we look for technology that will provide all levels of flexibility such as multiple devices reading the same data, recovery speeds, proprietary nature of the products involved, etc.
However, you need to know your requirements first and then match them to particular features.
More about shared technologies such as SAN, NAS and Clouds on other posts. Stay tuned.
Step 3: When Do You Back Up?
The short answer is whenever your data changes.
Again, it comes down to understanding your data. If you only change (or alter) specific files every day, then just back up those files EVERY DAY. If in doubt back up everything.
Backing up every day???
It comes down to how much data are you prepared to lose?
There are some great really simple tools such as SyncBackSE or SyncToy (and many many more) which can help you automate and tailor basic data copies or backups to suit a variety of needs. Anything from scheduling when to start backing up to back up everything to just the changes since a certain time window (snapshots or point-in-time copies). These tools in particular are just file copy tools that manage copies from one drive to another but there are more advanced tools that perform more comprehensive backups including multiple clients from a centralised backup server.
Backups can be scheduled:
- differences only
- snapshots and point-in-time copies
Step 4: Never Trust Your Backup.
Do not trust your backup(s).
“But you just told me” … What an odd thing to say.
However, in our many many years in the industry as support engineers, we’ve seen (mostly) everything.
Backup medium can be corrupted or get damaged or burnt in the fire or stolen or compromised, etc.
Back up your data more than once.
Back up to multiple tapes. Do not use the same tape to perform your nightly backup.
Back up data to multiple locations. This can be to other hard disks, memory sticks, tape drives, etc. and geographical locations (ie off-site)
Most importantly you must also test your backup by simulating a recovery.
How is this done? Simple!
Make sure you can read the backup media and confirm that you can recognise the files and data structures.
Pretend that you need to restore an old version of a file and restore it somewhere else such as some other computer.
Too many times we see people and organisations (seemingly) back up their data to find that nothing was ever on the backup tapes.
In one particular case a large company had some data loss and attempted to restore from their backup tapes. Unfortunately, the tape drive had some problems six months prior and had some hardware replaced. The replaced hardware seemed to be working but was damaging the tape beyond the head assembly. The data on the tapes was completely useless as it could not be recovered. This organisation had to restore from six months previous and had to null out many outstanding invoices that had no paper trail. Somehow the operation survived but the cost was huge.
Get into the habit of doing this regularly (ie ALWAYS).
A Quick Note on Dependent Backups.
What are dependent backups?
A dependent backup refers to backups that have a reliance on another backup. This refers to differential or incremental backups.
A full backup of a system may be very big to perform every day and if applicable, a full and differential/incremental backups will suffice.
Such a backup system can be something along the lines of performing a FULL backup on Sunday and perform a differential (only the differences) backup every other day.
Differential backups, back up only the changes since the last full backup.
Are they any good?
Yes. In many cases they suit. They can be very quick to perform. However, do not forget what is involved in a recovery / restore or your data. The recovery / restore procedure requires all the tapes up to and including the last good full backup. They can take a long time to restore.
ie The-FULL-backup + differential-1 + differential-2 + etc
In the case where I do a 1 week cycle of FULL backup on Sunday and differential every other day, then in the event that a crash occurs on Friday I will require the following tapes:
Restore = SUNDAY + MONDAY + TUESDAY + WEDNESDAY + THURSDAY
Let’s hope that all tape are good. What if my schedule was over 1 month? Don’t!
It would be recommended that you copy each tape and always keep one set off site.
It is a balancing act. So when designing your backup plan, consider the backup and recovery procedures.
Congratulations getting this far.
I hope this article equips you with an introduction to backup system considerations to make informed decisions. At least be able to ask the appropriate questions when considering backup systems.
If you have enjoyed this special guide or require assistance with more complex backup systems or architectures Contact us.
Stay tuned for the next part of this article which will cover how snapshots and point-in-time (PIT) copies can further improve your RPO requirements.