World Backup Day – 31st March 2017

There’s a day for everything it seems, isn’t there? At least there’s no reason to dress up for this one! I think World Backup Day is a really good idea, because even those of us who may think we have it all under control, we should use this prompt to question if we really do.

There are so many factors that can derail even the best laid plans, but there are steps that you can take to help mitigate such situations, entirely or at least partially.

Checking the validity of backups is all too often considered impractical, but I question if that is really true at all. There can be concerns over the time and effort it will take to test recovery from backup and a lack of resource to do it. This can be a valid concern; after all, I rarely speak to anyone who is more time rich in their teams than they were last year. Do you or your team find you have more spare time for tests than you have in the past?

Recovering files alone is not very helpful. That, in itself, doesn’t often provide a recovered system that is usable. There are OS considerations, drivers and customisation to make it familiar; all of that takes time to setup and use and may need to be blown away and re-setup for each test.

What about the kit needed to recovery to? Unless you are lucky, there is no bank of hardware just sitting there waiting to be used for a Disaster Recovery test. Some of the systems may be legacy too – so getting duplicate hardware or something remotely similar to recover to is difficult or perhaps impossible.

Ok, so you could try to find the time, try to find the kit, but how about ensuring it works once you have restored from backup? A count of files recovered is a bit of an indicator, but hardly enough to give you a high level of confidence that all will be fine in the world.

Everyone’s systems are different, so some basic checks will be a good start but maybe not really valuable enough.

Let’s not forget that recovering one system is not really enough, is it? For a truly valuable DR test, surely you’d need to recover all the dependent and connected systems too? Without that you are proving something, but maybe not quite enough. Recovering your connected machines to your production network could introduce more problems; probably bigger problems than the risk of being unable to recover from a backup – perhaps it’s best to forget all about it?

It should come as no surprise that I (and, probably, you too) know this is too important to simply ignore, but where it is ignored it is often for very explainable reasons and time pressures. Should disaster strike, those reasons start to become very questionable though. There is a way to overcome many of these challenges and to overcome them in a cost-effective, non-resource-hungry and quite do-able way.

This is where we come in.

Using Cristie software you can ensure when you recover a system you are recovering one that looks and behaves in a familiar way. This includes recovering the Operating System, favourites, shortcuts, application, drivers you are likely to need now (even where they were not present on the source machine) and the data you need.

Our solutions are designed to recover to dissimilar hardware, so that removes another blocker. Recovering to a dissimilar environment can enable you to recover to cloud or virtual environment (in addition to physical ones) so providing you with at-point-of-need hardware that can be released when not needed. This provides cost effective machine resource options and reduce reliance on spare and similar kit. Cloud is not a free resource, of course, but you can keep the costs down by ensuring that recovered systems are removed automatically if you forget. That can help eliminate some awkward conversations with the finance department when the bills come in.

In terms of testing the recovery – that can be easier too. Cristie’s software can check the integrity of the recovered systems, but also allow you to include your own customised scripts for post-recovery testing. This means that in combination, you can have both a solid level of confidence in the recovered system in general, but add in your own bespoke checks to increase reassurance further. In addition, the recovered systems should be usable, so if you wanted to give someone access to perform sanity checks, you can.

What about those connected systems? Cristie can help with those too. We have the ability to group systems together for recovery – even when they are spread across a range of Operating Systems and distributions. Further, the order in which the machines need to be brought live can be predefined, so all the dependencies can be observed. Issuing the boot commands in order is not good enough, we check to ensure the system is booted and running before it is fine to proceed with the next. Further, you can set isolated network environments to recover the machines into – so there is no need to introduce clashes and disrupt your production network; done properly, no-one will know.

Maybe the most important blocker of all has not been covered – when will you find the time to do this? Of course, a small investment would be needed to initially install the software or deploy our new Virtual Appliance, but setting up recurring simulations is quick and easy. It really is a set-and-forget process and many virtual or cloud environments can be released when not needed – so keeping costs and resources to a minimum. If there’s a problem, you will get an alert communication. You can check logs for extra confidence in recovery at any time, even when the recovered simulation machine(s) has long since been deleted. Once you have invested a little time, the recovery simulations can be set to run automatically into the future – so it is not an administratively intensive task at all.

All in this #WorldBackupDay is a great idea and the more people that get involved and ‘take the pledge’ the better. More details and information can be found at www.worldbackupday.com or browse our BMR solutions here

Tony Davey MBCS
Group Product and Project Manager