How to recover deleted files from a ZFS file system when no snapshot is available

ZFS is known for its advanced data integrity, including a snapshot mechanism that allows users to easily restore deleted files. However, if a snapshot has not been created prior to deletion, this leaves no straightforward way to roll back the changes.

Even in such cases, recovery may still be possible thanks to a ZFS feature known as "transactions". These records are created automatically by the file system and act as temporary non-persistent snapshots that may contain its previous states, as explained below. Yet, because transactions are volatile and can be quickly overwritten by new data, it is crucial to stop any write operations to the file system immediately after data loss is detected.

Recovery options and stages of the process

There are two possible options for recovering deleted data from ZFS volumes when no snapshot exists:

1. Using an automated scan:

   • Download and install the appropriate UFS Explorer software. Simple volumes can be analysed with UFS Explorer Standard Recovery, while stripe/RAID-Z volumes require a more advanced edition, such as UFS Explorer RAID Recovery or UFS Explorer Professional Recovery.

   • Select the ZFS volume in the program’s interface and click "Start scan". Proceed with the default parameters.

   • Once the analysis is complete, the software will present both existing and deleted files, allowing you to copy the data out.

   The article on how to recover data from a ZFS volume describes this approach in more detail. In this case, the software performs automatic search for file system transactions and other metadata, compares file system states across different transactions and identifies missing folders and files. However, this process can be very slow for file systems containing a large number of files. Thus, in such cases, the second option may be preferable.

2. By accessing file system transactions directly:

   • Download and install UFS Explorer Professional Recovery or Recovery Explorer Professional.

   • Identify the ZFS volume, right-click it in the interface and select "Show file system transactions". After a short wait, this will display the list of transactions available in "quick access", along with their creation timestamps.

   • Locate a transaction with a date/time prior to the data deletion and double-click it to open the file system in that state.

   • Find the missing data and proceed with recovery.

   • If the required transaction is not present in "quick access", you can scan for more transactions using the "Search transactions" tool in the "ZFS transactions" GUI. Newly found transactions will most likely lack timestamps, but they will still be ordered chronologically.

   • If a transaction has already been partially overwritten, the file system structure within it may be corrupted. In this case, you can use the "Run a quick scan on the transaction" function to overcome the corruption in the file system structure.

   Although this method offers less automation, it allows accessing ZFS data within minutes and without waiting for a long scan to complete.

What are "transactions" and how do they differ from snapshots?

Every modification to the metadata of a ZFS file system is performed using the copy-on-write mechanism, which prevents file system corruption in the event of an operating system or hardware failure. These modifications are allocated to new disk locations and, after a certain period, can be "committed" to the file system. If a system failure occurs before they are "committed", these pending changes are lost, and the file system is "rolled back" to its previous consistent state. So, a series of changes made to the file system metadata constitutes a "transaction".

An example of how a transaction is created is illustrated on the diagram below:

In this example, file "A" is deleted, while files "B1" and "B2" are added. The file system generates a new copy of metadata that keeps references to all unmodified files, removing the reference to the file "A" and adding new references to files "B1" and "B2". This updated version of metadata is stored as a new "transaction".

Unlike file system snapshots, transactions are not persistent. This means that the file system can easily overwrite an older transaction at any time to free up space for a new transaction or a new file.

What are "transactions" in "quick access"?

At the very top level of a ZFS file system, there is an array of up to 128 blocks (called "uberblocks"), each of which contains an entry point to the file system. The valid "uberblock" with the highest "transaction ID" represents the latest version of the file system. Any "uberblock" with a lower "transaction ID" corresponds to an older transaction and can be used to open the file system in a previous state.

Since the file system is frequently updated, the actual number of "uberblocks" with valid file system references may be limited.

Because these transactions can be identified immediately, without performing a scan, they are referred to as being "in quick access".

Typically, many more older transactions can be discovered by scanning the file system.

Last update: October 11, 2025

If you liked this article, you can share it on social media: