I've queried google exactly about this thing, yep I would like to hire someone then, to teach me how to "memorize" it it self. How much? Is it expensive?
I don't know. Find some ZFS developers; that's easy to do, the source code allows you to find committers. Assume that doing forensics will take many hours ... maybe a dozen or two dozen hours. I would think that someone skilled enough to be a ZFS developer would probably charge several hundred $ per hour. Is the data worth several thousand $ to you?
And there is absolutely no guarantee that this will work; they might easily find that you have overwritten too much.
To "teach you" how to do it would take much longer; they would need to spend dozens of hours explaining how a file system stores data, how it stores where the data is on the disk itself, what the data structures really mean, how you can find the data structures on disk.
Metadata is not the actual data, am I right?
Metadata is data about data. Thence the name. Let me explain a little bit how data is stored on a real disk. We begin by defining a "well known location". It might for example be sector 42 of the disk. ZFS could declare that it will always put a disk label on sector 42, which says: This is a ZFS disk, validated by the checksum of this sector being correct, it is volume X3 in a pool named Xxx, and the master index is in sectors 123 and 456. Then there are two copies of the master index, each of which could say: this pool contains 5 disks, which are named X1...X5, and they use RAID-Z2. This disk is 98765 sectors long. The data log starts at sector 1234, and the last written point was sector 9876. The directory/inode log starts at sector 12345, and the last written point was at 19876. The file system in this zpool is called /home. The root directory of file system abc is stored redundantly in blocks 45678 and 56789. Then sector 45678 is a directory data structure, which says the directory contains the directories bob, charlie and david (all relative to the file system name). And using this data, you can now hop and skip around the disk and eventually find everything. This is metadata.
What you did: You destroyed all the metadata that tells ZFS what the pool and the derived data structures are. So all these important bits of information may be on disk somewhere, but nobody knows where. We might be able to find them by doing an exhaustive search. That is very hard, requires writing specialized tools, and carefully interpreting half-broken bits of data.
I just want to get my /home back. Asking for Recipes
Recipe? (a) Don't destroy it. (b) Find someone who might be able to recover it. (c) Spend months learning ZFS internals to do that task yourself. (d) Give up and read the backup tape. You have a good backup, right?
gitlab.com
