/wsr/ - Worksafe Requests » Thread #1280006

[150 / 28 / 10]

Dead USB

Anonymous Mon 07 Nov 2022 18:57:21 No.1280006 View View Reply Original Report

Hey there /wsr/

My USB died and you guys suggested I should try Linux to recover it.
I finally got round to it, but the problem is that now I don't really know what to do.

The problem with the drive is it wasn't showing up in Windows, and if it did it was for a second before becoming inaccessible.
I've installed gparted on a USB and I'm booting from there.

When I run
>lsblk
the drive does show up with the right capacity, but it doesn't show up as being mounted to any mountpoints. I'm not sure how to mount it, I'm not even sure how to see the file explorer in GParted.

I was suggested to run ddrescue but I can't do that unless it's mounted, right?

How do I proceed?Any help is appreciated, thanks

Previous thread on this:
https://archive.alice.al/wsr/thread/1263908/

Anonymous

Anonymous Mon 07 Nov 2022 19:25:53 No.1280017 Report

Quoted By: >>1280024 >>1280028

>>1280006
>but I can't do that unless it's mounted, right?
No, ddrescue runs on raw block devices, you shouldn't be trying to mount it. You will need to mount a second device to hold the image file that ddrescue is going to make though

Anonymous

View Same Google ImgOps iqdb SauceNAO lainux masterrace.jpg, 321KiB, 934x1080

Anonymous Mon 07 Nov 2022 19:27:57 No.1280021 Report

Quoted By: >>1280024 >>1280028 >>1280166

>>1280006
I've read that its your first time on Linux and am in no way professional enough to guide you but first off
Start here
https://www.geeksforgeeks.org/mount-command-in-linux-with-examples/
Also read man mount and mount --help
I would try to Mount it first regularly
In my 5+ years of using Linux i've tried to stay away from dd commands as much as possible, because they are powerful enough to have earned themself the alias "disk destroyer", not to say they arent useful, but handle with care
Also even if you are a beginner, dont type commands you are not sure what they do, especially not when you sudo, look it up, it may seem complicated but most isnt
Last but not least: dont drink and sudo

Anonymous

Anonymous Mon 07 Nov 2022 19:29:38 No.1280024 Report

Quoted By:

>>1280017
This Anon knows more
t. >>1280021

Anonymous

Anonymous Mon 07 Nov 2022 19:36:12 No.1280028 Report

Quoted By: >>1280033 >>1280045

>>1280017
>>1280021
Thank you.
The disk shows up when I use lsblk
I tried to mount it, However, what I've noticed is that after about a minute, the drive will stop being detected and no longer be shown. So I tried to mount it, but it takes a bit of time and then it just says the USB device does not exist, because it has stopped being detected
I have been typing commands I'm unsure of, specifically with sudo so I'll stop that now, lel.

But yeah, I don't think I'm getting anywhere with mounting. The issue with gparted is I don't seem to have a basic file manager to check stuff either and I can't get the wifi working to install one. I'm running off a USB to be clear.

>>1280017
I think I can mount another device, so then once I do that I just run the ddrescue command?
For reference, will it still work if the drive keeps getting disconnected and if so, how do I check its progress?

Anonymous

View Same Google ImgOps iqdb SauceNAO 15D35E1B-566D-4A5F-83EC-C7247D83 (...).png, 5KiB, 647x259

Anonymous Mon 07 Nov 2022 19:43:26 No.1280033 Report

Quoted By: >>1280044

>>1280028
>do that I just run the ddrescue command?
Basically yes. Bear in mind that ddrescue does exactly what you tell it to, so you'll want to double-check you have everything right before pressing enter. You're wanting something like
>ddrescue </dev/block_device_of_usb> </mnt/mounted_other_device/My_Image_Files/brokenusb.img>
>will it still work if the drive keeps getting disconnected
It's supposed to, but if the device keeps getting a new name in /dev/ it won't be able to find it. You might have to tell it to "reopen on error", there's a guide to its options here: https://manpages.ubuntu.com/manpages/xenial/en/man1/ddrescue.1.html
>how do I check its progress?
It has a reasonably-detailed progress display, pic related

Anonymous

Anonymous Mon 07 Nov 2022 20:10:46 No.1280044 Report

Quoted By: >>1280050 >>1280053

>>1280033
So
sda1 is the usb that linux is running on
sdb1 is the spare usb that I'll be copying to
sdc1 is the broken usb that constantly disconnects

ddrescue </dev/block_device_of_usb> </mnt/mounted_other_device/My_Image_Files/brokenusb.img>

></dev/block_device_of_usb>
Is this the broken usb I use?

></mnt/mounted_other_device/My_Image_Files/brokenusb.img>
I also unfortunately don't really understand the mount commands here. I haven't mounted sdb1 yet but I can. I'd have to make a directory like this right?
mkdir /mnt/MyUSB

Sorry for the questions and thanks for the help. I'd mess around but don't want to screw up anything with ddrescue. I'm going to check the link too
When I ran it earlier that display didn't show at all but I probably ran it wrong

Anonymous

Anonymous Mon 07 Nov 2022 20:13:03 No.1280045 Report

Quoted By: >>1280047

>>1280028

mounting is something a bit different, it just has to be accessible.
ddrescue is powerful for recovery but still needs the device to be readable.
WHat it does is basically try over and over, first trying to go over the device and whenever a read error occurs it momrizes that and for that moment skips that block, then continues its journey over the device, then comes back to the failed sectors and tries again from both sides over and over and finer and finer to get whatever it can all around the error points.
But the device still has to respond to read requests in the first place. If it completely gets lost and disappears from the system then ddrescue cannot help either.
However, it saves where it was last time so you can seamlessly continue as long as it can find the device again.

Anonymous

Anonymous Mon 07 Nov 2022 20:16:47 No.1280047 Report

Quoted By:

>>1280045
>However, it saves where it was last time so you can seamlessly continue as long as it can find the device again.
Yeah the device does constantly show up as I replug it in, however it is momentarily and I have no idea if Linux is able to read any data on it or if it's just showing for the sake of it.
I just need to figure out what the right command is now but I'm not sure. I think I'll need to use the -o and -a options, but I don't want to get anything wrong before I run it

Anonymous

Anonymous Mon 07 Nov 2022 20:20:33 No.1280050 Report

Quoted By: >>1280051 >>1280053 >>1280056

>>1280044
>Is this the broken usb I use?

It's the important distinction between if (input) and of (output).
The first parameter is FROM WHERE you want to READ, your damaged device you want it to run over this one is unchanged, it is purely passively written. The second one is WHERE to WRITE the data, this writes, whatever was at the space before is overwritten. However, if you tell it to save an img file it's a file, it will be written to free space.
But this is why it's so important to not confuse these, you do not want to READ your system Disk and WRITE to your USB - but since that one is not mounted that would not happen anyway.

Anonymous

Anonymous Mon 07 Nov 2022 20:21:35 No.1280051 Report

Quoted By:

>>1280050

*it is purely passively READ

of course, that's the whole point

Anonymous

Anonymous Mon 07 Nov 2022 20:25:54 No.1280053 Report

Quoted By: >>1280057 >>1280059 >>1280060

>>1280050
>The second one is WHERE to WRITE the data, this writes, whatever was at the space before is overwritten
Wait, so will this delete all the files I have on that USB? It has enough storage space to copy all the data from the other USB.
>if you tell it to save an img file it's a file, it will be written to free space.
Oh right, so I would have to specify an .img file, how do I do that?

This is what I'm gathering so far

ddrescue -a -o /dev/sdc1
That's reading from the broken device.
I don't understand the mount bit written here >>1280044 so I don't know how to complete the command really. I also don't get the use of < >

Anonymous

Anonymous Mon 07 Nov 2022 20:34:25 No.1280056 Report

Quoted By:

>>1280050
>but since that one is not mounted
Small but important point, the target is a *file*, and you shouldn't get the "are you sure you want to do this" warning because that *file* shouldn't exist.

Anonymous

Anonymous Mon 07 Nov 2022 20:35:53 No.1280057 Report

Quoted By: >>1280064

>>1280053
>Wait, so will this delete all the files I have on that USB?
No, no, no!
Do not write to the device, write to a file.
Mount the USB, then write to a file on it, then umount the USB (or run "sync") before rebooting the computer.

Anonymous

Anonymous Mon 07 Nov 2022 20:37:55 No.1280059 Report

Quoted By: >>1280064

>>1280053
>I also don't get the use of < >
That's a Unix manpage convention for "this is just an example (and the parameter is not optional)". There's also [ ] for parameters you can omit if you want.

Anonymous

Anonymous Mon 07 Nov 2022 20:38:22 No.1280060 Report

Quoted By: >>1280064

>>1280053

< > is a placeholder to tell you what goes there in a not literal sense. Imagine it like in a command given as <Your username> <Your password>, that would not mean that you put in "Your username" but at that place your actual username.
Same here, whereh wrote </dev/block_device_of_usb> put in your ACTUAL deviceunder which your faulty USB stick is recognised.

>>1280053
>Oh right, so I would have to specify an .img file, how do I do that

By choosing a path , a name and the extension .img. From that ddrescue recognises that you want to write to a file. For example

> /home/my_username/my_USB_rescue_file.img

This would attempt to write the file "my_USB_rescue_file.img" into your Linux home directory.

Anonymous

Anonymous Mon 07 Nov 2022 20:46:02 No.1280064 Report

Quoted By: >>1280066

>>1280057
Right, thank you. I'll mount the USB.
>>1280059
Thanks
>>1280060
>/home/my_username/
The thing is I genuinely don't know any of my Linux directories. I don't think I even have a home/my_username.
The only directory I do know is /mnt/
I don't even know how to list my files from the usb in terminal

Say I do this

sudo mkdir /mnt/recUSB

sudo mount /dev/sdb1 /mnt/recUSB

ddrescue -a -o /dev/sdc1 /mnt/recUSB_rescue_file.img

Is that going to work or have I gone wrong?

Thanks again to everyone

Anonymous

Anonymous Mon 07 Nov 2022 20:54:28 No.1280066 Report

Quoted By: >>1280068 >>1280071

>>1280064
>Is that going to work

The concept is correct but your path got wrong.
This will let ddrescue attempt to work on sdc1 and write the result directly to /mnt/ under the name recUSB_rescue_file.img.
I think what you meant was

ddrescue -a -o /dev/sdc1 /mnt/recUSB/USB_rescue_file.img

Anonymous

Anonymous Mon 07 Nov 2022 20:58:24 No.1280068 Report

Quoted By: >>1280071 >>1280072 >>1280083

>>1280066
>ddrescue -a -o /dev/sdc1 /mnt/recUSB/USB_rescue_file.img
Ah yesm thanks
So is this a command that will work? If it's writing to mnt/recUSB, what USB device will it be writing to? sdb1, right? The one I mount here
>sudo mount /dev/sdb1 /mnt/recUSB
?
What directory would the rescue image file write to?
I guess I'm having a bit of trouble understanding mounts and then directories for a USB

Does the command look right to you if I want to copy sdc1 onto sdb1 without deleting any data on sdb1? And also allow ddrescue to constantly try and recover the data even after disconnections?

Anonymous

Anonymous Mon 07 Nov 2022 21:02:20 No.1280071 Report

Quoted By: >>1280075

>>1280066
>sdc1
>>1280068
>sdc1
You want /dev/sdc, that's the whole device.

The fact that there is a sdc1 is very good news, it implies linux can read the partition table.

Anonymous

Anonymous Mon 07 Nov 2022 21:04:27 No.1280072 Report

Quoted By: >>1280075

>>1280068
>I guess I'm having a bit of trouble understanding mounts and then directories for a USB
You have to
mkdir /mnt/recUSB
before you mount. Remember to umount (not "unmount", "umount") it before you reboot.
>What directory would the rescue image file write to?
When you put the USB stick in, anything written to /mnt/recUSB will be in the root directory of the USB.

Anonymous

Anonymous Mon 07 Nov 2022 21:10:55 No.1280075 Report

Quoted By: >>1280077

>>1280071
>The fact that there is a sdc1 is very good news, it implies linux can read the partition table.
Thanks for clarifying that! Linux does read it but like I said it also disconnects every minute or so. Strange.
>>1280072
>When you put the USB stick in, anything written to /mnt/recUSB will be in the root directory of the USB.
So then how do I get it to go in a specific folder?

Anonymous

Anonymous Mon 07 Nov 2022 21:14:59 No.1280077 Report

Quoted By: >>1280081

>>1280075
>So then how do I get it to go in a specific folder?
/mnt/recUSB/specificFolder/file.img

Anonymous

Anonymous Mon 07 Nov 2022 21:20:49 No.1280081 Report

Quoted By:

>>1280077
Would I have to mkdir that specific folder and if so at what point? Before mounting or after mounting?

Would it be like this?

sudo mkdir /mnt/recUSB

sudo mount /dev/sdb1 /mnt/recUSB

sudo mkdir /mnt/recUSB/recovery

ddrescue -a -o /dev/sdc1 /mnt/recUSB/recovery/rescue_file.img

Does that look right?
Thanks again btw, I'm almost there

Anonymous

Anonymous Mon 07 Nov 2022 21:22:58 No.1280083 Report

Quoted By: >>1280088

>>1280068

>what USB device will it be writing to
sdb1 since you mounted that one at that point

The img file will then be directly in that first main directory that you see when opening the plugged in stick.

>Does the command look right to you if I want to copy sdc1 onto sdb1 without deleting any data on sdb1

It is now a file, not different from selecting one and pulling it into the stick's window, only free space will be used.

>>1280068
>And also allow ddrescue to constantly try and recover the data even after disconnections

That is called a mapfile. At the end of the command you have to give another path for your mapfile. It is just a text file, so you can use an extension or not and which ever you want (.log, .map,...), often simply "mapfile" is used.

Anonymous

Anonymous Mon 07 Nov 2022 21:27:41 No.1280088 Report

Quoted By: >>1280093 >>1280095

>>1280083
Thank you for the help
Ideally i would want the img file to be in a folder on that stick

>>1280083
>That is called a mapfile. At the end of the command you have to give another path for your mapfile

ddrescue -a -o /dev/sdc1 /mnt/recUSB/recovery/rescue_file.img /dev/sdc1 /mnt/recUSB/recovery/logs.log

Like so? How would I then call that log file back so the next time I run it it would continue from there?

Anonymous

Anonymous Mon 07 Nov 2022 21:36:30 No.1280093 Report

Quoted By: >>1280095 >>1280098

>>1280088
>ddrescue -a -o /dev/sdc1 /mnt/recUSB/recovery/rescue_file.img /dev/sdc1 /mnt/recUSB/recovery/logs.log

The second giving of your read from device is unneeded

ddrescue -a -o /dev/sdc1 /mnt/recUSB/recovery/rescue_file.img /mnt/recUSB/recovery/logs.log

This will now simply create the folder logs and the file.
To use it you simply use the command again.
When there is no logs.log it will create it and start from scratch, if it is there it will see it and use it to continue.

Anonymous

Anonymous Mon 07 Nov 2022 21:38:48 No.1280095 Report

Quoted By: >>1280098

>>1280093
>sdc1
>>1280088
>sdc1
Again with the sdc1!
- sdc1 is the first partition
- sdc is the device
if you image sdc1, you'll leave off the first ~100k of the disk, and be left with an image that's a real pain in the ass to restore onto anything.

Anonymous

Anonymous Mon 07 Nov 2022 21:41:04 No.1280098 Report

Quoted By: >>1280106 >>1280163

>>1280095
Ah my bad! Sorry I was copying and pasting, I do know not to use sdc1

>>1280093
OK so these are the steps I am about to take, this all look good?

sudo mkdir /mnt/recUSB

sudo mount /dev/sdb1 /mnt/recUSB

sudo mkdir /mnt/recUSB/recovery

ddrescue -a -o /dev/sdc /mnt/recUSB/recovery/rescue_file.img /mnt/recUSB/recovery/logs.log

Anonymous

Anonymous Mon 07 Nov 2022 21:49:55 No.1280106 Report

Quoted By: >>1280110

>>1280098

Looks good.

If sdc craps itself you will get an error message and ddrescue will end, then as soon it is recognised again you can just run the command again and it will resume where it left off.

Anonymous

View Same Google ImgOps iqdb SauceNAO 1515391440688.jpg, 8KiB, 218x231

Anonymous Mon 07 Nov 2022 21:56:04 No.1280110 Report

Quoted By: >>1280113 >>1280115

>>1280106
So I ran it, finally. But nothing happens. After I press enter, it just sits there. No new lines turn up in terminal, it hangs until sdc disconnects and then it just says can't open input file.

It can't all have been for nothing, can it? I didn't just spend all that time on this only for that to happen, r..right?

Anonymous

View Same Google ImgOps iqdb SauceNAO 1538348904731.png, 16KiB, 882x758

Anonymous Mon 07 Nov 2022 22:02:33 No.1280112 Report

Quoted By:

I'm going to cry.

Anonymous

View Same Google ImgOps iqdb SauceNAO 1667259415459057.jpg, 96KiB, 600x776

Anonymous Mon 07 Nov 2022 22:05:33 No.1280113 Report

Quoted By: >>1280117

>>1280110
>If sdc craps itself you will get an error message and ddrescue will end, then as soon it is recognised again you can just run the command again and it will resume where it left off.
Since the other anon seems off
If nothing appears in the terminal it means that its working if error as anon said

Anonymous

Anonymous Mon 07 Nov 2022 22:07:53 No.1280115 Report

Quoted By: >>1280117

>>1280110

Sounds like the initialization phase, where it tries to connect the input device and say to it "hello, I would like to read from you, are you there?"
It seems like your stick has been knocked in a way that accessing it makes it sperg out.
You now know the commands, you just have to try over and over, maybe it will have a good day once in while.

You have a temperamental device that has reading problems, faulty hardware will always be a hassle to work with since things like ddrescue are software and are still reliant on cooperation of the device.
You can just hope and try again from time to time.

Does sdc also directly disappear when just trying to access it with TestDisk?

Anonymous

Anonymous Mon 07 Nov 2022 22:10:00 No.1280116 Report

Quoted By: >>1280117

Also does your img file and mapfile exist? And if are they still 0 byte or do they contain sth?

Anonymous

View Same Google ImgOps iqdb SauceNAO 1631024976154.jpg, 229KiB, 1314x1333

Anonymous Mon 07 Nov 2022 22:14:50 No.1280117 Report

Quoted By: >>1280127 >>1280137 >>1280166

>>1280113
I think some progress or attempt so show it's working should be turning up really

>>1280115
It seems like your stick has been knocked in a way that accessing it makes it sperg out.
What could cause this? I never damaged the stick or anything, it's a compact ultrafit usb but I don't get how it has fried itself to this level.

>Does sdc also directly disappear when just trying to access it with TestDisk?
Sorry, I'm not sure what TestDisk is, it does disappear from lsblk though

>>1280116
I don't know how to even check my files in gparted Linux
HOWEVER
One ONE occasion running this command, it actually booted gparted properly and it's reported as 1% rescued!
Every other attempt since has failed, but shit I got 1% I guess. I hope I can get a little more but now it doesn't seem to want to play nicely at all.

Anonymous

Anonymous Mon 07 Nov 2022 22:26:16 No.1280127 Report

Quoted By: >>1280133

>>1280117
>it actually booted [ddrescue] properly and it's reported as 1% rescued!
That map file it's creating, it tells it what's rescued so it doesn't waste its time rereading stuff it's already got. So you might be able to keep chipping away at it.

Anonymous

Anonymous Mon 07 Nov 2022 22:31:26 No.1280133 Report

Quoted By: >>1280143

>>1280127
Well it said the remaining time was 2362d 4h
I'm not sure I have quite that level of time unfortunately
I will keep trying but it's not playing ball at all now. No progress. Dunno if there's anything I could maybe do to get it to work for a little bit just to copy a bit more data. I even tried cleaning inside the thing with a brush and isopropyl before
Regardless a big thanks to everyone here. Really helpful stuff. I'm still upset really that it's not worked but at least it wasn't a total dud

Quick q, How do I go about actually getting the files from what ddrescue manages to recove?

Anonymous

Anonymous Mon 07 Nov 2022 22:33:40 No.1280137 Report

Quoted By: >>1280142

>>1280117
>What could cause this?

From the symptoms my guess would be that the actual storage is fine but the controller has gotten defective. Hair fractures because temperature changes over the time? plastic deformation in one of the microscopic structures?
A dust particle that got into the factory, set on the wafer and over time lead to a microscopic wire corroding?

USB sticks are not made for eternity and sometimes corrupt themselves after some time.

ONe would nearly want to say that removing the storage chipo and soldering it into an identical model would be worth a shot, but the cotroller probably also contains the wear leveling table - in other words only it know where each logical sector is physically, so I am not sure that would work...

Anonymous

Anonymous Mon 07 Nov 2022 22:37:02 No.1280142 Report

Quoted By: >>1280150

>>1280137
I don't have the soldering skills for that but funnily enough I do have an identical model. Won't try it though

>hair fractures temperature changes over time
Can you expand on this? Because it's an ultrafit the usb does get very hot, hot to the touch levels of hot.
I should also mention the USB stayed plugged in most of the time
What sucks is I bought another one to replace this but now I'm worried it'll run into the same issue. Backups will have to be kept I guess

Anonymous

Anonymous Mon 07 Nov 2022 22:40:54 No.1280143 Report

Quoted By: >>1280145

>>1280133
>How do I go about actually getting the files from what ddrescue manages to recove?
Getdataback can open these images, or you can use ddrescue to put the image onto a working USB stick. You can also convert it to a VHD that windows can mount: https://www.starwindsoftware.com/v2v-help/ConvertingtoVHDVHDX.html

Given how fucked it is, getdataback is probably the way to go. It does want you to pay for it, but there's a free trial, and you can pirate it if you don't want to pay.

Anonymous

Anonymous Mon 07 Nov 2022 22:45:41 No.1280145 Report

Quoted By: >>1280171

>>1280143
thanks
>ddrescue to put the image onto a working USB stick
Sorry what do you mean by this, the file or the restoration of the image? I could probably restore it to the drive I put the live linux on I guess.
Is getdataback the only way to deal with .img files?

Anonymous

Anonymous Mon 07 Nov 2022 22:52:47 No.1280150 Report

Quoted By: >>1280163

>>1280142

CHanges in temperature lead to different material expanding add contracting in different levels. A chip is made out of many many tightly packed materials, that can lead to physical stress which in the end can lead to brittleness and fractures.
And extreme macracsopic example would be a thick metal wire or really any piece of metal a human is strong enough to bend.
Even the strongest piece of metal easily be broken by bending it it back and forth a few times. Take a sturdy metal wirde and bend it back and forth a few times, it loses its ductility, then gets brittle and in the end breaks.
IN the chip physical stress is induced whenever large jumps in temperature occur. Over and over that can lead to these kinds of fractures.
For this kind the temperature itslef is not that relevant, the change is the important fact.
But high temparatre also allow unwanted chemical reactions (diffusions, galvanic reactions, corrosions etc) between elements to happen faster, this is why too high temperatures may reduce the lifespan.

Your stick is now in weird half dead state. Things like humidity, temparature etc may affect how it's working.
A few degrees more or less may change its behaviour for example.

Anonymous

Anonymous Mon 07 Nov 2022 23:18:58 No.1280163 Report

Quoted By: >>1280171 >>1280176

>>1280098
Oh, in case anyone reads this and has a go, or even if I just check the thread in future, the -a and -o need to be in caps. I needed a sudo in front of it too

so
sudo ddrescue -A -O /dev/sdc /mnt/recUSB/recovery/rescue_file.img /mnt/recUSB/recovery/logs.log

>>1280150
Right I see, well I guess I should have learnt all this before buying these sticks! Suck to learn but I'll buy a backup HDD or something I suppose. I'm not prepared to lose another drive.
Been trying the command this whole time btw, no further success. The 1% reported it did recover was around 2GB, so not the worst. It'd be really nice if it managed to recover all the directories, that would be ideal so I would know exactly what was on there.
It's kind of annoying since because this is a live linux boot, nothing actually saves. Anything I do in /mnt/ gets wiped once I reboot. I don't know if I should leave it for another day now or keep trying. And if I'm going to keep trying, how long do I really give it?
bah

Anonymous

View Same Google ImgOps iqdb SauceNAO 1660224108707020.gif, 3MiB, 200x234

Anonymous Mon 07 Nov 2022 23:28:35 No.1280166 Report

Quoted By: >>1280187 >>1280188

>>1280117
>I think some progress or attempt so show it's working should be turning up really
Maybe it does with an extra .. Appendex? I mean those little letters you put after the original command, but i am that anon >>1280021, it is possible to show progress with a certain letter, but in this Situation that doesnt matter (so it probably wasnt suggested)
Sure for someone who isnt used to a terminal, it is quite scary not seeing anything, but there is the difference of Linux and windows, you didnt tell the Computer to show progress so it doesnt
Let me phrase it differently:
If we all grew up using linux, we would know those those basics just as we do with windows

Anonymous

Anonymous Mon 07 Nov 2022 23:31:53 No.1280171 Report

Quoted By: >>1280188

>>1280145
>Is getdataback the only way to deal with .img files?
No, a .img made by dd is literally just the raw data from a disk in the same order it's on the disk, so lots of stuff can deal with it. Getdataback is just an example, although it's main purpose is data recovery from damaged FAT and NTFS filesystems, so it's probably what you need. If you do get a good near-100% read though, you can just dd the file onto a disk (which will erase the disk and (temporarily) change its capacity), or you can export a copy of the file in a format Windows likes (VHD or VHDX), and double-click the file and it will appear as a drive letter.
>>1280163
>Anything I do in /mnt/ gets wiped once I reboot
No, if you've mounted it properly, /mnt/recUSB is your other USB stick. If it's not, you need to fix that before you reboot, and copy the files over with cp.
If you didn't mount the USB stick at all, make a new directory and mount it there, don't mount it on top of a directory with files in or it will make them invisible until you unmount.
>I don't get mounting
It's like drive letters, except you only get one drive, and the rest are attached over the top of some folder in that drive. This is kinda dumb, so I don't blame you for not getting it.

Anonymous

Anonymous Mon 07 Nov 2022 23:34:53 No.1280176 Report

Quoted By: >>1280188

>>1280163

things like trying different temperatures may be worth a shot.
Be careful with cooling it though, you do NOT want water to condensate inside and then power it on!
But different levels of heat may lead to different reconnections in the controller.

YOur recovered file and the mapfile are on your other stick, so it's not the worst to boot into into it again once in a while. You can always continue with it from where you left off.
All you gotta do every time is to if it's not preinstalled get ddrescue back and use your three commands.
I personally would for a full test phase give it something like 2 weeks maybe? Trying different temperatures and pauses between attempts. Electroics are fickle little things. Sometimes after waiting 2 days they suddenly want to cooperate better than before, god knows why.
But I would I think vever really stop after some kind of deadline, still from time to time try it when there is some time, you never know.

Anonymous

Anonymous Mon 07 Nov 2022 23:42:22 No.1280187 Report

Quoted By: >>1280188 >>1280208

>>1280166

Seeing NOTHING on the terminal after starting ddrescue is not normal though, it should at least show its preamble like

>GNU ddrescue 1.xx
>Press Ctrl-C to interrupt
>Initial status (read from mapfile)
>rescued: X MB, tried: y B, bad-sector: z B, bad areas: 0

Anonymous

Anonymous Mon 07 Nov 2022 23:45:06 No.1280188 Report

Quoted By: >>1280204 >>1280209 >>1280218

>>1280187
>>1280166
Yeah this is what I figured. I did get the preamble to show once more, but man that's once in a very long time now and it didn't actually make progress

>>1280171
>Getdataback is just an example
Do you think there are free alternatives? I don't mind pirating, just wouldn't be sure where to get a legit copy
>you can export a copy of the file in a format Windows likes (VHD or VHDX), and double-click the file and it will appear as a drive letter.
That sounds more useful so I don't have to mess up another USB stick.
Is that easy to do? I think I'm gonna need a guide on the .img file as well because it seems a little more complex to recover data from than I assumed

>>1280171
>If you didn't mount the USB stick at all,
Oh no it's mounted, it's just because it's a live usb nothing saves on this install once you reboot. So I make /mnt/recUSB right? But once I reboot that folder is gone, I have to remake it then mount again.

>>1280176
Tbh the only thing I can try in terms of temperature is to have it cooler and it's not exactly easy to achieve that. It warms up very quickly in the laptop.

>But I would I think vever really stop after some kind of deadline, still from time to time try it when there is some time, you never know.
Well, Sandisk told me they'd replace this one for free, but I'd have to send mine in to them.
I mentioned my data, they said I could destroy the USB before sending it in.

So I guess another question is how do I destroy a USB so that my data isn't recoverable? I think I'm allowed to smash it.

Oh, also, will trying the usb boot of linux on different laptops possibly offer better results or is it not going to make a difference?

Anonymous

Anonymous Mon 07 Nov 2022 23:51:27 No.1280196 Report

Quoted By:

Got ddrescue to show again but the status on everything was unchanged from last time
Is it possible it's hit a wall and won't go past the 2GB it managed to grab? Can it work like that?

Anonymous

View Same Google ImgOps iqdb SauceNAO 1624694111992.png, 222KiB, 640x640

Anonymous Mon 07 Nov 2022 23:57:37 No.1280204 Report

Quoted By: >>1280205

>>1280188
>So I guess another question is how do I destroy a USB so that my data isn't recoverable?
Magnet, super strong, really super strong, thumb crushing strong should be enough

Anonymous

Anonymous Mon 07 Nov 2022 23:58:45 No.1280205 Report

Quoted By: >>1280212

>>1280204
I have Fridge Magnets, nothing stronger than that ;_;

Anonymous

View Same Google ImgOps iqdb SauceNAO 1667081478354292.jpg, 10KiB, 272x185

Anonymous Tue 08 Nov 2022 00:00:59 No.1280208 Report

Quoted By:

>>1280187
Yeah as said, I'm trying to avoid any dd command, but i also said i aint good enough to help

Anonymous

Anonymous Tue 08 Nov 2022 00:01:44 No.1280209 Report

Quoted By: >>1280213

>>1280188

>Oh no it's mounted, it's just because it's a live usb nothing saves on this install once you reboot. So I make /mnt/recUSB right? But once I reboot that folder is gone, I have to remake it then mount again.

Well is /dev/sdb the stick where there is also the live system on?
Also most live system still allow real writing to their own stick as long as there is still room.
If you open sdb1 in the file explorer and see the img file and recovery folder with the log file in it then it really IS saved on there.

Live system only means that system operations are only done in RAM, like the browser cache and such. But if you explicitely tell it "Write this file on your own stick" it should do that.

>So I guess another question is how do I destroy a USB so that my data isn't recoverable?

OPening it up, taking the storage chip, pair of pliers, CRACK!

Anonymous

View Same Google ImgOps iqdb SauceNAO 1483221289354.png, 454KiB, 482x486

Anonymous Tue 08 Nov 2022 00:03:15 No.1280211 Report

Quoted By: >>1280214 >>1280217

Bros it's jumped to 4.25%, 10GB
Is it actually grabbing my data? It works remarkably fast in the short times it's up. 103MB/s

Am I right to build hope?

Anonymous

Anonymous Tue 08 Nov 2022 00:06:08 No.1280212 Report

Quoted By: >>1280213

>>1280205
I do neither have a meme nor find one quick to express my "THATS NOT ENOOOUUUGH"

Anonymous

Anonymous Tue 08 Nov 2022 00:08:21 No.1280213 Report

Quoted By: >>1280215 >>1280219 >>1280220

>>1280209
sda is the stick with the live system
there is room on the USB but nothing saves after a reboot, I definintely had to make the directory again
>OPening it up, taking the storage chip, pair of pliers, CRACK!
Thanks. This is a doable option
Does make you wonder why they'd want it back if they're happy for me to destroy it
>>1280212
What if I get a couple of fridge magnets together? Would that raise the power level enough to be a super magnet?

Anonymous

Anonymous Tue 08 Nov 2022 00:11:23 No.1280214 Report

Quoted By: >>1280223

>>1280211

just look at the img file. If it grows then it has rescued stuff.
The 10 GB could also just mean scanned data including skipped one.

But yeah, that is the weird character of electronics, it's really as if they have moods and sometimes suddenly get off their asses.

Anonymous

Anonymous Tue 08 Nov 2022 00:14:12 No.1280215 Report

Quoted By: >>1280223

>>1280213
>I definintely had to make the directory again
The live system can't save "you wanted /dev/sdb1 mounted on /mnt/usbREC", and the directory "/mnt/usbREC" doesn't get saved for the same reason, but once you've made the directory and mounted everything, what's in the directory should be the USB stick. i.e. if you
touch /mnt/usbREC/hello.txt
and then reboot into windows, there should be a file e:\hello.txt

Anonymous

Anonymous Tue 08 Nov 2022 00:16:56 No.1280217 Report

Quoted By: >>1280223

>>1280211
This is looking encouraging.
>it's fast
The undamaged bits tend to be fast, the damaged bits are slow. ddrescue does a bunch of different passes, waiting and retrying more the more passes have elapsed. The idea behind the first pass is to get as much easy data as quickly as possible, in case the act of reading the device is damaging to it*.

* for example a hard disk with bits of platter dust rattling around in it

Anonymous

Anonymous Tue 08 Nov 2022 00:18:22 No.1280218 Report

Quoted By: >>1280223

>>1280188
>will trying the usb boot of linux on different laptops possibly offer better results
Maybe, it did when you were trying it in Windows, after all.

Anonymous

View Same Google ImgOps iqdb SauceNAO 1659353933564097.jpg, 194KiB, 749x890

Anonymous Tue 08 Nov 2022 00:19:39 No.1280219 Report

Quoted By: >>1280223

>>1280213
>Would that raise the power level enough to be a super magnet?
Probably not, but i aint no physician either

Anonymous

Anonymous Tue 08 Nov 2022 00:20:02 No.1280220 Report

Quoted By: >>1280223

>>1280213
>sda is the stick with the live system

Well then whatever sdb1 is contains the file and mapfile and will continue so even after a reboot.
After all with
>sudo mount /dev/sdb1 /mnt/recUSB
That partition is what you defined as your mount point.
It's not the live system stick and not the faulty one. So my guess is the laptop HDD. If it has Windows on it that was no obstacle, Linux has no problems with NTFS partitions.

Anonymous

Anonymous Tue 08 Nov 2022 00:24:21 No.1280223 Report

Quoted By: >>1280229 >>1280232 >>1280235

>>1280214
>just look at the img file.
I wish I could but I have no idea how to check in Linux
I'd have to unmount it and check in Windows but I don't want to ruin this little streak it has.
Last I checked the .img file was indeed 2GB though.
How do I know it's not just grabbing garbage data or indecipherable crap? How can this stick not show any signs of life yet somehow get its data pulled even partially? On Windows it would cause my PC to hang when plugged in. I never got it to actually display and I plugged it in and out so many times I'd have assumed the data got corrupted at this point.

I'm gonna need to look into how to restore .img files properly because even just a small percentage is very welcome if it works

>>1280217
I see. Thank you. I kind of hoped it would remain that quick because if it slows massively then I'm not sure how feasible it becomes to keep plugging the stick in and out to get the data. Would take far too long of just sitting glued doing the same thing over and over.

>>1280220
Yeah I think it should work like that, hopefully it al aligns well and does so.
sdb1 is a spare USB sick, I've not messed with the laptop ssd at all so my Windows should be fine.

>>1280219
Maybe if I just believe hard enough..

>>1280218
Ah well then that's something else to tinker with I guess. With Windows I was running off different installs whereas with the USB it's all just from the same OS, right?

>>1280215
Yeah I did check earlier and the files were on the USB stick. I just hope I've mounted it right this time with all the progress it's made and I do get this file. Any way I can check the file size within linux before I unmount the drive?
I genuinely have no clue where to look

Also another big thanks to you all bros. This is more than I expected to get (if it works) and you lads have genuinely been really helpful. I wish you a good week ahead.

Anonymous

Anonymous Tue 08 Nov 2022 00:38:49 No.1280229 Report

Quoted By: >>1280236

>>1280223
>I have no idea how to check in Linux

You can just open it in the file manager and look at the file size. I didn't mean inspect the file, like what is IN there, just the size.

>>1280223
>sdb1 is a spare USB sick

So why should the files be gone after rebooting?
It's just a storag device to the system like any other. it being a live system does not affect that in the slightest. All write operations on this INDEPENDENT device are REAL. The files are written on there and STAY there, completely independently from the current running linux system. You could later pull it out, plug it into another PC, open Windows and they will still be there.
All "live-system" means is that it loads the kernel and programs into RAM instead of a disk and uses the RAM as its root point "/".
Its original stick then to it becomes just an oridinary data device. If you tell a live system "Write this file THERE" it writes the file THERE.
The only thing lost after reboot is data written to the running system itself since that is actually just in RAM.

Anonymous

Anonymous Tue 08 Nov 2022 00:45:58 No.1280232 Report

Quoted By: >>1280236

>>1280223
>Any way I can check the file size within linux before I unmount the drive?
yf -yu
gives you the length of the file, and
qh -u
gives you how much space it's actually taking up. Run these commands through rot13.com, 4chan won't let me post them. In addition, "rescued" in ddrescue's output is usually correct, and IIRC "errsize" is how much it's skipped this session.

Anonymous

Anonymous Tue 08 Nov 2022 00:50:53 No.1280235 Report

Quoted By: >>1280236

>>1280223
you can also go
hd <filename> | less
and it should let you have a look at what is and isn't there. less is a reimplementation of a pager named "more", with an amusing name. "q" quits less.

Anonymous

Anonymous Tue 08 Nov 2022 00:52:28 No.1280236 Report

Quoted By: >>1280245 >>1280250 >>1280257

>>1280232
hmm, I don't see errsize, but I do see
>non-trimmed
>non-scraped
>bad sector
>bad areas
>read errors
All at 0. However i has to be noted that there's a lot left to go as of yet.
Thank you for the commands, seems pretty weird you were blocked from posting them.

>>1280229
>You can just open it in the file manager
I'm using gparted because it has ddrescue built in, I don't think it has a file manager which is a problem for a windowsbabby like me

>The only thing lost after reboot is data written to the running system itself since that is actually just in RAM.
Right, this is what I mean, sorry for not being clear. sda1 is the USB the live system is on, any directories or files I make here do seem to get wiped. That's what happened when I made mnt/

Also damn I really need to get to sleep but I can't stop with the progress this has been making in case it decides it doesn't want to work later. I'm going to be absolutely shattered tomorrow. Do I leave it and go to sleep or keep going? I don' even know how to set Linux to not put my laptop into sleep mode. Am I gonna make it brahs?

>>1280235
Thanks.

Anonymous

View Same Google ImgOps iqdb SauceNAO wasure smiling 4.png, 56KiB, 429x341

Anonymous Tue 08 Nov 2022 00:56:38 No.1280238 Report

Quoted By:

If anyone has any suggestions on extracting the data from an .img file I'm all ears

getdataback was suggested by a helpful anon earlier but I'd have to look around on where to pirate that safely so any alternatives are welcome

Anonymous

Anonymous Tue 08 Nov 2022 01:06:52 No.1280245 Report

Quoted By: >>1280261

>>1280236
>That's what happened when I made mnt/

Because these are system operations.
Everything written to the system (meaning "/" and under that is NOT an external device) is lost after rebooting. This includes the file that saves your file system properties like mount points (fstab). Same goes for system folders like etc, usr and so on. For example everything you save into your home folder will be gone afterwards since that is part of the system and is actually in RAM, but if you mount your windows SSD and write to it that will stay since that is an external device.

>Do I leave it and go to sleep or keep going?

If the laptop has power and won't turn off the worst thing that may happen is that ddrescue will quit because of the USB disappearing again. In that case you can continue after waking up again, mapfile be blessed.
Of course there is always the possibilty that these are the final hours of life for the USB so if it craps itself again and then the window is missed that was it, but if that hypothetical danger is worth it...

>I don' even know how to set Linux to not put my laptop into sleep mode

I'm not sure if a program running is regarded as being inactive, but you can select that is never go to sleep or shutdown in the power manager under Settings which you can find when opening the equivalent to the WIndows Start menu.

Anonymous

Anonymous Tue 08 Nov 2022 01:12:36 No.1280250 Report

Quoted By: >>1280261

>>1280236
>I don' even know how to set Linux to not put my laptop into sleep mode
I think it just sleeps the monitor and the laptop stays on. It's actually harder to put it to sleep than it is to not.

Anonymous

Anonymous Tue 08 Nov 2022 01:19:09 No.1280257 Report

Quoted By: >>1280261

>>1280236
>seems pretty weird you were blocked from posting them.
4chan has cloudflare's generic "anti-hacking" filter turned on, these commands are the kind of thing you might see in a payload intended to exploit an insecure website:
- trick one vulnerable php page into running arbitrary commands
- use <censored command> to find the names of all the files in the same directory as the page
- maybe I can just download the file with the database password in, seeing as I know its name now
- database password is the same as scp password
- use scp to replace the main page with one that serves malware
That's roughly how an attack on a site that's written its own PHP tends to go, so it's understandable that Cloudflare blocks it, even if it's annoying sometimes.

Anonymous

View Same Google ImgOps iqdb SauceNAO 1421860894990.jpg, 50KiB, 461x523

Anonymous Tue 08 Nov 2022 01:25:48 No.1280261 Report

Quoted By: >>1280266 >>1280270

>>1280250
Ah I see

>>1280257
Well that makes a lot of sense then. Commands i thought were harmless perhaps aren't as much.

>>1280245
>WIndows Start menu
gparted doesn't have one. All it has is the damn terminal, it's a pain for a windows babby like me lel

>Of course there is always the possibilty that these are the final hours of life for the USB so if it craps itself again and then the window is missed that was it, but if that hypothetical danger is worth it...
Anon why would you say this
There are very worrying signs for this USB now
It's stopped being picked up in the USB port I was using. So maybe it fried my (new) laptops USB port, I dunno. This was after it stayed connected for an hour(!)
I switched USB port and it worked for a while but then the same error with that port.
This can't be the end. It can't be.

Anonymous

View Same Google ImgOps iqdb SauceNAO 1667330945862664.jpg, 29KiB, 400x400

Anonymous Tue 08 Nov 2022 01:39:28 No.1280266 Report

Quoted By: >>1280273

>>1280261
>All it has is the damn terminal, it's a pain for a windows babby like me lel
Idk what it is about anymore since I'm a lil bit drunk but you can do this i believe in you with all my heart op

Anonymous

View Same Google ImgOps iqdb SauceNAO gparted.jpg, 121KiB, 794x531

Anonymous Tue 08 Nov 2022 01:48:42 No.1280270 Report

Quoted By: >>1280273

>>1280261
>gparted doesn't have one. All it has is the damn terminal

So wait, you don't actually have a desktop environment but chose a non graphical bootable version of GParted? Well that complicates things a little.
I thought you have a real full live system, GParted is a standard tool in every linux distro so you can use it and ddrescue while having a full graphical system at your disposal.

Anonymous

Anonymous Tue 08 Nov 2022 01:54:01 No.1280273 Report

Quoted By: >>1280274 >>1280279

>>1280270
Oh no it's a GUI, it just doesn't have a windows style start menu is what I meant. I've got gparted like in your screenshot

>>1280266
Thank you anon.
But my race might be run.
It goes up by about 0.2% when I can get it to run now.

My worry is the strain on the USB port. I'm constantly unplugging and plugging in, this could cause a lot of damage to the port, right? Even cause it to stop working entirely? I'm not jamming it in there hamfisted but still. I don't have USB to USB extenders except maybe an old one but it's USB2.0 and would likely make transfer speeds much slower

Anonymous

Anonymous Tue 08 Nov 2022 01:59:59 No.1280274 Report

Quoted By: >>1280276

>>1280273
>except maybe an old one but it's USB2.0
Definitely give that one a go, it could be one of the USB3 pairs is not reliable.

Anonymous

Anonymous Tue 08 Nov 2022 02:03:16 No.1280276 Report

Quoted By:

>>1280274
I will if I manage to find it I guess
I just worry how much slower the writing speeds will be

I'm really tired. I will try to come back to this.
In all this time it managed to get around 30% but progress seems to have halted very much so now. I don't know how this will end.

Anonymous

Anonymous Tue 08 Nov 2022 02:16:24 No.1280279 Report

Quoted By: >>1280468

>>1280273

Is it the GParted Live CD? In that case it should never shut down or go to sleep since it was made for doing this kind of file systems/device tasks.

>>1280273
>It goes up by about 0.2% when I can get it to run now

At least that's someting. That means you are now at a difficult part again. Just keep trying

>this could cause a lot of damage to the port, right?

Nah, I would not worry about the port too much, after all you are not ramming it in like a monkey.
These ports are designed for thousands of pluggings and unpluggings. Most of the stability comes from the rectangular body of the plug which grabs the protruding part of the port.
If you wanna be especially gentle carefully pull back the stick without fully removing it just enough so that it loses its power connection and then slide it back.

Anonymous

Anonymous Tue 08 Nov 2022 02:20:54 No.1280280 Report

Quoted By: >>1280284 >>1280355

Quick question since I'm heading to sleep anyway
I've got this .img file, right? Is there a quick way to check it so I can see if my data is there, so I can then continue with this if it's working or not as the case may be?

Anonymous

Anonymous Tue 08 Nov 2022 02:27:27 No.1280284 Report

Quoted By: >>1280468

>>1280280

In ints incomplete state it probably cannot be properly mounted in a way that you could see files in the normal Explorer yet (working Master File Table), so copy it, mount the copy as a device and then try an undeleter like PhotoRec or Recuva on it if they can find signatures and files.

Anonymous

Anonymous Tue 08 Nov 2022 09:06:43 No.1280355 Report

Quoted By: >>1280468

Thank you to which ever anon suggested ddrescue. I forgot it even existed until this thread and have just used it to recover some family videos I shot a while ago.

>>1280280
Did you run ddrescue with the -v option? That's the verbose switch that will show you what's happening.

Did you run ddrescue with the optional mapfile/logfile as in
ddrescue -v /dev/sdb1 /mnt/gooddev/recovery.img /mnt/gooddev/recovery.log

My card disappeared about 25% into the process but reinserting it and running the same command allowed the process to continue from where it left off. 100% complete recovery in a couple of hours.

Anonymous

View Same Google ImgOps iqdb SauceNAO 1594837082490.gif, 99KiB, 456x373

Anonymous Tue 08 Nov 2022 18:00:23 No.1280468 Report

Quoted By: >>1280603

>>1280279
>Is it the GParted Live CD?
I'm running off a USB, it's actually my first time booting Linux myself

>>1280279
>Just keep trying
I will but man progress is slow
The thing is, the data on there wasn't necessarily all that vital. If I put this time into getting some of the files or creating them again, I could probably have had it done by now
But there are 2 main reasons I haven't just done that.
>It's almost a principle thing. I feel like my own stupidity has faulted me here due to a lack of backup, so I want some way to rectify that and make amends
>This way I at least learn something new
But now with progress being very slow and me having to sit in front of my laptop replugging a usb and running a command a bazillion times, maybe I cut my losses.

>If you wanna be especially gentle carefully pull back the stick without fully removing it just enough so that it loses its power connection and then slide it back.
Great tip, I'm doing that now

>>1280284
Sorry but how do I mount the copy as a device please? I'm not really good with this stuff. I'd look it up but I'm harassing my laptops USB port

>>1280355
>just used it to recover some family videos I shot a while ago.
Hey, I'm glad you managed to recover some stuff! Maybe this thread was of use then. What was wrong with your storage device that caused you to lose your files?

