On 9/26/23 21:42, sprits killshot wrote:
I did the thing.
dd'd a 5gb img to my ssd instead of my usb and I want to die.
dd if=file.iso of=/dev/sd1c
I am using a CRYPTO RAID partition and luckily I'm smart enough not to
nuke that.
My ssd is 2TB so I believe it uses FFS2 by default. I'm hopelessly
running scan_ffs on it in case it was silently updated or the man is
wrong or there's a God.
ok...so the first 5G of sd1 is gone. So most likely, all file systems
that have any bit of them in that first 5g are not practically
recoverable. (here's the sad bit -- if you were trying to steal info
like credit card numbers or personal ID numbers, there's probably lots
still accessible, but for your uses, just consider all partitions that
start in the first 5G gone.
BUT ... everything after that has potential.
Put in pictures ...
* If you have one big 2TB partition, stop reading now, you can start
crying, and wish you had a good backup system in place.
==> sd1a: 2000GB # Practically speaking, gone. Too much clobbered.
* If you have multiple partitions and some of them start after 5GB,
you might be in luck. Let's say you have three partitions:
(start of disk)
==> sd1a: 4GB # Totally gone.
==> sd1d: 500GB # Practically gone. Too much clobbered.
==> sd1e: 1496GB # untouched.
(note: the letter orders don't matter, it's the starting
offsets that matter to you. If you put the 1.5TB sd1e at the front
of the disk, and sd1a and sd1d after it, sd1a and sd1d are untouched,
but sd1e is not (practically) recoverable.)
To recover sd1e, you need to recreate a disklabel that matches what
was there before...exactly. To the sector.
Now..I see you clobbered sd1c, not sd0c. With a bit of luck,
perhaps sd0 (or at least, not sd1!) is where your /var partition is,
and with a little more luck, you have left your machine on over
night enough times to let /etc/daily run and save your butt.
[edit: just realized sd1 is probably your softraid encrypted
drive, so you probably lost your /var. But maybe you have a copy
somewhere]
Take a look in /var/backups/ for disklabel.sd1*. IF they exist,
they are backups of exactly the disklabel that was on that disk
when they were made. Hopefully, that is recent enough for you.
Drop a new MBR (or EFI) on sd1 with fdisk, then import that
disklabel (disklabel -e sd1, clear it,
":r /var/backups/disklabel.sd1.current", write it, quit), and
you should be in business -- your un-nuked partitions will
become immediately available (but sd1a and sd1d will not be
"formatted" for you at this point).
Note: I haven't done exactly this, but I think it will work,
based on doing enough things with OpenBSD disk layout that I
think I know what you can get away with. Practicing on a
spare system would be advisable.
Now...what if that /var/backups directory doesn't contain a
disklabel backup? Well, you MIGHT still be in business.
OpenBSD disk layout stuff is very predictable. IF you know
how your disk was originally laid out and you repeat that
process, you will end up in the same place again.
For example, if you know that you created a 4GB partition,
a 500GB partition, and then the rest of the disk as a third
partition, AND you know the disk was created using an MBR
layout, you can probably:
fdisk -iy sd0
disklabel -E sd0
> create 1G partition
> create 500G partition
> create "rest of disk" partition
And...most likely, that 1G partition would be where it was
before, the 500G would be where it was, and (ta-da) your
"rest of disk" partition would be exactly where it was.
Exception: a number of years ago, OpenBSD changed the
default starting offset from 63 sectors to 64 sectors to better
handle 4k block drives. You will need exactly the correct
offset. Assuming your disks were set up at the same time,
your sd0 would be a good guide there.
I just reread your note and realize that you might be saying
that sd1 is an encrypted disk. In which case, all the
above applies, BUT you probably can't see your /var partition,
so you might be out of luck. But if you know how it was
created (and your daily output e-mails might be of use there),
you might get lucky recreating the disklabel. You might want
to start by imaging the remains of the disk to another drive
before going any further so you can try again if you guess
wrong.
But yeah. You need a good backup.
here's mine: https://holland-consulting.net/scripts/ibs/
ksh shell script + rsync + another computer and big disk.
Nick.
