Recovering broken filesystems

Question

Before I ask my question, here's what the setup involved is:
I have one SSD, which holds / and /boot (not LVMed), and one 2TB HDD that held /var, /tmp, swap, and 2 data partitions.I had run out of space, so I bought 2 more 2TB hard drives. I'd planned to make a degraded RAID5 out of them, put an LVM over top of it with partitions matching my existing ones, copy data over, then wipe the original disk and add it to the array.
Now, what happened:
Basically, I wasn't paying as much attention as I should have when I used fdisk. I knew what the 2TB drive's letter was before I added the two new ones, but of course I didn't consider that adding disks would change it. So, I formatted 2 disks, 1 of the new ones plus the old one, with a full-disk partition with the type set to Linux RAID auto-detect. Before I wrote anything else to them, though, I realized I'd reformatted the wrong disk. So, I formatted it back to an LVM partition, and used /etc/lvm/archive to recreate the physical volume. LVM figured it out and was happy.
Here's where it gets a bit weird. Since LVM configurations are backed up before, not after, a new command is run, the last and largest of the partitions wasn't recreated by this. That was fine, though, the guide I was using ( http://insights.oetiker.ch/linux/lvm/ ) noted that, and had a way to restore that last partition. Since the command creating the backup of the configuration is in the backup, I could just run that with an extra flag. Well, that went fine too, I thought. LVM happily restored, everything was good. But, when I tried to get device-mapper to see them, the other 4 showed up in /dev/mapper, but this 5th one failed with an error about being too large for the target.
But, I have (relatively) recent backups of that one, so I didn't concern myself with it. Restoring /var and the other data volume was my primary concern. So, I kept going. But even though LVM knew about them and device-mapper saw them, something was wrong with those partitions, too. I couldn't mount or fsck them. When I tried, I got a bad superblock/bad magic number error. So I tried one of the backup superblock locations. No dice. None of the partitions would work. Dumpe2fs didn't even see the superblocks.
I thought that was especially strange, because no data apart from one mdadm partition's metadata should have been written. They should still be there, and since I'd "successfully" restored the volumes, their filesystems should be intact.
From there I wasn't sure where to go, for a while. Finally, I took a look at the raw partitions. For example, cat /dev/G2/var | less. I could see my data, and in fact I could see text. Text files still show up undamaged. So why weren't things working?
Next I looked at the volumes in hexdump. From here I'm less sure that my approach was right, because I don't know that much about the filesystems, but:
I looked at the working partitions on another, similarly formatted computer (var, tmp, and a data volumes on a HDD, swap on its own non-LVMed partition, and / and /boot on the SSD). For example, comparing the tmp volumes. When I did hexdump -c -v on the working one, it began with:
0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
0000010 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
The broken one, however, starts:
0000000 \0 201 \0 \0 \0 201 001 \0 \0 201 002 \0 \0 201 003 \0
0000010 \0 201 004 \0 \0 201 \f \0 \0 201 \r \0 \0 \0 \0 \0
I wasn't sure what was going on there, but when I looked further down in the working one, I saw something that looked similar...
0002000 002 200 \0 \0 002 200 001 \0 002 200 002 \0 002 200 003 \0
0002010 002 200 004 \0 002 200 \f \0 002 200 \r \0 002 200 030 \0
Similar things show up periodically throughout both volumes, so it's definitely filesystem related. Either inodes or superblock backups, right? (As I said, I don't know enough about the FSes to be confident about anything I say here). Either way, it looks like either when the LVM partition was recreated, or when the volumes were restored, things got shifted by some number of bytes from where they originally were.
So, my questions: Am I right? Am I just totally off base here? Is there anything I can do to recover my data?
I've spent the last couple days trying to get things fixed, so at this point even just a fresh pair of eyes on the problem would really help.

Answer 1

Hi, JoshHardman. Welcome to the Nokia Support Discussions! Just to verify, did you create a backup file before this happened? Which files are you very interested in saving or recovering? Your contacts and paid apps are in sync with your Microsoft account while your media files can be synced to your One Drive account, aside from your memory card.
Have you tried to press and hold the volume down and power keys until it vibrates? This should get your phone to reboot and respond properly again.
Let us know the outcome.