First off, hi! Second, yes, I''m an idiot and A) don''t have backups, and B) don''t have snapshots enabled (yes I''m going to enable them once I get all this sorted out). :D So here''s what happened: I''ve got a 3x2TB raidz pool full of media files, which includes audio files I record fairly regularly, which are dumped from my R-09 recorder. This device uses oh-so-descriptive filenames like R09_0001.WAV, R09_0002.WAV etc., splitting the file & incrementing the number every 2G, until the SD card is filled and/or emptied, so I organize said files into directories with the date and other descriptors. Now, somehow I managed to put the files from one day in the wrong directory (I''d created several in advance which I knew I''d be using), and when I moved the next batch of recordings, it blew away one of the old ones, since those were sitting in the ''current'' day''s directory and also happened to be named R09_0001.WAV (I''ve since written a bash function to force ''mv -i'' as well as use the directory''s date-description as part of the filename to avoid any future recurrence of this problem). I caught & cancelled the ''mv'' after noticing that there was an R09_0002.WAV in the directory (with an earlier timestamp) while R09_0001.WAV was still growing, so I still have 0002, but it''s only the last 15-20m- 0001 has the first 2 hours, which I''d like to recover if in any way possible. OK, so that''s how I lost the file. Here''s how I''m hoping to get it back: 1) My first attempt was to recover from the R-09''s SD card, which was used to make the audio recording in the first place. I did a dd dump of the card immediately and ran ''photorec'' (set to check only for RIFF files, since that''s all that''s ever been on there), but since >4h of recording took place after the file I''m trying to recover was moved off, that didn''t work. 2) Using http://cuddletech.com/blog/?p=407 as a guide, I was able to use zdb -ddd... to find the other file (R09_0002.WAV) from the lost recording and use this to determine the object ID of the file I''m missing (I also know the file size, since it''s the R-09''s maximum 2G wav file). But since the file is gone, I have no way of finding the disk offsets which would be (hopefully) useful for zdb -R''ing the file chunks back into existance. So AFAIK that''s out as well. Unless there''s some undocumented wizard feature to grab the offset info from a known-but-deleted object id? 3) Last ditch: Since my pool is a 4TB raidz, photorec and similar recovery tools (which expect a block device or dd dump) simply won''t work. But- using zdb -mmm, I can grab the metaslab data and, after sorting and comparing each line''s ''start'' offset to the previous line''s ''end'' position, use that to find the offsets/ranges of all the ''free'' blocks on the filesystem. Theoretically, I can then dump all the free offsets with -R onto another drive and use photorec (or something) on the resulting ~300G ''dd image'', and hope that something turns up from that. The main problem with this is that it''s going to be PAINFULLY slow, with about 1400 metaslabs, and each one taking hours to complete (I''ve got a script that''s been running for about an hour or so now and has managed to reconstruct about 80M out of ~300M free from a single metaslab- then I get to run it for all the other metaslabs). So if this idea is completely insane and absolutely will not work anyway, it''d be nice to know now. :) If anyone has any other advice (other than the obvious "use backups/snapshots!") it''d be much appreciated. Thanks. -Eric