Data Recovery Case File · NAS & Network Storage · Copy Everything, Then Delete
At Every Moment, Part of It Existed in One Place Only
Her enquiry describes a migration performed in the way that feels most sensible and carries the most risk. Moving data from a network device to a cloud service: "I started moving data and deleting what was already copied. Halfway through the move, it stopped working." Two providers have since looked at it. Deleting as you go feels tidy and orderly — and it means that throughout the entire operation, some portion of the data exists in exactly one place, which is where the failure found her.
| Media | Network storage appliance undergoing migration to a cloud service — content deleted incrementally as it was copied; device failing partway through the operation; two prior assessments performed |
| Reported situation | Data being migrated from the appliance to a cloud service · content deleted from the appliance as each portion was copied · device ceasing to function partway through the migration · assessed by the manufacturer without result · assessed by an independent provider · contents required |
| Fault class | Device failure during incremental migration — deleted content at risk on the source with destination completeness unverified; migration boundary undetermined |
| Equipment used | Destination audited and completeness established before source work · prior providers' methods and any write activity established · disk imaged write-blocked · deleted content recovered where present · results reconciled against the destination inventory |
The decode: the boundary, and the practice that avoids it
Why deleting as you go feels right: it gives visible progress, keeps the source from filling, and avoids the confusion of not knowing what has moved. It is orderly, and orderliness is usually a virtue.
Why it is the dangerous pattern: at every moment during the operation, the data divides into three parts — the portion copied and still present on the source, safe in two places; the portion not yet copied, present only on the source; and the portion just deleted, present only at the destination. Two of those three have exactly one copy. A failure at any point during the migration lands on one of them.
What the halfway failure produced: an unknown boundary. Some material is at the destination and safe. Some is still on the failed device. And some was deleted from the device on the assumption that it had arrived — an assumption nobody verified, because verification was not part of the process.
So the first action is not on the device at all: audit the destination. Establish exactly what arrived, file by file, and check that it opens rather than merely appearing. That produces an inventory of what is definitely safe, and by subtraction defines precisely what is missing and must come off the device. Until that exists, nobody knows what they are recovering.
Why the deleted portion is the anxious part: content deleted from the source before the failure is recoverable in principle — deletion removes references rather than overwriting — but it competes with everything else for whatever the device can still yield. Knowing whether a given file actually arrived at the destination determines whether it needs recovering at all.
The practice that removes the whole problem: copy everything, verify everything, then delete. It requires enough space to hold both copies simultaneously, which is the only real cost, and in exchange nothing is ever in one place. Verification means checking that files match rather than that a transfer reported success, since a transfer confirms bytes moved and not that they are the right ones.
On the two prior assessments: worth asking both what they attempted and whether anything was written, since a device that has been through two providers has a history that changes what remains possible.
On the bench
The destination was audited and completeness established before any source work — an incremental migration leaving an unknown boundary, with content deleted from the source on the assumption it had arrived, so an inventory of what is definitely safe defines by subtraction what must be recovered. Prior providers' methods and any write activity were established. The disk was imaged write-blocked, deleted content recovered where present, and results reconciled against the destination inventory.
The outcome
The destination audited first, prior handling established and the disk imaged with results reconciled against what had genuinely arrived. Free assessment, one fixed written figure including VAT; where a drive has to be opened, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. The decode: deleting as you copy means that throughout the whole operation, part of your data exists in exactly one place — the part not yet copied, and the part just deleted. A failure anywhere lands on one of them. Copy everything, verify it, then delete.
Migration interrupted while deleting as you copied
Audit the destination before anything else — check what actually arrived, file by file, and open a sample rather than trusting that it's listed. That inventory tells you what's definitely safe and, by subtraction, exactly what has to come off the failed device, which is information nobody has right now. The pattern is what caught you: deleting as you go feels orderly, but at every moment your data is in three parts, and two of them exist in only one place — what hasn't been copied yet, and what was just deleted on the assumption it arrived. A failure anywhere lands on one. The alternative is copy everything, verify it matches, then delete, which needs space for both copies and nothing else.
Audit the destination first — then call Guildford Data Recovery on 01483 901310; completeness established before source work, prior handling established, results reconciled against what genuinely arrived.
Request a quote online →
Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.