Data recovery seeks usable files. Forensic preservation protects the source and handling record. A repair utility, rebuild command, or repeated power cycle may improve access while changing metadata or exhausting a failing component. GDF begins with the required data, source condition, prior handling, and intended use. Counsel decides legal preservation duties and evidentiary use. GDF documents the technical work and does not provide legal advice.
Data recovery triage before repair
Intake records the last good state, errors, unusual sounds or heat, physical exposure, power events, prior attempts, encryption, backups, and priority data. A failed device should not be powered merely to try it again. Repeated starts can worsen damage, consume degraded flash, trigger repair, or rebuild an array against the wrong member.
Triage separates likely logical corruption from physical or firmware failure. The recommendation may be protected imaging, specialist evaluation, another source, or no further handling until authority is clear.
Forensic preservation and defensible chain of custody
When later review may matter, handling starts before reconstruction. The record identifies the device, condition, supplier, receipt date, and authority. Custody transfers and material changes include carrier and specialist handoffs.
Where feasible, recovery uses a sector image or controlled clone. Read errors, retries, skipped regions, resets, and settings remain recorded. Hashes identify completed images and copies but do not make unreadable sectors complete. Reconstruction uses a working copy rather than the best acquisition.
- Identification, condition, authority, and custody records
- Imaging settings, read-error maps, retries, and exceptions
- Separation of preserved acquisitions from working copies
- Client instructions for return, retention, transfer, or destruction
Hard drive, SSD, RAID, and server failure patterns
Sources include hard drives, SSD and NVMe media, USB devices, memory cards, virtual disks, server volumes, and RAID members. Drives can deteriorate during a read. Flash may remap blocks or remove deleted content through trim. RAID recovery depends on member order, geometry, parity, and disk condition.
A deleted name, fragment, thumbnail, journal entry, or prior version is not an intact file. Results identify each item's source and condition.
Clean-room and specialist vendor boundaries
Platter work, head replacement, micro-soldering, chip-level access, and proprietary firmware tools require a qualified specialist. GDF identifies the provider, purpose, expected changes, cost authority, custody method, confidentiality terms, and stop point before transfer. The specialist decides whether its physical procedure is feasible and documents the work performed.
GDF does not describe a third-party clean room as its own laboratory or imply that opening a drive guarantees recovery. Returned images, parts disposition, notes, errors, and custody records are reconciled before logical reconstruction continues.
Encryption, cloud copies, and backup alternatives
Readable sectors do not defeat BitLocker, FileVault, hardware encryption, encrypted containers, or application keys. Recovery keys, escrow records, identity accounts, trusted devices, and key-management services should be checked before expensive physical work. Credentials and keys require an approved secure channel, not the public form.
A better copy may exist in backups, snapshots, cloud version history, email, collaboration platforms, mobile devices, database exports, server replicas, tape, or another synchronized endpoint. Those copies have different metadata and retention limits. GDF compares provenance, timestamps, completeness, versions, and hashes where available, then identifies the source of each delivered item.
- Local, cloud, snapshot, and backup comparison
- Encryption and recovery-key dependencies
- Version, timestamp, provenance, and duplicate reconciliation
- Targeted priority-file collection when full recovery is impractical
Scope and recovery priorities
Scope states what is needed, by when, and for what use. Continuity may prioritize a database; a legal matter may require a preserved image; a security event may put logs first. The plan names priority data, dates, applications, output, deadline, restrictions, and access to the original.
A limited assessment can precede broader authority. Accessible material outside scope is not reviewed. Client and counsel instructions for privilege, confidentiality, personal information, and protective orders govern the plan.
A documented recovery process
Work moves through intake and authority, condition assessment, stabilization or acquisition, logical reconstruction, and validation with delivery. The order changes for safety, active business impact, degradation, encryption, or a fixed deadline.
- Confirm authority, priorities, prior handling, and preservation needs
- Choose a no-power, logical, imaging, vendor, or alternate-source path
- Acquire the best available source and retain method details
- Reconstruct, validate, reconcile exceptions, and package results
Deliverables that show what was recovered
Deliverables may include the condition and custody record, acquisition identifier, hashes, error summary, source inventory, recovered files, folder structure, version table, exception list, and method summary. A legal or expert assignment may also require a retained image and fuller report.
Results distinguish readable files from partial, corrupt, carved, reconstructed, encrypted, or metadata-only items. Validation may include file opening, application checks, archive tests, database consistency, or comparison with an independent copy. Sensitive data is delivered through an agreed method, not an ordinary email attachment.
Limits and no-guarantee terms
No provider can guarantee a particular file, percentage, or complete result before examining the source. Outcome depends on physical condition, prior power cycles, overwrite, trim, encryption, missing keys, controller behavior, array state, damage, and prior handling. A directory listing does not prove that every file is readable, and an opening file can still contain corruption.
GDF reports actual results and known gaps. Success does not prove completeness beyond the tested sources and validation steps. Timing depends on stability, capacity, retries, replacement parts, vendor queues, encryption access, and data volume. Estimates state their assumptions and approval points.
Data recovery questions
Should the device be powered on? Usually not before triage. If safe, disconnect it and avoid repair prompts, formatting, rebuilds, or scans. Live systems require administrator or vendor coordination.
Can deleted files always be recovered? No. Later writes, trim, file-system behavior, encryption, and surviving replicas control what remains. A name or fragment can survive after full content is gone.
Will recovery alter the original? Some procedures cause change. GDF documents condition, uses a protected acquisition where feasible, and identifies unavoidable changes or logical-only access.
Can a cloud copy or backup replace the failed device? It may satisfy the business need but answer a different technical question. Provenance and required use are compared before substitution.
What belongs on the first call? The source, symptoms, last good state, prior attempts, encryption, backups, priority data, deadline, and authorized contact. Do not send evidence, credentials, or keys through the website.