iSCSI LUN Recovery

Written by

Louis Rossmann

Founder & Chief Technician

Updated 2026-05-24

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.

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.