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

2) Using 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.

zfs-discuss mailing list

Reply via email to