The process of data recovery from QNAP NAS running QuTS hero OS
In comparison to classic QNAP NAS, models with QuTS hero OS are using very different approach for data storage. Instead of using LVM and EXT file system, these devices use ZFS file system pools. QNAP done a great job customising the file system to the purpose however this made their version of QNAP ZFS file system (called internally QZFS) not compatible with third party file system drivers. There are many differences not only in metadata format, but also in the algorithm of RAID-Z operations. Support of this file system (QNAP ZFS or QZFS) is only available in our UFS Explorer Technician product.
Data recovery after the device failure
In the unlikely case of device failure in most cases you can simply move the disk pack to another compatible QNAP NAS running the same or higher version of QuTS hero OS and having the same number of drive bays or more.
Not all versions of QZFS are compatible to all versions of QuTS hero, so it’s advised to ensure compatibility in accordance with the maker’s recommendations.
As an alternative, our UFS Explorer Technician product can also recognise QZFS file system and let you gain an access to the data. This could be useful when a replacement device is not available or access to the data is required as soon as possible before the replacement device unit arrives.
Deleted data recovery
Typically, you can do this via the network Recycle Bin folder by simply restoring the deleted data.
If the data is deleted from the Recycle Bin or without moving it to the Recycle Bin, in many cases you can still recover the recently deleted data using UFS Explorer Technician. To do this, follow these steps:
Connect all disks from the NAS to a Windows PC or server for data recovery and run UFS Explorer Technician. The software should assemble the data store automatically and display QZFS file system:
Right click the file system and choose ‘Show file system transactions’. After a short wait this will display the list of most recent ZFS transactions:
Each such a transaction includes most recent modifications to the file system. Check if a transaction with the date/time before data deletion is present and open the transaction to review contained file system files. The transaction should contain the file system in the state before the data was deleted.
Use the opened file system to copy the data out.
In case the file system was used for a longer time and so even the oldest transaction on the quick access doesn’t contain the deleted data, you can still run the scan for older transactions. To do this:
Click on the “Search transactions” button on the toolbar and specify the search parameters:
QNAP QZFS usually don’t have compression on root metadata entries, so it’s advised to disable both LZJB and LZ4 decompressions for performance reasons (unless transactions displayed after the quick access check show compression enabled).
It’s advised to enable “Scan components simultaneously” option, especially if source components (images) are on different physical storage devices.
Click “Start scan” and the software will start finding previously undetected transactions, typically without dates, but still sorted in their chronological order by ID:
You can check these transactions even while scan is still running. After you can identify a transaction containing your data, you can stop the scan and proceed to data recovery.
Recovery of deleted datasets
Deletion of datasets on ZFS file system (in case of QNAP these are typically different shared folders) works using the same mechanism as deletion of normal files and folders. Please follow the instructions for deleted data recovery for recovering of deleted shared folders/datasets.
Data recovery after pool deletion
This is the most complicated scenario because pool deletion involves deletion of all metadata that describes the pool, including RAID-Z configuration, quick access to the file system or transaction, and so on. For this reason, the software will not be able to identify neither pool nor even pool components automatically.
To proceed, the first recommended step is to create a ‘test’ pool on the same NAS and with the same RAID level, but on different drives of the same capacity (you can use less drives for the ‘test’ pool). When done, connect the drives to a PC for the sample analysis. Right-click the recognised ‘test’ pool and check the parameters:
Write down values of “Minimum stripe size” and “Metaslab size” (specific to the capacity of disks in pack).
Then go back to the original datastore components and do the following steps:
Click “RAID”->”New ZFS pool” from the main menu:
Click “Add a new vdev” to start building the pool; select vdev type (such as RAID-Z) and select vdev components in their original order, including placeholders for missing components. Also specify the valid values for “Minimum stripe size” and “Metaslab size”:
Click ‘Build the pool’. This will produce a new pool volume without a file system on it (the metadata is missing, as described above). As the result, ZFS related functionality will not be available as well:
Select “Scan for lost data”, but instead of configuring and starting a new scan, click on the “(transactions)” link next to the “ZFS” file system selection:
The program will open the “Transactions” dialogue with the empry list. This is because there is no superblock table and so no transactions on the “quick access”:
Start the scan for lost transactions. Wait for some reasonable time for transactions to appear. When they are found – you can proceed and open the file system:
It’s recommended to check multiple transactions backwards to return to the state before the pool deletion (most recent transaction can reflect states in the process of dataset deletions).
If no transactions found this could indicate incorrect RAID configuration. Edit the RAID and try again from the p.4.
QNAP ZFS (QZFS) and computer forensics
QZFS file system is not supported by most known computer forensic programs and requires export of found data for a forensic analysis.
Note that making of a disk image of the assembled RAID-z is strongly not recommended because RAID-z can’t be imaged as a single disk image in a working condition or in a state that represent the actual data on it. The reason for this is the RAID-z rotation and block size are encoded in file system pointers and so can not be restored out of context of the file system and RAID-z.
For data analysis purposes it’s recommended to extract files from the QZFS file system to an empty (zeroed and then formatted) media of a supported format and proceed to the forensic analysis.
Also note that for purposes of evidence collection and tracking them over time it’s possible to extract multiple file system states defined by different transaction, ordered by timestamps or transaction IDs, according to the procedure of “deleted data recovery”.
Last update: October 07, 2025