Recover files from previous filesystem
Accidentally, I installed a new linux distro over a 100G partition of a 250G SSD, with my previous linux. I used it (system upgrades, web browsing) for around 30 minutes before I realised what I did.
It happened around 2019-02-26 22:15:00 -> 22:40:00. I am also interested in a specific directory, my previous home (/home/user). I am not searching for a specific file but everything I can recover.
Afterwards, I dumped the partition to an image. To be sure, I did it with 2 tools: dd and ddrescue. Also, to work with one of this two images (data-recovery process), I have copied it again. The partition is unmounted.
I started with ext4magic, but with no luck. I don't know if I am wrong, but it seems it needs the filesystem where we are trying to recover files. In my case, I cannot recover the previous filesystem.
Some info:
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: ccb8bdf8-659b-4ad6-84b3-4fd918aee5e6
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6553600
Block count: 26214400
Reserved block count: 1310720
Free blocks: 23951139
Free inodes: 6317540
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Tue Feb 26 22:20:43 2019
Last mount time: Tue Feb 26 22:31:47 2019
Last write time: Tue Feb 26 22:31:47 2019
Mount count: 2
Maximum mount count: -1
Last checked: Tue Feb 26 22:20:45 2019
Check interval: 0 (<none>)
Lifetime writes: 10 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 5b295e79-85ff-4af7-bef2-e42d1c48dbf8
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0x0bb27e03
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
|-----------c_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 204037 |**************************************************| Tue Feb 26 22:29:59 2019
|-----------d_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 914 |**************************************************| Tue Feb 26 22:29:59 2019
|-----------cr_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 206292 |**************************************************| Tue Feb 26 22:29:59 2019
ext4magic : EXIT_SUCCESS
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
Using internal Journal at Inode 8
Activ Time after : Tue Feb 26 10:34:29 2019
Activ Time before : Tue Feb 26 22:30:00 2019
Error: Inode not found for "/home/user"
Check the valid PATHNAME "/home/user" and the BEFORE option "Tue Feb 26 22:30:00 2019
"
ext4magic : EXIT_SUCCESS
As you can see, it cannot find the pathname "/home/user", mainly because the current filesystem does not have a "/home/user". So, it seems it is not searching in the previous filesystem. I also tried with different datetimes around 22:30.
I am not centered in ext4magic, but I started with it. I read about other tools: extundelete, testdisk or photorec.
What would be the best approach to recover every dir/file that existed before overwritting the partition (eg. at 2019-02-26 21:00:00) under the directory /home/user? Any recommedation?
I have tried photorec a few times before, but it is a huge mess to detect and re-organise those thousands-to-millions of files because they don't preserve location/path/name. In case this is the only solution, what would you recommend to "semi-automatic re-organisation"?
data-recovery
asked Feb 27 at 10:07
user3819881user3819881
61
add a comment |
Accidentally, I installed a new linux distro over a 100G partition of a 250G SSD, with my previous linux. I used it (system upgrades, web browsing) for around 30 minutes before I realised what I did.
It happened around 2019-02-26 22:15:00 -> 22:40:00. I am also interested in a specific directory, my previous home (/home/user). I am not searching for a specific file but everything I can recover.
Afterwards, I dumped the partition to an image. To be sure, I did it with 2 tools: dd and ddrescue. Also, to work with one of this two images (data-recovery process), I have copied it again. The partition is unmounted.
I started with ext4magic, but with no luck. I don't know if I am wrong, but it seems it needs the filesystem where we are trying to recover files. In my case, I cannot recover the previous filesystem.
Some info:
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: ccb8bdf8-659b-4ad6-84b3-4fd918aee5e6
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6553600
Block count: 26214400
Reserved block count: 1310720
Free blocks: 23951139
Free inodes: 6317540
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Tue Feb 26 22:20:43 2019
Last mount time: Tue Feb 26 22:31:47 2019
Last write time: Tue Feb 26 22:31:47 2019
Mount count: 2
Maximum mount count: -1
Last checked: Tue Feb 26 22:20:45 2019
Check interval: 0 (<none>)
Lifetime writes: 10 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 5b295e79-85ff-4af7-bef2-e42d1c48dbf8
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0x0bb27e03
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
|-----------c_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 204037 |**************************************************| Tue Feb 26 22:29:59 2019
|-----------d_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 914 |**************************************************| Tue Feb 26 22:29:59 2019
|-----------cr_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 206292 |**************************************************| Tue Feb 26 22:29:59 2019
ext4magic : EXIT_SUCCESS
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
Using internal Journal at Inode 8
Activ Time after : Tue Feb 26 10:34:29 2019
Activ Time before : Tue Feb 26 22:30:00 2019
Error: Inode not found for "/home/user"
Check the valid PATHNAME "/home/user" and the BEFORE option "Tue Feb 26 22:30:00 2019
"
ext4magic : EXIT_SUCCESS
As you can see, it cannot find the pathname "/home/user", mainly because the current filesystem does not have a "/home/user". So, it seems it is not searching in the previous filesystem. I also tried with different datetimes around 22:30.
I am not centered in ext4magic, but I started with it. I read about other tools: extundelete, testdisk or photorec.
What would be the best approach to recover every dir/file that existed before overwritting the partition (eg. at 2019-02-26 21:00:00) under the directory /home/user? Any recommedation?
I have tried photorec a few times before, but it is a huge mess to detect and re-organise those thousands-to-millions of files because they don't preserve location/path/name. In case this is the only solution, what would you recommend to "semi-automatic re-organisation"?
data-recovery
asked Feb 27 at 10:07
user3819881user3819881
61
Can you confirm that photorec finds your old files at all and not just new ones? You have SSD storage andmke2fsunfortunately does discard/TRIM by default, so usually all old data is gone and there is no way to recover anything. That's unless mkfs was run with-E nodiscardor the filesystem is on top of LUKS without allow-discard or the new partition was smaller than the old filesystem...
– frostschutz
Feb 27 at 10:23
Effectively, I tried photorec using the whole ext4 image and it just found files from the new system. Panic.
– user3819881
Feb 27 at 11:12
add a comment |
Accidentally, I installed a new linux distro over a 100G partition of a 250G SSD, with my previous linux. I used it (system upgrades, web browsing) for around 30 minutes before I realised what I did.
It happened around 2019-02-26 22:15:00 -> 22:40:00. I am also interested in a specific directory, my previous home (/home/user). I am not searching for a specific file but everything I can recover.
Afterwards, I dumped the partition to an image. To be sure, I did it with 2 tools: dd and ddrescue. Also, to work with one of this two images (data-recovery process), I have copied it again. The partition is unmounted.
I started with ext4magic, but with no luck. I don't know if I am wrong, but it seems it needs the filesystem where we are trying to recover files. In my case, I cannot recover the previous filesystem.
Some info:
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: ccb8bdf8-659b-4ad6-84b3-4fd918aee5e6
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6553600
Block count: 26214400
Reserved block count: 1310720
Free blocks: 23951139
Free inodes: 6317540
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Tue Feb 26 22:20:43 2019
Last mount time: Tue Feb 26 22:31:47 2019
Last write time: Tue Feb 26 22:31:47 2019
Mount count: 2
Maximum mount count: -1
Last checked: Tue Feb 26 22:20:45 2019
Check interval: 0 (<none>)
Lifetime writes: 10 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 5b295e79-85ff-4af7-bef2-e42d1c48dbf8
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0x0bb27e03
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
|-----------c_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 204037 |**************************************************| Tue Feb 26 22:29:59 2019
|-----------d_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 914 |**************************************************| Tue Feb 26 22:29:59 2019
|-----------cr_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 206292 |**************************************************| Tue Feb 26 22:29:59 2019
ext4magic : EXIT_SUCCESS
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
Using internal Journal at Inode 8
Activ Time after : Tue Feb 26 10:34:29 2019
Activ Time before : Tue Feb 26 22:30:00 2019
Error: Inode not found for "/home/user"
Check the valid PATHNAME "/home/user" and the BEFORE option "Tue Feb 26 22:30:00 2019
"
ext4magic : EXIT_SUCCESS
As you can see, it cannot find the pathname "/home/user", mainly because the current filesystem does not have a "/home/user". So, it seems it is not searching in the previous filesystem. I also tried with different datetimes around 22:30.
I am not centered in ext4magic, but I started with it. I read about other tools: extundelete, testdisk or photorec.
What would be the best approach to recover every dir/file that existed before overwritting the partition (eg. at 2019-02-26 21:00:00) under the directory /home/user? Any recommedation?
I have tried photorec a few times before, but it is a huge mess to detect and re-organise those thousands-to-millions of files because they don't preserve location/path/name. In case this is the only solution, what would you recommend to "semi-automatic re-organisation"?
data-recovery
asked Feb 27 at 10:07
user3819881user3819881
61
Accidentally, I installed a new linux distro over a 100G partition of a 250G SSD, with my previous linux. I used it (system upgrades, web browsing) for around 30 minutes before I realised what I did.
It happened around 2019-02-26 22:15:00 -> 22:40:00. I am also interested in a specific directory, my previous home (/home/user). I am not searching for a specific file but everything I can recover.
Afterwards, I dumped the partition to an image. To be sure, I did it with 2 tools: dd and ddrescue. Also, to work with one of this two images (data-recovery process), I have copied it again. The partition is unmounted.
I started with ext4magic, but with no luck. I don't know if I am wrong, but it seems it needs the filesystem where we are trying to recover files. In my case, I cannot recover the previous filesystem.
Some info:
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: ccb8bdf8-659b-4ad6-84b3-4fd918aee5e6
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 6553600
Block count: 26214400
Reserved block count: 1310720
Free blocks: 23951139
Free inodes: 6317540
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Reserved GDT blocks: 1024
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Tue Feb 26 22:20:43 2019
Last mount time: Tue Feb 26 22:31:47 2019
Last write time: Tue Feb 26 22:31:47 2019
Mount count: 2
Maximum mount count: -1
Last checked: Tue Feb 26 22:20:45 2019
Check interval: 0 (<none>)
Lifetime writes: 10 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 5b295e79-85ff-4af7-bef2-e42d1c48dbf8
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0x0bb27e03
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
|-----------c_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 204037 |**************************************************| Tue Feb 26 22:29:59 2019
|-----------d_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 914 |**************************************************| Tue Feb 26 22:29:59 2019
|-----------cr_time Histogram----------------- after -------------------- Tue Feb 26 10:34:29 2019
1551177962 : 0 | | Tue Feb 26 11:46:02 2019
1551182255 : 0 | | Tue Feb 26 12:57:35 2019
1551186548 : 0 | | Tue Feb 26 14:09:08 2019
1551190841 : 0 | | Tue Feb 26 15:20:41 2019
1551195134 : 0 | | Tue Feb 26 16:32:14 2019
1551199427 : 0 | | Tue Feb 26 17:43:47 2019
1551203720 : 0 | | Tue Feb 26 18:55:20 2019
1551208013 : 0 | | Tue Feb 26 20:06:53 2019
1551212306 : 0 | | Tue Feb 26 21:18:26 2019
1551216599 : 206292 |**************************************************| Tue Feb 26 22:29:59 2019
ext4magic : EXIT_SUCCESS
Filesystem in use: /mnt/data/rescue.wip/ddrescue_f_n_sda4.img
Using internal Journal at Inode 8
Activ Time after : Tue Feb 26 10:34:29 2019
Activ Time before : Tue Feb 26 22:30:00 2019
Error: Inode not found for "/home/user"
Check the valid PATHNAME "/home/user" and the BEFORE option "Tue Feb 26 22:30:00 2019
"
ext4magic : EXIT_SUCCESS
As you can see, it cannot find the pathname "/home/user", mainly because the current filesystem does not have a "/home/user". So, it seems it is not searching in the previous filesystem. I also tried with different datetimes around 22:30.
I am not centered in ext4magic, but I started with it. I read about other tools: extundelete, testdisk or photorec.
What would be the best approach to recover every dir/file that existed before overwritting the partition (eg. at 2019-02-26 21:00:00) under the directory /home/user? Any recommedation?
I have tried photorec a few times before, but it is a huge mess to detect and re-organise those thousands-to-millions of files because they don't preserve location/path/name. In case this is the only solution, what would you recommend to "semi-automatic re-organisation"?
data-recovery
data-recovery
asked Feb 27 at 10:07
user3819881user3819881
61
asked Feb 27 at 10:07
user3819881user3819881
61
edited Feb 27 at 10:16
user3819881
asked Feb 27 at 10:07
user3819881user3819881
61
asked Feb 27 at 10:07
user3819881user3819881
61
asked Feb 27 at 10:07
user3819881user3819881
61
61
Can you confirm that photorec finds your old files at all and not just new ones? You have SSD storage andmke2fsunfortunately does discard/TRIM by default, so usually all old data is gone and there is no way to recover anything. That's unless mkfs was run with-E nodiscardor the filesystem is on top of LUKS without allow-discard or the new partition was smaller than the old filesystem...
– frostschutz
Feb 27 at 10:23
Effectively, I tried photorec using the whole ext4 image and it just found files from the new system. Panic.
– user3819881
Feb 27 at 11:12
add a comment |
Can you confirm that photorec finds your old files at all and not just new ones? You have SSD storage andmke2fsunfortunately does discard/TRIM by default, so usually all old data is gone and there is no way to recover anything. That's unless mkfs was run with-E nodiscardor the filesystem is on top of LUKS without allow-discard or the new partition was smaller than the old filesystem...
– frostschutz
Feb 27 at 10:23
Effectively, I tried photorec using the whole ext4 image and it just found files from the new system. Panic.
– user3819881
Feb 27 at 11:12
Can you confirm that photorec finds your old files at all and not just new ones? You have SSD storage and
mke2fs unfortunately does discard/TRIM by default, so usually all old data is gone and there is no way to recover anything. That's unless mkfs was run with -E nodiscard or the filesystem is on top of LUKS without allow-discard or the new partition was smaller than the old filesystem...– frostschutz
Feb 27 at 10:23
Can you confirm that photorec finds your old files at all and not just new ones? You have SSD storage and
mke2fs unfortunately does discard/TRIM by default, so usually all old data is gone and there is no way to recover anything. That's unless mkfs was run with -E nodiscard or the filesystem is on top of LUKS without allow-discard or the new partition was smaller than the old filesystem...– frostschutz
Feb 27 at 10:23
Effectively, I tried photorec using the whole ext4 image and it just found files from the new system. Panic.
– user3819881
Feb 27 at 11:12
Effectively, I tried photorec using the whole ext4 image and it just found files from the new system. Panic.
– user3819881
Feb 27 at 11:12
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503291%2frecover-files-from-previous-filesystem%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f503291%2frecover-files-from-previous-filesystem%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Can you confirm that photorec finds your old files at all and not just new ones? You have SSD storage and
mke2fsunfortunately does discard/TRIM by default, so usually all old data is gone and there is no way to recover anything. That's unless mkfs was run with-E nodiscardor the filesystem is on top of LUKS without allow-discard or the new partition was smaller than the old filesystem...– frostschutz
Feb 27 at 10:23
Effectively, I tried photorec using the whole ext4 image and it just found files from the new system. Panic.
– user3819881
Feb 27 at 11:12