iSCSI LUN Recovery

Written by

Louis Rossmann

Founder & Chief Technician

Updated 2026-08-01

What an iSCSI LUN is and how it is actually stored

iSCSI exposes a block device to a remote server over a standard TCP/IP network. The server, called the initiator, sees the LUN as a local hard drive and formats it with its own filesystem. The NAS, called the target, receives SCSI commands over IP and translates them into reads and writes against its internal storage pool.

The critical detail most competitors miss is what happens on the NAS side. On Synology DSM, an Advanced LUN is a sparse file named EP_DAT_00000 inside a hidden @iSCSI/EP/ directory on the Btrfs or ext4 volume. The file appears to be the full provisioned size, but Btrfs only allocates extents on demand. On QNAP QTS, a Block-Based LUN bypasses the host filesystem entirely and is carved from the LVM storage pool as a logical volume.

This means recovery is never a single-layer operation. Engineers must reconstruct the RAID, parse the host filesystem or LVM metadata, extract the LUN container, and then parse the initiator filesystem inside it. A VMware ESXi host writes VMFS; a Windows server writes NTFS. Both of those filesystems live inside the sparse file or LVM volume on the NAS.

Because the container sits on top of the storage pool, the underlying array reconstruction has to succeed before the @iSCSI namespace is even addressable; a degraded or accidentally rebuilt RAID is the first failure we image and reassemble read-only. When the target is a packaged appliance, the same job overlaps with NAS data recovery, since the Synology or QNAP unit that presents the LUN is a Linux host managing those drives with mdadm, LVM, or ZFS rather than dedicated SAN hardware.

Why did my Synology iSCSI LUN disappear after a reboot?

The LUN disappeared because the link between the iSCSI Target daemon and the underlying sparse file was severed. The most common causes are host filesystem corruption, a failed DSM update that reset the target configuration database, or an accidental deletion in SAN Manager.

When Btrfs on the host volume crashes, the directory tree that points to @iSCSI/EP/EP_DAT_00000 may become unreachable. The extents that hold the actual VMFS or NTFS data are still intact on the physical drives, but the metadata that maps logical LUN addresses to physical RAID stripes is damaged. Without that map, the iSCSI Target daemon cannot respond to SCSI READ commands from the initiator, and the datastore appears empty or offline.

A less common but equally destructive cause is snapshot rollback inconsistency. Synology Advanced LUN snapshots use Btrfs Copy-on-Write and proprietary EP_FRI and EP_ROD tracking files.

If a rollback is interrupted by power loss or insufficient free space, the metadata linking the active LUN to its snapshot base shatters. The LUN either fails to mount or mounts as corrupted raw space.

What is the EP_DAT_00000 file inside @iSCSI?

EP_DAT_00000 is the data payload of a Synology Advanced iSCSI LUN. It is a sparse file on the Btrfs or ext4 host volume, and the numeric suffix increments for additional LUNs. Alongside it, a typical Advanced LUN directory holds several internal container and index files that the iSCSI manager uses to track the LUN and its snapshots:

EP_DAT_00000

The sparse file containing the block-level data written by the initiator. It holds the nested VMFS, NTFS, or ext4 filesystem.

EP_TBL

An index file the LUN uses to map its logical block addresses to byte offsets inside the sparse data file.

EP_FRI

A snapshot tracking file used by the Copy-on-Write snapshot engine.

EP_ROD

A snapshot tracking file the snapshot engine uses to manage LUN clone dependencies.

EP_BUF

A buffer file the iSCSI manager uses for transactional writes and snapshot consistency.

If the index file that maps the LUN's logical blocks to byte offsets is corrupted, the LUN's logical-to-physical mapping is lost. Recovery requires Btrfs forensic tools to locate the older inode or extent records that describe the sparse file's block layout before the crash.

How are QNAP Block-Based and File-Based LUNs different?

QNAP offers two architectures, and the recovery path depends entirely on which one was configured.

QNAP strongly recommends Block-Based LUNs for performance. The tradeoff is that recovery from a deleted Block-Based LUN requires deep LVM knowledge, because the logical volume metadata must be reconstructed from the LVM header backups stored on the member drives.

