New answers tagged data-recovery
You don't have to run anything after resizing, but you cannot just resize the logical volume even if you have unmounted the filesystem on it. You have the resize the filesystem first (for ext4 you can use resize2fs), to make sure there are unused blocks in the logical volume that can be freed up (to transfer to swap). This normally requires some calculation ...
Do they just mark the space as "free"? Yes. "Removing" the file would take extra work and is in most cases unnecessary.
If your openSUSE boots to a blank screen with cursor, you may still be able to login to tty1 (CTRL+ALT+F1) and copy data with command line tools.
You can use some recovery distribution, try to choose from this link for example. I'm personally using SystemRescueCD, but I have install it on the USB stick. I think, that other distros can be installed on USB stick, too. Please check it on the projects' websites.
Photorec should work. You will have to specify the specific format(s) you want though, you can't just say "audio". http://www.cgsecurity.org/wiki/PhotoRec_Step_By_Step#Selection_of_files_to_recover
If you can scan the document again, you might be able to automatically compare that against the recovered documents. But if that is the case you probably don't need to recover. That leaves finding the right PDF, and since opening them one by one in programs like evince is cumbersome I recommend you run the following in the directory where the .pdf files are ...
I think what happened is you did try to reduce lvm size before getting filesystem shrink. Should do resize2fs to shrink filesystem before lvmreduce Do not mount it. You might end up getting filesystem corruption. Check if you have vg metadata backup it is under /etc/lvm/ when you modify vg it puts there as default since you have access to there check it ...
ddrescue marks bad sectors not until it reaches the second phase: https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html (Second phase; Trimming) Trimming is done in one pass. For each non-trimmed block, read forwards one sector at a time from the leading edge of the block until a bad sector is found. Then read backwards one sector at a time ...
Try running pdfinfo on your files. The output may have Creator: Simple Scan or similar in it, so you can search for that. You can also try using the CreationDate field if you know the approximate date of creation. Of course pdfinfo will return an error if the file isn't a PDF file, so you'll need to send errors to /dev/null. Try scanning a document using ...
The scan image data in the PDF file will most likely be preceded by something like <</BitsPerComponent 1/ColorSpace/DeviceGray/DecodeParms<</Columns 2480/K -1>>/Filter/CCITTFaxDecode/Height 3507/Length 96349/Name/Im0/Subtype/Image/Type/XObject/Width 2480>>stream I'd therefore start to narrow things down with grep -Fil ...
Top 50 recent answers are included