On Thu, Jun 27, 2024 at 04:39:09PM -0400, Steve Litt wrote:
> Anon Loli said on Thu, 27 Jun 2024 04:12:57 +0000
>
> >On Wed, Jun 26, 2024 at 11:34:02PM -0400, Steve Litt wrote:
> >> Anon Loli said on Wed, 26 Jun 2024 16:17:35 +0000
>
> >> But wait. Unless that "other drive" is somehow hotpluggable (like
> >> USB), you'll need to shut down the computer to plug it in, and it's
> >> way too soon in this process to turn off that computer.
> >
> >Why? I have it plugged in already and I've successfully not only DDd
> >to the backup drive, but also verified that the data on both SSD and
> >the backup HDD is the same sha512 hash, even if there's a 19G
> >difference in size
>
> I don't understand exactly what you did.
>
> >> >the /mnt/hdd is the mountpoint of the crypto volume of the secondary
> >> >disk, and then somehow reformat the sd2/3 (the SSD with the
> >> >corrupted FS), and then copy over the corrupted image backup from
> >> >the HDD?
> >>
> >> The backup from your dd command isn't reliable, because garbage in
> >> garbage out. dd makes a byte for byte copy --- it doesn't heal
> >> anything.
> >
> >But the steps that I already took is good, right?
>
> You seem to be in an improved situation.
>
> > Is my corrupt data
> >backed up at least?
>
> You're difficult to understand, but it sounds like your corrupt data is
> backed up to your computer's other disk, in some form or other.
>
> >I need the raw disc copy, not the sd3i copy,
> >right? Should I copy both? I have space
>
> The more the merrier, if you really have the space. Once again, I'm
> concerned if you're copying to a disk already in use on your computer.
> Be sure you filenames clearly identify which is which.
>
>
> >> >(I got the adapter now, over the network it'd take many days, not
> >> >counting broken pipes and what-not
> >>
> >> 200GB, many days? What are you dealing with, 10Mbit?
> >>
> >> >
> >> >I didn't understand 100% of what you wrote, but if I understand
> >> >correctly this is the simpler version of what you recommended, yes?
> >> >(no idea what ddrescue is compared to dd)
> >>
> >> ddrescue helps with iffy disk sectors.
> >
> >why is everyone recommending rsync then?
>
> Because at one point you had said you have a mount containing the
> unencrypted files. If this had been true, rsync would have been
> cleanest and easiest. But your subsequent email stated you do NOT have
> a mount containing unencrypted files. Also, nobody said rsync should be
> the *only* copy you made, but if it had been possible it should have
> been the first.
>
> >> >In that case the worst problem then would be how to get a
> >> >functioning filesystem out of that image of the corrupted system?
> >> >(assuming the raw disk of the crypto volume is the image of the
> >> >filesystem, should be)
> >>
> >> I thought you currently have a mount of this partition that's
> >> unencrypted. That's sure what it sounded like you said. If so, for
> >> gosh sakes, copy all those files somewhere safe before turning off
> >> the computer.
> >
> >I do, it's on /mnt/ssd, but it says no such directory even though `df
> >-h` says otherwise
>
> *What* says "no such directory"? If you can't read the data, then you
> don't really have an unencrypted partition, even if /mnt/ssd formerly
> contained unencrypted readable files.
>
> You really need to express yourself unambiguously. And all this
> misunderstanding is why every single person advised you to keep it
> simple.
>
> >
> >
> >> >Or you people keep on saying something like "do this and this and
> >> >then backup/save files and directories", but I can't do that if I
> >> >can't read the files directly, so how to do it indirectly?
> >>
> >> It sounded like you were saying you have a mount with an unencrypted
> >> version of the files. If not, please forget the step I mentioned
> >> about rsyncing the files somewhere else.
> >
> >I do
>
> There you go again. Just a few paragraphs ago you said you can't read
> it. Please write for clarity and unambiguousness.
>
> >
> >
> >> >I copied the image with the above command to the backup drive, what
> >> >worries me is the following size on respective disks:
> >> >primary disk (SSD with the corrupted crypto volume filesystem): used
> >> >220G secondary disk (the backup HDD): used 239G
> >>
> >> I hope the capacity of that backup disk is more than 239GB, because
> >> that would be cutting it pretty tight. Maybe you had 19GB of stuff on
> >> the backup drive before doing this operation?
> >>
> >> >
> >> >Why is the size like 19G difference? Does it have something to do
> >> >with me DDing over the 1st 74M of the primary disk?
> >>
> >> OK, here I'm not understanding you at all.
> >
> >data on original disk SSD - is 220G
>
> Measured with what command?
>
> >data on the backup HDD that I just DDd and VERIFIED - is 239G
>
> 239GB measured with what command?
>
> And what do you mean "data on original disk SSD"? At this point that
> SSD is nothing but a drive with at least one partition.
>
> >how can there be a 19G difference in a same file (DDd image or
> >whatever it's called), and still be the same hash?
>
> [snip]
>
> >No kidding? The 1st few people made it sound like it's going to be
> >relatively easy :(
>
> Like you say, easy is relative. Several days ago, you should have had
> an image of /dev/borkedisk, that image should be a file, not a device,
> and it should be on a 2TB spinning platter USB interface external disk.
> Also on that USB disk should have been a partition image file for each
> of the partitions on the borked disk. Separately. And if you had a
> partition with *readable, unencrypted* files, you should have rsynced
> that into a tree on the USB external disk.
>
> Anon, with your insistence of doing it your (complicated) way instead of
> following almost everyone's suggestions, plus your ambiguous and at
> times contradictory descriptions of the situation, *you* have slowed
> your progress for recovering (if possible) your data.
>
> SteveT
>
> Steve Litt
>
> http://444domains.com
>
I have autism, please be patient ._.
I have had data unencrypted, readable from sd3i, mounted on /mnt/ssd (example
mountpoint), I think I explained it a lot of emails ago, that's what confuses
me but you probably have better things to do than to read all of the emails on
this matter..
I used `df -h` on the drives to get their size, like I said in one of my
emails. the borked ssd shows 220G, the copy of that to the backup HDD (also
borked data) is 239G, but both give the same sha512 hash...
I'm sorry for not using rsync, I don't like replcaing utilitites that are
already present in OpenBSD and have served me well so far (except this caes
where it was my fault user error :( )
No comments:
Post a Comment