Remote Data Recovery Services

Transportation is a daunting obstacle when you’ve just lost data from a large RAID server or storage area network, and you may have other security-related qualms about shipping a storage device to have its data recovered.

Fortunately, though, not all data loss situations require full in-lab service. There are many occasions when Gillware can recover your data and get you back up and running in no time—all without your having to send your equipment on the road.

Gillware’s expert forensic investigators and data recovery specialists can remote into your network, diagnose the issue preventing you from accessing your data, and get you up and running again with minimal downtime.

Gillware’s specialized team of computer scientists and computer engineers offer best-in-class remote data recovery services in data loss situations that do not involve physical or mechanical failure of the storage media. The ability to perform recovery services remotely means there is no need to ship your device(s) or server to Gillware’s lab.

Remote data recovery over network is the perfect option for enterprise businesses where downtime needs to be kept to a minimum.

Remote data recovery can be particularly useful in certain data loss events, such as ones involving:

• A large number of storage devices that make shipping logistics challenging
• Extremely sensitive data (i.e., personally identifiable information, medical records, intellectual property, or company secrets)
• Production systems that can’t easily be shut down without significantly impacting operations.

Using proprietary software tools developed by Gillware’s remote recovery team, we can:

• Access your system
• Evaluate the damage
• Develop a recovery strategy
• Execute that strategy

…without so much as setting foot outside of our headquarters in Madison, WI. For clients like you, this means a secure, simple, and cost-effective remote recovery solution. It also means that you get your critical business systems back up and running quickly with minimal impact on business operations.

Key Features of Gillware’s Remote Data Recovery Services

When it comes to consumer and enterprise storage devices, we know servers, NAS devices, and SAN devices backward, forward, and side to side. We work with just about every file system, RAID configuration, hypervisor, and virtual machine setup imaginable on a daily basis.

The engineers who will be assisting you and remotely recovering your data are experts at:

• RAID data recovery: Any RAID level, any RAID setup, any RAID controller. Our engineers have seen it and solved it, probably more than once.
• Virtual Machine data recovery: Only specialists with years of in-depth and hands-on experience delving into the guts of virtual machine systems could have come up with the tools, techniques, and tricks our engineers have at their disposal for getting the best results from VM data recovery.
• iSCSI and LUN data recovery: Recovering deleted data from these “soft partitions” requires so, so much more than a passing familiarity with file systems (usually Linux). It requires an intimate knowledge of file system architecture often on par with the system’s creators themselves.

Advantages to Remote Recovery

1. Faster turnaround time since there is no need to ship equipment
2. Increased data security because no data leaves your organization’s network
3. No downtime of other systems which use the shared hardware of the system that needs data recovery performed on it

To see how our remote data recovery specialists work their magic, read on for a step-by-step walkthrough of the process:

The Remote Data Recovery Process

1. Create the recovery environment

Gillware sends you a preconfigured virtual machine (“appliance”) to deploy to along with an ESXi host. If you don’t have another ESXi datastore, we provide a proprietary self-booting USB which contains a proprietary tool for creating a physical machine. In either case, the newly created “appliance” will serve as Gillware’s recovery environment.

2. Set up remote access to the recovery environment

Gillware’s engineers will configure the software that will allow remote access to the recovery environment created in Step 1.

3. Attach the storage containing the missing data over iSCSI to the recovery environment

Exactly what it says on the tin: We use iSCSI protocols to connect the environment you need us to recover your data from to the environment we’ve created to hold onto the data we salvage.

4. Run a data recovery analysis

Gillware’s software will scan the iSCSI volume to collect critical file system information and metadata. We use this data to build a custom software tool to be used in the data recovery phase.

5. Deliver a Statement of Work (SOW)

Based on the results of the data recovery analysis, Gillware engineers will produce a Statement of Work. The SOW details the data to be recovered, the timeframe required, and the associated cost. Just like with our in-lab data recovery process, we don’t move forward with the operation unless you approve the SOW, and we don’t charge you a dime until we’ve succeeded in recovering your data.

6. Build the data recovery software tool

After receiving approval of the SOW, Gillware engineers will use the information learned in Step 4 to create a custom piece of software to recover your data.

7. Run data recovery software tool

Gillware engineers attach a suitable destination storage device and run Gillware’s data recovery software, which will recover your data and copy it to the destination storage.

8. Your IT team can go home and finally get some sleep!

…And depending on the time of day, so can ours!

Every moment of downtime you suffer as a result of an IT disaster makes the whole situation hurt more and more. These are not circumstances you want to let linger while you try to go about your business. You need to get things sorted out ASAP, and remote data recovery can make that happen.

Whether you’re too far away from our location for in-lab recovery or you worry that even our expedited in-lab recovery options will result in too much downtime, Gillware can still help you if the situation calls for it.

Still curious about the finer details of remote data recovery? Wondering if remote data recovery is the correct option for your organization? Take a look at the case study below to get a closer look at our process:

