LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 01-03-2014, 11:35 PM   #16
cbtshare
Member
 
Registered: Jul 2009
Posts: 610

Original Poster
Rep: Reputation: 42

ok, so here we go.After redumping the backup a disk I get :

Code:
 dd if=backup_set_1.img of=/dev/sdb
117210240+0 records in
117210240+0 records out
60011642880 bytes (60 GB) copied, 4595.2 s, 13.1 MB/s
Code:
Disk /dev/sdc: 80.0 GB, 80000000000 bytes
240 heads, 63 sectors/track, 10333 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x48d97f5e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1          14      105808+  83  Linux
/dev/sdc2              15        7752    58499280   8e  Linux LVM
Code:
# hexdump -C /dev/sdc2 | head -20
00000000  00 00 00 00 00 00 00 00  02 80 00 00 00 00 00 00  |................|
00000010  4c 45 53 00 48 43 53 41  00 61 72 5f 46 49 4c 45  |LES.HCSA.ar_FILE|
00000020  53 00 30 31 31 00 00 00  00 00 00 00 00 00 00 00  |S.011...........|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  00 00 00 00 00 00 00 00  02 80 00 00 00 00 00 00  |................|
00001010  4c 45 53 00 48 43 53 41  00 61 72 5f 46 49 4c 45  |LES.HCSA.ar_FILE|
00001020  53 00 30 31 31 00 00 00  00 00 00 00 00 00 00 00  |S.011...........|
00001030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00002000  00 00 00 00 00 00 00 00  02 80 00 00 00 00 00 00  |................|
00002010  4c 45 53 00 48 43 53 41  00 61 72 5f 46 49 4c 45  |LES.HCSA.ar_FILE|
00002020  53 00 30 31 31 00 00 00  00 00 00 00 00 00 00 00  |S.011...........|
00002030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00003000  00 00 00 00 00 00 00 00  02 80 00 00 00 00 00 00  |................|
00003010  4c 45 53 00 48 43 53 41  00 61 72 5f 46 49 4c 45  |LES.HCSA.ar_FILE|
00003020  53 00 30 31 31 00 00 00  00 00 00 00 00 00 00 00  |S.011...........|
00003030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
When I did file-s /dev/sdc1 and dev/sdc2, it show it as only "data"
file -s /dev/sdc1
/dev/sdc1: data

file -s /dev/sdc2
/dev/sdc2: data

then I ran fsck on it
Code:
 fsck -y -f /dev/sdc1
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext2: Superblock invalid, trying backup blocks...
Adding dirhash hint to filesystem.

Pass 1: Checking inodes, blocks, and sizes
Inode 2, i_blocks is 8, should be 6.  Fix? yes

Inode 12, i_blocks is 162, should be 160.  Fix? yes

Inode 4084, i_blocks is 2, should be 0.  Fix? yes

Inode 4081, i_blocks is 4, should be 2.  Fix? yes

Inode 4085, i_blocks is 4, should be 2.  Fix? yes

Inode 4086, i_blocks is 4, should be 2.  Fix? yes

Inode 4088, i_blocks is 18, should be 16.  Fix? yes

Inode 4089, i_blocks is 18, should be 16.  Fix? yes

Inode 4090, i_blocks is 16, should be 14.  Fix? yes

Inode 4091, i_blocks is 16, should be 14.  Fix? yes

Inode 4092, i_blocks is 18, should be 16.  Fix? yes

Inode 4093, i_blocks is 16, should be 14.  Fix? yes

Inode 4094, i_blocks is 22, should be 20.  Fix? yes

Inode 4095, i_blocks is 16, should be 14.  Fix? yes

Inode 4096, i_blocks is 16, should be 14.  Fix? yes

Inode 4097, i_blocks is 20, should be 18.  Fix? yes

Inode 4082, i_blocks is 114, should be 112.  Fix? yes

Inode 4087, i_blocks is 210, should be 208.  Fix? yes

