The term "IT data recovery" is applied to two very different activities with very little in common. The first one is continuity. Continuity includes documented processes, tested restores, a failover process, an ordered list (from most critical) of the items to be brought back online during an outage, as well as a person identified as responsible for making those decisions. All of these are part of the planning process; they are all completed before an incident occurs; and without them there would likely be little or no opportunity for a business to keep trading through an event. The second is salvage. Salvage refers to a particular piece of storage (for example a disk) that has failed or been destroyed, and someone will have to recover the data from it. This is bench work. It can only occur after an incident has occurred. Regardless of how much planning goes in, at some point someone still needs to do the actual salvage work.
Many people do not realise this distinction (the difference between the recovery plan and the salvage work) because the two are often sold together, and they cross over at exactly one moment: when the restore fails. Prior to that instant, the plan is working as intended. However, after that instant the plan does not have anything else to provide, and the issue becomes physical in nature: what was stored on that disk, and can it even be read? Even if a company has a solid recovery plan in place, at some point or another they will find themselves calling a data recovery bench. If they don't have a plan in place, they end up there in a much worse mood.
This pattern has a local shape. Mid-Norfolk's agricultural and food industries run production, traceability and cold-chain records using systems that were specified many years ago and which have quietly been allowed to bear all of the weight (a line PC in a room nobody visits; a camera recorder capturing a process that some auditor will one day want to view). If one of these pieces of equipment fails then the loss will be both regulatory and commercial. At Great Yarmouth, the offshore wind supply chain generates and stores survey information, inspection reports and project archives on kit that spends the majority of its time being carried, and portable drives living in bags fail for reasons that are purely physical.
Then there is the research side. There is a large volume of data generated by researchers at both Norwich Research Park and the University of East Anglia (UEA) which remains in only one location for longer than anyone likes to admit: a postdoctoral researcher's external hard disk drive, an instrument PC with a local capture folder, or a laptop taken home each evening. None of this is negligence; it is what happens when the researcher who generates the data is also accountable for it while working towards a grant deadline. The usual causes apply here too: dropped external drives, dead laptop hard disk drives, and a Network Attached Storage (NAS) device that ran for six years on disks purchased together and then failed two of them within two weeks.
Firstly, keep one copy offline. A second drive on your desk is not offline. A share on the same network, or a sync folder that faithfully mirrors deletions, is not offline either. Keep it offline or genuinely off site, rotated, and boring. Secondly, test a restore. An untested backup is a belief, not a backup, and don't wait for the moment it fails to discover this difference. Restore something real, quarterly, and time how long it takes.
Thirdly, write down what matters and in what order: which system has to be up first, who decides, who can be told. Half the cost of an incident is because of people standing around waiting to get permission. Fourth, and this is the one that actually saves the data: do not touch failing hardware. A drive that has started clicking, a NAS halfway through a rebuild it will not finish, a server that reboots every few minutes; with each further attempt to make them work, less will come back. It would be helpful to put the following statement on your wall: an array is not an archive. The purpose of RAID is to allow trade to continue as normal when a single disk dies. RAID provides no protection for other types of disaster, such as a deleted file, an encryption run, a pipe bursting, or a poorly completed rebuild.
Turn off the affected machine (do not let it keep trying), and do not start or continue a rebuild. Put a label on each disk to indicate which bay it came from before anything moves. That information will be very valuable later, and it will be lost forever if someone tidies the disks into a box. Call 0800 689 0668 and tell us what it is stopping. The job is flagged on this call and goes to an engineer as soon as it arrives, instead of going through the general queue.
Once you receive a quote (via telephone or our free online diagnostic), please send us the storage, not the whole machine. Tracked and insured post delivers your storage to the Cambridge bench the next working day from anywhere in Norfolk. Alternatively, you may use your own courier if your firm already has an account, booked and paid for by you, or someone can drive it to the Cambridge desk. We do not collect, so none of the steps in the recovery rely upon a van arriving. Each disk is imaged separately before we start rebuilding, so nothing is ever risked on a live rebuild. The free diagnostic is finished within 2 working days of the storage arriving, and a fixed price quotation is prepared before any chargeable work is done. We will happily work alongside your own IT staff to get the best possible outcome.
An array is not an archive. RAID is in place to ensure that if one disk dies you will still be able to trade this afternoon. It protects you from none of the other things which might happen later (a deletion, a ransomware attack, a burst pipe, a rebuild that goes wrong); only a copy that is not attached to the system does that.
Free diagnostic inside 2 working days of arrival and a fixed quote; on logical faults you only pay if we recover your data. Start online or ring the freephone now.