The “handover” to Oxford Science Park takes place once you have your quotation, when you have dropped off at our site in Oxford (for those living locally) or sent through the post. Every single drive will walk along the same route, and pass the same benches, regardless of whether that journey started from Oxford, Reading or Banbury. This is the tour: bench by bench, what each piece of equipment is; what it does; and why it settles which recoveries work.
Each job has its own path through the stations (some skip certain ones): intake write-blocking, hardware imaging, firmware repair and a bench for mechanical jobs.
This is the first stage for any mechanical fault, and the lowest margin for error.
Hard drives have their read/write head flying over the platter at a fraction of the width of a strand of hair; if you put a single particle of dust from your house into this space, it will scratch the platter. It is because of this reason that the sealed environment must never be opened by yourself at home.
The process itself is very methodical and non-dramatic: lift out a damaged head stack and install a replacement; transfer an inoperable drive’s platter pack into a donor enclosure while maintaining rotation orientation; free heads bonded to the surface using a vertical pick-up tool as opposed to pulling on them horizontally. All of these are attempted once; thus we immediately image your data after each repair attempt rather than testing.
The first step which every other action depends upon, and it makes the most obvious distinction between a lab and a piece of software.
In this broad category of failures with a working mechanism but nothing reported from the hard drive.
Both hard disks and solid state devices retain all of their operational firmware (for hard disk) or translation table (for SSD) in a separate service area located on each of the respective platter(s)/flash module. When either is corrupted, both still power up but report zero capacity/blank model/some other obviously incorrect size, and both contain the users’ intact data.
Manufacturers have diagnostic modes available to read, repair and replace (from matching donor units) these service areas directly; rebuild bad modules/substitute new ones from a matched unit/use existing defect list to generate replacement translator tables/transfer the ROM adaptive as required when replacing the board. On SSDs, we use vendor modes to access the NAND chip’s mapping tables so we can differentiate the raw NAND data into usable data.
This marks the end of physical repairs and the start of logical analysis.
We determine stripe size, disk sequence, how parity rotates, and the starting point for the data based on tests conducted on candidate solutions against the data until reassembled to produce valid data structures rather than noise.
RAID array stored on disk (mdadm), pool structure stored above it (LVM), and thin provisioning metadata used to map virtual disk blocks to actual disk blocks: this is how most NAS devices work today.
Master file table entries from NTFS, container information and checkpoint data from APFS, superblock data from ext, and tree structures from Btrfs, are rebuilt from available records.
When a complete file system cannot be built back, we look for file signatures and return just what we can find with no file names or directory/folder information; it’s something, but let’s say it out loud anyway.
We open the recovered files directly within their associated application. Any unreadable files will be reported by their exact filename as opposed to returning a file that you open to nothing.
Since the read/write head floats a fraction of the thickness of human hair away from the disk platter and a speck of household dust floating into that gap could scrape the disk surface, do not ever attempt to open the sealed compartment yourself.
Provide the read control at a level of granularity software cannot utilise, i.e., provide a means of per-head targeting, and time-out values that are controllable by the user; in addition, instead of locking-up when encountering unreadable sectors, allow the application to “skip” such sectors and write their locations to a log file. Importantly, it is strictly read-only; therefore, the source cannot be modified.
Repairing the reserved area in which a drive stores its own operational firmware. If these areas become unusable, the drive will boot properly and report nothing. The user’s data remains unaltered; however, manufacturers’ diagnostic tools enable an operator to rebuild that section.
No, and that is not the purpose of our repair process. We only perform repairs necessary to obtain readable copies of the user data; a drive utilising replacement heads, or one having a transplanted platter pack is used solely as a recovery tool, and not as a useable disk. The restored user data is provided on new media.
No. All work performed is done from an image of the original storage device(s), created using read-only methods. In addition, all data recovery processes run against a copy of the image being utilised. Therefore, any action taken does not diminish what could potentially be recovered. This represents the greatest distinction between performing software-based operations on the original versus performing data recovery operations.
Once you have a quote, devices may be left at John Eccles House on the Oxford Science Park without an appointment. They may also be sent via insured post and all recovery will be completed in house by one of our engineers as opposed to being sub-contracted. All data remains within the U.K.
The first station is free of charge. This includes a diagnostic within 48 hours and subsequently a written quote prior to any recovery taking place.