Hello.

My problem is this one:
I need to generate a disk image of a whole 2 To disk in order to pick some important files I mistakingly purged. I'll do it with Testdisk, fro cgsecurity. But I don't have other 2 To disks, instead, several 1 To disks.
How can I emulate a big partition with putting in a way, those smaller disks in a row ? It must be that someone had to that someday.

Thanks for your help, here a desperate history student...

You use LVM. The approximate workflow:
After that, you have a 2TB device /dev/myvolgroup/mybigdisk, on which you can make a filesystem, which you can then mount.

Before you follow my instructions, please find an LVM tutorial on the internet to confirm you are doing the right thing.

No you don't. Classic case of xyproblem. Just tell us what the problem is and ask for suggestions.

Testdisk doesn't interfere with the source drive. Simply use the smaller drives as targets for testdisk. Works best if you can limit what you are looking for - only word files say, or photos. Generates a lot less, and easier to search. Be aware you get random names for the files.

I can do this on empty disks without risks, at least.
Thanks, exactly what I needed, and pretty simple at that ! I love you.

Didn't see last post: Ok. I purged two to three odt files in a partition which now 1.7 To, and was the /home partition of the last installation, before I wiped it out and reinstall (I wrecked it for other reasons). These files are important works.
Using photorec would take several days non stop of work to scan the whole disk, I can't do this, and in the past weeks, everytime I tried, it shut itself out after between 10 minutes and a hour of work. I mean it blocked completely, doesn't respond to the close button. So that I can't resume the process later.
It makes the computer awfuly slow, so I want it to work only the night. I guess with testdisk, not having to look into what the copied octets mean (while making the image) would avoid that slugginess, but I can be wrong.

It's strange, the first (tens of ?) times I ran photorec, it could scan up to a third of the partition maybe, in less than 8 hours. Eventhough the partition IS read-only, it looks like the repeated scans altered it, so that photorec became unusable, crashing again and again.
And it's not like only the screen was blocked, no, AAAALL ressources are stolen and the scan is NOT being made.

I complained about this on cgsecurity's forum, and they told me (answered only ONCE, if memory serves me well) to use testdisk instead, way faster. So...

I'll go for LVM, until someone's has a better idea :,(

I used LVM. Now, I have no clue on how to use testdisk to recover lost file of a otherwise usable partition.

You really should not need lvm. Try 'foremost'. Read the part about the config file at the end of the man page.

At face value what is now 1.7 TB was or is not the same as the last installation?

I assume the idea was to use the dd command to create an image file of your existing drive to the new LVM. You can run the data recovery tools using the image file as the source instead of the original drive. If you reinstalled exactly as the original installation and the location of the deleted files were such that they were located on the disk were they were not overwritten then there is still a chance they could be recovered. However, at the moment it does not look promising.

No more than one day was spent when I understood I did something wrong, and I stopped using that partition instantly. Less than a day after that, I put in read-only mode. It's still on the same disk, on the same computer. Nothing changed whatsoever. That disk is huge, and I did NOT write Mo-big after the removal of the files. Many files do have been saved, I saw that, but I am still looking for the ones I want. There can't be more favorable situation to get them back, contrary to what you say.
I actually can't fathom why or how the partition would have been altered, since it was always scanned while read-only.
It worked the whole night doing the image, and hasn't finished. No progress bar with dd, shit.

Thanks Awasomemachine, I didn't something like foremost, I guess it's faster than the two previous tool ?
But in the manual, it DOES need an image to work on. So still need LVM.

Unfortunately, it couldn't finish: I'm still trying foremost with this. Are there better dd (or better than dd ?) parameters to avoid errrors on loooong session ? Or if it's in the disk itself, ignore it and resume writing octets.

I gave foremost the parameters:
foremost -i image.dd -t zip,pdf -q (quick mode, seems unrecommenced only for NTFS) -Q (quiet mode) -d (indirect detection) -K 4000 -o where_to_save

Often foremost sets an urgence flag, which was seems to be errors, but I don't get it. It continues on a few lines after that. Those are corrupted files, right ?

I would appreciate being able to see how much it has progressed, like with sending SIGUSR1 to dd. It seems quite slow... any option ?

/home/me/foremost.conf has (only):
odt n 10000000 opendocument.text
I made several tests on usb stick partitions, all files it seems to recover (are called odt, but I doubt those are the good ones) are unreadable.
Even for existing, normal files, not even deleted ones.
I guess the signature is wrong then !

ddrescue is designed to work with damaged disks. You will probably find a package available in your Linux distribution.

I used it. It worked, up to a point, the very last one: in fact the very last octet/bit, can't be rescued. I would have expect at two third, but no. I wonder what that is.

I managed for the signature:
odt n 1000000000 \120\113\003\004\024\000\000\010\000\000???\115\136\306
It seems to do the job, and tell appart odt (or at least opendocument formats) from zip. I guess there are more requirement than for photorec, since foremost won't ask the file system for the file boundaries.

It's strange, all files recovered range from 450 to 600 Mo. Why ?? I can't give a footer, since not all odt have a common pattern. Most files are corrupt to the point of crashing libreoffice, so it will take time...