I am running with the logfile, not with verbose. The thing is my USB doesn't disappear every 2%, it's disappears every 0.4% if not less than that. And it only reappears at complete random from me constantly unplugging and plugging in the USB
So it's a very long process and the USB was 256GB, so there's a lot of data to sift through to boot.

Anonymous

Anonymous Tue 08 Nov 2022 20:34:34 No.1280519 Report

Quoted By: >>1280525

Bros

I hit 99.99pct rescued
It's trying a pass 2 but failing. Am I good to go with this or do I have to let pass 2 run? I'm unsure because things in the
"Current status" are changing

When I was done it showed

ipos 249189mb
opos 249189mb
non-tried 10485kb
rescued 250439mb

but then later the current status showed

ipos 67357mb
opos 67357mb
non-tried 3801kb
rescued 250439mb

I'm not entirely sure what to do now

Anonymous

Anonymous Tue 08 Nov 2022 20:53:25 No.1280525 Report

Quoted By: >>1280532 >>1280534

>>1280519
>then later the current status showed
It's skipping around all the stuff it skipped over earlier.

You have the map file, so you can always pick up later if you want. It would be fine to call it quits, just make absolutely sure the data's all saved somewhere, and sync/umount before you reboot.

Anonymous

Anonymous Tue 08 Nov 2022 21:00:55 No.1280532 Report

Quoted By:

>>1280525
Oh right, should I just continue then?
I don't mean picking it up later, I just meant if the file I had was good to start recovering from now. But I guess I need Pass 2 to run fully, right?
Should I copy the .img file somewhere before continuing with Pass 2 or won't it matter?
Thanks for the help

Anonymous

View Same Google ImgOps iqdb SauceNAO 1483221289555.png, 336KiB, 335x495

Anonymous Tue 08 Nov 2022 21:12:11 No.1280534 Report

Quoted By: >>1280539 >>1280553

>>1280525
Thank you. I ran the command again. It went through about 5 passes.

The final line was
>finished.

I..is it done? That's my .img file complete, right? ddrescue is now over? No more sitting at my laptop plugging in a USB endlessly?

Now the real work begins. To see if my files really are actually recoverable.
I'm gonna back up this .img file. I tried looking online earlier but I still have no idea how to read the data from it. Even some of the stuff I did find didn't seem all that easy to follow.

Anonymous

Anonymous Tue 08 Nov 2022 21:32:03 No.1280539 Report

Quoted By: >>1280566 >>1280568

>>1280534
>how to read the data from it
https://www.wikihow.com/Open-an-Img-File-on-PC-or-Mac
Should do the trick, i hope

Anonymous

Anonymous Tue 08 Nov 2022 22:09:19 No.1280553 Report

Quoted By: >>1280566

>>1280534
>I..is it done? That's my .img file complete, right?

Yes. According to ddresecue that is as much as can be done.
Does not necessarily mean that everything is back, but everything that COULD be rescued now IS.
Obviously to get to an end after some tries it eventually stops at the critical points and assumes that those are lost to the ether forever, otherwise it would run forever.

It said over 250 MB of data was rescued, that's a fantastic result for such a problem device.

>>1280534
>I still have no idea how to read the data from it

Your img file is a 1:1 copy of the partition/data on the stick. That one probably was FAT or exFAT, so you can now virtualize plugging the stick in by using programs like DeamonTools or others.
Depending on how damaged it was when the Master File Table is still intact you may be able to open and use it in the explorer as if it was the real thing and see the files, with only getting some errors at the parts where it could not rescue, so there are now zeros. Meaning some files will be corrupt or gone if a picture was small enough to completely fit in there for example.
Since you now have backups of your img file you can experiment with it, let chkdsk run over it and fix the file system, run PhotoRec over it and scan for file signatures etc.

Anonymous

Anonymous Tue 08 Nov 2022 22:32:14 No.1280566 Report

Quoted By: >>1280568 >>1280582 >>1280632

>>1280539
Thanks, I'll try this, looks simple.

>>1280553
>over 250 MB of data was rescued, that's a fantastic result for such a problem device.
Ah probably but shit with how long it took I hoped for a little more than that.
>DeamonTools
I'll have to look this up, I'm unfamiliar with it and its usage.
I can only run chkdsk once I mount it in Windows, as instructed here >>1280539, right?
For Photorec, I grabbed the GUI version. I pointed it at the .img file that was generated because I don't really know what I'm doing to see what would happen.
It's just generating files
>f[number]. riff/elf/ape/bmp/tx?

I have no idea what these are. Also I have 2 rescue files.
One is rescuefile_img.img (244gb)
The other is rescuefile.img (2gb)
I probably made a mistake when entering the command at one point but as I had logs to tell the ddrescue where to pick up from, is it possible that neither file is actually complete or is it fine?

Anonymous

Anonymous Tue 08 Nov 2022 22:36:02 No.1280568 Report

Quoted By: >>1280569 >>1280607

>>1280539
>>1280566
Alright, so I can't mount like that because it just says the disc image file is corrupted

Anonymous

View Same Google ImgOps iqdb SauceNAO 1663320483730528.png, 204KiB, 264x378

Anonymous Tue 08 Nov 2022 22:45:58 No.1280569 Report

Quoted By: >>1280570

>>1280568
Still cant help very much, sry i just thought to jump in till the more knowledgeable anons arrive

Anonymous

Anonymous Tue 08 Nov 2022 22:47:00 No.1280570 Report

Quoted By:

>>1280569
No worries, thank you for taking the time anon

Anonymous

Anonymous Tue 08 Nov 2022 22:53:07 No.1280572 Report

Quoted By: >>1280581

Can't mount using daemontools either.

Could it be because I created 2 .img files or is that unlikely to do with anything?

What I assume happened is that at one point I ran
ddrescue -a -o /dev/sdc /mnt/recUSB/recovery/rescuefile.img /mnt/recUSB/recovery/logs.log

But at a later point I ran

ddrescue -a -o /dev/sdc /mnt/recUSB/recovery/rescue_file.img /mnt/recUSB/recovery/logs.log

Anonymous

Anonymous Tue 08 Nov 2022 23:12:05 No.1280581 Report

Quoted By: >>1280583 >>1280599

>>1280572

NO! NONONONO!
You have two img files of slightly different name?!
You used the same mapfile for two different images? In that case you now have two incomplete images. If you have two img files then you indeed switched as some point.

For max compability and reusability ddrescue allows using arbitrary images with any mapfile, it does not scan the file if it fits the mapfile, it just uses it. You just tell it "Use this mapfile on this device and save it to THIS destination".
That means at that point you created a new empty image and SKIPPED everything that according to the mapfile was already rescued.
You now basically have two incomplete img files adding together to the full thing.
If you could bitwise join them together - but for that you would have to know which parts of which was skipped since zeros from being skipped cannot be exactly distinguished from normol zeros, other than there ebing a lot of them in a row. otherwise you have to do ALL over again (or try to salvage from both files whatever you can with an undeleter like PhotoRec, but they will never be valid file systems.

Anonymous

Anonymous Tue 08 Nov 2022 23:13:40 No.1280582 Report

Quoted By: >>1280599 >>1280632

>>1280566
>is it possible that neither file is actually complete
Yes, but there is a solution because ddrescue never writes data to the wrong position in the file.
Make backups of everything, then on the backups go
dd bs=512 if=rescuefile.img of=rescuefile_img.img conv=sparse,notrunc

This will overwrite the big one with every block in the small one that's not just zeroes. You can get dd for windows, or you can boot a linux again.

Anonymous

Anonymous Tue 08 Nov 2022 23:15:16 No.1280583 Report

Quoted By: >>1280590

>>1280581
>zeros from being skipped cannot be exactly distinguished from normol zeros, other than there ebing a lot of them in a row
Yes they can, they're zeroes in both images. Think about it for a second.

Anonymous

Anonymous Tue 08 Nov 2022 23:28:27 No.1280590 Report

Quoted By: >>1280592

>>1280583

Huh, I am confusing myself

Let's say a bitstream in File one is
10100 00001 10111 00011
and for the other one
10000 01101 01000 01101

Which bunch of zeros do now have a meaning and which are empty space?
What tells me which zeros of one i can overwrite with the part from the other?
If I overwrite a zero with an incorrect 1 that would destroy things... Ah, but the
important thing is that there ARE no incorrect ONES! Now I see it. That's the
important fact.
So every 1 in place of a 0 should be correct assuming the skipped space really
is all 0s - which it should be.

So OR ing them should result in the full file...

Anonymous

Anonymous Tue 08 Nov 2022 23:32:44 No.1280592 Report

Quoted By: >>1280595

>>1280590
>Huh, I am confusing myself
>Let's say a bitstream in File one is
>10100 00001 10111 00011
>and for the other one
>10000 01101 01000 01101
That can't happen, the block was read off the same device and stored in whichever file at the same offset as it was at on the device, so if it's in the same place it has to be identical.
Remember also that ATA is quantised to 512B sectors, so you can't read "bit 3 of byte 402 of sector whatever".

Anonymous

Anonymous Tue 08 Nov 2022 23:40:10 No.1280595 Report

Quoted By:

>>1280592

Oh, I am thinking too complicated.
Basically: What stands in one file can't be in the other because what was successfully written was then marked as done and later skipped - and vice versa. So they exactly add together.
NOW i see it.
Man, sometimes you really overthink things...

Anonymous

View Same Google ImgOps iqdb SauceNAO 1563932519714.jpg, 34KiB, 467x483

Anonymous Tue 08 Nov 2022 23:57:38 No.1280599 Report

Quoted By: >>1280606

>>1280581
>You used the same mapfile for two different images? In that case you now have two incomplete images. If you have two img files then you indeed switched as some point.
It was a mistake. A very bad one but man I was so tired last night and then when I resumed I must not have realised. I don't know how I got it wrong or how I made this sort of mistake.
Do you know how long this took and how long I spent plugging in a USB? Now I have to do it all again? I mean I got lucky the first time round because there was ONE point where he drive stayed connected for an hour. I was not having such luck later.
Shit man.

>>1280582
>You can get dd for windows, or you can boot a linux again.
Oh, thank you so much. I hope this is the solution and it works because shit man. How will I know it worked by the way? What's the failure/success state I'm looking for?
Also I'm going to keep my backups but edit the main file because that's on a USB I can easily plug in anyway with nothing else really on it.

Also, how do I know for certain that I did actually make this stupid mistake, and that rescuefile.img wasn't just a test run I did after which I started proper on rescuefile_img.img? Is there any way to check this please?

>>1280582
>dd bs=512 if=rescuefile.img of=rescuefile_img.img conv=sparse,notrunc
This should be my next step regardless, right?

Anonymous

Anonymous Tue 08 Nov 2022 23:58:45 No.1280601 Report

Quoted By:

As a final note, I ran PhotoRec on the .img file that's likely incomplete as I've now learned

It's recovered a lot of files, but none of them are in their proper directories or with filenames so it has created over 300 folders and it's a bit of a mess to go through. It's also weird, at one point I had a portable browser on that USB stick, and it seems to have recovered a bunch of files that I never saved but just browsed past on the internet. So there are loads of icons, webms, random images. I had some ROMs of some older games, which I think come as .isos but they've kind of been extracted out so now all the audio files and such are split up across different folders rather than being in a neat .iso file.
Does this suggest there is hope that at some point I will be able to get these files back with their original file structure?

Anonymous

Anonymous Wed 09 Nov 2022 00:03:43 No.1280603 Report

Quoted By: >>1280604

>>1280468
Thank you for sharing gladness. In the middle of your problem it's a noble thing to be able to celebrate someone else's joy.

>What was wrong with your storage device that caused you to lose your files?

I'm not sure but nothing like yours. It had something to do with a failed write. I hit stop recording on my phone but when I got it out 20 minutes later it was stuck in camera mode and didn't respond to software or hardware buttons. The recording light was on but the recording timer wasn't updating and the pause button wasn't active though the viewfinder was updating to show whatever I pointed the camera at so some processing was going on. After a few minutes of waiting but no responses I removed the battery. On start up the SD card was not found and on reinsert it reported as corrupted.

The last video was partially present as "video_temp" but it was less than 100 MB and it should have been closer to 1 GB based on when I hit the stop button. Video recovery worked on that file since what was saved was a good stream, just missing the headers and too short.

Admittedly I don't know how Android video recording works but it seems to me that the problem started before I removed the battery which is why the temp video file was so short and why ddrescue reported no errors at all. I still wonder if the card might have failed gracefully if I had let the battery discharge, maybe the OS would have sent a shutdown code on low battery detection and I would only have had only a single corrupted video not a corrupted file system but the lack of any responses to hardware buttons makes me think there were system wide problems.

Anonymous

Anonymous Wed 09 Nov 2022 00:10:32 No.1280604 Report

Quoted By: >>1280626

>>1280603
Huh, that camera issue sounds weird. I can understand an SD Card failing but to lock up your phone too, I don't think I've come across that.
Did your SD Card show up in Windows after that at least or was it just permacorruped? I think letting the battery discharge normally probably wouldn't have made a difference. Since the system was hung it would have probably just shut off abruptly anyway and give you the same result. Either way it's good you were stlil able to get the files back regardless though.

Anonymous

Anonymous Wed 09 Nov 2022 00:12:34 No.1280606 Report

Quoted By: >>1280608

>>1280599
>Now I have to do it all again?

No :)

