Looking for help recovering an rm'd directory

Full disclosure, I was rushing and ended up deleting something I shouldn’t have. 100% My fault, i’m here to humbly ask if there’s any way to undo my idiocy.

Original directories
/home/valheim/.config/unity3d/IronGate/Valheim
/opt/valheim

Order of operations

  1. cp /opt/valheim /opt/valheim-bak
  2. mkdir /opt/valheim/savedir
  3. mv /home/valheim/.config/unity3d/IronGate/Valheim/* /opt/valheim/savedir/ (my fault I didn’t cp)
  4. Things happened went to restore bakcup
  5. rm -rf /opt/valheim
  6. cp /opt/valheim-bak /opt/valheim

and it’s at this point I realized I was screwed because my world was gone and I realized that I didn’t make savedir part of the backup.

so now I’ve got /opt/valheim that doesn’t have the /opt/valheim/savedir directory inside it, and that’s what I’m trying to recover.

Environment:
OS: Ubuntu Server LTS 20.04
Drive format: ext4
I’ve already unmounted the drive, and mounted it as read-only within a Ubuntu Live-boot session, as well as another drive for r/w recovery purposes. I’ve tried running extundelete, ext4magic, & photorec, but none of them are coming up with any recovered files under /opt/valheim/savedir.

Is there any hope of recovery or did I just perform ragnarok on my data?

Sorry, it’s (most likely) gone man.

Linux does what you tell it to do.

On step 5 you can’t rm a non-empty directory so did you do -rf as well?

that’s what I like about Linux, unfortunately I shot myself in the foot.

I updated the original steps for the omitted typo, yes, it was an rm -rf.

I sohuld not that ext4magic & photorec did find several things to recover, and some of them got dumped into generic filenames vs the original, I just can’t find anything under the specific path I was looking for.

Depending on the total diskspace in your /opt partition, you might get away with using http://extundelete.sourceforge.net/
ext4 always allocated new blocks on previously not used blocks if possible - this makes undeleting possible. (also makes ext4 a horrible bad filesystem for thin-provisioned filesystems… but, that’s besides the point)

You’ll need to use this tool from a rescue USB or similar, as extundelete requires the partition to be unmounted.

I would assume a rescue disto like this will have the required tools: https://www.system-rescue.org/

EDIT: Ohh, and what-ever you do… DO NOT place more files in /opt right now, as it might override your old files :wink:

2 Likes

you could give testdisk a shot. It has been a while since I have had to do a recovery so I am a little rusty on the processes.

As long as no data has overwritten the sectors where your data was you should be able to recovery the data out of those sectors.

A quick google search on using testdisk on linux found this article … https://www.howtogeek.com/700310/how-to-recover-deleted-files-on-linux-with-testdisk/

hope it helps.

2 Likes

thanks, I unmounted r/w and remounted as r/o as soon as I realized what I did, I’ll give that link a shot, thanks for the heads up.

thanks for the heads up, I hadn’t come across that utility so I’ll give that a shot as well.

that’s my concern. before I unmounted, that step 6 has me worried that I overwrite the data, even though there was plenty of free space on drive. My distant hope is that when it did the copy, it used new sectors to store the data, and didn’t overwrite the old sectors, I just need a way to get to those old sectors. (phrasing, not 100% sure on sector terminology)

TestDisk is a great suggestion. If that doesn’t work, there’s a few others you can try, but as long as you don’t write to that disk, there’s a very strong likelihood you can recover your data.

I would pull the drive, make an exact copy of it, then keep your original disk powered off somewhere safe until you can recover the data and make a backup IMMEDIATELY. Having 1 copy of your data is the same as having none. Drives fail. Good luck in your recovery, sir!

2 Likes

It was a totally different use case, an SD card that went bad for unkmown reasons and demanded it be formatted before it could be used in any way, but a quick format to make it actually mountable and PhotoRec got just about everything back from it, a lot more than I was expecting.

Worth a shot, it has a Linux version, I could not get it to work there as I am not a regular Linux used for more then a decade but the windows version worked perfectly.

Testdisk has saved me a few times, and it is a nice tool to have in your back pocket. I would also follow @harrypnyce advice and make a back up of your drive. So you can perform all the recovery on the copy and not risk the Original.

Just be careful with those DDs.

1 Like

so attempting to run TestDisk via the guide linked, and when I attempt to list files following the guide linked, i’m getting a "Support for this filesystem wasn’t enabled during compilation.
The drive is a linux LVM drive (default options with Ubuntu LTS Server). root@ubuntu-server:/mnt/new-drive/testdisk# pvdisplay --- Physical volume --- - Pastebin.com *display output

I’m doing some research now, but any quick answers to getting testdisk to properly read the partition on /dev/sda? photorec didn’t have an issue, so I know it’s something I’m doing/not doing or option I’m selecting within testdisk.

What partition are you attempting to scan? Difficult for us to know what options you’ve followed. Hopefully your file system isn’t damaged (or encrypted). What partition are you trying to scan, /dev/sda2 ?

sorry, info would have helped.

Disk /dev/sda: 500 GiB, 536870912000 bytes, 1048576000 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 08028048-C028-4793-9CB7-9670BE10C2D8

Device       Start        End    Sectors  Size Type
/dev/sda1     2048       4095       2048    1M BIOS boot
/dev/sda2     4096    2101247    2097152    1G Linux filesystem
/dev/sda3  2101248 1048573951 1046472704  499G Linux filesystem


Disk /dev/sdb: 500 GiB, 536870912000 bytes, 1048576000 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3EF443DB-025B-4ECE-AEBF-6E61D87187E0

Device     Start       End   Sectors   Size Type
/dev/sdb1   2048 976562175 976560128 465.7G Linux filesystem


Disk /dev/sdc: 500 GiB, 536870912000 bytes, 1048576000 sectors
Disk model: Virtual disk
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 08028048-C028-4793-9CB7-9670BE10C2D8

Device       Start        End    Sectors  Size Type
/dev/sdc1     2048       4095       2048    1M BIOS boot
/dev/sdc2     4096    2101247    2097152    1G Linux filesystem
/dev/sdc3  2101248 1048573951 1046472704  499G Linux filesystem
root@ubuntu-server:~# pvdisplay
  WARNING: Not using device /dev/sdc3 for PV 0yQ7Vy-1CYb-PyVC-O8yr-xCQZ-8mxK-vFcVfz.
  WARNING: PV 0yQ7Vy-1CYb-PyVC-O8yr-xCQZ-8mxK-vFcVfz prefers device /dev/sda3 because device name matches previous.
  --- Physical volume ---
  PV Name               /dev/sda3
  VG Name               ubuntu-vg
  PV Size               <499.00 GiB / not usable 0
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              127743
  Free PE               76543
  Allocated PE          51200
  PV UUID               0yQ7Vy-1CYb-PyVC-O8yr-xCQZ-8mxK-vFcVfz

root@ubuntu-server:~# vgdisplay
  WARNING: Not using device /dev/sdc3 for PV 0yQ7Vy-1CYb-PyVC-O8yr-xCQZ-8mxK-vFcVfz.
  WARNING: PV 0yQ7Vy-1CYb-PyVC-O8yr-xCQZ-8mxK-vFcVfz prefers device /dev/sda3 because device name matches previous.
  --- Volume group ---
  VG Name               ubuntu-vg
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               <499.00 GiB
  PE Size               4.00 MiB
  Total PE              127743
  Alloc PE / Size       51200 / 200.00 GiB
  Free  PE / Size       76543 / <299.00 GiB
  VG UUID               eDMQDs-qD2R-X1kv-caVi-ZxLY-ZhE3-3U8dik

root@ubuntu-server:~# lvdisplay
  WARNING: Not using device /dev/sdc3 for PV 0yQ7Vy-1CYb-PyVC-O8yr-xCQZ-8mxK-vFcVfz.
  WARNING: PV 0yQ7Vy-1CYb-PyVC-O8yr-xCQZ-8mxK-vFcVfz prefers device /dev/sda3 because device name matches previous.
  --- Logical volume ---
  LV Path                /dev/ubuntu-vg/ubuntu-lv
  LV Name                ubuntu-lv
  VG Name                ubuntu-vg
  LV UUID                eNqLRN-oiML-k30M-mSQp-AQpS-R1Pp-q741Pb
  LV Write Access        read/write
  LV Creation host, time ubuntu-server, 2021-02-15 21:06:08 +0000
  LV Status              NOT available
  LV Size                200.00 GiB
  Current LE             51200
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto

of note, the drive I’m working with is /dev/sdc. /dev/sda is the original, /dev/sdc is the dd copy of /dev/sda, and /dev/sdb is a misc r/w drive i’m using to mess with while I recover data from /dev/sdc

Could you post output and options you selected from Testdisk?

wanted to post an update.

so apparently testdisk doesn’t work with ext4 or LVM filesytems. photorec was able to read the filesystem, but then came the part of having to figure out which recovered files were the ones I was looking for. Through some help on another subreddit, they were able to give me a hex file signature that I was able to add a custom signature for photorec to look for. After letting photorec scan the drive with the new targeted signatures, it was able to find the necessary files and restore my data. Backups are now in place!

Thank you to the people here pointing me towards testdisk & photrec as those definitely helped the recovery process.

2 Likes