On Tue, Jun 25, 2024 at 03:05:08AM -0400, Steve Litt wrote: > Anon Loli said on Mon, 24 Jun 2024 18:29:52 +0000 > > > >I don't understand what's so complicated about DD, > > dd isn't complicated. ddrescue is even better. However, you mentioned > you have a decrypted partition on your computer, and transferring that > is better done with rsync than dd or ddrescue. > > >ssh/scp or > > DNS, routing, firewalling, all while you're under pressure. > > >encryption? > > Isn't encryption part of what got you into this situation in the first > place? It's a massive complication when 99% of your priority is > recovery. And why do you worry about data security on these USB disks > (not sticks, disks) when they're only temporary? > > >I'll have to find my USB adapter, > > A new USB adapter will cost you what, forty bucks? What are your > priorities here? How much do you value your data? > > >this is going too slow > > Not if it's USB3. I think 200GB would take less than an hour. > > >over the network, > > If your network is 1 Gbit, it makes no material difference. If it's > 100Mbit, it's still not going to turn into a big problem. > > >that being said, I think that I mentioned the source > >drive being over 200GB in size, so why mention USB sticks? lol > > LOL, I said USB disks, not sticks. > > https://www.newegg.com/model-wdbu6y0020bbk-wesn-2tb/p/1E8-0006-00101 > > Three of those cost you three less than $300, and each one holds ten > times your 200GB of data. > > > > >Encryption is a must, it's not just family photos, but even if it was, > >I'm still not putting them on clear disk > > Well, if that's the hill you're willing to die on. > > Did I mention these intermediate disks are temporary, for the purpose > of recovering you data, and they can be wiped later? Maybe this data > isn't important enough to reduce the risk of mistakes in encryption? > > > > >Now if you can't answer this that's fine, maybe someone else can.. if > >I they can't then I'll cry > >Question is: > >if I write to the raw crypto volume (the decrypted disk), everything > >should still be encrypted, right? > > Am I understanding that you want to write to the borked disk? Whatever > the theory of it not hurting things (on a non-injured disk, of course), > if you value your data I'd not touch the disk in question. > > >I don't understand exactly how under > >the hood OpenBSD FDE works, > > Another excellent reason to make this thing as easy and simple as > possible. > > but if I understand correctly, anything > >written to the crypto volume gets encrypted and what-not, and then > >stored to the drive encrypted, right? > > Whatever the answer is in theory, you're dealing with a disk injured in > a way that's not describable on a mailing list > > > > >I need to make a filesystem out of the backed-up copy if I understand > >correctly, will it still work if 74M of it is overwritten? > >Because then I could maybe DD over the raw(/non-raw?) crypto volume > >and it should work? > >Like what use is backing it up now and then making the filesystem on > >the same drive and fucking up that entire drive? > > If you value your data, and please remember that unless you have > your borked computer plugged into a known good uninterruptable power > supply that can last longer than your longest power outages, you're > one power outage away from losing your data forever, so time is of > the essence. Here is the procedure I would personally use to get the > whole thing done *today*: > > 1. Go to the store and buy two usb3 spinning rust disks between 1TB and > 2TB. I'd also buy a 7200 RPM SATA drive to act as your final > *encrypted* disk, or perhaps an SSD or NVMe of the same size. > > 2. Format and partition both of the USB disks. I highly suggest you not > encrypt them, because mistakes happen and things go wrong. > > 3. Use rsync to copy the unencrypted part to a tree on one of the USB > disks. Be sure to unmount it before unplugging it. Now at least you > have that. > > 4. Use ddrescue to whole device copy the borked device to a file on the > other spinning rust USB drive. Be sure to unmount it before > unplugging it. > > 5. USB3 copy both those drives to the computer you intended to copy them > to over the network. Be careful to copy the to the correct mount or > loop mount, because you don't want to bork a second computer. > > 6. Back up the computer you just copied to. The backup can be > encrypted. Just be careful to remember the decryption key and > > 6. Do whatever you can to rescue any data you haven't already rescued > from the borked disk. > > 7. Power down the machine with the borked disk, remove the borked disk, > and keep it for a year in case you need it. > > 8. Install your new SATA disk in the formerly borked machine, format > and encrypt it (remember the key or password). > > 9. Copy your old data onto the newly installed, formatted and encrypted > hard drive. > > 10. Wipe and reformat and encrypt your USB drive with the directory tree > (not the drive image). > > 11. Rsync your new SATA drive's files and directories that USB drive, > which becomes your backup preventing another disaster. > > 12. Take regular backups so this doesn't happen again. > > The preceding procedure should take you a few hours, especially given > the fact that you have two computers so can be formatting and > encrypting with one while backing up the other. > > SteveT > > Steve Litt > > http://444domains.com >
Why can't I just have another drive(encrypted of course), and do `dd if=/dev/rsd3i of=/mnt/hdd/brokenFSimage bs=1m` 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? (I got the adapter now, over the network it'd take many days, not counting broken pipes and what-not 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) 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) 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? 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 Why is the size like 19G difference? Does it have something to do with me DDing over the 1st 74M of the primary disk? By the way it might be my imagination, but I think that the primary USED size was bigger like 24 hours ago (more than 220G), but I might just be seeing things