How do you reconstruct a deleted QNAP Block-Based LUN from the LVM thin pool?

A deleted QNAP Block-Based LUN is reconstructed by restoring the LVM logical-volume metadata offline from the header backups on the member drives, then carving the thin-pool allocation map and mapping the virtual offsets back to physical RAID space. Deletion unlinks the logical-volume metadata, but the thin-pool extents that held the LUN payload often survive until QTS overwrites them.

QNAP QTS stores a Block-Based LUN as an LVM logical volume carved from a thin pool, not as a file on a host filesystem. That distinction sets the recovery path.

On QTS the work targets the LVM layer; on QuTS hero a Block-Based LUN is a ZFS ZVOL, a separate block device inside the pool with its own copy-on-write semantics, and the reconstruction follows ZFS dataset logic rather than LVM extent logic. Identifying which platform wrote the array is the first decision, because a thin-LVM carve and a ZVOL reconstruction share no tooling.

The QTS reconstruction runs against forensic images, never the live array. The sequence is offline throughout:

1. Reassemble the members read-only. Every member drive is imaged first, then mdadm --assemble --readonly rebuilds the array from the image files so the original mdadm superblock state is preserved and no write reaches a member.
2. Restore the LVM metadata. LVM writes a textual backup of the volume-group layout to a header area on the physical volumes. vgcfgrestore against that on-disk header backup rebuilds the volume-group and logical-volume definitions that the deletion unlinked, re-establishing the thin pool and the deleted volume's identity.
3. Carve the thin-pool extent map. Thin volumes do not occupy contiguous space; the thin pool tracks which physical extents back which virtual addresses through its own B-tree metadata. The allocation map is parsed so each surviving virtual offset of the LUN is tied back to the physical extent on the RAID that holds it.
4. Export the reconstructed volume. Once the virtual-to-physical extent map is rebuilt, array-aware forensic software exports the logical volume as a raw image. That image is the LUN container, ready for the nested initiator filesystem to be parsed.

When the thin-pool B-tree metadata is itself damaged, the map is rebuilt bottom-up by gathering surviving leaf nodes rather than trusting the unlinked top-level pointers. This is why a deleted Block-Based LUN is not a file-undelete problem. There is no host filesystem directory entry to restore; the entire logical-volume and thin-pool addressing stack has to be reassembled before a single byte of the initiator's data is readable.

The thin pool itself is a thin logical volume in a QTS volume group, so the carve depends on the broader LVM metadata recovery work that restores the volume-group descriptor area before any extent map is parsed. That volume group rarely sits on a bare disk; it lives on the mdadm block layer beneath the LUN, which is why the array superblocks are examined and the members reassembled read-only before LVM is even activated.

What happens if a Synology iSCSI LUN snapshot rollback is interrupted?

An interrupted Synology Advanced LUN snapshot rollback shatters the metadata linking the active LUN to its snapshot base, so the LUN fails to mount or mounts as corrupted raw space. Synology Advanced LUN snapshots use Btrfs copy-on-write together with the proprietary EP_FRI and EP_ROD tracking files, and a rollback rewrites the references that bind the live LUN to the snapshot generation it is being reverted to.

Power loss or insufficient free space partway through that rewrite leaves the tracking files describing a state that no longer matches the on-disk Btrfs generation. The LUN's logical-to-physical map is now inconsistent: the active EP_DAT_00000 extents and the snapshot extents disagree about which blocks are current, and the iSCSI Target daemon either refuses to bring the LUN online or presents raw space the initiator reads as a corrupt VMFS or NTFS volume.

Forensic recovery is read-only. The goal is to locate the historical Btrfs generation tree root that still describes the pre-rollback EP_DAT_00000 block layout, then extract that sparse file with btrfs restore against the image, which reads the older tree without writing anything back to the filesystem.

