Data recovery decisions in Wales

For a data recovery request from Wales, the first useful decision is whether the device can be read safely at all.

Case intake Record the medium, symptoms, chronology, actions already taken and the genuinely essential files.
Technical diagnosis Assess physical, electronic, array and logical layers before deciding how the source may be acquired.
Source protection Create protected images where appropriate and reconstruct the required volumes, databases or file sets away from the original.
Result validation Open representative priority files, explain any damage or omissions and prepare the usable result on healthy storage.

data recovery laboratory — data recovery

The symptom changes the first action

A clicking hard drive should be powered down, while a healthy disk containing deleted files must be protected from new writes. An SSD that disappears and a RAID with two warnings cannot be treated as equivalent logical faults.

The initial assessment records power events, impacts, prompts, previous repairs and changes in recognition before choosing any sustained read.

Assessment separates enclosure, electronics, firmware, mechanical media and file-system symptoms, selecting the least intrusive next step supported by evidence.

An SSD missing from the BIOS or stuck in read-only mode

An SSD has no moving parts, but its controller and flash translation data can still fail abruptly.

An NVMe or SATA SSD may stop identifying, show an implausible size, freeze the host or refuse new writes.

Record the precise model and the circumstances of failure, including an update or power interruption. TRIM and garbage collection may affect deleted data, while hardware encryption can make controller-level access dependent on intact metadata, so outcomes must be assessed rather than assumed.

Do not initialise, format or update the SSD firmware.
Stop retries when the device drops out or causes the machine to hang.
Preserve any BitLocker, FileVault or device recovery key separately.

Match the first response to the storage symptom

Clicking or scraping calls for shutdown; deletion calls for write protection; a degraded array calls for preserved member history.

Assessment separates enclosure, electronics, firmware, mechanics and file-system damage. Keep encryption keys, recorder clocks and virtual-disk snapshots with the brief.

Stable sources are imaged with bounded retries. Reconstruction and file checks continue on protected working material, not the submitted device.

An unavailable server, datastore or virtual machine

Restoring service and preserving recoverable data are related but not identical jobs.

A host may fail to boot after a storage fault, an interrupted update, a full datastore or corruption within a virtual disk.

Document the server and hypervisor versions, physical and logical storage layout, virtual disk formats, encryption and backup state. That map lets assessment separate hardware, RAID, datastore, guest file system and application data, then prioritise the service or database that has actual operational value.

Suspend automated restarts, resynchronisation and file-system repairs.
Preserve logs and configuration on separate healthy storage where safe.
Rank virtual machines, shares and databases by business priority and required date.

Deliver a result that can return to use

The useful result may be a validated database export, selected project folders or a documented set of video sequences rather than a bootable replica of the failed system.

Opening tests, hashes where relevant and a clear list of partial or absent items support the handover decision.

For business data, validation checks database or virtual-machine coherence instead of treating a mounted volume as proof that the service can restart.

A controlled route from failure to usable files

A copied database file may still contain broken pages, damaged indexes or an incomplete transaction sequence.

Power loss, storage failure or interrupted replication can leave the primary data file, logs and secondary files at different recovery points.

Secure the source set before repair. On copies, inspect headers, pages and log relationships, then test required tables and date ranges for business-level consistency.

Usable exports are reported separately from unresolved corruption so an application starting successfully is not mistaken for complete recovery.

Stop the database service and automatic repair jobs
Keep data files, logs and configuration together
Identify critical tables, tenants and the required recovery point
Assess physical, electronic, array and logical layers.

Facts to gather before a diagnostic assessment

Virtual-disk extents, descriptors, snapshots and datastore metadata form one dependency chain.

Creating a replacement VM or consolidating snapshots can overwrite allocation records and blocks needed to restore the missing guest state.

Preserve configuration, extents and parent identifiers before mounting. Rebuild geometry on copies and attach read-only where the platform permits.

Validate selected guest files and databases rather than relying on a boot screen, which may represent an older but superficially plausible snapshot.

Do not create a new VM or datastore on the affected storage
Preserve configuration files, descriptors and snapshot names
List critical guest data and the last known working state
Previous restarts, scans, repairs or rebuilds.
Priority folders, formats and date ranges.
For arrays: bay order, logs and encryption.

Data recovery laboratory — ISO 5 Class 100 Cleanroom Data Recovery

For a case referred from Wales, the diagnostic assessment identifies the storage technology and the damaged layer before directing the medium to an appropriate mechanical, electronic, logical or system-level laboratory process.

An SSD contains NAND memory and a controller rather than flying heads and platters. Assessment separates power, electronics, firmware, translation, file-system, encryption and TRIM effects; cleanroom opening is not the relevant treatment.

ISO 5 Class 100 Cleanroom Data Recovery

Define the required period and verify playable or readable content

For Wales, required dates, channels, time zone, format, controller and overwrite risk are fixed before acquisition. Containers, indexes and structures are preserved, then representative media are opened rather than judged by names or thumbnails alone.

The source is not repaired in place. A sector-level or device-appropriate acquisition is created where condition permits, and every read limitation remains logged for later reconstruction.

File systems, containers, arrays or application layers are analysed on a separate working copy. This prevents an incorrect assumption from changing the only available source.

The result is checked by opening priority documents, media, archives or application data and comparing them with known dates and structures.

FAQ

Frequently asked questions

Should a degraded array be rebuilt before it is submitted?

No. Preserve member order and logs. A rebuild can stress another disk or overwrite the last consistent state.

Can a recovered database be checked without starting the original server?

Often yes. Copies can be assessed or exported in a controlled environment using the correct engine and transaction files.

Is an SSD easier to recover because it has no moving parts?

No. Flash translation, controller failure, TRIM and encryption can make SSD cases fundamentally different from magnetic hard drives.

Should a damaged virtual disk be mounted read-write to repair it?

Not as a first step. Work should preserve the original and use a controlled copy so repair attempts do not become the only version available.

Is locating the missing database file enough to declare recovery successful?

No. The file must be opened with the appropriate engine and checked for structural and business-level consistency. Validate required tables, dates and record totals explicitly.

Should an orphaned virtual disk be attached directly to a new VM?

Not from the original storage. Mounting can write metadata; secure dependencies and a read-only image before testing an attachment. Record parent identifiers throughout the snapshot chain.