If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#16
|
|||
|
|||
End of year survey for how much storage you typically use for your Windows program files & program data
Auric__ wrote:
My 4tb storage drive got overwritten with a (blank) ~100GB NTFS partition, at the very beginning of the disk. Not sure what happened or why, but I am not exactly thrilled, as you can imagine. One of the rules of installing, is to disconnect all drives that do not need to be touched by the install. For example, I have three drives on this computer, and during an OS install, two get disconnected as they have nothing to do with it. That way, only one drive needs to be backed up just before the install attempt. I''ve lost a couple drives (target drives) while setting up multi-boots. I would recommend being especially careful with Debian itself. Paul |
Ads |
#17
|
|||
|
|||
End of year survey for how much storage you typically use for your Windows program files & program data
On Sat, 02 Jan 2021 16:35:33 -0500, Paul
wrote: Auric__ wrote: My 4tb storage drive got overwritten with a (blank) ~100GB NTFS partition, at the very beginning of the disk. Not sure what happened or why, but I am not exactly thrilled, as you can imagine. One of the rules of installing, is to disconnect all drives that do not need to be touched by the install. For example, I have three drives on this computer, and during an OS install, two get disconnected as they have nothing to do with it. That way, only one drive needs to be backed up just before the install attempt. I''ve lost a couple drives (target drives) while setting up multi-boots. I would recommend being especially careful with Debian itself. Paul I am doing dual boot but the OS's are on different drives. I boot W/7 from a SDD but my DOS 6.3 is on a FAT 16 partition on another drive. W/7 still sees it OK so I can move files around. I had an XT drive out there too but on my last reorganization I decided I was done with XP on this machine. My C: partitions on both drives are pretty small and easy to image. All of my "data" is on other drives including the folders Windows uses as much as possible. There isn't much in "my documents". I have a 500g SSD with 2 partitions one being a 50g Windows C: A 1TB "data" drive with 3 partitions and another mirrored set of 1TB drives I use as short term backup cache. Then I really just need to back that one up to the external drive. My movies and other big stuff are on 2 other machines on the network, manually mirrored. |
#18
|
|||
|
|||
End of year survey for how much storage you typically use for your Windows program files & program data
Auric__ wrote:
I wish I knew more about how ext2/3/4 works. I have a very basic user-level understanding of it, but I'm not sure how to use the info presented to me to recover my files (and believe me, if I can recover instead of restore from backup, I'll be a happy man). Man, I miss the simple days of UNDELETE.EXE. https://www.sciencedirect.com/scienc...42287617300270 "Contribution It can be concluded from the findings of this work that, by using the described approach, files can be reconstructed from Ext4 file systems even without knowledge about the particular structure of the file system. By separating the inode search from the inode reconstruction, it is possible to find inodes when there is no given information about the file system layout available. Neither the file system size, nor the examined Ext4 file system's offset to the begin of the partition are necessary in order to locate inodes (and thus gain first information about potential files). " So what that says, is EXT4 has some special properties. Especially if it wasn't a conversion from EXT3 to EXT4. Apparently EXT4 likes to use Extents, and then if the recovery software searches for inode signatures, that makes it easier to recover complete files. The files may be sans path information, but for a download folder, getting the file itself back is a start. The recovery then, doesn't have to be as bad as Photorec just randomly grabbing blocks and slapping them together. There may be enough "local structure" to what is on the disk, to allow recovery of most everything still there. All it takes is an Extent Aware recovery tool. (Apparently the following code fits into the SleuthKit framework, which is command line.) https://www.cs1.tf.fau.de/research/a...file-recovery/ # source code http://faui1s205.informatik.uni-erla...is-Seufert.rar Paul |
#19
|
|||
|
|||
End of year survey for how much storage you typically use for your Windows program files & program data
Paul wrote:
https://www.sciencedirect.com/scienc...42287617300270 [snip] https://www.cs1.tf.fau.de/research/a...file-recovery/ # source code http://faui1s205.informatik.uni-erla...is-Seufert.rar Wow, thank you very much. I'd never heard of SleuthKit, much less this. This looks very, very promising. R-Studio seems to be able to at least detect the inodes (or whatever), but you get a pretty heavy information overload. I'll have to spend some time reading and dinking around. Elsewhere, Paul also wrote: One of the rules of installing, is to disconnect all drives that do not need to be touched by the install. For example, I have three drives on this computer, and during an OS install, two get disconnected as they have nothing to do with it. I know, I know, after 35+ years you'd think I'd be doing it religiously, but no, I have to be an idiot... -- There is no rest for me in my search for peace. |
#20
|
|||
|
|||
End of year survey for how much storage you typically use foryour Windows program files & program data
Auric__ wrote:
Paul wrote: https://www.sciencedirect.com/scienc...42287617300270 [snip] https://www.cs1.tf.fau.de/research/a...file-recovery/ # source code http://faui1s205.informatik.uni-erla...is-Seufert.rar Wow, thank you very much. I'd never heard of SleuthKit, much less this. This looks very, very promising. R-Studio seems to be able to at least detect the inodes (or whatever), but you get a pretty heavy information overload. I'll have to spend some time reading and dinking around. Elsewhere, Paul also wrote: One of the rules of installing, is to disconnect all drives that do not need to be touched by the install. For example, I have three drives on this computer, and during an OS install, two get disconnected as they have nothing to do with it. I know, I know, after 35+ years you'd think I'd be doing it religiously, but no, I have to be an idiot... I finally got a result on my attempts to recover EXT4 files. To simulate your disaster, I formatted a 500GB drive as EXT4, copied over 5000 files (from my Downloads folder), then changed the first partition to NTFS and "formatted". This causes about 100MB of writes to the partition, guaranteed to cause at least some file loss for where the NTFS $MFT metadata file is stored. I got the Sleuthkit file source, and added the inode carving module. The package build did not go well at all. It turns out the "framework" module, would be something a person writing a program would use, rather than being immediately useful to an end user. so this turned out to be a dead end. I then tried working on "tsk_recover", part of the SleuthKit you can install from Synaptic package manager. So now, imagine the situation. I have an EXT4 partition but it's disguised as NTFS. 1) First step, was to use FDISK or GDISK, to change the partition number from 0x0700 to 0x8300. So the partition table type would change from NTFS to EXT. This really didn't do much of anything. Sleuthkit tsk_recover said its internal use of some e2fs utility was unable to find an EXT partition. Something like that. 2) Next step, was to make an identical disk, and mkfs.ext4 to the partition, so I would have partition header (the first few sectors) plus all the Superblock locations. Turns out, I didn't need any Superblock info. I took a look with a Hex editor (from Windows, the HxD one), and I copied 4096 bytes from the newly minted empty partition, over to the damaged partition. So now I've replaced the first few sectors (8 sectors of 512 bytes), with what should be a very similar file system header to what used to be there. At this point tsk_recover indicated it scanned and found 177 files of around 5000 files total. Still not doing good enough. 3) Next, with backup in hand, I tried a few fsck runs. I figured, maybe some genius fixed fsck to make use of the new extent features and all that sweet redundant information, and I could "make" a partition out of the thing. I used Gnome-disks and used the star menu to select "scan disk" and "repair disk". These whined and it didn't look like they did anything. Next, I did a simple "sudo fsck /dev/sda1" kind of command from Terminal, and the command seemed to complete. Now when I ran tsk_recover, the utility claimed it had copied most everything that used to be on there. With fsck, you never know whether the wiring will be better or worse than it was before (that's why you make a backup with "dd" beforehand - I just cloned the original disk to a scratch disk to run this test case). I haven't checked sizes, nor verified anything yet. Because the process finished relatively quickly (should have been maybe 40GB of files), I suspect I'm in for a rude surprise when I compare the "before and after" file sets. But at least it claims to have done something. When I tried the RStudio trial, it promised to return more files than I'd put there in the first place. Pictu https://i.postimg.cc/qMF2CMKQ/its-fun-to-pretend.gif Paul |
#21
|
|||
|
|||
End of year survey for how much storage you typically use for your Windows program files & program data
Paul wrote:
Pictu https://i.postimg.cc/qMF2CMKQ/its-fun-to-pretend.gif Paul Ran hashdeep on the recovered data from the tsk_recover and the files recovered seem good. The dates are wrong, and have todays date. But the size ahd MD5s are correct. There are the expected missing files, which correspond to the approx 100MB of metadata NTFS writes out during formatting. So whatever files were hit by that, aren't recovered. The size of the recovered data is 44GB, and perhaps the original test dir was 46GB or so. Perhaps one of my downloaded ISOs did not survive. By combining your (older) backup, with the recovered data, you'd have good coverage for the damaged files in the recovery (written long ago and backed up), as well as the files up near the end of the partition which are recoverable. Paul |
|
Thread Tools | |
Display Modes | |
|
|