What you never do is the opposite: btrfs check --repair, btrfsck --repair, and mount -o recovery,ro all write updated pointers into the live Btrfs and overwrite the very copy-on-write generation roots that describe the pre-rollback layout. On a shattered snapshot rollback, those in-place operations convert a recoverable inconsistency into permanent loss of the prior generation.

Why can't I just run fsck or btrfsck --repair on the NAS?

Running btrfsck --repair or fsck.ext4 on a live, degraded NAS is the single most common cause of permanent iSCSI data loss. These tools attempt to rebuild broken metadata trees in place.

On a CoW filesystem like Btrfs, that means allocating new blocks and updating pointers. The old tree roots are not erased, but the generation pointers that lead to them are overwritten.

If the repair logic guesses wrong, and it often does on a damaged chunk tree, the tool orphans the @iSCSI subvolume from the root tree. The sparse files inside it become unreachable by any standard mount.

Even worse, btrfsck --repair may decide that the unallocated extents holding the LUN data are free space and update the block group accounting to mark them as empty. The next write to the NAS will overwrite your VMFS or NTFS payload.

The same risk applies to mount -o recovery,ro. The recovery option replays the Btrfs log tree, which writes updated pointers to disk even when paired with ro.

If the log references corrupted blocks, the replay writes bad pointers into the live filesystem. What started as a mountable degraded volume becomes completely unmountable.

How do professional engineers recover a crashed iSCSI LUN?

Our workflow is strictly offline and non-destructive. We run every step on forensic clones, never the original drives.

1. Write-blocked imaging: Every NAS member drive is cloned sector-by-sector with ddrescue or the PC-3000 Portable III. Write-blocking prevents the host OS from triggering Btrfs CoW or SCSI UNMAP space reclamation.
2. Offline RAID assembly: We virtually reconstruct mdadm parity geometry, LVM volume groups, or ZFS pools from the cloned images on a forensic Linux workstation. mdadm --assemble --readonly preserves the original superblock state.
3. Host filesystem parsing: For Synology Btrfs volumes, we run btrfs inspect-internal dump-super to inspect superblock copies, then btrfs-find-root to locate historical tree roots with intact @iSCSI namespaces. For ext4, we use inode carving to locate the extent tree mapping the LUN file.
4. LUN sparse file extraction: Once a valid root is found, we use btrfs restore -t <bytenr> to extract the EP_DAT_00000 sparse file read-only. For QNAP Block-Based LUNs, we reconstruct the LVM thin-pool extent map and export the logical volume as a raw image.
5. Initiator filesystem mount: The extracted LUN file is exposed as a loopback block device with losetup -f. We then parse the encapsulated VMFS, NTFS, ReFS, or ext4 filesystem and export the virtual machines, databases, or files to a separate storage array.

All work is performed in-house at 2410 San Antonio Street, Austin, TX 78705. We use named equipment: PC-3000 Portable III, PC-3000 Express, DeepSpar Disk Imager, and a 0.02 micron ULPA-filtered clean bench. Founded in 2008.

How is a VMFS datastore on an iSCSI LUN actually recovered?

A VMFS datastore on an iSCSI LUN is recovered through four nested extraction stages, because the VMFS lives inside the LUN container, the container lives inside the NAS host filesystem or LVM, and that layer lives on the reconstructed RAID. Each layer has to be peeled before the one inside it is even addressable, which is why this is not a single VMFS scan.

1. Reconstruct the underlying array. The member drives are imaged, then the RAID or mdadm array is reassembled virtually from those images with mdadm --assemble --readonly on a forensic workstation. Nothing is parsed against the live members.
2. Parse the host filesystem or LVM metadata. On a Synology target the host Btrfs or ext4 filesystem is parsed to reach the @iSCSI namespace; on a QNAP Block-Based target the LVM volume-group and thin-pool metadata is restored instead. This stage yields the location and addressing of the LUN container.
3. Extract the LUN container. The container itself is pulled out: the Synology sparse file EP_DAT_00000 extracted with btrfs restore, or the QNAP logical volume exported as a raw image from the rebuilt thin-pool extent map. The output is a single block image representing exactly what the initiator saw as its disk.
4. Parse the initiator filesystem inside the container. The container is exposed as a loopback block device, and the initiator's own filesystem is parsed. For a VMware ESXi host that means navigating the VMFS heartbeat region, the VMFS metadata, and the VMDK descriptor and flat extents to rebuild each virtual disk. For a Windows initiator it means parsing NTFS. Only then are the VMs, databases, or files exported to a separate destination array.

