Taking work now — the first look is freeNAS drives posted in from anywhere in the UK, or handed in at ten drop-off pointsQuicker still, give us a ring:0800 6890668
NDRNAS Data Recovery 0800 6890668 Price my job
NDR / Every kind of NAS / iSCSI LUNs, VMs and Docker

iSCSI LUN · VMFS · VHDX · VMDK · Docker · Virtual Machine Manager

iSCSI LUNs, virtual machines and containers on a NAS. A volume inside a volume inside a volume, each one rebuilt on the last.

A NAS that serves a hypervisor or runs its own virtual machines stores file systems inside file systems: an iSCSI LUN is a large file or a block range on the NAS's volume, and inside it sits VMFS, NTFS or ext4 belonging to the machines that used it; a VMDK or VHDX on a share is the same thing one layer up; Docker volumes and Synology's Virtual Machine Manager keep their disks on the Btrfs volume in the same way. When the pool beneath fails, all of it fails together, and it comes back in order: the pool from the drive images, the volume from the pool, the LUN or disk file from the volume, and the guest file system from inside that. A set is £500 + VAT upwards after the free look, fixed in writing, five to ten days at the bench.

Free first lookOne fixed figure in writingNo data, no bill on most jobsReturn postage paid

Rather talk it through? An engineer answers the bench line
0800 6890668

Power it down. Label each drive with its bay number. Do not rebuild, repair, initialise, reinstall or reset. A rebuild reads every sector of every surviving drive, and on a set with a second weak member it finishes what the first failure began. Nothing on the drives gets worse while the unit is off.

LUN and VM symptoms, and what each means.

Not listed? Describe it on the form →
Packing it and posting it: power the unit down, write the bay number on each drive with a marker before it comes out, and send every drive from the set, including any SSD cache. Each drive travels in an anti-static bag inside its own padding, in a box with nothing able to move; the unit itself comes too if it holds an encryption key or a proprietary layout, and its power supply with it. Insure the parcel for what the files are worth rather than the price of the drives, and use a tracked service. The posting address is not printed anywhere on this site; it arrives by email in reply to the form, with a booking sheet to print; the sheet inside the parcel is what matches it to your enquiry when it is opened. Or hand the sealed parcel in at the nearest of ten drop-off points, your name on the outside and the sheet inside; say where you are on the form and it comes by email. We pay the postage home either way. The whole of it is written up on the guide to packing and posting.

How it is laid out, and what fails.

Block LUNs and file LUNsSynology's block-level LUNs are LVM volumes; its file-level LUNs are large files on the Btrfs volume; QNAP's are files or thin volumes; TrueNAS's are ZFS zvols. Each is found on the reassembled volume by its metadata and extracted whole.
Thin provisioningA thin LUN or volume is allocated as it is written, and its map lives in the thin-pool metadata. A full thin pool takes every LUN offline at once; the map is rebuilt from the images before anything inside can be read.
The guest file systemsVMFS from VMware, NTFS or ReFS from Hyper-V, ext4 and XFS from Linux guests, each opened from the extracted LUN image and repaired there where a power cut left it inconsistent.
VMM, Virtualization Station and DockerDisk images and container volumes on the NAS's own file system, recovered as files from the volume image and then opened as disks.

What it says, and what it means.

Describe yours to us →
What you see The usual reason for it Where that leaves you
Datastore inaccessible after a pool crashThe LUN is inside the crashed poolPool from images; LUN extracted; VMFS opened
Thin LUN offline; pool fullThin-pool space exhaustedThin metadata rebuilt; LUNs extracted
VM boots to a repair screenGuest file system inconsistentRepaired on the extracted disk image
LUN recreated by mistakeBlocks still on the volumeOld LUN carved from the volume image
Container data missingSubvolume or bind mount lostRecovered from the volume image

From the box arriving to your files going back.

Work we have closed →
01

Logged the day it lands, and the first look costs nothing Free

A case number goes on the parcel and a number on every drive the day it is opened, and an engineer settles what has actually happened before anything spins. The unit is examined on its own; each drive is assessed on our own equipment, never in a NAS that will try to rebuild. Back to you come two things together: a straight note of what is liftable and what is not, plus one figure, fixed and written down. Accept it, or decline and owe us nothing.

