Data Recovery Technology in RapidSpar

Software Applications: Waiting indefinitely, hoping the drive responds

If a read command falls on a bad sector, it will be handled by layers of system software (BIOS/OS) that the software application can’t control. The best-case scenario is that the computer waits without crashing until the drive responds to the read command on its own. Every time the read command falls on a bad sector, the drive will spend somewhere from 4 seconds to over 20 seconds making hundreds of failed read attempts, then conclude the sector is bad, write to its firmware area (located on the platters) to update various logs, and finally respond with an error message, at which point the software application can send the next read command. This process wastes time, quickly causes further physical degradation of the drive, and risks firmware corruption.

RapidSpar Hardware: Quickly skipping bad sectors with resets

RapidSpar’s proprietary ATA controller can automatically terminate bad sector processing. If a drive does not respond to a read command within a fraction of a second, RapidSpar uses different reset commands to force the drive to stop processing it early. This alone eliminates the large majority of fruitless processing, and in most cases also stops the drive from registering bad sectors in its firmware logs, substantially decreasing the chances of causing further damage. If a serious internal exception causes the drive to stop responding to all commands, as a last resort RapidSpar automatically repowers it to seamlessly continue the recovery process.

Software Applications: Indirect access causes big problems

Software data recovery applications do not have direct control of or exclusive access to the drive. They can only send read commands to the OS API; with luck, the communication attempt passes through each layer of system software without any issues, and the drive is capable of consistently processing read commands.

But if the drive isn’t operating as expected, communication can break down at any point, halting the recovery effort. If the drive is responding with errors, any of the system software layers could have an exception and take the whole system offline. If the drive has an internal exception when processing a bad sector — for example, while updating firmware logs — it may not respond within a reasonable timeframe, which would also cause the computer to freeze, restart, or drop the connection to the drive. To make matters worse, because the software application has no direct connection to the drive, it may not even be aware when the connection has been dropped. In that case, it will keep trying to recover data, but none of its attempts will actually go through, leaving the drive to idle. After 20-30 seconds of idling, modern drives execute self-scans, attempting to seek out and reallocate bad sectors. This state quickly degrades the drive; entering it is one of the worst things that can happen to a degrading drive.

RapidSpar Hardware: Exclusive drive access and control

RapidSpar has direct control of and exclusive access to drives. At every step of the recovery process, it uses proprietary software, firmware, and hardware designed specifically to handle degraded drives.

Software Applications: Limited to drives visible by the OS

The standard file system mounting process will automatically begin as soon as a drive is connected to Windows or MacOS. While mounting the drive, the operating system will reach the first unreadable 8 sector block within critical file system metadata, attempt to read it a number of times, and if it’s not successful then it will either give up (MacOS), or restart mounting from the beginning (Windows). Mounting will fail in this manner even if the contents of the unreadable block are not necessary to mount the drive. Standard operating systems do not work with blocks smaller than 8, so even if just 1 sector is bad, the entire 8 sector block it belongs to will be missed and the drive will not be mounted. If the mounting process fails to complete then the drive will remain invisible to the operating system.

RapidSpar Hardware: Intelligent file system parsing

RapidSpar loads the file system in an entirely different manner. First it will clone as much file system metadata as possible to the healthy target drive, including every good sector within every unreadable block. From there it will work only with the target drive to parse the file system and build a file tree. Occasional bad sectors within file system metadata will not be an issue, provided they do not restrict access to data which is strictly necessary to load the file tree. Some file system elements have multiple copies, which will be located and used automatically in place of elements that have bad sectors. This process allows RapidSpar to successfully load the file tree and recover the files in the majority of such cases. Even if the file tree can’t be loaded due to logical corruption, RapidSpar can still be used to take a full clone of the drive, handling read instability issues and allowing you to run logical recovery scans on the clone afterward.

Software Applications: Slow and imprecise

Software data recovery applications usually read data in large blocks of sectors (typically 512-4,096). They are designed to work like that due to the combination of the following three limitations: timing overheads imposed by the system architecture which reduce speed of data access by up to 75% at small block sizes; risk of one of the system software layers crashing when processing a read error; and the inability to terminate bad sector processing. Reading in large blocks allows the application to use fewer commands to read the drive, reducing the consequences of these limitations. If the drive fails to read a block, that entire block is usually forgotten — a loss of 512-4,096 sectors. Because a hard drive will fail to read a block if even a single sector within it is bad, thousands of good sectors remain unread, corrupting a larger number of files.

Some Linux-based cloning tools can be configured to use small read block sizes and do multiple drive passes to retry missed blocks one sector at a time. However all the aforementioned limitations are still there, severely restricting these capabilities. Even with Linux, there is no control over how bad sectors are processed, and every failed read attempt takes up at least a few seconds as a result. If just a few sectors are bad, this isn’t an issue. If there are more, reading in small blocks and then retrying them sector by sector will force Linux to spend far too much time processing failed read commands for the recovery process to be practical or safe. Linux-based tools also generally can’t target specific files or folders for recovery, so they must take full partition clones, recovering countless unnecessary sectors, further increasing recovery time and the potential for something to go wrong.

RapidSpar Hardware: Faster, with more data

An efficient architecture and the ability to quickly stop bad sector processing has a substantial impact — RapidSpar can often dig into an entire unreadable block one sector at a time before a software application finishes waiting on a single failed read command.

The RapidSpar architecture has very low timing overheads for processing of individual commands, so it can use a much smaller read block size, typically from 128 to 256, without sacrificing speed. Blocks that fail to read can be retried one sector at a time to ensure that all good sectors within each unreadable block are recovered.

RapidSpar understands file systems, allowing targeting critical file system information and then specific files and folders, usually eliminating the need for time-consuming full-drive cloning. As well, RapidSpar identifies exactly which files are corrupted by bad sectors, simplifying recovery validation.

Software Applications: Limited to the most complex drive initialization process

To begin working with drives, standard computers send a large number of initialization commands, such as Set UDMA Transfer Mode, Initialize S.M.A.R.T., Initialize Device, Recalibrate and so on. If a drive is degraded, it may fail to respond to all of these commands within the expected timeframe, which usually leads to a failure to identify the drive. This doesn't mean the drive has actually failed, or even that it has any serious problems — it's just that its degraded firmware subsystem has failed to process one of these initializations commands in the exact way it was expected to.

Furthermore, most of these initialization commands are unnecessary for modern hard drives and only create a potential for problematic behavior. They are a part of the initialization process in standard computers because they are necessary for older drives. Standard computers do not make any distinction between older and newer drives, and instead always use the most complex initialization process to support the largest number of drives, which causes some degraded, but still functional drives to remain unidentified.

RapidSpar Hardware: Keeping it simple

RapidSpar uses the lightest initialization procedure in each case, which for most modern drives is a single Disk Identification command. RapidSpar is also built to be forgiving of possible deviations in the drive's response, ensuring that there are no unexpected problems and that only truly failed drives are unidentified.