This stack is why iSCSI recovery is not "just like recovering a VMDK." A flat VMDK sits directly on a host VMFS volume you can scan in one pass. A VMFS-over-iSCSI datastore is encapsulated: the VMFS bytes are interleaved through the LUN container's sparse or thin-provisioned addressing, which is itself interleaved through the host filesystem or LVM, which is itself striped across the RAID.

Raw block extraction skips every one of those translation layers, so it returns discontinuous fragments that no VMFS parser can mount. The extent maps at each layer have to be honored in order, or the VMFS heartbeat region and VMDK descriptors never line up with their flat extents.

The same nested-extent discipline scales up to dedicated enterprise SAN recovery, where the iSCSI or Fibre Channel targets are presented by a rack controller instead of a NAS appliance but still expose LUNs as thin-provisioned block devices. On a controller-based filer the LUN virtualization is even deeper, which is the case with NetApp FAS and ONTAP arrays that wrap each LUN inside a WAFL flexible volume before it ever reaches the initiator.

How is a TrueNAS iSCSI LUN different from a Synology sparse file?

A TrueNAS zvol is a block device carved directly from the zpool; it appears on the host at /dev/zvol/<pool>/<zvol>. It is not a Btrfs or ext4 sparse file, and there is no @iSCSI directory to walk. The zvol has its own block size, set at creation and readable with zfs get volblocksize, which the recovery has to honor so the nested filesystem's blocks line up with the zvol's addressing.

The SCSI target daemon lineage differs by edition: TrueNAS CORE uses ctld, the FreeBSD CAM Target Layer daemon, and TrueNAS SCALE uses scst on Linux. The daemon is not the recovery layer, though. It only advertises the target and maps it to a backstore. The data lives in the zpool and the zvol, so recovery targets those, not the target daemon's configuration.

The recovery sequence is read-only from the first step. The pool is imported read-only and unmounted with zpool import -o readonly=on -N against forensic clones, never a plain zpool import on a degraded pool, which can hang and can commit writes. Then the zvol block device is read, and only then is the nested initiator filesystem inside the zvol, whether VMFS, NTFS, or a VHDX container, parsed and exported.

If the pool used ZFS deduplication, the Deduplication Table has to fit in RAM for the pool to import, roughly 5 GB of RAM per 1 TB of deduplicated data. An undersized host hangs zpool import and can panic mid-import. That is why the import is attempted read-only on a workstation with adequate RAM, never forced back on the original NAS that crashed in that state.

1. Image every member drive. Each pool member is cloned first so the pool is only ever touched through the images, never the originals.
2. Import the pool read-only and unmounted. zpool import -o readonly=on -N brings the pool up against the clones without mounting datasets or committing any write.
3. Locate and read the zvol. The LUN is the zvol block device at /dev/zvol/<pool>/<zvol>, which is read as the container image the initiator saw as its disk.
4. Parse and export the nested filesystem. The VMFS, NTFS, or VHDX inside the zvol is parsed and the virtual machines, databases, or files are exported to a separate destination.

Because the LUN is a zvol on a live ZFS pool, the recovery overlaps with the wider TrueNAS pool recovery work that reconstructs the zpool before any zvol is addressable. An all-flash TrueNAS pool's NVMe members are imaged with the PC-3000 SSD; SATA members are imaged with the DeepSpar Disk Imager, and SAS members through a SAS HBA with a hardware write-blocker. When the array geometry itself has to be reconstructed before extraction, that is done with Data Extractor Express RAID Edition against the member images.

How do you recover a Proxmox VE iSCSI LUN with LVM on top?