A Case Study in Remote Recovery Services

For most of the recoveries that Gillware performs, taking the system offline and shipping all of the hard drives or solid state drives to our lab is not an issue. Or, at the very least, it is an issue, but not a major one. It isn’t fun or painless to experience downtime. But the failed storage device usually only deals with one aspect of the client’s organization. They can usually go without with their hard drive, SSD, NAS device, or server while our engineers work to recover their data.

However, storage area network (SAN) units, especially large ones, often perform a wide range of tasks simultaneously. Taking the entire SAN down and shipping it would result in wide-reaching and crippling incapacitation of your organization. Sometimes there is only an issue with one of the many logical unit numbers (also called LUNs) the SAN has been carved into. Taking the entire network down for the sake of one misbehaving section is simply unacceptable!

In this type of situation, Gillware’s specialists need physical access to that LUN alone to recover its data. The rest of the LUNs, though, need to stay online. This is a difficult balance to strike during in-lab recovery. Gillware Data Recovery’s remote recovery technicians can perform the recovery remotely, however, with zero downtime to any of the other systems.

Take a recent remote data recovery case we performed for a Nigerian client, for example. Not only was the client unwilling to suffer downtime, but they were also constrained by the vast distance between their Nigerian base of operations and our data recovery lab in the United States (Madison, Wisconsin, to be precise). In this recovery case, only remote action would do.

Remote Data Recovery Case Study

One of the LUNs on an IBM SAN hosted a file share for all of the user data in the whole organization. During some routine maintenance, the file share fell offline. The client had a backup. But as can happen with backups, when they went to restore from it, they found it to be six months out of date. Data recovery was the only option to avoid losing six months of data.

In our client’s situation, the SAN was responsible for hosting another VMware ESXi datastore on another LUN. This ESXi server hosted virtual machines for their organization including their Windows Server domain controller, their exchange server, and other systems. As you can imagine, taking down the whole business to recover the data from the file share was not an option.

A Home Renovation Analogy

Think of it this way. Your three-bathroom house needed some plumbing work in the bathroom to get the toilet working again. It’s quite inconvenient that you can’t use that one toilet while it’s getting fixed. But it would be even less convenient if the water to your entire house needed to be shut off to work on the broken toilet. Then you’re down to zero toilets!

Wouldn’t you agree two out of three toilets are obviously better than none?

At Gillware Data Recovery, we’ve been responding and adapting to every emergency situation imaginable for over thirteen years. So when this client asked if we could perform this recovery remotely, the answer was a simple “Of course!”

At Gillware, we created our recovery platform in-house. This has the advantage of letting us customize to fit any situation. In this case, we deployed a modified version of our recovery software to a small virtual machine. We then took the VMDK from the virtual machine and sent it over to the client to run on their ESXi server. After the client deployed our data recovery virtual machine and allowed us remote access to that machine, we were off to the races.

A Sharper Image

Our remote recovery virtual machine was attached to the same network as the client’s SAN, which allowed us to attach the LUN to our virtual machine using iSCSI protocols. Attaching the LUN using iSCSI allowed us to interact with it at a block level rather than a file level. Block level access is a necessity for data recovery.

With data recovery, sometimes the only way to get a complete recovery is to create a full disk image of the corrupted data volume, and then use our software to piece together the metadata and recover the data in the best form possible. In the lab, we image media from clients onto ICDs (Internal Cloning Devices). This process requires having block storage available that’s slightly larger than the original storage medium. With this remote recovery of a 20TB file share, the client only had 14TB of free space left on the SAN. We needed to save that as a place to which we could extract the recovered data.

In lieu of creating a full image of the file share to perform the recovery on, our system scanned the entire volume for relevant pieces of information. These pieces of information included metadata such as:

• NTFS volume headers
• MFT records
• INDX records

As well as thousands of other valuable metadata that the Gillware data recovery platform tracks, including common file headers. Our data recovery software scanned the client’s entire volume and collected all of the relevant metadata and stored it in a relational database. This relational database is the “secret sauce” of the data recovery process. The data in this database can be used by our engineers to create the most optimal recovery outcome.

Remote Recovery Case Results

In this case, the MySQL database created after the metadata scan was 16GB. Once we’d created the optimal file list, we could start extracting recovered data. We created the file list as a CSV which held, among other things:

• The file’s name
• The folder it should be extracted to
• Metadata about access times
• The run list (all the little pieces of the file stored all over the corrupted volume that must be reassembled)

Once we had this CSV created, a piece of recovery software running on the virtual machine could take that file list and extract all of the recovered data to any other local or network destination.

In this situation, we were able to recover 98% of the client’s data, with the other 2% being overwritten by an accidental filesystem reformat. However, everything of value to our client across the Atlantic had been successfully retrieved—all without any of us having to leave our offices… or our client’s server having to fly across the Atlantic!