Deleted iSCSI LUN Recovery

An iSCSI LUN (Logical Unit Number) is a block-level virtual disk carved from a storage pool or RAID volume. The NAS or SAN exposes this block device over the network via the iSCSI protocol, and the connected host (ESXi, Windows Server, Proxmox) treats it as a local disk. It formats the LUN with VMFS, NTFS, ext4, or whatever filesystem the host needs.

When you delete a LUN through the storage management UI, the system wipes the LUN allocation table and metadata. On thin-provisioned LUNs, it returns the allocated blocks to the storage pool's free space bitmap. On thick-provisioned LUNs, it releases the reserved block range. In both cases, the actual data written to those blocks stays on the physical drives. The storage controller simply marks those sectors as available for reuse.

On hard drive arrays, the data blocks are not zeroed at deletion time. The data is orphaned, not destroyed. On SSD-based pools with Space Reclamation (UNMAP) enabled, the storage controller may issue TRIM commands after LUN deletion, which directs the SSD firmware to erase freed blocks. Immediate power-off is critical on all-flash arrays to prevent the controller from completing this process.

How RAID-Level Data Persists After LUN Deletion

The LUN is a logical construct sitting on top of a RAID volume or storage pool. The RAID layer does not know or care that a LUN was deleted. It stores blocks on physical drives according to its stripe and parity configuration, and those blocks remain intact until the storage pool allocates them to a new write operation.