Proxmox drives the target with targetcli on the Linux LIO framework. The backing store beneath the LUN can be a ZFS zvol, an LVM thin logical volume, or a raw block device. Proxmox does not store LUNs in an @iSCSI directory, so the recovery path follows the backstore, not a hidden filesystem folder.

Adding an iSCSI target directly in Proxmox maps the whole raw LUN to a single VM disk. To run many VM disks with thin provisioning, Proxmox instead puts an LVM volume group on top of the iSCSI block device. That means recovery has to reconstruct the LVM volume-group header on the recovered target before any thin logical volume, each holding one VM disk, can be carved back out.

A common LIO failure mode is a lost mapping. targetcli reloads its configuration from /etc/rtslib-fb-target/saveconfig.json at boot. If the backing devices are not online when the service starts, the target-to-backstore mapping fails to restore and the LUN vanishes from the initiator. The extents usually survive; only the mapping is lost, which is a metadata problem, not a data-destruction event.

1. Image the underlying disks. Every member or backing disk is cloned so all reconstruction runs against images.
2. Recover the storage layer first. Import the ZFS pool read-only, or restore the LVM volume-group header with vgcfgrestore from the on-disk backup, depending on which backstore Proxmox used.
3. Reconstruct the LVM-on-iSCSI volume group. The volume group Proxmox layered on the iSCSI block device is rebuilt so its thin volumes become addressable again.
4. Carve the thin LV and export the guest. The thin logical volume holding each VM disk is carved, then the nested guest filesystem inside it is parsed and exported.

When the backstore is a ZFS pool, this recovery shares its first stage with Proxmox VE recovery, and the LVM-on-iSCSI reconstruction depends on the same LVM metadata recovery work that restores the volume-group descriptor area before any thin volume can be carved.

Pricing

iSCSI LUN recovery is priced per member drive, multiplied by the number of drives requiring imaging and analysis. Standard consumer NAS drives use our HDD pricing tiers:

Helium-filled enterprise drives (8TB and larger Toshiba MG, WD Ultrastar, Seagate Exos series) use helium-specific pricing: From $200 through $3,000–$4,500. A 5-bay NAS with four standard drives and one helium drive would be priced as the sum of the applicable per-drive tiers.

Rush service adds 100. +$100 rush fee to move to the front of the queue Donor drives are matching drives used for parts. Typical donor cost: $50–$150 for common drives, $200–$400 for rare or high-capacity models. We source the cheapest compatible donor available.

No diagnostic fees. No data, no recovery fee. If we cannot extract your virtual machines or databases, you pay nothing for the recovery attempt.

How long does iSCSI LUN recovery take?

Imaging takes 6 to 10 hours per 4TB drive. A 4-drive NAS with a crashed Btrfs host filesystem typically takes 2 to 4 business days for RAID assembly, host filesystem parsing, LUN sparse file extraction, and initiator filesystem export. If member drives have bad sectors or head degradation, bitwise imaging with PC-3000 adds time.

Thin-provisioned LUNs with heavy fragmentation or SCSI UNMAP history take longer because the extent map must be reconstructed from Btrfs chunk trees or LVM thin-pool metadata rather than simply copied sequentially.

Frequently asked questions

Why did my Synology iSCSI LUN disappear after a reboot?

The LUN likely disappeared due to corruption in the underlying Btrfs or ext4 filesystem, severing the metadata link to the @iSCSI directory, or due to a failure in the Synology iSCSI Target daemon after a DSM update. The data extents usually remain intact on the RAID.

What is the EP_DAT_00000 file on my Synology NAS?

EP_DAT_00000 is the sparse file representing the actual Advanced iSCSI LUN payload. It contains the nested filesystem (VMFS, NTFS, etc.) written by the connected server. It lives inside the hidden @iSCSI/EP/ directory on the host Btrfs or ext4 volume.

Can I recover an accidentally deleted QNAP block-based LUN?

Yes, if the storage pool has not been overwritten. Recovery requires extracting the drives, imaging them, and reconstructing the LVM thin-pool extent map offline to reassemble the deleted logical volume.

Should I run a filesystem check to fix a crashed LUN?