>dd bs=512 if=rescuefile.img of=rescuefile_img.img conv=sparse,notrunc

will give you the full file.
I understand the confusion, I was confused myself after all. Very simple example, imagine your stick to rescue just had 1s and at first you skipped the middle, then when restarting mistyped the filename but everything was recovered sucessfully, since what is in one can't be in the other your two files will look like sth this

stick:
11111 11111 11111 11111 11111
rescuefile:
11111 11000 00000 00011 11111
rescue_file:
00000 00111 11111 11100 00000

As you see they exactly add together, you can just write one over the other and get the full one.
That PhotoRec found a lot of stuff is a VERY good sign, it means the files are there and your incomplete file is just lacking its proper table for a complete file system. There is a high chance that they both combined will create a fully mountable and browsable image. Or at least one chkdsk can fix.

>This should be my next step regardless, right?

YES, definitely.

Anonymous

Anonymous Wed 09 Nov 2022 00:12:46 No.1280607 Report

Quoted By: >>1280608

>>1280568
I see scrolling down the thread that you've had some success which is cool, and possibly an annoying duplication too.

Are you trying to open the image in Windows?

I, the guy who had some success, gave up (quickly) trying to mount it in Windows. But both booting into Linux and running a Linux virtual machine, the image file opened perfectly.

Anonymous

Anonymous Wed 09 Nov 2022 00:19:53 No.1280608 Report

Quoted By: >>1280612 >>1280613 >>1280619 >>1280626

>>1280607
>Are you trying to open the image in Windows?
Yeah, using tools like daemontools didn't work
I used photorec for recovery which got some files but in a really messy way and in a manner where I can't really salvage much from it. I'm also gonna let GetDataBack finish running on the .img file because someone suggested that earlier too.

Booting and mounting in Linux sounds like a good idea, Linux was able to identify my faulty USB for instance but the problem is I'm using gparted and I don't know how to access anything except the terminal on there. Network doesn't work either and I don't see a file manager. I'd have to probably install a different Linux live distro or somehow get gparted to work but I don't know how really.

>>1280606
>No :)
That's a relief. Thank you for the explanation also.
But just one question. How do I know these are 2 incomplete files that will combine and not just 2 separate independent files in general?
I do only have one logs file so I suppose that's a bit of a giveaway
>one chkdsk can fix
You have to mount before you can chkdsk right? I wasn't able to mound the .img files.

Anonymous

Anonymous Wed 09 Nov 2022 00:28:00 No.1280612 Report

Quoted By: >>1280617

>>1280608
>How do I know these are 2 incomplete files that will combine and not just 2 separate independent files in general?
It always puts the block from the device into the same address in the file as it was on the device. (I don't think I'm explaining this very well).

So say you restart 2GB in and you change the filename and it makes new file B: the block it just read 2GB into the device, it writes 2GB into file B, not at the start of file B. It always writes stuff to the same offset it came from, which is why you can combine the files.

Anonymous

Anonymous Wed 09 Nov 2022 00:29:56 No.1280613 Report

Quoted By: >>1280617

>>1280608
>I'm also gonna let GetDataBack finish running on the .img file
If you do combine the two files (which I think you should do), restart the scan from scratch. If the file's only 2GB, that means it's full of data from the start, which is where the metadata usually lives.

Anonymous

Anonymous Wed 09 Nov 2022 00:37:10 No.1280617 Report

Quoted By:

>>1280612
Thanks, I do get that, but I think maybe I didn't pose the question well
Basically, what if the 2gb is just a dummy file anyway and has nothing to do with the other recovery file? Maybe I just created it while testing something, and then began anew? So the recovery file i have could possibly be a full one regardless
Eh, either way I have a backup at this point so I will do the combine. I just have to let these things finish running

>>1280613
I will definitely combine the files
I'm not keen on GetDataBack because I've still not found where to pirate it. I only ran it to see if my data was actually accessible. QPhotoRec seems to have recovered some entire movies I had on there.
Just to be clear, GetDataBack doesn't alter the .img file in any way right? Just want to be sure the backup and base file are still identical, I've not done anything to them except trying to mount which failed and then running them through recovery programs to see what pops out

Once again, a huge thanks to you all. I'd probably be sat here crying not knowing what to do next if it wasn't for you lads.

Anonymous

Anonymous Wed 09 Nov 2022 00:37:50 No.1280619 Report

Quoted By: >>1280620

>>1280608
>But just one question. How do I know these are 2 incomplete files that will combine and not just 2 separate independent files in general?

Because you always used the same mapfile.
The mapfile is constantly updated, whenever something as been successfully written to the current img file it is recorded as being skippable.
Ill give you an even simpler example, now our device only is 10 bits big:

11111 11111

You now start, create mapfile and the first run recovers these 6

rescuefile:
11000 10111

All these are now recorded as rescued.

Now you start it again and confuse the img name, you now create a new file. ddrescue reads
the SAME mapfile, sees the 6 done bits and continues from there, the 6 will therefore in your new file always be 0. It now manages to recover 2 more:

rescue_file:
00100 01000 <- bit 0,1,5,7,8,9 are 0 because they were skipped

The mapfile now has 8 bits marked as done.
Now you see your error and rewrite it AGAIN back to "rescuefile" and the one last is recovered, one cannot:

rescuefile:
recovered in this pass: 00010 00000 <- bit 3 (the FOURTH one) was recovered, the other ones are old ones from the first pass
total: 11010 10111

result:

rescuefile:
11010 10111

rescue_file:
00100 01000

As you see they again add together into the full one, except that one bit that could not be recovered.
But they together are still the complete file that would have resulted from not mistyping.

Anonymous

Anonymous Wed 09 Nov 2022 00:40:02 No.1280620 Report

Quoted By: >>1280621

>>1280619
Yeah, I think you are right. I do only have one mapfile generated so it's probably unlikely I had a different one and then deleted it or something
I get what you're saying.
GetDataBack has now just hung, and QPhotoRec seems unresponsive too. Not sure whether to just say screw them and head to linux to combine the files now

Anonymous

Anonymous Wed 09 Nov 2022 00:50:35 No.1280621 Report

Quoted By: >>1280625 >>1280632

>>1280620

You should have combined them by now already :)
This will give you the reward for plugging the stick in over and over. Even it does not directly mount GetDataback and PhotoRec will still work a lot better and manage to recover more from the complete one.
But it may even be possible to make it mountable in this case. There are tools like testDisk that can restore partition tables etc etc....

Anonymous

Anonymous Wed 09 Nov 2022 00:56:51 No.1280625 Report

Quoted By:

>>1280621
>testDisk
QPhotoRec comes with testdisk, but I'm not sure how to use testdisk itself
I was waiting for GetDataback and PhotoRec o finish but they both just ended up hanging. Had to just close them.
I'm now booting back into gparted to combine the files

Anonymous

Anonymous Wed 09 Nov 2022 00:57:35 No.1280626 Report

Quoted By: >>1280633

>>1280604
Windows Explorer would make the disk inserted sound, then the disk ejected sound and then repeatedly play a seemingly random series of both. Disk Manager would sometimes load but not report anything for any disk until I pulled the card out, or load but never find the card. The same hardware worked under Linux to at least find the card though not mount it.

>>1280608
>I'd have to probably install a different Linux live distro or somehow get gparted to work but I don't know how really.

I've taken to using Mint recently. As a Windows user you'll be able to find your way around Mint pretty well. If you have a spare USB or DVD it's really easy install. (It's not hard to dual boot with Windows but think you'd rather not start mucking around with that just now.)

I'd choose Cinnamon (nicer looking) or Mate (for lower end machines) from here
https://linuxmint.com/download.php

Here are install instructions
https://linuxmint-installation-guide.readthedocs.io/en/latest/burn.html

Once you've booted int Mint you will need to install Gparted and gddrescue (gddrescue is ddrescue but with an extra letter at the front because the name was already used, the commands are the same, ie invoke it with ddrescue not gddrescue) but that's really easy too.

I think terminal is easier
sudo apt-get update
sudo apt-get install gparted
sudo apt-get install gddrescue

but you can go to the "start" menu and use Software Manager and use the search bar there.

Of course you can copy across your recovered image and log/map files so all the work you've done so far isn't lost.

Anonymous

Anonymous Wed 09 Nov 2022 01:15:39 No.1280632 Report

Quoted By: >>1280635

>>1280566
>>1280582
>>1280621
Man am I silly. I wrote the files that I had wrong in my post.
It's actually rescue_file.img and rescuefile.img
So it was this for me
>dd bs=512 if=rescuefile.img of=rescue_file.img conv=sparse,notrunc
I ran the command with the wrong filenames and it just made a copy of resculefile.img camed recuefile_img.img kek. I'm going to put it down to me being tired, I should probably be in bed.

Anyway, I combined the files, but the listed filesize when I use ls -l isn't any bigger. Is that normal? This was what terminal showed

5632128+0 records in
5632128+0 records out
2883649536 bytes (2.9GB, 2.7GiB) copied
The file definitely updated but same filesize

Anonymous

Anonymous Wed 09 Nov 2022 01:17:43 No.1280633 Report

Quoted By: >>1280640

>>1280626
>The same hardware worked under Linux to at least find the card though not mount it.
Hmm so it's a little similar then I guess, Windows wouldn't find my USB but Linux did, albeit for about a minute each time

>If you have a spare USB or DVD it's really easy install.
Creatine a live gparted USB was really easy so if it's anything like that then I imagine dualbooting isn't too bad.
gparted live worked well for me though since it has ddrescue built it so it saved me some bother since i'm on a live install.
A full Linux dualboot might be for another time but maybe I could test a live Mint from USB so I could try mount in there

Anonymous

Anonymous Wed 09 Nov 2022 01:26:11 No.1280635 Report

Quoted By: >>1280638

>>1280632
>but the listed filesize when I use ls -l isn't any bigger. Is that normal?

It's not just normal it's how it SHOULD BE. You are not hanging one after the other but I guess you could call it "zippering" them together, like the parts of a zipper they become "interleaved", some zeros beome ones, but the overall number of bits does not change

10011 <-5 bits
00100 <-5 bits
=
10111 <- STILL 5 bits

If it WASN'T the case something would be wrong.

Anonymous

Anonymous Wed 09 Nov 2022 01:29:07 No.1280638 Report

Quoted By: >>1280641

>>1280635
Thank you!
Rebooting back into Windows now
Can I delete everything PhotoRec gathered the first time?
I just don't have the storage space to run it again and keep a second lot of the files

Anonymous

Anonymous Wed 09 Nov 2022 01:35:31 No.1280640 Report

Quoted By: >>1280643

