Data recovery decisions in Northland

For Northland, a business data recovery case is defined by service impact and dependencies, not only by the number of terabytes.

Request a quote

Case intake Gather the storage details, failure chronology, prior actions, encryption information and priority files.
Technical diagnosis Determine the physical and logical risks and select an acquisition approach suited to the medium.
Source protection Use protected images where possible to rebuild arrays, volumes and file structures outside the source.
Result validation Test representative priority data, describe incomplete results and prepare readable files 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.

Diagnostic assessment separates enclosure, electronics, firmware, mechanical and file-system symptoms before choosing the least intrusive supported action.

A NAS or RAID set after one or more disk alerts

Disk order and event history are part of the data needed to reconstruct an array.

A shared NAS can survive one disk fault, then lose its pool during a rebuild, power interruption or second member failure.

Photograph and label the bays, preserve disks that were removed earlier and record the RAID and volume configuration. Member health can be assessed separately and the logical array assembled from protected copies where appropriate, without committing changes to the original set.

Keep every member in its known bay order, including drives marked failed.
Cancel initialise, new-pool and automatic rebuild prompts.
Save alerts and list disk replacements, resets and power events in sequence.

Reconstruct storage and application layers separately

A RAID can be virtually assembled while its file system remains damaged, and a virtual disk can mount while its database is inconsistent. Each layer therefore has its own checks and limits.

Copies of members, datastore metadata, snapshot chains and transaction logs allow hypotheses to be tested without changing the source set.

Array members and virtual disks are imaged separately where possible, allowing parity, stripe and snapshot assumptions to change without altering the source set.

Storage exposed to floodwater, salt water or a spill

Contamination and power are a dangerous combination even after visible moisture disappears.

Floodwater, sea spray and drinks leave salts or residue that can corrode boards and bridge fine contacts.

Remove power safely and record what liquid reached the equipment and whether it was operating. Different media require different cleaning and assessment; heating, shaking or opening a hard drive can add damage rather than remove contamination.

Keep batteries, USB and mains power disconnected.
Do not use rice, an oven, a heat gun or direct sun.
Note the liquid type, duration, power state and any drying already attempted.

Checking recovered files

A detected file is not automatically usable. Checks focus on important formats, dates, folder structure and representative samples that can be opened.

Destroyed areas, overwritten blocks and encrypted access without a key are reported without overstating what is possible.

The handover distinguishes complete, partial and missing files, records unreadable ranges, identifies the healthy destination and preserves agreed priorities in the final assessment record.

The stages of a defensible data recovery

A NAS rebuild can combine incompatible member states when disk order or warning history is incomplete.

Stripe layout, parity rotation, controller metadata, and the failure sequence define the likely coherent state.

Label bays before transport, image members separately, and test layouts virtually. Do not let the appliance initialise a pool or write replacement parity.

Keep firmware details, alert history, and replaced disks with the case. A candidate layout must expose the newest coherent shares and selected files.

Label every drive in the position in which it was found
Stop rebuild, initialisation and member-replacement attempts
Preserve controller logs and the timing of each warning
Image safely and rebuild on protected working copies.

A practical brief for the diagnostic assessment

A virtual disk is inseparable from its descriptors, extents, snapshots, and datastore allocation.

Replacement VMs and snapshot consolidation may consume blocks or metadata needed by the missing guest.

Preserve configuration first, rebuild dependencies on copies, and test essential guest files or databases. A boot screen alone is not sufficient validation.

Record datastore extents, hypervisor version, and snapshot parent identifiers. One incorrect dependency can present an older guest while hiding the latest application state.

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
Maker, model, capacity and connection.
Precise warning, noise or detection behaviour.
Last healthy use and incident sequence.

Data recovery laboratory — Hard Drive Recovery in an ISO 5 Clean Room

For media arriving from Northland, essential folders, dates and access details are agreed before laboratory acquisition. The result is checked against those priorities and separates usable, partial and unavailable content.

A degraded RAID comprises member devices, configuration metadata and parity relationships rather than one generic disk fault. Record bay order, serial numbers, member count, controller alerts and recent replacements.

Hard Drive Recovery in an ISO 5 Clean Room

Stop new writes after deletion or formatting

For Northland, synchronisation, indexing, updates and normal use are stopped because new writes can replace surviving content or metadata. File-system type, event time, encryption and tools already used are documented before reconstruction on an image.

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

Does a diagnostic assessment automatically commit the case to recovery?

No. It is used to clarify the fault, the likely scope, timing and limits before any committed recovery work.

What information should be prepared?

The storage media model, capacity, symptom, incident date, actions already attempted and the list of priority data.

Can two failed NAS disks be swapped at the same time?

Doing so can remove the only members containing a coherent older state. Preserve the complete set and establish the array history before replacement or rebuild.

Is salt-water exposure different from fresh water?

Yes. Salt is highly conductive and corrosive, but every liquid incident still needs the media to remain unpowered until its condition is assessed.

Can the original RAID disk order be found by trial and error?

It can often be tested, but not by writing to the original members. Metadata and disk images provide the safer evidence for reconstruction.

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. Map datastore extents and snapshot parents before attachment.