Yes, if you shutdown immediately after, you have a reasonable chance of full recovery.
That article seems reasonable, except that you have to import the pool to get the pool history. Based on that, I would use the following, all from the command line unless specified otherwise;
- Arrange to boot without the pool auto-importing, (which would be R/W, potentially bad at this stage).
- Manually import the pool R/O.
- Get the pool history, and the ZFS write transaction ID for the dataset destroy
- Export the pool
- Import the pool R/W using the specific ZFS write transaction ID you got from step 3.
- Verify that the pool is good to go in regards to the formerly destroyed dataset.
- Export the pool
- Import the pool from the GUI, check if looks good. Potentially rebooting to restore any shares or apps using the pool or it’s datasets.
Now I’ve left off specific commands and options as I have not done this before, BUT, the concept is very sound.
Caveats:
- The pool import with the specific ZFS write transaction ID has to be R/W. Otherwise when you export the pool, the destroyed dataset is still destroyed on any simple import of the pool.
- You loose any writes that occurred after the dataset destroy, however, you said you made none, so that should not be a problem. (I mention it for future readers with a similar problem, but DO want to preserve later written data.)
- The GUI / TrueNAS middleware won’t know anything about what you are doing from the command line. Thus, ignore the GUI / TrueNAS for the moment. This is all underlying ZFS work on the command line.
- All TrueNAS users should have a basic understanding of ZFS, and what it can and can’t do. ZFS is not the end all to solve all problems… but it does have greater data integrity that anything else out their at present. And, it is the only file system and RAID manager that TrueNAS supports.