Back in time - or: zpool import -T
A disclaimer first: I found an undocumented option of a Solaris 11.1 command. Again: This is an undocumented option. So: It can break everything. It will probably break everything. Because it’s undocumented, it’s officially not there. And it’s still undocumented, as my blog isn’t the documentation of any product of Oracle. It’s just a report about an discovery i made. The option, that’s officially not there, can disappear at any time and without further notice. The world may be going down when using it. And a laser could rasterize you and suck you into the computer. At least when you use it wrong, you can create a lot of havoc with it.
Sometimes you find out interesting stuff just by Google and trying something out. Yesterday i’ve searched for some information for ZFS on FreeBSD (one the OSes i keep in my OS zoo) and in the course of it, i found a mail on a FreeBSD list talking about the command zpool import -T . -T? There is no -T option on zpool import? Or is it just in FreeBSD?
However i couldn’t believe that there is a feature that interesting in ZFS on FreeBSD but not available on Solaris. So i booted up my Solaris 11.1 in my virtual box. At the end i found out how to import a zpool with a state back in the past based on the transaction group without using snapshots.
Normally you get a “invalid option” message, when you try an unknown option.
However trying out
-T yielded a different result:
OOOOOKAAAAAY, there is a parameter -T. But hey, it’s not in the man page , it’s not in the usage messages of zpool, it’s not documented.
You had my curiosity. But now you have my attention. There is indeed an option for the import subcommand of zpool.
Like the command i found at the mailing list it wants a transaction group number as it’s parameter. Okay, let’s play with it. At first i needed a test pool. I didn’t want to try on a live filesystem.
Now i’m creating a number of test files
Just to visibly check the files contain the same data and are still accessible , i’m creating some checksums. I don’t need it to proof the correctness, the checksums in ZFS ensure that it’s either correct or not accessible.
The wildcard in the command delivers 4 files.
Okay, the -T option want a transaction group number. Where do i get it? For my test i just dumping the current transaction group number to screen
Now i will delete all the data in the filesystem.
And now i will create a new file and printing the checksum of the file to screen.
As you have surely recognised the wildcard got us 1 file. Okay, now i will try this strange option. I’m importing the pool read only at the state of the transaction group 21.
Let’s check the content of the filesytem.
That’s interesting. You have now 4 files in the filesystem. The first one isn’t readable anymore. I assume parts has been overwritten by
/testpool/5. As soon as you delete a file and it isn’t part of a snapshot, the space it had occupied will be freed. When something is overwritten the checksums in the tree doesn’t match any longer, so the systems denies access. But the other 3 are still readable.
This matches the output of
zpool status -xv:
Let’s now try other txg group numbers:
Ah … i can scroll back through time … perhaps a really nice example to show customers the transactional behaviour of ZFS in in an simple example.
As we’ve mounted the pool read-only nothing has changed. So
/testpool/5 is still readable when we get back to the newest state.