[SOLVED] Need to recover accidentally overwritten disk

moy0 · 2024-12-07 01:55:52

I accidentally dd'ed over the beginning of my main archive+backup disk. Need help recovering, please.

I frantically ctrl-c'ed the dd a second or two after it started, but of course the initial part of the disk is gone. What I've tried:

I figured there was no harm in re-creating the partition table, which I did and it worked fine.
It had a single partition, with dm-crypt, containing an ext4 filesystem. After I re-created the partition table cryptsetup is now able to open the encrypted partition!
But the ext4 filesystem cannot be mounted.
testdisk is able to recover some of it, but whenever it finds a bad file it seems to treat it as some sort of symlink to the root of the filesystem and it starts a full copy of the whole tree at that point. I think this means I'll have to recover files individually, which is infeasible.

Other things to note:

This is a 4TB disk and I don't have anything bigger, so I can't make an image of it elsewhere. I bought another 4TB disk to save as much as I can recover, but that's all I have.
I don't have another backup. This was the beginning of an effort to make redundant, regular, better backups.

Any ideas?

Last edited by moy0 (2024-12-07 02:49:44)

frostschutz · 2024-12-07 02:10:10

Specific commands involved? Full command history would help a lot to understand what happened from your description. It sounds strange since if it killed the partition table, and the first partition was LUKS encrypted, it would have killed the LUKS header, too. Otherwise if it didn't then the filesystem inside should also be fine. So something doesn't add up.

What does "cannot be mounted" mean? Specific error message, in dmesg? (Mount likes to spout generic "could be anything or other error" messages, when dmesg has the real one).

In the best case you made the partition too small so it would complain about the size not being correct. Easily fixed by making the partition larger.

With ext4 in general you can try debugfs in catastrophic mode, see if it lists any files. Won't work if large segments were overwritten though.

moy0 · 2024-12-07 02:43:54

Thanks, @frostschutz.

Specific commands involved?

dd if=file.iso of=/dev/sda

It sounds strange since if it killed the partition table, and the first partition was LUKS encrypted, it would have killed the LUKS header, too.

Yeah, I was surprised at that too.

What does "cannot be mounted" mean? Specific error message, in dmesg?

EXT4-fs (dm-3): bad geometry: block count 976750289 exceeds size of device (976750080 blocks)

So you're right! This sounds like the original partition was smaller but just by a little bit, correct? That's weird to me, because I'm guessing I just made it as big as possible. I do sometimes leave a gig (or more) at the end, but this doesn't seem like that.

Is there a risk of breaking something if I try to recreate the partition table with progressively smaller partitions? (I'm not able to tell from this how much smaller I need to make it, especially since it's wrapped inside dm-crypt.)

moy0 · 2024-12-07 02:45:21

Oh wait, no, this does mean that the partition is too small, not that it's too big. But again, I'm pretty sure I just picked the defaults in fdisk, so it should be "as big as possible". I'm confused.

moy0 · 2024-12-07 02:49:05

Hot damn, that worked!! For some reason fdisk didn't automatically give me the last sector on the disk in creating the partition. I re-created it with the first and last sectors and now I'm able to mount it. Thanks a million, @frostschutz!

ewaller · 2024-12-07 03:02:30

I would be very careful at this point. I would not trust that it is completely stable. I would wait until your new drive arrives and you can put a file system on it, then use a safer tool like rsync that works on the file level to copy data from the old drive to the new drive. Then, after the data have been transferred, reformat the existing drive and use it as a backuo disk. Look at rsync some more for use as a backup https://wiki.archlinux.org/title/Rsync# … up_utility

moy0 · 2024-12-07 03:13:14

I would be very careful at this point. I would not trust that it is completely stable. I would wait until your new drive arrives and you can put a file system on it, then use a safer tool like rsync that works on the file level to copy data from the old drive to the new drive. Then, after the data have been transferred, reformat the existing drive and use it as a backuo disk.

Good point, thanks!

Arch Linux

#1 2024-12-07 01:55:52

[SOLVED] Need to recover accidentally overwritten disk

#2 2024-12-07 02:10:10

Re: [SOLVED] Need to recover accidentally overwritten disk

#3 2024-12-07 02:43:54

Re: [SOLVED] Need to recover accidentally overwritten disk

#4 2024-12-07 02:45:21

Re: [SOLVED] Need to recover accidentally overwritten disk

#5 2024-12-07 02:49:05

Re: [SOLVED] Need to recover accidentally overwritten disk

#6 2024-12-07 03:02:30

Re: [SOLVED] Need to recover accidentally overwritten disk

#7 2024-12-07 03:13:14

Re: [SOLVED] Need to recover accidentally overwritten disk

Board footer