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.

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. The name prefix EP stands for Extent Pool, and the numeric suffix increments for additional LUNs. A typical Advanced LUN directory contains several files:

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

The translation table mapping logical block addresses of the iSCSI LUN to byte offsets inside the sparse file.

EP_FRI

Snapshot metadata tracking the front index of Copy-on-Write delta blocks for Snapshot Replication.

EP_ROD

Read-Only delta tracking used by Synology's snapshot engine to manage LUN clone dependencies.

EP_BUF

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

If EP_TBL 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.

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.

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:

• File system recovery (logical): From $250
• Firmware repair (unrecognized / wrong size): $600–$900
• Head swap (clicking / beeping): $1,200–$1,500

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.