A hard drive that is beginning to fail rarely fails cleanly. In most cases the user notices unusual noises, slow file access, or repeated read errors days or even weeks before the drive becomes fully inaccessible. The decisions made during that window often determine whether the data can be recovered and at what cost.The first rule is to stop writing to the affected drive. Every write carries a risk of overwriting data that has been marked as deleted or relocated by the drive's internal remapping. Ordinary system activity, indexing services, and automatic updates continue to write in the background, which is why simply leaving the drive connected and running is not safe.The second rule is to avoid running repair utilities at the file system level. Tools such as chkdsk or fsck will attempt to repair the structure of a file system that may be failing because the drive beneath it is physically deteriorating. A successful repair in that situation can make recovery significantly harder by relocating and rewriting metadata on failing sectors.The correct first step is to disconnect the drive and, if the data has any business value, arrange for a sector-level image to be taken on professional equipment. Imaging is non-destructive, produces a working copy that can be analysed safely, and preserves the original state of the drive in case a second attempt is needed.Acting quickly, but acting correctly, makes the difference. In our own case records, drives brought in within the first 48 hours of symptoms appearing have a recovery rate roughly double that of drives that continued in use for a week or more.

RAID is often treated as a form of data protection. In practice it is a form of availability engineering — it keeps systems running despite individual drive failures, but it does not protect against many of the events that cause real data loss. A significant proportion of the RAID cases we handle begin with a rebuild that went wrong rather than with the original drive failure itself. The first common error is replacing a failed drive in a degraded array without first verifying the health of the remaining drives. In RAID 5 in particular, the rebuild process reads every sector of every surviving member drive. If any one of those drives has undetected read errors, the rebuild will fail partway through, and the array will typically drop further members in the process. The second common error is forcing a drive back online after a brief disconnection. Most controllers will mark a drive as foreign or failed after a timeout, and the correct procedure is to investigate before re-including it. Forcing the drive back into the array can cause the controller to use stale parity data, silently corrupting the file system from the inside. The third is changing controllers mid-failure. A RAID array is specific to the controller firmware that wrote it. Moving disks to a different model or even a significantly different firmware revision during recovery can make the original metadata unreadable, and from that point onward the array must be reconstructed from first principles rather than simply reassembled. Where an array has already degraded, our standing recommendation is simple: power the system down, preserve the physical drive order, and consult before acting further. An incident that begins as a single drive fault can almost always be resolved. One that has been through a failed rebuild is a materially harder case.

SSDs and hard drives look similar from the operating system's point of view, but the recovery process for each is almost entirely different. A solid-state drive has no platters and no read-write heads, so the mechanical failure modes that dominate hard drive recovery do not apply. What does apply is a combination of controller failure, NAND wear, firmware corruption, and the effect of TRIM. TRIM is the feature that matters most for deleted-file recovery. When a file is deleted on an SSD, the operating system issues a TRIM command telling the drive that the blocks holding that file are no longer needed. The drive then schedules those blocks for internal erasure as part of its garbage collection cycle. In many cases the data is unreadable within minutes of deletion, regardless of whether the file system still shows it as recoverable. This is the single largest difference between SSD and traditional recovery, and it is the reason that deletion-based recovery jobs must reach us quickly to stand any chance. Physical recovery of an SSD typically involves either controller repair or direct chip-off reading of the NAND packages. Chip-off is a destructive process for the drive — the packages are desoldered and read in a specialist adapter — and the raw output must then be reassembled using the controller's internal mapping, its wear-levelling tables, and in many modern drives its encryption layer. For these reasons, the window to recover deleted files from an SSD is narrow, and the cost of physical recovery is generally higher than for an equivalent hard drive. The practical consequence is that backups matter more, not less, when SSDs are in use.

Most organisations we work with contact us for the first time during an active incident. In a minority of cases they contact us in advance, ask us to review their backup and recovery arrangements, and never need to call us again. The second outcome is always cheaper, faster, and less stressful for everyone involved. A workable recovery plan does not require specialised software or major infrastructure investment. It requires three pieces of clear information: what data the business cannot operate without, where copies of that data are held, and how long it would take to return to normal operations if the primary copy were lost. Each of those questions produces decisions. The first identifies which systems need protecting and which do not. The second exposes gaps — data held only on the laptop of one employee, backups stored on the same server they are meant to protect, cloud tenants without a second copy outside the provider. The third forces an honest assessment of recovery time, which is often much longer than the team assumed once the full restore process is considered end to end and under realistic network conditions. We recommend that every organisation with more than a handful of employees produce a written recovery plan, test it at least annually with a real restore, and update it whenever significant infrastructure changes. The cost of producing the plan is trivial compared with the cost of discovering its absence during an incident.

Cloud storage providers are, on the whole, more reliable than the infrastructure most organisations could operate themselves. Their outages make headlines because they are rare, not because they are common. The risk that does justify attention is the quiet one: a single provider holding both the live copy of business data and every copy of the backup of that data, with the assumption that the provider's internal resilience removes the need for an independent second copy. That assumption fails for three distinct reasons. The first is account compromise. A credential breach that reaches administrative level can result in deletion of both data and backups inside a single session, and recovery depends entirely on the provider's retention window. The second is misconfiguration. Retention policies are often set once and then forgotten; we have seen cases where the retention window was shorter than the interval between audits that would have caught the error. The third is billing or contractual dispute, during which access to data can be suspended or lost with short notice. None of these scenarios requires any technical failure on the provider's side. All of them are in scope of the risks a business has to manage for itself. The practical answer is not to distrust the provider, but to maintain at least one copy of business-critical data outside the provider's administrative boundary. That copy does not need to be large or expensive; it needs only to be independent, regularly refreshed, and occasionally test-restored. The cost is modest. The alternative, as we see regularly, is a recovery engagement under time pressure.