>>1280633
>dualbooting isn't too bad
It's not, but unless you want to dual boot permanently it takes up a few GB of drive space and you'll have to think about how you want to partition the drive, and that involves a small chance of data loss (it's very safe and it's done routinely but you always back up before repartitioning which seems like more work than you need atm).

>maybe I could test a live Mint from USB so I could try mount in there

Definitely. Installing gparted and gddrescue to the live Mint USB takes about a minute including the time to type the commands because they're both small files, < 650 kB to download total, < 3 MB disk space total installed.

Using a two button mouse you just right click on the image file and open with disk image mounter to avoid those annoying windows mount problems but with a full GUI desktop.

Anonymous

Anonymous Wed 09 Nov 2022 01:37:08 No.1280641 Report

Quoted By: >>1280643

>>1280638

Probably.
If it does not directly mount it would be good idea to let them again run over the now complete one, which you would do anyway and those programs don't have a mapfile that lets them skip already recovered parts as far as I know.
So you are gonna get them back a second time anyway.

Anonymous

Anonymous Wed 09 Nov 2022 01:47:07 No.1280643 Report

Quoted By: >>1280663

>>1280640
Ah right, I see. I actually don't have much on my current laptop so data loss wouldn't be a huge deal, but on the flipside I'm still trying to sort this mess out
I don't know whether I should try mounting in Linux now, or just run photorec and getdataback and then try Linux later.
I'm not sure photorec and getdataback are really even the best programs for this desu, they're just ones that popped up.

>>1280641
Thanks, it doesn't directly mount. Still says corrupted and Daemon tools won't do it either.
Do you suggest I run QPhotoRec and GetDataBack on this new .img file? Any other programs? I'm probably going to set them to run and then head to sleep honestly

Once again want to say thank you so much to all you top lads for helping me out. Loads of useful tips and you've assisted every step of the way when I've been lost which has been great in getting something out of this drive. Been really nice of you good folk

Anonymous

Anonymous Wed 09 Nov 2022 01:51:32 No.1280646 Report

Quoted By: >>1280663

Quick update, qphotorec still seems to be recovering to made up directories with files being everywhere

GetDataBack I can't run right now because the file is in use. Fair enough. I'm really going to have to look to see where I can pirate that. Maybe rutracker. I tried searching for alternate ways to get data from .img files but I think I must have typed the wrong keywords because there weren't any real program suggestions

Anonymous

Anonymous Wed 09 Nov 2022 02:00:20 No.1280663 Report

Quoted By: >>1280666

>>1280643

My go to choice is always PhotoRec.
I don't know GetDataBack tho.

I would let PhotoRec run over it, which as I see from >>1280646 is what you already started.
Then after it has finished tomorrow you could then as a final act try to let TestDisk and such at it to see if we can actually make it mountable again. The absolute majority will be that point have been recovered and save so it would just be for a bit of fun and principle, but that takes the pressure out of it.
For now just let PhotoRec do its magic while you get some rest.

Anonymous

Anonymous Wed 09 Nov 2022 02:05:42 No.1280666 Report

Quoted By: >>1280671

>>1280663
The problem with photorec is it ends up making over 400 folders with gibberish filenames for everything, and there are a bunch of random .dll files everywhere
It's almost unfeasible to sift through because I don't really know what file is what and since I had a browser and a handful of programs on he USB, it's even worse with all the cached data and such.

That said it's pretty stunning just how much data has sort of managed to have been recovered even like this. I think TestDisk might be a good idea, failing that I may try Linux Mint on a live install and see if it mounts there.
Someone suggested chkdsk but I don't think I can run that unless it mounts, I'm not sure there's a way to "fix" the .img file so it mounts.
I feel like there's surely some way to get the filenames back, I mean, would it really have all this data yet no access to any of the filenames? I don't get QPhotoRecs naming coonvention of f[numbers] either

Anonymous

Anonymous Wed 09 Nov 2022 02:22:17 No.1280671 Report

Quoted By: >>1280728

>>1280666

That's because filenames are stored in the Master File Table or File Allocation Table along with other metadata. It the MFT or FAT is damaged these tools perforn a deep inspection for signatures.
So basically what happens is that PhotoRec for example sees "I found a JPG file, it sarts at this position and ends at this one. Hey, this is an mp4 file! And its other cluster is at position XYZ!"
So it only can find files and recognize their type, but the names and other metadata are lost. Same goes for the folder structure that was on the disk.
That's why the naming and folder convention is so confusing. Numbers are the most convenient way to give the files names since you can easily make sure that none will be double.
I'm not sure other programs could do that better unless they at first do not try deep inspections but maybe use remainders of the table if they can find it to deduce the names.

Anonymous

View Same Google ImgOps iqdb SauceNAO 1614570135193.png, 334KiB, 688x490

Anonymous Wed 09 Nov 2022 07:29:18 No.1280728 Report

Quoted By: >>1280744 >>1280775

GetDataBack has finished running...
Most if not all of my files are there. I see them with their proper file structure AND filenames.
Even still, I can Right Click > Open some of these files within GetDataBack and they actually show up. I don't quite know how.

There's hope yet. I'm seeing the light at the end of the tunnel.
Now the problem is finding a pirated version of getdataback without malware up the wazoo, OR finding another way to get my data back. Would booting into Linux mint and mounting it there possibly work given what GetDataBack managed to recover?

>>1280671
Is it possible I did something wrong with qphotorecs then? I don't see quite how it would recover into 300 separate folders while GetDataback seemingly has all my files.

Anonymous

Anonymous Wed 09 Nov 2022 09:43:27 No.1280744 Report

Quoted By: >>1280780

>>1280728
>I don't see quite how it would recover into 300 separate folders while GetDataback seemingly has all my files.
It doesn't even make an attempt to understand the filesystem or reconstruct it, it just goes from the start of the image to the end, seeing if anything it encounters looks like the start of a file.

Anonymous

Anonymous Wed 09 Nov 2022 11:35:22 No.1280775 Report

Quoted By: >>1280777 >>1280780

>>1280728

That means your MFT/FAT is mostly intact, it's just knocked too much for Windows to be able to read the file system and the boot sector probably is damaged.
That's where TestDisk has its strength, restoring partitions and boot sectors is its bread and butter.
Also Linux often is less sensitive and can mount devices for which Win gives up, so it's worth giving a shot.
>>1280728

>Is it possible I did something wrong with qphotorecs then?

QPhotorec is a pure deep inspector, you can only choose between scanning free space and everything. It then wanders all over the partitions and restores everyting it can find.
It does not care about partial tables or anything.
It values getting back the files higher than attempting to restore the file system, and for most users the pure happiness to just getting back their files should compensate for the last step of wanering through the folders and looking at the restored data to manually sort and name them back.
This is of course a bit bad for games or so, where you have many files for which you didn't even know the content, so if they are just there as a number in a random folder you have idea where to put them back.
But whenever data has to be restored the most valuable one is obvously the personal one, pictures, videos, documents,...

Considering your table seems to be mostly intact there is a high chance that TestDisk or chkdkc if you can get it to work with it could restore it.
Maybe it really just needs a new boot sector and then it mounts.

Anonymous

Anonymous Wed 09 Nov 2022 11:43:27 No.1280777 Report

Quoted By: >>1280780

>>1280775
>Maybe it really just needs a new boot sector and then it mounts.
OP really needs to merge (a working copy of) the two images, because the important metadata is in the small image and the file data is in the big one.

Anonymous

View Same Google ImgOps iqdb SauceNAO 1460812422256.png, 368KiB, 500x569

Anonymous Wed 09 Nov 2022 11:53:10 No.1280780 Report

Quoted By:

>>1280777
I already did merge the 2 files as I was kindly told how to do, I still got the same errors

>>1280744
>>1280775
Ah right, I see thanks
That does make sense, I mean, if these were pictures then the lack of file structure wouldn't be an issue really. It's just that in this specific case the data is very muddled because I had a lot of different things on the drive as I never really sorted it out properly. Sad thing is I planned to near the day it failed completely.

>>1280775
>TestDisk has its strength, restoring partitions and boot sectors is its bread and butter
How does TestDisk work then? I ask because when I went to download it, I just got qPhotoRec with it and figured they were the same thing. How do you restore with TestDisk? I would have tried it earlier but I just didn't really know

I should mention, I got GetDataBack from rutracker in the meantime. It's been restoring now. Slowly but surely, my files seem to be coming back with their names and their folders. Holy shit.

Anonymous

Anonymous Wed 09 Nov 2022 12:13:20 No.1280782 Report

Quoted By: >>1280785 >>1280967

>How does TestDisk work then? I ask because when I went to download it, I just got qPhotoRec with it and figured they were the same thing.

While TestDisk has an undeleter that is not its main purpose.
TestDisk restores not FILES but the partition information and the boot sectors.
Basically a device has a "header" where it writes what partitions are on there, where they are, how big they are etc. if those are missing the volume cannot be mounted anymore since the system does not understand how the data folling it is choppeninto "chunks" (partitions).
THIS is where TestDisk operates, it scans the volume, then if needed asks the user for additional information, then calculates what the header SHOULD look like for the found system (sectors, cylinders, position etc etc) and writes a conform one with these information back.

Think of it as aa tool that for a book helps you restore the table of contents, but in this model imagine that the reader without the table cannot find the chapter he wants whereas with real books you can of course still look through it, mounting a volume is a bit different from opening a book... But for a basic understanding this image should work. PhotoRec tries to scan through the pages and restore the text, TestDisk tries to restore the TOC.

Anonymous

View Same Google ImgOps iqdb SauceNAO A4C709B3-A708-42DF-B11D-02EB3E5A (...).jpg, 146KiB, 601x619

Anonymous Wed 09 Nov 2022 12:28:55 No.1280785 Report

Quoted By: >>1280790

>>1280782
Huh. I had no idea it could do this, I thought it just recreated the partition table.

Anonymous

Anonymous Wed 09 Nov 2022 12:42:29 No.1280790 Report

Quoted By:

>>1280785

Recreating the partition table is the one use TestDisk is probably best known for - since that is the case that most users use it for probably, they were too careless and crashed their partitioning, dangit! But the file systems themselves are fine. So they use TestDisk to restore that.
But it is a full suite with more functions than that. As you can se from the list it can restore other parts, including the MFT/FAT if there is still a working copy on the system.
If on yours the copy of the table is undamaged it can do it too.
Also of course its undelete function, that it can actually kinda do the same thing as programs like Recuva or GetDataBack. But I think it does not do a deep inspeection so it can only recover basic deleted stuff (accidentally emptied the recycle bin etc.).
But yeah, it's more versatile as you may think.

Anonymous

View Same Google ImgOps iqdb SauceNAO 1625970811642.png, 968KiB, 740x913

Anonymous Wed 09 Nov 2022 14:52:47 No.1280842 Report

Quoted By: >>1280919 >>1281029

GetDataBack has finished.
Well, I think it has, there was nothing to show it's complete, it's just not doing any operations anymore.

I...I think that's all my data.
I think it worked. There's over 200GB here.
They told me it couldn't be done bros. They told me my USB was dead and there was no hope. I myself didn't think it would work.

But here we are. Holy shit. A USB that Windows wouldn't even pick up and Linux only picked up for 1 minute at a time and somehow I've managed to get all my data off it thanks to your help.
Thank you so much anons, thank you /wsr/, you really helped me a bunch with all this, I know I was lost on a number of occasions but shit you guys pulled through each time and told me what to do. What top lads. Thank you for believing in me.

I have to ask though, what wizardry is this? How the hell has this worked this efficiently? I feel like you've all taught me some sort advanced magic I wasn't supposed to be in on. This is a stunning level of recovery for a drive that failed and wasn't being picked up. Then after that it was plugged and unplugged into Windows a bunch of times just in the hope it'd turn up.
But shit, so much in tact. There may be the odd missing files, I'd have to go through it all but I honestly wasn't sure this was going to work at all. I almost didn't even bother with trying Linux because I thought it may just be people suggesting it because they hate Windows.

Thank you to everyone who made suggestions on the way, from both the first thread and this one. A combined effort, I got my damn files back.

Anonymous

View Same Google ImgOps iqdb SauceNAO hola hombre.jpg, 106KiB, 723x1024