No. Running btrfsck --repair or fsck.ext4 on a live NAS overwrites Copy-on-Write metadata blocks that forensic tools need to locate previous valid states of the LUN. Live repair is the most common cause of permanent iSCSI data loss.

What is the difference between QNAP File-Based and Block-Based LUNs?

File-Based LUNs are image files on a standard volume (ext4), similar to a VMDK. Block-Based LUNs are carved directly from the LVM storage pool as block devices, bypassing the host filesystem for better performance and native thin provisioning.

How long does iSCSI LUN recovery take?

Imaging takes 6 to 10 hours per 4TB drive. A typical 4-drive NAS takes 2 to 4 business days for full RAID assembly, host filesystem parsing, and LUN extraction. Drives with bad sectors require additional time for bitwise imaging with PC-3000.

Are iSCSI LUNs physical partitions on the NAS drives?

No. On Synology, an iSCSI LUN is a sparse file inside the @iSCSI directory on Btrfs or ext4. On QNAP Block-Based configurations, it is an LVM logical volume inside a storage pool. It is never a physical partition.

Can I just extract raw blocks from the NAS drives to get the LUN back?

No. Modern iSCSI LUNs are thin-provisioned and fragmented across the RAID. Without parsing the extent map (Btrfs chunk trees, LVM thin B-trees, or Synology EP_TBL), raw blocks cannot be reassembled into a coherent initiator filesystem.

How do you recover a deleted QNAP Block-Based LUN?

We image the member drives, reassemble the array with mdadm --assemble --readonly, restore the unlinked LVM logical-volume metadata from the on-disk header backup with vgcfgrestore, then carve the thin-pool allocation map so each surviving virtual offset is tied back to its physical RAID extent. Deletion unlinks the volume metadata, but the thin-pool extents usually survive until QTS overwrites them. A QuTS hero Block-Based LUN is a ZFS ZVOL instead and follows ZFS dataset logic rather than LVM carving.

What happens if a Synology LUN snapshot rollback is interrupted?

An interrupted rollback shatters the EP_FRI and EP_ROD tracking metadata that links the active LUN to its snapshot base, so the LUN fails to mount or mounts as corrupted raw space. Recovery is read-only: we locate the historical Btrfs generation tree root that still describes the pre-rollback EP_DAT_00000 block layout and extract the sparse file with btrfs restore. We never run btrfs check --repair or mount -o recovery,ro, because both overwrite the copy-on-write generation roots that describe the prior layout.

Can a VMFS datastore on an iSCSI LUN be recovered?

Yes, through four nested stages: reconstruct the RAID from member images, parse the host Btrfs/ext4 or LVM metadata, extract the LUN container (Synology EP_DAT_00000 sparse file or QNAP logical volume), then parse the VMFS inside it by navigating the heartbeat region, VMFS metadata, and VMDK descriptor and flat extents before exporting the VMs. It is not the same as recovering a flat VMDK, and raw block extraction fails because it skips every encapsulation layer's extent map.

Is a TrueNAS iSCSI LUN a sparse file like on Synology?

No. TrueNAS presents an iSCSI LUN as a ZFS zvol, a block device carved from the zpool at /dev/zvol/<pool>/<zvol>, not a sparse file in an @iSCSI directory. Recovery imports the pool read-only and unmounted with zpool import -o readonly=on -N against clones, then reads the zvol and parses the nested VMFS or NTFS. A degraded pool is never imported without the read-only flag, and a deduplicated pool needs its DDT to fit in RAM, roughly 5 GB per 1 TB deduplicated, or the import hangs.

How is Proxmox VE iSCSI recovery different?

Proxmox drives the target with targetcli on the Linux LIO stack and usually layers an LVM volume group on the iSCSI block device so several VM disks share one LUN. Recovery is storage-layer first: recover the ZFS pool or reconstruct the LVM volume-group header, then carve the thin logical volume holding each VM disk. Proxmox does not store LUNs in an @iSCSI directory, and a lost saveconfig.json mapping is a metadata problem, not data destruction.