RAID and server data recovery in Geelong
For Geelong, if storage fails, stop writes and repeated tests, note the exact symptom and identify the files that are essential.
- Case intake Document the storage media, symptoms, incident timeline, previous attempts and priority data.
- Technical diagnosis Assess physical, electronic and logical risk before deciding whether and how the source should be read.
- Source protection Create or work from protected images where appropriate, then reconstruct the relevant volumes and files.
- Result validation Check representative priority files, record partial or missing data, and prepare the result on healthy media.
Preserve the set before replacing a member
A second warning during a rebuild can leave several plausible but incompatible states. Bay position, serial number, event time and controller messages should be recorded before disks are moved.
Each readable member is acquired independently so reconstruction does not depend on the array writing new parity.
For Australian arrays and servers, bay order, controller alerts, encryption and application dependencies are captured before any member is moved or rebuilt.
A hard drive that clicks, stalls or disappears
Mechanical symptoms call for fewer power cycles, not more troubleshooting.
A desktop or portable hard drive may start clicking, scraping, spinning down or taking minutes to appear.
For a case from Geelong, note any knock, power event or gradual slowdown and leave the enclosure closed. A controlled assessment separates a simple interface fault from damage that makes further reads risky, then sets priorities before extraction begins.
- Power the drive down if it makes a new mechanical noise.
- Keep the original enclosure, power supply and interface details with the case notes.
- List the folders and date ranges that matter before any long read is attempted.
Trace RAID, volume and virtual-machine dependencies
Stripe parameters lead to a virtual volume; file systems, datastores, VMDK or VHDX files and snapshots sit above it. Damage at one layer should not be hidden by forcing repairs at another.
The last known working state and application requirements determine which branch is tested first.
Each array member or virtual disk is acquired separately where possible, allowing stripe, parity and snapshot assumptions to be revised safely.
Deleted files, reformatted storage or ransomware
Logical incidents are time-sensitive because every new write can replace useful content or metadata.
After deletion or a quick format, the system may reuse space that still contains file data.
Ransomware requires containment: isolate affected systems from networks and shared storage, preserve encrypted data, the ransom note and relevant logs, and follow the organisation's response process. Feasibility depends on backups, overwriting and the specific encryption event; it must not be presumed.
- Stop writing to the affected disk, share or virtual volume.
- For ransomware, isolate systems without deleting encrypted files or logs.
- Prepare the last known good time, affected paths and available backup details.
Check databases and shares before handover
Mounting a volume does not prove that a database, mail store or project archive is consistent. Priority services are checked using their own formats and logs wherever possible.
Results distinguish recoverable exports, partial sets and structural gaps so a restart decision is based on evidence.
Application checks cover databases and virtual machines rather than treating a mounted volume as proof that business services can resume.
How a data recovery case is assessed
An external disk can fail in its cable, power pack, USB bridge, controller electronics, or mechanism.
Repeated power cycles are unsafe when the unit clicks, overheats, or smells electrically damaged.
Test enclosure and disk separately under controlled power. Retain the original bridge and identifiers because encryption or sector translation may rely on them.
If the mechanism is stable, a write-protected direct connection can confirm bridge failure without initialising the disk or allowing an automatic repair utility to run.
- Keep the original enclosure, power supply and cable together
- Stop powering the unit if there is noise, smell or abnormal heat
- Do not fit an unrelated controller board without checking firmware and ROM data
- Record the device, event sequence, attempts and vital files.
What to prepare before requesting an assessment
Virtual disks depend on descriptors, extents, snapshots, and datastore allocation records.
Creating a new VM or consolidating snapshots can overwrite exactly the metadata needed for reconstruction.
Retain configuration and datastore files, rebuild geometry on copies, and validate critical guest files or databases rather than relying on a single successful boot.
Record every datastore extent, hypervisor version, and snapshot parent. An apparently complete guest can still point to an older state when one dependency is misplaced.
- 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
- Manufacturer, model, capacity and interface.
- Exact alert, noise or detection behaviour.
- Last normal use and event sequence.
Data recovery laboratory — ISO Class 5 Clean-room Data Recovery
When a device is shipped from Geelong, stop further starts, repair tools, rebuilds and writes. Recording the first symptom and every later attempt gives the laboratory a safer basis for planning assessment.
Clicking, scraping, stalled rotation or an impact while powered can indicate internal hard-drive damage. Keep the disk off until assessment shows whether a controlled opening could create a safe imaging opportunity.
Reconstruct volumes, snapshots and application dependencies together
For Geelong, virtual disks, descriptors, snapshot chains, RAID or HBA metadata, keys and transaction logs are kept as one dependency set. Storage reconstruction and application consistency are tested separately on copies.
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 the later reconstruction.
File systems, containers, arrays or application layers are analysed on a separate working copy. This keeps a wrong 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
Why keep failed RAID members that were already replaced?
An older member may retain blocks or metadata needed to understand the sequence, even if it cannot rejoin the live array.
Is a virtual machine boot enough to validate recovery?
No. Guest file systems, databases and priority application data still need consistency and opening checks.
Should a clicking hard drive be connected once more to check it?
No routine retry is worth the extra mechanical stress. Record what happened, disconnect it and arrange an assessment without opening the drive.
Should recovery software be installed after accidental deletion?
Not on the affected storage. Installation and scan output can overwrite the files being sought; preserve the source and assess from a separate working environment. Identify affected accounts and the newest trustworthy backup.
Can an external hard drive simply be moved into another enclosure?
Not always. A bridge may change sector presentation or encrypt data. Preserve the original enclosure and identify the failed layer first.
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. Preserve datastore extents and snapshot parents in order.
Diagnostic assessment
Unsure about a storage device or fault?
Datastrophe assesses the risk before any recovery attempt and points you towards the safest next step.