Anonymous Wed 09 Nov 2022 15:02:14 No.1280850 Report

Quoted By: >>1280967

What a beautiful ending
Cant tell you what wizardry this is exactly but part of it is your endurance and willpower + the patience and knowledge of those other anons

Anonymous

Anonymous Wed 09 Nov 2022 19:33:00 No.1280919 Report

Quoted By: >>1280967

>>1280842

Isn't ddrescue great? :)

>I have to ask though, what wizardry is this?
Your stick not being completely dead and Linux from the beginning being designed to work with devices (dd and then ddrescue).
Basically what this allowed you to do is keeping progress and therefore chopping away the stick file system piece by piece.
Now you can let the stick meet Mr Pliers and then get a new one.

Anonymous

Anonymous Wed 09 Nov 2022 22:37:59 No.1280967 Report

Quoted By: >>1280976 >>1281039

>>1280850
Thank you for the support anon, I've appreciated all the help tips and even just general discussion

>>1280782
>TestDisk restores not FILES but the partition information and the boot sectors.
Oh right, that actually makes a lot of sense. I didn't know it did that. I suspect doing that would maybe make it easier for me to mount the .img file and recover data without tools like getdataback?
If I'd have known earlier I'd have given it a shot, I'm not really sure how it works or is used though. I floated to qphotorecs because it has a GUI for babbies like me
Maybe one to note for the future

>>1280919
Thanks, but man even knowing that it still seems insane to me it pulled so much data.
I'll have to contact SanDisk because it was a few months back that they told me they'd send me a new one. Hopefully I've not gone past my warranty date or something.

Quick question, if I need to transfer these recovered files to another drive, bearing in mind there are loads of little files, what's a good way to do it? I ask because I set it to just copy and paste, and the process has taken hours and is only halfway. I think there's a more efficient way than this, there has to be really.

Also as a reminder to myself if I come back to this thread, don't forget to use umount to unmount USB drives in Linux

Anonymous

View Same Google ImgOps iqdb SauceNAO 34F96958-637B-44F2-B6EE-32ED4B40 (...).jpg, 63KiB, 440x492

Anonymous Wed 09 Nov 2022 23:00:12 No.1280976 Report

Quoted By: >>1281008

>>1280967
>what's a good way to do it?
You just gotta wait and let it do its thing. Your time is valuable, the computer's time is not, don't spend your time trying to find a way to save the computer time. Just set it going and come back when it's done.
>I think there's a more efficient way than this, there has to be really.
>don't forget to umount
The reason it's taking so long is it's leaving the disk in a consistent, unpluggable state at all times, which means a lot of waiting until blocks are definitely on the disk before proceeding. You can turn this off by turning off both these boxes, but you probably shouldn't because then you have to "safely remove device" every time it's plugged in with these boxes set, or you will lose data, potentially the whole filesystem.

Anonymous

Anonymous Thu 10 Nov 2022 00:08:05 No.1281008 Report

Quoted By: >>1281029 >>1281039

>>1280976
>Just set it going and come back when it's done.
Thank you, but when I do long transfers like this with so many files I don't know, I always sort of worry I'm drastically affecting the lifespan of the USB stick?
Is that unfounded? I mean, I've been messing around with 200+GB each time, and now I've got the files themselves there are loads of small files and .dlls and whathaveyou that are transferring across, it's a lot of data that's being written, could it be a problem?

Anonymous

Anonymous Thu 10 Nov 2022 01:44:13 No.1281029 Report

Quoted By: >>1281122

>>1280842
Really cool. Thank you to the people who write FOSS so we have these tools and to those who teach us how to use them.

>>1281008
>long transfers drastically affecting the lifespan of the USB stick

It should last at least 10 000 write cycles. Writing its full capacity to it once every day it should last more than a decade (bearing in mind that changing a file's contents then saving involves writing the file to a new location, then marking the old location as empty).

Even though poor manufacturing of the silicon will lead to cells failing and limiting your writes, you're more likely to physically damage (such as breaking the connector) or overheat it (which cooks the components shortening their life span) or find out poor manufacturing leads to a different failure (like bad solder joints breaking) or lose it or find it's too small and buy a new one than run out of writes. Your problem seemed much less like a huge amount of the storage cells failing than some other problem.

Anonymous

View Same Google ImgOps iqdb SauceNAO wasure spoon 3.png, 103KiB, 1345x1151

Anonymous Thu 10 Nov 2022 02:06:15 No.1281034 Report

Quoted By:

Posting in this legendary thread.

Anonymous

Anonymous Thu 10 Nov 2022 02:19:03 No.1281039 Report

Quoted By: >>1281122

>>1280967
>Quick question, if I need to transfer these recovered files to another drive, bearing in mind there are loads of little files, what's a good way to do it? I ask because I set it to just copy and paste, and the process has taken hours and is only halfway.

With loads of small files and 200+ GB there really isn't a way to circumvent the first slow transfer. Once you THEN have them on a faster medium further transfers will be faster if it has a faster output, but the initial one can only be as fast as the medium allows and lots of samll files for transfer speeds is basically the worst case.
You really just had to sit through it once.

>>1281008
>I always sort of worry I'm drastically affecting the lifespan of the USB stick

Well yeah, a bit, but that is true for EVERY write operation on it. It does in this case not matter if it is many small or a few large files since they are chunked into sectors anyway.
Also if I see this correctly you are now talkin about transfer FROM the stick to another drive?
In this case it does not affect its cells' span, only WRITE operations over time with many many cycles wear down the cells.
SO if you now for example just use the stick to transfer from it to an HDD it does not wear it down at all, only for the destination if that one is another stick it would mean again ONE write operation on a bunch of cells of this other one.
File sizes for this are irrelevant though, they just affect the speed, but each cell is still only written over ONCE.

Anonymous

Anonymous Thu 10 Nov 2022 08:19:05 No.1281122 Report

Quoted By: >>1281156 >>1281157 >>1281171

>>1281029
>Thank you to the people who write FOSS so we have these tools and to those who teach us how to use them.
Absolutely!

>It should last at least 10 000 write cycles. Writing its full capacity to it once every day it should last more than a decade
>buy a new one than run out of writes.
Oh, well that's more reassuring thanks. Given the size of the data and the nature of the files I just worried I might be murdering my drive very quickly. I had stuff on there you probably shouldn't run off a USB at the time.
Plus the one I'm writing to now is a relatively new USB so I was a bit unsure. I guess I feel better about it now

>>1281039
>With loads of small files and 200+ GB there really isn't a way to circumvent the first slow transfer
If I sent everything to a .zip file would that help or probably not since it's moving the same data anyway?
Both devices were USB3.0 but one may just have throttled or something.
>since they are chunked into sectors anyway
Right, ta. I was always under the impression that if I copied say, 1000 separate 1kb files, it'd be much worse than moving a 1mb file over. Don't know why

>Also if I see this correctly you are now talkin about transfer FROM the stick to another drive?
Nah it was reading from the other drive, writing to the stick.
When I restored the files using getdataback I restored it to a HDD, now I've moved them onto a USB

Anonymous

Anonymous Thu 10 Nov 2022 13:05:59 No.1281156 Report

Quoted By: >>1281623

>>1281122

You just have to keep in mind how much 200+ GB really IS.
10-20 MB/s is a decent real life write speed for a USB stick for many small files. 20 MB/s would mean 50 sec per GB, with fluctuations let's just simply say 60 sec = 1 min per GB
AN hour has 60 minutes, so add up to 200+ minutes and you already are at 3 1/2 hours.
That adds up quickly with that amount of data, more than you would expect without actually calculating it through.

Anonymous

Anonymous Thu 10 Nov 2022 13:16:41 No.1281157 Report

Quoted By: >>1281171 >>1281172 >>1281623

>>1281122
>If I sent everything to a .zip file would that help or probably not

Yes it would for the actual transfer, but for overall wait time it would be a detriment.
You see, in this example you only have your stuff on that USB, to send it as a zip you would first have to MAKE this zip. So you'd on your stick create the big zip file, more write operation which on a USB stick are comparatively slow and more wear and more wait to THEN at the end sending that over faster - when instead of packing it during the time you had to wait for that to finish you could have started the transfer already which would probably be close to finish at that point already. So you waited only to then wait again.
It only slowly becomes a plus if you transfer the data so many times that the faster speed per transfer amortizes the time you had to wait the first time - which I doubt there will be that many.

Anonymous

Anonymous Thu 10 Nov 2022 14:59:27 No.1281171 Report

Quoted By: >>1281623

>>1281157
>you would first have to MAKE this zip
Doesn't matter, it'll either make it in %TEMP% (which is a fast local device not subject to disabled write caching), or on the device (which is only one atomic operation.
What's holding the transfer back is atomic operations: creating a file has to either succeed or fail, it's not permitted to half-succeed and leave the device in an inconsistent state just because the user pulled it out at the wrong time. This means the OS has to do a cycle of
- allocate extent and directory entry for file
- flush buffers
- check file is allocated
- populate extent with data
- flush buffers
- check extent is populated
- repeat
Whereas on a device that's fixed, it can do
- allocate extents and directories for hundreds of files in parallel
- populate extents as soon as they're allocated
- let the buffers flush themselves as and when
- read through the buffers so the FS driver sees a consistent disk image
- flush everything if the user shuts down the OS, otherwise don't bother

This is why writing a hundred small files is slow on a USB but fast on an SSD (it's less fast on a HDD because the head has to flip back and forth between the extents and the directory entries and FAT): nothing can happen in parallel and the OS has to check the disk all the time to make sure its writes went through.
>>1281122
>Right, ta. I was always under the impression that if I copied say, 1000 separate 1kb files, it'd be much worse than moving a 1mb file over.
It's vaguely worse for write amplification, but it doesn't really matter. 1000 1kb files will amplify to 2-4MB, as opposed to one 1mb file which will amplify to 1028-1032kb, so there is a relative difference, but as an absolute workload it really doesn't matter that much unless you're doing it constantly all day.

Anonymous

Anonymous Thu 10 Nov 2022 15:03:15 No.1281172 Report

Quoted By: >>1281623

>>1281157
Also USB sticks are often FAT/ExFAT, whilst fixed disks are NTFS. NTFS uses copy-on-write structures internally, which means you can do cool stuff like allocating the entire copy as a transaction, and only committing at the end. So you write all your files as "this file will be here once commit #whatever is issued", then at the end you use one atomic write to make the commit. You see this most with Windows Update: the updates now either succeed or fail, and if the computer doesn't boot, WU asks the filesystem to roll back the commit and the computer unupdates itself.

Anyways, point is NTFS is a lot better at slapping down a bunch of random files without having to check all the time that the filesystem didn't get scribbled.

Anonymous

Anonymous Fri 11 Nov 2022 00:21:39 No.1281352 Report

Quoted By:

Nice

Anonymous

View Same Google ImgOps iqdb SauceNAO wasure tv.png, 530KiB, 8185x8283

Anonymous Fri 11 Nov 2022 20:03:57 No.1281623 Report

Quoted By:

>>1281156
I guess that's fair, this probably took over 10 hours though honestly. It is done now though thankfully, onwards and upwards

>>1281157
>first have to MAKE this zip
Ooops, of course. Somehow I skipped over the importance of this part. I probably won't be transferring it again. Maybe once if SanDisk are still willing to replace the drive which I hope hey are.

>>1281171
>>1281172
Thank you for the information. What you're saying makes sense. Even after my main problem was resolved you continue to illuminate me /wsr/,

Capcode	All Only User Posts Only Verified Posts Only Moderator Posts Only Manager Posts Only Admin Posts Only Developer Posts Only Founder Posts
Show Posts	All Only With Images Only Without Images Only Spoiler Images Only Non-Spoiler Images
Deleted Posts	All Only Deleted Posts Only Non-Deleted Posts
Ghost Posts	All Only Ghost Posts Only Non-Ghost Posts
Post Type	All Only Sticky Threads Only Opening Posts Only Reply Posts
Results	All Grouped By Threads
Order	Latest Posts First Oldest Posts First

On these archives

Your latest searches

Dead USB