MultiDrive – free backup, clone & wipe disk utility from Atola Technology

All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 1 post ] 
Author Message
 Post subject: QNAP OPENZFS
PostPosted: December 27th, 2025, 8:50 
Offline

Joined: August 26th, 2021, 17:52
Posts: 71
Location: Brasil
Hello everyone,

I am are using the UFS Explorer Technician to work on a RAID recovery case from a QNAP NAS, which uses a custom QNAP-modified implementation of ZFS (QZFS). The storage system is composed of 10 4 terabyte disks, configured in a striped RAID layout. For analysis purposes, we created full sector-by-sector images of all drives. These images are currently stored across 4 destination disks, distributed in a way that avoids I/O bottlenecks.

Using these images, we manually assembled the RAID configuration multiple times, testing different layout parameters. In particular, we rebuilt the volume repeatedly while selecting different metaslab size values, testing all available options ranging from 2 GB up to 128 GB, in order to rule out alignment or space-allocation issues related to metaslab configuration. In all cases, regardless of the metaslab size selected, UFS Explorer Technician successfully assembles the RAID and presents the filesystem as healthy (green), with no reported filesystem inconsistencies.

We were able to successfully assemble and detect the volume structure; however, during the data extraction process, we are encountering consistent issues where multiple files — regardless of size, ranging from a few kilobytes up to very large multi-terabyte files (e.g., ~14 TB) — either cannot be copied at all or are copied only partially. This behavior remains unchanged regardless of the metaslab size selected during manual reconstruction, as the same results were observed across all tested values. At the same time, some large recovered files are fully functional, including video files in the tens of gigabytes range, and we were also able to successfully open a virtual disk image (QCOW2) of several hundred gigabytes, which indicates that the volume structure is at least partially consistent, while the issue appears to be more pronounced with very large and highly fragmented files.

As a final validation step to rule out any I/O bottleneck or performance-related limitation, we repeated the tests by working directly from the physical disks whenever possible. For a small number of problematic drives, we used sector-by-sector clones instead. In all scenarios, UFS Explorer Technician correctly detects the RAID and automatically assembles the volume, and the filesystem is consistently shown as healthy (green). This behavior remains the same whether working from disk images or physical disks, and regardless of the metaslab size selected during manual reconstruction. The results were identical during both the data extraction process and manual RAID assembly, which further suggests that the issue is not related to throughput, storage performance, image handling, or RAID detection itself.

Out of 30 terabytes of total data, only 5 TB has been copied successfully so far.

We would greatly appreciate any guidance on how to proceed in order to safely and completely extract the full dataset, with special attention to these very large virtual disk files, avoiding corruption or incomplete copies.

Thank you in advance for your support. We look forward to your insights.


Attachments:
File comment: This is a screenshot of the error UFS Explorer Technician gives me regarding the files it cannot extract.
Sem título.png
Sem título.png [ 209.47 KiB | Viewed 131 times ]
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: Google [Bot] and 22 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group