Tag Info

New answers tagged

0

Apparently it is not possible to recover the old ext4 filesystem. I am currently recovering some files with Photorec, with mixed success. A response from the developing of UFS Explorer is as follow: The reason is ext4 on time of format destroys completely all inodes and even file system journal so volume only contains file data; usually it is ...


1

My recommendation is UFS Explorer. If that fails, you'll need professional assistance. Standard recovery rules apply... Don't write to the affected volume and try to recover to another device. Also see: How to recover XFS file system with "superblock read failed"


1

If one disk is already gone entirely, you're left with no redundancy. If another disk is failing then, you could duplicate that disk using ddrescue and then see what's left using the duplicate. At this point you have silent data corruption; with some effort you could locate the affected files, by means of having ddrescue record which areas could not be ...


2

"Rebuilding" a newly added disk to a RAID array or accessing a degraded ARRAY are signicantly close in term of stress on the disks. The difference here is more about the size of the data to read: 6 GB against just 1 GB. I would advise you to copy all you can while you can on that spare disk. The worst case scenario being that the dying disk dies before you ...


2

Copy the data from the array first. Rebuilding a full RAID 5 set will involve reading all the data anyway, as new parity data has to be calculated. If you only copy the data you need, you'll be putting less strain on the failing disk.


1

NOTE: I added this answer regarding some other question about deleted database files (MySQL server) which was closed and pointed to this one. I believe it can be useful in some other similar situations too (as far as some process still holds the file descriptors open). If your process is still runnig then you can find your files in /proc/<pid>fd/ and ...


0

Thanks Psusi This would have been far easier than what I did in the end. I used testdisk with a deep analysis to re-rediscover the underlying partition. This took a few hours as it was a 89% full 2TB drive. Once I had found the drive and its dimension (automatically by testdisk), I wrote the changes. One caveat though is to select intel as the partition ...


0

Looking at the usage guide on extundelete]1 it seems as though you're limited to undeleting files to a few ways. Restoring all extundelete is designed to undelete files from an unmounted partition to a separate (mounted) partition. extundelete will restore any files it finds to a subdirectory of the current directory named “RECOVERED_FILES”. To run the ...


2

LUKS has a distinct header, you could find possible offsets with grep: # grep -a -b --only-matching 'LUKS' /dev/sda5 1832480940:LUKS 1959072314:LUKS 2019974297:LUKS For each possible offset you find, you could create a loop device and see if it's a valid LUKS device or not: # losetup --find --show --offset 1832480940 --read-only /dev/sda5 /dev/loop3 # ...


1

I did this same thing myself the other night while debugging gparted. I used dd if=/dev/zero count=1 of=/dev/sdc to wipe out the dos partition table, then pvcreate --uuid xxxx --norestorefile to reinitialize the lvm header, and finally vcfgrestore to restore from the backup in /etc/lvm/backup, which you can also look at to find what the uuid of the drive ...


1

The process will depend on what type of files you have (image, text file, etc.) and what file system is in use. This page of the Arch Wiki has some good places to start. It specifically mentions Foremost, Extundelete, Testdisk, and PhotoRec as some programs to look at. One method mentioned that may be of interest to you is basically getting all raw text ...



Top 50 recent answers are included