You are not logged in.
Remember that 'laugh at me' thread? Now I just got myself in an identical situation - except it's probably wayyy worse.
My original Arch disk is dying - bad blocks and failures happen, and it's also too slow. So I bought a new SSD for Arch to reside in. After multiple failed attempts with 'dd', I read an ArchWiki title describing how to clone disks proper. One of the parts of the title talked about 'ddrescue' so I went to Archiso and used it.
But I did not tell apart my disks well enough. I pulled a disk from the computer and put my new disk in place of it since the article tells me to directly use the SATA ports on my computer for the best results. And then when I was typing the ddrescue commands I just put in the block device paths by instinct and immediately left home afterwards, leaving 160GB of my data burning away.
It wasn't until now that I realized that I fucked up. What's worse, the original partition table is well overwritten, and the signature conflict also stops me from modifying the UEFI bootorder to make the firmware try to boot from another copy. Thankfully though, there's almost 2TB of them and 160GB's loss probably would not hurt so much to me. But still, I need those data. What is a good way to me to restore those?
Offline
Just reformat the drive and restore the data from your last backup.
Offline
Just reformat the drive and restore the data from your last backup.
PROBLEM: I do not have a backup beforehand. ![]()
So of course, the first 160GB is lost, forever. I'm only seeking to regain access of the last 1840GB to see what's left of it.
Offline
What's worse, the original partition table is well overwritten
If the drive was originally partitioned in a way that had the relevant partition offset >= 160GB, the filesystems behind that are still intact.
You only need to restore the previous partition table and should™ be able to mount any partition that wasn't touched by your DiskDestroyer experiment.
testdisk can even find them for you if you don't recall the layout.
the signature conflict also stops me from modifying the UEFI bootorder to make the firmware try to boot from another copy
Edit: nope.
Humm? So you have backups?
In that case just flatten the drive, re-install and restore the backed up data.
Otherwise you're fucked.
I just put in the block device paths by instinct
From windows, you can pray that chkdsk is able to recover the FS, but I'd not hold my breath - it's not corrupted, but erased.
If it wasn't bitlocker encrypted, you can give testdisk and photorec a shot, but the filesystem (filenames, paths, connections of larger, fragmented data) is gone.
https://wiki.archlinux.org/title/File_r … d_PhotoRec
"dd" and "instinct" don't go along at all.
Last edited by seth (2022-12-16 16:20:59)
Online
I do remember the original partition layout though.
<START>| [ 2000GB NTFS ] |<END>
Offline