Nothing to pay for lookingA single figure, put in writingNo rebuilds, no repairs, no resets
02

The unit, and the drives, apart

The box and the disks are two different jobs. The unit is tested separately, because a dead power supply, a failed board or a bricked boot flash leaves the drives untouched more often than not. Each drive is then read on the bench: the ones that answer at full speed, and the weak or failed ones in clean air where they need head work. On units that hold an encryption key or a layout of their own, the unit is part of the data and is kept with it.

Unit and disks assessed separatelyFailing members to the clean bench
03

Every member imaged, once

The pool is reassembled from the drive images and the NAS's own file system mounted read-only from the virtual volume. The LUN, zvol, VMDK or VHDX is then extracted whole and opened as a disk in its own right, and the guest file system inside it repaired on that image. Three layers, each on the image of the one beneath, none on the originals.

Every drive, including the cacheWeak areas last
04

The set put back together, from the images

Order, chunk size, parity rotation and the reshape point are read from the drives' own metadata and the array is reassembled in software: mdadm and LVM under SHR, X-RAID and QTS pools; a ZFS pool imported read-only; Drobo's BeyondRAID zones reconstructed. The file system, Btrfs, ext4, XFS or ZFS, is repaired on the virtual volume, and encrypted volumes are unlocked there with the key you supply. Never on the originals.

Rebuilt in software, from imagesThe file system repaired on the virtual volume
05

You see the file list before you pay

What was recovered is listed for you first, and only then does a bill exist. Approve the list and it is invoiced; turn it down and it is not — and where nothing has come back, most jobs carry no charge at all. Recovered data travels home on fresh media bought in for your job, with the postage at our end. Your case is not closed until you have opened the files on a machine of your own.

No charge until you accept the figureFresh media, supplied with the jobFive to ten days at the bench

What arrives most often

  • Tell us what the LUNs held. Which hypervisor, which guests, which of them matter most. The extraction is planned around it.
  • A thin pool that filled up is a stop-everything moment. Every further write on the way to shutdown lands in metadata the bench needs.
  • The guest's own repair tools are not run, because they write. The guest file system is opened from the LUN image and repaired there.
  • Snapshots of LUNs and VMs taken by the NAS often survive on the volume and are frequently the cleanest copy.

One job, followed all the way through.

UK · NDR-2026-0547JOB LOGGED ✓

A QNAP TVS-872XT serving a VMware host by iSCSI, with the thin pool full and every LUN offline

The pool had been over-committed and filled without anyone noticing until the datastores dropped. The unit was powered down. All eight drives were imaged, the QTS pool reassembled, the thin-pool metadata rebuilt from the images, and the three LUNs extracted and their VMFS volumes opened. Every virtual machine came back, on a new pool sized honestly.

100% of the LUNs recovered9 days here, and back by post
Illustrative example — replace with a genuine case

What helps, and what harms.

Do this much first

  • Power down the NAS and the hypervisor's access to it
  • List the LUNs, the guests and what matters most
  • Send every drive, the cache and the unit
  • Tell us the NAS OS version and the hypervisor

What sets us back

  • Expanding, deleting or recreating LUNs
  • Running the guest's disk repair
  • Reconnecting the hypervisor to try again
  • Freeing space by deleting snapshots

Questions answered before you commit.

The NAS crashed and my VMware datastore is gone. Can it come back?

Usually. The LUN is a file or block range inside the NAS's pool; the pool is rebuilt from the drive images, the LUN extracted, and the VMFS opened from it. The virtual machines come back as disk files.

My thin LUN ran out of space and went offline. Is the data corrupt?

Not usually; it is inaccessible until the thin-pool map is rebuilt, which is done from the images. Power down before anything else writes to the pool.

Can you recover a single VM rather than the whole LUN?

Yes, once the LUN is extracted; the guest's file system is opened and the machine's disk copied out.

What does it cost?

A set is £500 + VAT upwards after the free look, fixed in writing; rack units from £1,250 + VAT.

How long does it take?

Five to ten days at the bench.

Nothing gets worse while it is powered down.

Looking at it is free. Back comes a list of what opened and what did not, together with a single price to finish, set down in writing while you are still free to say no. On most jobs an invoice only follows the data. Until that list reaches you, leave the unit off and the drives in their bays.

0800 6890668