On 2018-07-14 12:16:53, Chris Bennett <cpb_m...@bennettconstruction.us> wrote:
> I very carefully and surely tested which flash drive to use and then
> pulled out the wrong one.
> I stopped the install with halt and done nothing else.
> Should I have yanked it, halted it or just said goodbye?
>
Ouch... Sooner or later, I think most all people will do
something that will cause loss of data, so don't feel too bad.
The good news is that it usually only happens once, because most
people will find an event like this to be a very strong motivator
to implement additional backup strategies. It certainly was for
me...
Ordinarily, yanking it would've been the best thing to do, since
halting the system would've flushed more data to the disk that
wouldn't have been written if it had just been yanked, but IIRC
the OpenBSD install program mounts disks synchronously so I don't
think it would've made much difference in this case.
I remember reading a guide about this long ago on the net, and the
first suggested step of data recovery was,
1. PANIC!
The reason being that it's better to take a step away from one's
computer and do the panicking AWAY from the computer so as not to
exacerbate the situation and cause even more data loss by doing
something hasty.
Once that's done, I can only offer some general advice.
The good news is that the OpenBSD installation is only about 300
MB. If it was a network install then you may have to double that
(~300 MB to hold the tarballs, ~300 MB to hold the installation).
That means that you very likely have only lost less than a
gigabyte of data. Depending on how big and how full the flash
drive was, that may leave a significant amount of space that will
still be intact.
The writing of alternative superblocks in the newfs stage would've
probably poked lots of little holes in the data all over the disk.
If you stored large files on the disk, it's likely that they may
have small bits of them that were overwritten.
On the other hand, if you had many small files, it's more likely
that the majority of them will still be intact.
> ddrescue or something else or nothing else?
>
>From what I can tell, ddrescue is meant more to recover data from
a failing disk; not one that has been overwritten.
But first things first, make a COPY of your drive with dd RIGHT
NOW! Anything you do to try to recover anything should be done on
the copy, not the drive itself.
Once that's done, something like sysutils/testdisk is probably
more in line with what you're looking for.
% cat ports/sysutils/testdisk/pkg/DESCR
TestDisk is a powerful free data recovery software! It was
primarily designed to help recover lost partitions and/or make
non-booting disks bootable again when these symptoms are caused by
faulty software, certain types of viruses or human error (such as
accidentally deleting a Partition Table). Partition table recovery
using TestDisk is really easy.
PhotoRec is a file data recovery software designed to recover lost
files including video, documents and archives from Hard Disks and
CDRom and lost pictures (thus, its 'Photo Recovery' name) from
digital camera memory. PhotoRec ignores the filesystem and goes
after the underlying data, so it will still work even if your
media's filesystem has been severely damaged or re-formatted.
%
So it looks like PhotoRec is probably the one you want.
If you need to find your old disklabel (so you know what the
bounds of the disk were) you can try looking in /var/backups.
There should be several "disklabel.*.{backup,current}" files in
there that may contain the disklabel for the drive. Though I
think those are only created as part of the /etc/daily script run
by cron, so the disk would've had to have been plugged into the
computer when it was run.
If you use multiple disks that would share the same device node
(e.g. /dev/sd3) you could also try looking in /var/mail/root which
would log any changes to those files in the daily insecurity
report.
Other than that, it's almost guaranteed that at least *some* data
was lost. Depending on the nature of the data, you may be able to
find some scraps of it on your main hard drive too.
Text editors and word processors tend to create backup files, so
looking around for any files that end in ".bak" or a tilde might
provide some results. Checking vi.recover might also be worthwile
if you were typing anything important in vi.
Once you get through this, I can recommend a few things that may
help to mitigate this in the future:
1) Backup your USB drives to a directory on your hard disk
regularly. rsync is a good simple tool for this, though
borgbackup is nice too. Bonus points if you automate it through
hotplug(4).
2) Since manual backups don't tend to get done as often as
necessary, set up an automatic backup system. rsnapshot is a good
tool for this that runs from cron (it's a thin wrapper around
rsync). borgbackup is also nice too. It's less convenient to
access the files since its FUSE support doesn't seem to work on
OpenBSD yet, but it has compression and dedup so it saves a lot
more space than rsync does.
I hope some of this advice is useful, and that you can manage to
salvage what you need from the disk.
If you're successful, please consider updating the list with the
steps you took.
--
Bryan
