Hey all, I dumbly performed sudo rm -r on a directory that contained the mount point for a storage drive, seemingly losing everything on it. Is there a way I could potentially recover the lost files from it?
Misc. info:
OS: Canonical Ubuntu 20.04 LTS
HDD: Seagate 1TEAPG-500 3 TB USB (affected, not root, is ext4)
Hey welcome! Have an F
Have you tried photorec?
Have a backup of an index of the filesystem? Was the rm canceled before it finished? You can definitely recover. Based on how important the files are, I’d have a professional do it or you can try yourself.
Thank you; no I have not.
I don’t think so.
The rm completed, so the disk now shows as ‘92.3 MB used / 2.8 TB free’ where it used to have hundreds of GBs of data.
I would like to have a crack at it myself, I’m just not sure where to start w/ all this. I’m under the impression that it’s best practice to dump a block-level image of the disk on which to operate, though. So short of paying a data recovery specialist, where should I start? What utilities for cloning, recovery, etc.?
Step1: umount the partition ASAP ; do not mount it again.
Simplest cloning utilities only… dd, cat, pv, etc. pv will display progress if that matters. More advanced tools like clonezilla/partclone/partimage will dutifully skip over the deleted files.
Then try extundelete, testdisk or photorec on the cloned image and see how you fare. If those don’t work, there are others.
By that you mean they won’t be backing up anything deleted? I was going to use Clonezilla, but I guess not then!
What do you think about ddrescue? I’ve seen that recommended over dd. Thank you for the advice.
I like DDrescue, with a log file, but have not had to recover from deletions; mostly just making images and stuff form failing drives (all drives die)
There was a post about making a copy with DDRescue, then Testdisk to undelete:
I would not worry so much about the mac side, and see if that helps?
Testdisk actually looks pretty slick for undeleting; will have to remember that in case I fat finger in the future…
Looking at a couple places, it seems straight forward enough but again, I’ve not needed it.
Would you be kind enough to feed back to us on any hurdles or problems? for posperity?
Just remembered I unmounted & re-mounted a couple times, hopefully that wasn’t too damaging then. Of course right now it is unmounted & stowed away.
I would, but it’ll take a couple weeks for me to acquire an adequately sized disk to put the 3TB cloned image on so I can more safely operate on & undelete files from it. Not sure what this forum’s policy is on when to sunset threads, but I would appreciate more assistance when I have the materials in order.
Yep, this one.
A filesystem’s job is to keeps track of pieces of files and lists of files in directories reliably, when you delete a file there’s probably multiple pieces of data that need to be modified and they’re usually a journal entry made that’s meant to help get the filesystem into a consistent state in case power is lost half way through modifying all the places.
extundelete can walk the journal and can try and find the old data that’s no longer referenced.
ddrescue doesn’t care about the filesystem, it can just make a copy of the data block by block, it’s like dd, but it has additional options that make working with broken devices easier, it won’t help you make sense of the data.
getting a copy of the data is very useful before you actually start the recovery using extundelete because extundelete also writes metadata, meaning it might overwrite someplace on disk where old useful metadata used to be, so having a copy is somewhat useful.
I don’t know about photorec internals, apparently it scans each block on disk for useful stuff of any kind.
Once you recover (or don’t recover), start using btrfs with snapper or timeshift, or start using lvm2.
Slower and more complex to use, for no benefit in your situation. ddrescue is a great utility when you have (potentially) damaged hardware to deal with.
I only recently got that new drive to dump a backup on to using dd, but not even that seems to have worked?
sudo dd if=/dev/sda of=/dev/sdb
[sudo] password for chris:
dd: error reading '/dev/sda': Input/output error
87672112+0 records in
87672112+0 records out
44888121344 bytes (45 GB, 42 GiB) copied, 2776.43 s, 16.2 MB/s
To clarify, it looks like nothing was copied on to the target (certainly no output file) & the target is still a 6 TB volume, so doesn’t seem to me like any action has actually taken place. I probably used dd incorrectly.
Well then I guess you do need to learn ddrescue after all:
Are you sure of that? I was just talking to someone who told me my issue was I didn’t specify a .img to clone into & that i should retry the cloning w/ that specified.
Relevant lsblk info:
sda 8:0 0 2.7T 0 disk
└─sda1 8:1 0 2.7T 0 part /media/chris/CHRISDRIVE
sdb 8:16 0 5.5T 0 disk /media/chris/BACKUP
nvme0n1 259:0 0 238.5G 0 disk
├─nvme0n1p1 259:1 0 512M 0 part /boot/efi
└─nvme0n1p2 259:2 0 238G 0 part /
Was it wrong to use sda as the input instead of sda1? The 2.7T disk is what everything got deleted on that I’m trying to backup to recover from. sdb is my target.
EDIT: just reformatted the 6 TB target disk (sdb), & now it’s:
sdb 8:16 0 5.5T 0 disk
└─sdb1 8:17 0 5.5T 0 part /media/chris/BACKUP
This is also how it used to look before I used dd, I’m guessing my using sudo dd if=/dev/sda of=/dev/sdb wiped the target disk’s partition & rendered the disk raw? I guess I should be cloning sda1 to sdb2? Should I be specifying a .img to create also?
Hi, It might be better to copy the whole disk, but the partition should still have the deleted files (marked for deletion in the directory tree)
You can copy to a file if you rather, and then mount the image later.
The original dd command you showed, should have ended up with the data in /dev/sdb1. perhaps try testdisk on it, and see what it has?
I would still recommend ddrescue though, noting that dd uses the if= and of= but ddrescue does not need that. you could still choose a bunch of options to fine tune the process, check man ddrescue
If the large drive (sdb) is formatted with a filesystem, and mounted at /media/chris/BACKUP then
sudo ddrescue /dev/sda /media/chris/BACKUP/imagefileofdrive.img /media/chris/BACKUP/mapfile.map
If the large drive is not formatted and mounted (like, if the first DD overwrote the mounting info) then you can put the mapfile in your home directory, and copy over the large disk
sudo ddrescue /dev/sda /dev/sdb /home/chris/mapfile.map
This should end up with 2 drives, both showing with the same UUID and partition labels and stuff.
The original issue was an accidental delete? So we would not be so worried about corruption, with several passes extracting variously damaged blocks.
It does kind of rely on the older drive being disconnected / unplugged / not mounted in the mean time.
If the drive has been in/on, there is a chance the system might have tried to fix stuff, and garbage collect the deleted files…
Either way, once a copy is made, then testdisk is the tool to go with, to examine the directory tree, and un-delete stuff, in my opinion.
Hello, thank you, parallel to you typing your reply I read dd's manpage & came up w/ this:
sudo dd if=/dev/sda of=/media/chris/BACKUP/sdadisk.img status=progress
I’m pretty confident that’ll work, so will probably be running it imminently, but what’s the .map stuff you showed & is it exclusive to ddrescue? Certainly didn’t see it documented by dd.
The mapfile is just a logfile, used to resume an interrupted transfer.
If you gotta quit part way through, it can pick up where left off, saving the time of the bits done is all.
To be fair, I would give the recovery software a go on the partial copy you already have, see if it shows anything, but then, I may be a little unhinged.
Anyways, the status=progress does give some output, which is reassuring, knowing it is working as it is whirling away
Same result?
sudo dd if=/dev/sda of=/media/chris/BACKUP/sdadisk.img status=progress
[sudo] password for chris:
44888121344 bytes (45 GB, 42 GiB) copied, 797 s, 56.4 MB/s
dd: error reading '/dev/sda': Input/output error
87672112+0 records in
87672112+0 records out
44888121344 bytes (45 GB, 42 GiB) copied, 809.004 s, 55.5 MB/s