1.Synology (mdadm + LVM + Btrfs/EXT4): Synology DSM creates iSCSI LUNs as files on a Btrfs or EXT4 volume, or as block-level LUNs mapped directly to LVM logical volumes. Deleting the LUN removes the LVM mapping or deletes the LUN file, but the underlying ext4/Btrfs blocks on the mdadm RAID array still hold the data.
2.QNAP (mdadm + LVM or ZFS): QNAP QTS uses a similar stack. iSCSI LUNs are either file-backed (stored as a file on the RAID volume's filesystem) or block-backed (direct LVM logical volume). LUN deletion frees the LVM extent or removes the backing file. The RAID member drives retain the block data.
3.Dell EMC Unity / enterprise SAN: Enterprise SANs manage LUNs as objects in a proprietary storage pool. Deletion marks pool extents as reclaimable. The physical drives are still accessible for imaging once removed from the chassis.
4.ZFS pools (TrueNAS, Proxmox, custom): ZFS zvols used as iSCSI targets behave differently. ZFS is copy-on-write, so destroyed ZFS zvols leave orphaned block pointers scattered across the vdevs. Recovery requires scanning for transaction group (TXG) metadata to locate the orphaned blocks.

Stop all writes immediately. If other LUNs, VMs, or file shares are writing to the same storage pool, every write risks overwriting blocks from the deleted LUN. Power down the NAS/SAN if the deleted LUN held your only critical data. If other production workloads depend on the system, isolate the storage pool from further writes at minimum.

How We Recover Data from a Deleted iSCSI LUN

The recovery process works at the drive level, below the storage controller layer. You ship us the individual RAID member drives from the NAS or SAN. We do not need the NAS chassis or SAN controller.

1.Write-protected imaging via PC-3000: Each RAID member drive is connected to a PC-3000 Express or PC-3000 Portable III in write-blocked mode. We create a sector-level image of every drive. If a drive has bad sectors or firmware issues, the PC-3000 handles error recovery and adaptive imaging to extract maximum data from degraded media.
2.RAID geometry reconstruction: Using the drive images, we reconstruct the RAID array: stripe size, parity rotation direction, member order, and RAID level (RAID 5, RAID 6, RAID 10, etc.). For Synology SHR arrays, we identify the multiple mdadm arrays and LVM volume group layout.
3.Filesystem and LUN metadata scanning: Once the RAID volume is reconstructed, we scan for residual filesystem signatures at known offsets. For file-backed LUNs, we search for the LUN image file within the host filesystem (Btrfs, EXT4). For block-backed LUNs, we scan the LVM metadata area for surviving logical volume definitions that map to the deleted LUN's block range.
4.LUN reconstruction and data extraction: If LUN allocation metadata survives (even partially), we rebuild the LUN's block map and mount the guest filesystem (VMFS, NTFS, ext4, XFS) from within the reconstructed LUN image. Files are extracted and verified against checksums where available.
5.File carving as fallback: If the LUN metadata is fully overwritten, we fall back to file-signature carving across the reconstructed RAID volume. This recovers files by type (VMDK, VHD, SQL databases, PST archives, document formats) but does not preserve directory structure or filenames.

Platform-Specific LUN Deletion Scenarios

Synology Storage Manager

DSM's Storage Manager → SAN Manager → iSCSI LUN tab allows one-click deletion. DSM does not prompt for confirmation on LUNs that have no active iSCSI sessions. File-backed LUNs (the default in newer DSM versions) are stored as sparse files on the Btrfs volume; deletion removes the file's directory entry but not the Btrfs extents. Block-level LUNs (Advanced LUN in older DSM) are backed by LVM logical volumes; deletion removes the LV mapping. In both cases, the Synology RAID member drives retain the raw block data.

QNAP QTS / QuTS hero

QNAP's iSCSI & Fibre Channel panel lets admins delete targets and their associated LUNs. QTS uses LVM on top of mdadm RAID arrays (similar to Synology). QuTS hero uses ZFS natively, where iSCSI LUNs are zvols. For QTS LVM-based LUNs, the recovery approach mirrors Synology: image drives, rebuild mdadm, scan LVM metadata. For QuTS hero ZFS zvols, recovery follows the ZFS pool recovery methodology with transaction group scanning. QNAP NAS recovery requires all member drives regardless of which LUN was deleted.

Enterprise SAN (Dell EMC, NetApp, HPE)

Enterprise SAN controllers manage LUNs through proprietary storage pools and RAID groups. We do not service the SAN controller itself. For recovery, you remove the individual drives from the SAN disk shelves and ship them to our Austin lab. We image each drive, reconstruct the RAID geometry from on-disk metadata, and scan for the deleted LUN's block allocation records. Enterprise SANs frequently use drives formatted with 520-byte or 528-byte sectors (rather than standard 512-byte blocks) for internal checksumming, which requires specialized SAS controller configurations and proprietary metadata parsing during RAID reconstruction.

Accidental `zpool destroy`

zpool destroy wipes the ZFS label from every vdev member, but does not zero the data blocks. The pool's uberblock, spacemap, and object set metadata are marked invalid, but older copies of these structures (ZFS keeps multiple uberblock copies across the vdev) may survive. Recovery involves scanning each drive for residual ZFS metadata and reconstructing the pool state from the most recent valid transaction group. See our ZFS pool recovery guide for the full technical breakdown.

Thin vs. Thick Provisioning: Impact on Recovery

Thick-Provisioned LUNs

●Full block range is reserved at creation time. A 2TB LUN occupies 2TB of contiguous (or near-contiguous) blocks on the RAID volume.
●After deletion, those blocks are less likely to be immediately reused because the pool must allocate them to a new request of similar size.
●Recovery success rate is higher because the data layout is contiguous and predictable.

Thin-Provisioned LUNs

●Blocks are allocated on demand as the host writes data. The LUN's blocks may be scattered across the storage pool.
●After deletion, freed blocks return to the pool's free space immediately. Any subsequent write to any LUN on the same pool can claim those blocks.
●Recovery depends on reconstructing the thin-provisioning bitmap from residual metadata. If the bitmap is overwritten, file carving by signature is the fallback.

What to Ship Us

We need the individual drives from the NAS or SAN, not the enclosure. Label each drive with its bay/slot number before removal. Drive order is critical for RAID reconstruction.

●All RAID member drives, including any that were already marked as failed or degraded before the LUN deletion.
●Any hot spare drives that were part of the storage pool.
●SSD cache drives (if the NAS uses SSD read/write caching), as they may contain recently written blocks.
●A note describing: the NAS/SAN model, RAID level, number of LUNs that existed, which LUN was deleted, and whether the LUN was thin or thick provisioned.

See our mail-in shipping instructions for packing guidelines. Use anti-static bags and padded enclosures. Do not stack bare drives without padding.

Pricing

Deleted iSCSI LUN recovery is priced as a RAID recovery case. The complexity depends on the number of drives, RAID level, whether drives have physical faults, and whether the LUN metadata survived deletion. Our no data, no recovery fee guarantee applies: if we cannot recover your data, you pay nothing.

Service Tier	Price	Description
Simple CopyLow complexity	$100	Your drive works, you just need the data moved off it Functional drive; data transfer to new media Rush available: +$100
File System RecoveryLow complexity	From $250	Your drive isn't recognized by your computer, but it's not making unusual sounds File system corruption. Accessible with professional recovery software but not by the OS Starting price; final depends on complexity
Firmware RepairMedium complexity – PC-3000 required	$600–$900	Your drive is completely inaccessible. It may be detected but shows the wrong size or won't respond Firmware corruption: ROM, modules, or translator tables corrupted; requires PC-3000 terminal access Standard drives at lower end; high-density drives at higher end
Head SwapHigh complexity – clean bench surgery50% deposit	$1,200–$1,500	Your drive is clicking, beeping, or won't spin. The internal read/write heads have failed Head stack assembly failure. Transplanting heads from a matching donor drive on a clean bench 50% deposit required. Donor parts are consumed in the repair
Surface / Platter DamageHigh complexity – clean bench surgery50% deposit	$2,000	Your drive was dropped, has visible damage, or a head crash scraped the platters Platter scoring or contamination. Requires platter cleaning and head swap 50% deposit required. Donor parts are consumed in the repair. Most difficult recovery type.

Hardware Repair vs. Software Locks

Our "no data, no fee" policy applies to hardware recovery. We do not bill for unsuccessful physical repairs. If we replace a hard drive read/write head assembly or repair a liquid-damaged logic board to a bootable state, the hardware repair is complete and standard rates apply. If data remains inaccessible due to user-configured software locks, a forgotten passcode, or a remote wipe command, the physical repair is still billable. We cannot bypass user encryption or activation locks.

All tiers: Free evaluation and firm quote before any paid work. No data, no fee on simple copy, file system, and firmware tiers. Head swap and surface damage require a 50% deposit because donor parts are consumed in the attempt.

Target drive: The destination drive we copy recovered data onto. You can supply your own or we provide one at cost. For ultra-high-capacity drives (20TB and above), the target drive costs approximately $400+ due to the large media required. All prices are plus applicable tax.

Frequently Asked Questions

Is deleted iSCSI LUN data actually gone?

No. Deleting a LUN through a NAS management interface (Synology Storage Manager, QNAP QTS, etc.) removes the LUN metadata and allocation tables. The actual data blocks on the underlying RAID volume or storage pool are not zeroed or overwritten at deletion time. They persist on disk until new writes occupy those blocks. The critical variable is how much write activity has occurred since deletion.

Does thin provisioning affect LUN recovery chances?

Yes. Thin-provisioned LUNs allocate blocks on demand rather than reserving the full LUN capacity upfront. When a thin LUN is deleted, the storage pool reclaims those blocks for reuse immediately. Any new LUN creation or write operation on the same pool can overwrite the freed blocks. Thick-provisioned LUNs have better recovery odds because the blocks were reserved contiguously and are less likely to be partially overwritten by unrelated pool operations.

Can I recover a deleted LUN myself with Linux tools?

If the LUN sat on a simple RAID volume with EXT4 or XFS, and you have experience with mdadm, LVM, and filesystem forensics, self-recovery is possible. You would need to image every RAID member drive with a write-blocker, reconstruct the RAID offline, then scan the volume for residual filesystem metadata. For Btrfs or ZFS pools, the internal block allocation is more complex, and standard carving tools do not understand their copy-on-write structures. If the data is irreplaceable, professional imaging with PC-3000 eliminates the risk of additional writes from a mishandled recovery attempt.

What should I do immediately after accidentally deleting a LUN?

Stop all I/O to the storage pool. If other LUNs on the same pool are actively serving VMs or file shares, every write to those LUNs risks overwriting blocks that belonged to the deleted LUN. Power down the NAS or SAN if possible. If that is not an option because other production workloads depend on it, at minimum stop any VMs, databases, or file shares that write to the same storage pool. The fewer writes that occur after deletion, the higher the recovery yield.

How long does deleted LUN recovery take?

Imaging time depends on drive count and capacity. A 4-drive NAS with 8TB drives takes roughly 24-48 hours to image all members via PC-3000 with write-protection. RAID reconstruction and filesystem scanning add another 12-24 hours depending on the RAID level and whether the LUN allocation tables have surviving fragments. Total turnaround is 3-7 business days from drive arrival.