RAID and server data recovery in Perth
For Perth, when storage fails, continued testing is not neutral. The device is assessed for safe power-up, controlled acquisition and a recovery route based on the files that actually…
- 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 NAS or RAID volume after a disk failure
Array recovery depends on the full set, its order and its history, not one disk in isolation.
A NAS can become degraded after one disk fails, then go offline when another member develops unreadable sectors or a rebuild stresses the remaining drives.
Keep every member, including any drive already marked failed, and document the bay positions before removal. The goal is to image unstable members where appropriate and rebuild the logical volume from evidence, rather than asking the live array to guess its way through another rebuild.
- Label each disk with its original bay number without altering connectors or labels.
- Cancel rebuild, initialise or factory-reset prompts.
- Save screenshots of alerts and record every disk swap or configuration change.
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.
Missing footage from an NVR or surveillance recorder
Video recovery needs the recorder context as well as the hard drives.
An NVR may show gaps after a disk fault, accidental initialisation, a recorder reset or continued recording over the relevant period.
Preserve the recorder model, installed disk order, channel map, displayed time zone and the exact date window required. Extracted footage must be checked for playable sequences, timestamps and channel identity; a list of found files alone does not establish that the needed event is usable.
- Stop recording if continued operation could overwrite the required window.
- Photograph disk bays and record the displayed date, time and time zone.
- Specify the relevant cameras and the narrowest useful incident window.
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
A database service may start even though pages, indexes, or transaction history remain inconsistent.
Blackouts and interrupted replication can leave data files and logs at different points.
Secure storage files before repair. Validate headers, page structure, log sequence, and selected records on copies, separating usable exports from unresolved damage.
Specify the engine version, application owner, required tables, and local time range. Service startup alone cannot establish that transactional or operational records are complete.
- Stop the database service and automatic repair jobs
- Keep data files, logs and configuration together
- Identify critical tables, tenants and the required recovery point
- Acquire safely; reconstruct on protected working images.
What to prepare before requesting an assessment
Encrypted storage requires a readable container plus legitimate key material; one without the other is insufficient.
A controller or boot fault can resemble a rejected password.
Image the medium, preserve encryption identifiers, and collect keys from authorised systems. Strong encryption cannot be bypassed by a generic recovery tool; valid credentials and intact metadata must align.
Review managed-device escrow, account portals, and printed recovery records before resetting trusted hardware, changing firmware, or reinstalling the protected operating system.
- Preserve recovery keys and passphrases exactly as recorded
- Avoid a TPM reset, operating-system reinstall or re-encryption
- Note the device, user account and last successful unlock
- Last normal use and event sequence.
- Previous restarts, scans, repairs or rebuilds.
- Vital folders, formats and date ranges.
Data recovery laboratory — ISO Class 5 Clean-room Data Recovery
For storage submitted from Perth, priority folders, dates and credentials are documented before laboratory acquisition. Validation focuses on those needs and distinguishes usable, partial and missing material instead of relying on detected names.
A degraded RAID combines member media, controller metadata and parity relationships, so diagnosis starts with the whole system. Record disk count, bay order, serial numbers, alerts and recent replacements.
Define the required period and verify playable or readable content
For Perth, 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 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.
Can a new disk simply be inserted to rebuild the NAS?
Only after the array state is understood. An automatic rebuild can overwrite useful metadata or place extra load on another weak member. Retain bay photographs, alert history and appliance firmware details.
Is the recorder required when the NVR disks are available?
Often it is valuable because it identifies the recording format, channel layout and clock settings, even when analysis is performed from protected disk images.
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. Test required tables, time ranges and record totals separately.
Can an encrypted drive be recovered without its key?
Properly implemented strong encryption cannot realistically be bypassed. All legitimate key sources should be checked before technical work continues.
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.