Let me summarize what I've read in this thread, and the parent thread (about GELI), and the one about making copies of a ZFS volume using dd.
You run a system that uses a very peculiar "backup" strategy, one that is inherently completely broken in the sense that the backups are designed to be modified and overwritten in place. Well, that was a big mistake, but we all have to learn from first making mistakes. In spite of having a very paranoid attitude towards using computers (for example, having a complex but mis-begotten backup system), you used the same password for everything; that seems to implausible that I'm hard pressed to believe it. Then a set of adversaries took over your system for a month, and performed a series of actions that taken together sound like something right out of a science fiction movie. The hacked your cable modem (so even today you think they're listening for what you do, and are spoofing you), and you haven't fixed that. They edited your facebook posts. They understand internals of ZFS and administration of FreeBSD well enough to perform detailed modification of your file system. The actually set a perfect trap for you, making sure that your own use of backups after they have finished the hack will do you in.
And the next thing is where this turns from a difficult-to-believe story into a fever dream: When you came back from your month-long absence, instead of immediately seeking help from law enforcement and not touching the computer, you started messing around madly, copying partitions using dd in the most bizarre fashion, re-encrypting things, and starting on the very complex journey of wanting to develop a "ZFS time machine", which is what this thread is about. This is insane. Here is my advice: Stop. Get help from professionals. Contact law enforcement about the hack (which if it happened as you described is a serious crime). Consult with a good lawyer for what your options for regress to the hackers (which you seem to know) are. Abandon the existing system, get a new set of hardware and OS, and start from scratch. And consult with mental health professionals, to see whether your ability to make good decisions is being negatively affected by a psychological or medical problem that should be treated.
Now to the topic you asked about above. You say (correctly) that ZFS typically doesn't overwrite information (both file data and file system metadata) in place, and that it often writes multiple copies of metadata to disk. You wish to create a tool which acts like a time machine does in science fictions: it rewinds the state of a ZFS file system to a given point in time in the past (which you will specify as a transaction ID). To begin with, this it not in general completely possible, as the ZFS scattered bits of metadata are not guaranteed to be complete. It is also in general not unique: If you have the current state of a bit of ZFS metadata, and some earlier version found randomly on disk, there are usually many possible ways that older version could have evolved into the current state. As a hypothetical example: You find that a directory has 10 entries today, files named a ... j. You find an older copy of the metadata for the directory (but not its content), saying that it had 11 entries a week ago. You also find 1000 file metadata entries on disk that were unlinked within the last week. You have no idea which of the 1000 files was the 11th entry a week ago. In order to replay "the log" (the incomplete an unordered sets of metadata), you have to try out all 1000 possibilities. That seems easy, since computers are pretty fast and capable of running many things in parallel. But then you immediately get into another problem: The other 999 unlinked files could be in any other directory, for which you have not found older metadata. If you have 10,000 directories in your system, there are (10000 999) ways those could be arranged (where the notation means the binomial coefficient), and that number is astronomically large. To put it differently, the task of guessing which path an unknown file system modification took requires checking a very large number of combinations, and like most combinatorial problems, it is intractable (learn about complexity theory and non-polynomial problems). Certainly, with some research it would be possible to create heuristic solutions to this problem, but that's in the realm of a major CS research problem. In my opinion, this is the kind of thing a grad student could do as a PhD thesis.
To my knowledge, no such "time machine forensics" tool exists. And given that it is of very limited use (few people need anything better than fsck for UFS and scrub for ZFS), and much better solutions exist for production systems (namely actual backups, and large production file systems that perform actual transaction logging and have built-in backup mechanisms), it makes sense that nobody is going to invest time into it.
If you really want to write such a tool for yourself, I would start by reading the chapter on ZFS in the "black book" (Design and Implementation of FreeBSD, by Kirk McKusick and friends), and then attending one of the classes that Kirk teaches on ZFS internals. That will give you a solid base for understanding the on-disk data structures, and mechanisms by which they are updated in normal operation. Then schedule a few months of free time.
You run a system that uses a very peculiar "backup" strategy, one that is inherently completely broken in the sense that the backups are designed to be modified and overwritten in place. Well, that was a big mistake, but we all have to learn from first making mistakes. In spite of having a very paranoid attitude towards using computers (for example, having a complex but mis-begotten backup system), you used the same password for everything; that seems to implausible that I'm hard pressed to believe it. Then a set of adversaries took over your system for a month, and performed a series of actions that taken together sound like something right out of a science fiction movie. The hacked your cable modem (so even today you think they're listening for what you do, and are spoofing you), and you haven't fixed that. They edited your facebook posts. They understand internals of ZFS and administration of FreeBSD well enough to perform detailed modification of your file system. The actually set a perfect trap for you, making sure that your own use of backups after they have finished the hack will do you in.
And the next thing is where this turns from a difficult-to-believe story into a fever dream: When you came back from your month-long absence, instead of immediately seeking help from law enforcement and not touching the computer, you started messing around madly, copying partitions using dd in the most bizarre fashion, re-encrypting things, and starting on the very complex journey of wanting to develop a "ZFS time machine", which is what this thread is about. This is insane. Here is my advice: Stop. Get help from professionals. Contact law enforcement about the hack (which if it happened as you described is a serious crime). Consult with a good lawyer for what your options for regress to the hackers (which you seem to know) are. Abandon the existing system, get a new set of hardware and OS, and start from scratch. And consult with mental health professionals, to see whether your ability to make good decisions is being negatively affected by a psychological or medical problem that should be treated.
Now to the topic you asked about above. You say (correctly) that ZFS typically doesn't overwrite information (both file data and file system metadata) in place, and that it often writes multiple copies of metadata to disk. You wish to create a tool which acts like a time machine does in science fictions: it rewinds the state of a ZFS file system to a given point in time in the past (which you will specify as a transaction ID). To begin with, this it not in general completely possible, as the ZFS scattered bits of metadata are not guaranteed to be complete. It is also in general not unique: If you have the current state of a bit of ZFS metadata, and some earlier version found randomly on disk, there are usually many possible ways that older version could have evolved into the current state. As a hypothetical example: You find that a directory has 10 entries today, files named a ... j. You find an older copy of the metadata for the directory (but not its content), saying that it had 11 entries a week ago. You also find 1000 file metadata entries on disk that were unlinked within the last week. You have no idea which of the 1000 files was the 11th entry a week ago. In order to replay "the log" (the incomplete an unordered sets of metadata), you have to try out all 1000 possibilities. That seems easy, since computers are pretty fast and capable of running many things in parallel. But then you immediately get into another problem: The other 999 unlinked files could be in any other directory, for which you have not found older metadata. If you have 10,000 directories in your system, there are (10000 999) ways those could be arranged (where the notation means the binomial coefficient), and that number is astronomically large. To put it differently, the task of guessing which path an unknown file system modification took requires checking a very large number of combinations, and like most combinatorial problems, it is intractable (learn about complexity theory and non-polynomial problems). Certainly, with some research it would be possible to create heuristic solutions to this problem, but that's in the realm of a major CS research problem. In my opinion, this is the kind of thing a grad student could do as a PhD thesis.
To my knowledge, no such "time machine forensics" tool exists. And given that it is of very limited use (few people need anything better than fsck for UFS and scrub for ZFS), and much better solutions exist for production systems (namely actual backups, and large production file systems that perform actual transaction logging and have built-in backup mechanisms), it makes sense that nobody is going to invest time into it.
If you really want to write such a tool for yourself, I would start by reading the chapter on ZFS in the "black book" (Design and Implementation of FreeBSD, by Kirk McKusick and friends), and then attending one of the classes that Kirk teaches on ZFS internals. That will give you a solid base for understanding the on-disk data structures, and mechanisms by which they are updated in normal operation. Then schedule a few months of free time.
? ... Was it not impossible once to make fire of your own instead of relying on a lightning striking a tree? Was it not once impossible to treat diseases that used to kill billions? Was it not once impossible to do ... almost anything?
