On Fri, Mar 8, 2019 at 12:56 AM <no_spam@xxxxxxxxxxxx> wrote: > > $ sudo blkid>> > > Good call. Don't know why I didn't think of that. I guess I was > expecting a permission denied error instead of blank output. > > /dev/md0: LABEL="1.42.6-5698" > UUID="b2d6eb2b-3946-4b5b-83e8-12e2880fb83a" TYPE="ext4" Extra confirmation that /dev/md0 is root file system, using ext4. > /dev/md4: LABEL="2017.05.25-01:26:55 v15101" > UUID="f4bc4bd1-af0d-4d54-9b05-6a719ddec086" > UUID_SUB="e40c544c-3d7d-4e01-93af-a5b70985d4f1" TYPE="btrfs" That's interesting. But at the moment it's not directly related to /dev/md3 > PARTUUID="f0c6ebb5-02" > /dev/md3: PTUUID="1828c708-ca70-4672-9095-a1ee53065320" PTTYPE="gpt" This again. I'm gonna say ignore it for now, it might be a stale signature, or there could be a bug somewhere where it even goes away once the missing 1MiB from /dev/md3 is restored. Once everything is fixed, if this still shows up, I'd file a bug with Synology, but otherwise leave it alone. > > << How did you backup /dev/md3 to that 10T drive by the way? What was > the command? >> > > Exact command was: > # dd if=/dev/md3 bs=100M conv=sync,noerror | pv -s 9T | dd of=/dev/sdd1 OK so /dev/sdd1 contains the md logical volume, the array contents - meaning they are interchangeable. One piece of advise, be really careful not to activate /dev/md3 and /dev/sdd1 drives at the same time on the same system. They're identical byte for byte copies, that includes the LVM UUIDs and Btrfs volume UUIDs. Normally there's never two separate volumes with identical metadata, and there are gotchas (bugs and corruption) that can occur when two volumes with identical UUIDs appear to the same kernel at the same time. Ergo when you're ready to repurpose /dev/sdd1 (the 10T drive) you'll want to wipe signatures from it while its on the test PC. > << ($searchdev) might be /dev/md3 on the NAS; or maybe /dev/sdX if it's > the 10T backup on your test PC, might be slightly faster on the 10T > because no RAID parity reconstruction is needed. >> > > I'll kick off the search on the test pc w/ 10TB backup mounted. The search is done on an unmounted /dev/sdd1 - for one you can't mount it if it's an exact copy of /dev/md3, because its first 1MiB is missing, same as md3. > > << OK so that's as expected. Data begins 1MiB into /dev/sda6. Command to > read a MB of that > > $ sudo dd if=/dev/sda6 skip=2048 count=2048 of=/tmp/sda6missing1M.bin > >> > > updated file is on gdrive. > https://drive.google.com/open?id=1A4e2UnzCiN0JUcJZdHe3QwXZa55-kMpd > I didn't think to run it to thru the hexdump like you suggested; I'll > do that tomorrow. > 00030040 5f 42 48 52 66 53 5f 4d 5a 66 18 00 00 00 00 00 |_BHRfS_MZf......| _BHRfS_M is the magic for Btrfs. There's now essentially conclusive proof that /dev/md3 is an LVM2 volume, and is a PV that makes up an LV that's formatted with Btrfs. We've got multiple independent sources of information telling us this, and where these signatures are located, so we know what to look for, and once we find that the LVM2 signature you're searching for, where it and the Btrfs signature need to be relative to this 1MiB missing strip. And even if that fails, there's still another way of making a recovery attempt. -- Chris Murphy