Pass 2: Checking directory structure
i_file_acl for inode 2 (/) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4081 (/grub) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4082 (/grub/splash.xpm.gz) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4084 (/grub/menu.lst) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4085 (/grub/device.map) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4086 (/grub/stage1) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4087 (/grub/stage2) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4088 (/grub/e2fs_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4089 (/grub/fat_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4090 (/grub/ffs_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4091 (/grub/iso9660_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4092 (/grub/jfs_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4093 (/grub/minix_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4094 (/grub/reiserfs_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4095 (/grub/ufs2_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4096 (/grub/vstafs_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 4097 (/grub/xfs_stage1_5) is 4644, should be zero.
Clear? yes

i_file_acl for inode 12 (/message) is 4644, should be zero.
Clear? yes

Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -4644
Fix? yes

Free blocks count wrong for group #0 (3549, counted=1).
Fix? yes

Free blocks count wrong for group #1 (7677, counted=7140).
Fix? yes

Free blocks count wrong for group #2 (7935, counted=7690).
Fix? yes

Free blocks count wrong for group #3 (7677, counted=2048).
Fix? yes

Free blocks count wrong for group #4 (7935, counted=0).
Fix? yes

Free blocks count wrong for group #5 (7677, counted=4844).
Fix? yes

Free blocks count wrong for group #6 (7935, counted=0).
Fix? yes

Free blocks count wrong for group #7 (7677, counted=4052).
Fix? yes

Free blocks count wrong (96790, counted=64503).
Fix? yes

Free inodes count wrong for group #0 (2029, counted=2021).
Fix? yes

Free inodes count wrong for group #2 (2040, counted=2023).
Fix? yes

Directories count wrong for group #2 (0, counted=1).
Fix? yes

Free inodes count wrong for group #3 (2040, counted=2021).
Fix? yes

Free inodes count wrong for group #5 (2040, counted=2036).
Fix? yes

Free inodes count wrong (26509, counted=26461).
Fix? yes


/boot: ***** FILE SYSTEM WAS MODIFIED *****
/boot: 59/26520 files (25.4% non-contiguous), 41305/105808 blocks
and now it shows
file -s /dev/sdc1
/dev/sdc1: Linux rev 1.0 ext3 filesystem data

but /dev/sdc2 still show any filesystem

Code:
# fsck -y -f /dev/sdc2
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdc2

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

[root@vpnusa ~]# file -s /dev/sdc2
/dev/sdc2: data
[root@vpnusa ~]
havent tried anything else , wanted to get input first.
 
Old 01-04-2014, 10:53 AM   #17
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 2,959

Rep: Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268
I trust that the "of=/dev/sdb" vs. subsequent examination of "/dev/sdc" is due to the drives being rearranged between those events.

I would have liked to see what the start of partition 1 looked like before fsck made changes, some of which were not the sort of errors one would expect to find on an image made while a filesystem was mounted. That repeated sector in the hex dump is also troubling. But, let's see what testdisk can find now. Again, it would probably be best to turn off the "Align partition" option.
 
Old 01-04-2014, 06:06 PM   #18
cbtshare
Member
 
Registered: Jul 2009
Posts: 610

Original Poster
Rep: Reputation: 42
YES,after the dd command, the name was changed.Ok, I will run testdisk on the drive again.
 
Old 01-05-2014, 08:49 PM   #19
cbtshare
Member
 
Registered: Jul 2009
Posts: 610

Original Poster
Rep: Reputation: 42
Test is still saying :

Code:
Disk /dev/sdb: 80.0 GB, 80000000000 bytes
240 heads, 63 sectors/track, 10333 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x48d97f5e

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          14      105808+  83  Linux
/dev/sdb2              15        7752    58499280   8e  Linux LVM
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63

The harddisk (80 GB / 74 GiB) seems too small! (< 119 GB / 111 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partition can't be recovered:
     Partition               Start        End    Size in sectors
>  HPFS - NTFS           9724 254 63 14587 254 62   78124095
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63

The harddisk (80 GB / 74 GiB) seems too small! (< 143 GB / 133 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partitions can't be recovered:
     Partition               Start        End    Size in sectors
>  HPFS - NTFS           9724 254 63 14587 254 62   78124095
   HPFS - NTFS           9725 254 63 17489 254 62  124728660
I'm lost as to what to do next, **sighs

Last edited by cbtshare; 01-05-2014 at 10:17 PM.
 
Old 01-05-2014, 10:38 PM   #20
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 2,959

Rep: Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268
At least that's consistent with your 60GB image on an 80GB disk. Those NTFS boot sectors that were found in cylinders 9724 and 9725 are just leftover junk at the end of the 80GB disk, well beyond the 60GB that was restored.

But, is that all that testdisk found? Did it not even report the current partitioning? Is sdc1 still in its post-fsck fixed-up state, or did you perhaps run the restore again? If the corrected superblock is there, I do not understand why testdisk did not see it. Did you go into the "Options" menu and turn off the "Align partitions" option?

It is really frustrating having to guess at what might have gone on to result in a given report. It is very unusual for testdisk not to pick up remnants of something, even if those detections turn out to be false hits. Even if the LVM header is totally destroyed, there should still be filesystems in there, and testdisk should still find those headers even if the rest of the filesystem is fragmented in the LVM structure.
 
Old 01-06-2014, 01:14 PM   #21
cbtshare
Member
 
Registered: Jul 2009
Posts: 610

Original Poster
Rep: Reputation: 42
Quote:
Originally Posted by rknichols View Post
go into the "Options" menu and turn off the "Align partitions" option?
No I did not, I will do as you suggest and then report again.Also, this is after post fsck, I did not run it again, after I ran it once, (dev/sd1)the disk was able to be mounted./dev/sdc2 is the issue.
Sorry if I asked this already, but I still dont understand why if its an LVM created partition, why is testdisk showing it as NTFS?
 
Old 01-07-2014, 02:52 PM   #22
cbtshare
Member
 
Registered: Jul 2009
Posts: 610

Original Poster
Rep: Reputation: 42
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

 1 * Linux                    0   1  1    13  44 63     211617 [/boot]

Bad sector count.
No LVM or LVM2 structure
 2 P Linux LVM               13  45  1  7295 254 63  116998560
 2 P Linux LVM               13  45  1  7295 254 63  116998560

Bad relative sector.

Then it does a search and then cant find anything

Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63

The harddisk (80 GB / 74 GiB) seems too small! (< 119 GB / 111 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partition can't be recovered:
     Partition               Start        End    Size in sectors
>  HPFS - NTFS           9724 254 63 14587 254 62   78124095










[ Continue ]
NTFS, blocksize=4096, 39 GB / 37 GiB
Then I am brought to this screen after clicking continue for it to do a deeper search
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
     Partition               Start        End    Size in sectors
>* Linux                    0   1  1    13  44 62     211616 [/boot]
   Linux                   20  68 49  6914 127 61  110755840
   HPFS - NTFS           4862   0  1  9724 254 63   78124095
   Linux                 7836   1  1  7836  66  1	4096
   Linux LVM             9142   1  1  9534 254 63    6313482
 P FAT12                 9725   0  1  9725 254 63      16065 [DOSBOOT]





















Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
ext3 blocksize=1024 Sparse superblock, 108 MB / 103 MiB
I selected the NTFS partition and it searched and found nothing.So I go to this screen
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63

The harddisk (80 GB / 74 GiB) seems too small! (< 143 GB / 133 GiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partitions can't be recovered:
     Partition               Start        End    Size in sectors
>  HPFS - NTFS           9724 254 63 14587 254 62   78124095
   HPFS - NTFS           9725 254 63 17489 254 62  124728660
then I go back here
Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
     Partition               Start        End    Size in sectors
>  Linux                    0   1  1    13  44 62     211616 [/boot]
   HPFS - NTFS             13   0  1  7295 254 63  117001395
   Linux                   20  68 49  6914 127 61  110755840
   Linux                   22 143 58  6916 203  7  110755840
   Linux                   28 206 51  6923  10 63  110755840
   HPFS - NTFS           1962   0  1  9725 254 63  124728660
   HPFS - NTFS           4862   0  1  9724 254 63   78124095
   Linux                 7836   1  1  7836  66  1	4096
   Linux LVM             9142   1  1  9534 254 63    6313482
   FAT12                 9725   0  1  9725 254 63      16065 [DOSBOOT]

















Structure: Ok.  Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted
Keys A: add partition, L: load backup, T: change type, P: list files,
     Enter: to continue
ext3 blocksize=1024 Sparse superblock, 108 MB / 103 MiB
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted >[Quick Search] [ Backup ]
Any ideas how I can get back my data, mounting the img file didnt work and this is my last hope.

Last edited by cbtshare; 01-07-2014 at 02:55 PM.
 
Old 01-08-2014, 12:02 AM   #23
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 2,959

Rep: Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268
Quote:
Originally Posted by cbtshare View Post
I still dont understand why if its an LVM created partition, why is testdisk showing it as NTFS?
testdisk is just reading through the drive sector by sector looking for anything that might be the start of some data structure that it understands. When it sees a sector that it can identify as an NTFS boot sector, it will report a possible NTFS partition starting at that location. If you took the beginning of an NTFS partition and copied those blocks into a file in a Linux filesystem, testdisk would dutifully report that those blocks might be the start of an NTFS partition.

Quote:
Originally Posted by cbtshare View Post
Then I am brought to this screen after clicking continue for it to do a deeper search

Code:
TestDisk 7.0-WIP, Data Recovery Utility, October 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /dev/sdb - 80 GB / 74 GiB - CHS 9726 255 63
     Partition               Start        End    Size in sectors
>* Linux                    0   1  1    13  44 62     211616 [/boot]
   Linux                   20  68 49  6914 127 61  110755840
   HPFS - NTFS           4862   0  1  9724 254 63   78124095
   Linux                 7836   1  1  7836  66  1	4096
   Linux LVM             9142   1  1  9534 254 63    6313482
 P FAT12                 9725   0  1  9725 254 63      16065 [DOSBOOT]
Something here makes absolutely no sense. What are the chances that a 60GB disk would have an NTFS boot sector located at exactly the right spot such that the 40GB filesystem it defines would extend right to the end of an 80GB disk? Is that really what is in that 60GB image file? Also, a previous run of testdisk found the corresponding NTFS backup header in its expected location at the end of the 80GB disk. This is starting to look like at least part of the 80GB disk got copied to the image file instead of the other way around.

Note: You can disregard the last 3 entries in that list. The 60GB image (60011642880 bytes) extends only to CHS 7295 255 63. Anything beyond that is just whatever was on the 80GB disk before you copied the image to it.

Try this: Run testdisk on the image file itself. I strongly suggest running testdisk as a non-privileged user who has read-only access to the file. In testdisk, the partition table type will default to "None", and you should leave it that way.

BTW, you realize that you are running a Beta version of testdisk, right? ("WIP" = "Work In Progress"). Version 7.0 is identified as "Beta" on the testdisk download site.
 
Old 01-08-2014, 11:55 PM   #24
cbtshare
Member
 
Registered: Jul 2009
Posts: 610

Original Poster
Rep: Reputation: 42
Ok,thank you.... Can you please give a example how youd want me to run testdisk on the backup img.? i am guessing the instruction about the partition type is for when running against the backup img file ,because on the hard disk i always chose 'intel'.
 
Old 01-09-2014, 10:52 AM   #25
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 2,959

Rep: Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268
Quote:
Originally Posted by cbtshare View Post
Can you please give a example how youd want me to run testdisk on the backup img.? i am guessing the instruction about the partition type is for when running against the backup img file
From a text command window, just run testdisk with the file name as an argument. You just need read permission on the file and don't have to have root privileges:
Code:
testdisk /path/to/backup_set_1.img
Yes, leaving the partition table type as "None" is for use with the image file. Actually, you can set it to "None" when using testdisk on a whole disk as well. That setting would just keep testdisk from trying to parse any existing partition table. It also blocks testdisk from trying to write a new partition table.
 
Old 01-09-2014, 03:45 PM   #26
cbtshare
Member
 
Registered: Jul 2009
Posts: 610

Original Poster
Rep: Reputation: 42
I did as you suggested, the results are below.

Code:
TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

  TestDisk is free software, and
comes with ABSOLUTELY NO WARRANTY.

Select a media (use Arrow keys, then press Enter):
>Disk /media/New Volume/backup_set_1.img - 60 GB / 55 GiB









>[Proceed ]  [  Quit  ]
Code:
TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /media/New Volume/backup_set_1.img - 60 GB / 55 GiB - CHS 7296 255 63
     Partition               Start        End    Size in sectors
>P ext3                     0  20  6    13  64  4     211616 [/boot]
 P NTFS                    13   0  1  7295 254 63  117001395
 P ext3                    16 205 22  6911   9 34  110755840









Structure: Ok.
 
Old 01-09-2014, 06:03 PM   #27
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 2,959

Rep: Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268
Quote:
Originally Posted by cbtshare View Post
Code:
TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org

Disk /media/New Volume/backup_set_1.img - 60 GB / 55 GiB - CHS 7296 255 63
     Partition               Start        End    Size in sectors
>P ext3                     0  20  6    13  64  4     211616 [/boot]
 P NTFS                    13   0  1  7295 254 63  117001395
 P ext3                    16 205 22  6911   9 34  110755840
Is that the result from the "Deeper Search"? I find it strange and disturbing that testdisk is finding that same NTFS header but at a different location than where it shows up on the 80GB disk. In fact, none of the entries match what was found on the disk despite reporting the same 255 head 63 sector geometry for both. Frankly, I'm no fan of testdisk, with its horrible UI and frequently incomprehensible behavior. I just don't know of any other tool that comes close to doing the same job.

Is this backup_set_1.img file still in the original location where you created it (i.e., this is not a copy of the original)? If so, what is the output from "ls -l backup_set_1.img"? Does the timestamp agree with when you originally created it?

Frankly, I'm somewhat at a loss for ways to proceed in the face of these inconsistent results. I suppose my next step would be to run hexedit (another program with a UI that caters only to those who use it regularly) and try to find the blocks containing the files that were in /etc/lvm/backups, then give that data to vgcfgrestore to try to rebuild the LVM structure. If you want to try that, the string I would search for is
Code:
description = "Created *after* executing
which, in the hex digits that hexedit needs, would be
Code:
6465736372697074696f6e203d202243726561746564202a61667465722a20657865637574696e67
I don't know what else to suggest.
 
Old 01-09-2014, 06:20 PM   #28
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
Do you have parted? .. If you have parted installed, could you please run it on the image.. The ideea after this is to try and mount a partition from your image..

See this article: http://www.andremiller.net/content/m...ns-using-linux

Or print the result of parted and I'll try to guide you

LE: Sorry, I forgot to mention what I want from parted..

After running it on the image type the following at the parted command prompt:
Code:
unit
and when asked about it type B (UpperCased)

then simply type
Code:
print
This is the part that is of interest for us...

Last edited by Smokey_justme; 01-09-2014 at 06:26 PM.
 
Old 01-09-2014, 07:33 PM   #29
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 2,959

Rep: Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268Reputation: 1268
@Smokey_justme: You'll find quite a bit of that work back in the original thread. If you can spot something that was overlooked there, I'm sure your efforts will be appreciated.
 
Old 01-09-2014, 07:41 PM   #30
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 534

Rep: Reputation: 203Reputation: 203Reputation: 203
Ahh, did not saw that.. I was quite wondering how none of you think of this earlier.. I'll take a look and if I see something or have some ideea, I'll get back to you.. Sorry for the interruption...
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] How do I SSH into an Encrypted partition? I have backed up all of my files on it theif519 Linux - Newbie 3 07-05-2011 11:15 AM
fresh 9.10 install reboot error no device trying to mount partition mount: can't fin bud1237 Ubuntu 1 06-24-2010 01:44 AM
how mount mount ntfs partition of windows xp kashif2131971 Linux - Newbie 3 07-07-2009 07:34 PM
Fedora 11: Cannot mount partition on Seagate FreeAgent Drive's secondary partition Erik Anderson Linux - Newbie 5 06-25-2009 02:10 AM
This is how I backed up my root partition cragwolf Slackware 3 09-14-2004 07:39 PM


All times are GMT -5. The time now is 08:18 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration