LinuxQuestions.org
Help answer threads with 0 replies.
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-09-2014, 08:16 PM   #31
cbtshare
Member
 
Registered: Jul 2009
Posts: 619

Original Poster
Rep: Reputation: 42

@rknichols
No I do not think this is the result of a deeper search , I can do one now and present the findings.

Yes, the backup is in its original location

ll backup_set_1.img
-rwxrwxrwx. 1 stain stain 60011642880 Mar 6 2013 backup_set_1.img

With regards, to using hexedit, I will try it after exhausting all other avenues, I dont think this should be challenging and primarily I'm at a loss because I backed up, didnt touch the backup and its now screwed it seems.

@Smokey

I will review the link you submitted and see if anything useful is there.

Thank you
 
Old 01-09-2014, 11:54 PM   #32
cbtshare
Member
 
Registered: Jul 2009
Posts: 619

Original Poster
Rep: Reputation: 42
Ok, so the deeper search found the following

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

The harddisk (60 GB / 55 GiB) seems too small! (< 74892 TB / 68114 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

The following partitions can't be recovered:
     Partition               Start        End    Size in sectors
>  VMFS                   505 210 41 515220845 135 42 146274313977856
   HFS                   1038  25  5 55343 143 27  872417282
   Linux SWAP 2          6907 110 12 379571 182 43 5986851728
Then I got to this screen

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   0 62    13  44 60     211616 [/boot]
 P ext3                     0   1  1    13  44 62     211616 [/boot]
 P ext3                     0  20  6    13  64  4     211616 [/boot]
 P ext3                     0  20 28    13  64 26     211616 [/boot]
 P ext3                     0  24 56    13  68 54     211616 [/boot]
 P ext3                     0  25 11    13  69  9     211616 [/boot]
 P NTFS                    13   0  1  7295 254 63  117001395
 P ext3                    13  51  5  6907 110 17  110755840
 P ext3                    13  51  7  6907 110 19  110755840
 P ext3                    16 205 22  6911   9 34  110755840
 P ext3                    16 211 28  6911  15 40  110755840
 P ext3                    16 233 50  6911  37 62  110755840
Structure: Ok.
 
Old 01-10-2014, 10:57 AM   #33
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,541

Rep: Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556
Now that is actually encouraging! Let's see if one of those ext3 partitions makes sense.
Code:
losetup -r -f --show -o $(( ((13*255+51)*63+4)*512 )) --sizelimit $((110755840*512)) /media/New Volume/backup_set_1.img
file -s -k /dev/loop0         # Should report an ext2/3/4 filesystem
e2fsck -n -f /dev/loop0       # Could have some benign inconsistencies
mount -r /dev/loop0 /mnt/tmp  # Will probably fail if the FS needs journal recovery
ls -l /mnt/tmp
I'm assuming that losetup shows "/dev/loop0" as the device it used. If it uses something else, use that in place of "/dev/loop0" in the subsequent commands. Stop, of course, if things don't look right. I've deliberately made the losetup mapping read-only and elsewhere used options that would prevent writing to the image. Change that only at risk of losing any chance at recovering your data.

You will want to unmount the filesystem (if you got that far) and run "losetup -d /dev/loop0" to delete the mapping when you are through. I wrote that losetup command line with the raw numbers so that you can see where they came from should you want to try some of the other candidates in the testdisk output. Actually, you can try to examine those filesystem candidates from within testdisk, but AFAIK you would have to run the whose deep scan again to get back to that point.

That NTFS header at CHS 13 0 1 is still very troubling. It is right where it belongs on a cylinder boundary, and defining a 40GB filesystem that goes exactly to the end of an 80GB disk. Unless that 60GB disk was at some point in its life the unwilling recipient of an image intended for an 80GB disk, there is just no way that NTFS header would be there.

And, I have no idea why testdisk does not find the same candidates on the 80GB drive loaded with that image.

Last edited by rknichols; 01-10-2014 at 10:59 AM.
 
Old 01-10-2014, 06:55 PM   #34
cbtshare
Member
 
Registered: Jul 2009
Posts: 619

Original Poster
Rep: Reputation: 42
Well when I started , I got the following error,but the loop device is created, should I continue?

Code:
[root@vpnusa ~]# losetup -r -f --show -o $(( ((13*255+51)*63+4)*512 )) --sizelimit $((110755840*512)) /media/New\ Volume/backup_set_1.img  
/dev/loop0
losetup: /media/New Volume/backup_set_1.img: warning: file does not fit into a 512-byte sector the end of the file will be ignored.
[root@vpnusa ~]# losetup -a
/dev/loop0: [0831]:31170 (/media/New Volume/backup_set_1.img), offset 108575744, sizelimit 56706990080
[root@vpnusa ~]#
and bad news:
Code:
[root@vpnusa ~]# file -s -k /dev/loop0
/dev/loop0: data

Last edited by cbtshare; 01-10-2014 at 06:57 PM.
 
Old 01-10-2014, 08:08 PM   #35
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,541

Rep: Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556
That warning from losetup is very strange. Is that file on a local disk, or is it perhaps on a network drive mounted via NFS or other network protocol? If it is a local drive, is it on a USB interface? What do "mount | grep '/media/New Volume'" and "df '/media/New Volume'" show? My guess is that something is limiting the file size to (2^32 - 1).

Scratch that. I updated to util-linux-ng-2.17.2 and there seems to be a bug with large offsets and/or size limits. I'll try to find out what it is doing.

On further examination, in util-linux-ng-2.17.2, losetup always gives that warning when a size limit is specified. It's harmless.

With that loop device set up, what does "dd if=/dev/loop0 count=10 | hexdump -C | head -20" show? Hopefully, it's not that same repeated sector that showed up in the previous hex dump.

Last edited by rknichols; 01-10-2014 at 09:33 PM.
 
Old 01-11-2014, 01:24 PM   #36
cbtshare
Member
 
Registered: Jul 2009
Posts: 619

Original Poster
Rep: Reputation: 42
It shows the following(and yes, the backup image is on a NFS drive, not sure if that impacts anything)

Code:
[root@vpnusa ~]# dd if=/dev/loop0 count=10 | hexdump -C | head -20
10+0 records in
10+0 records out
5120 bytes (5.1 kB) copied, 0.00556885 s, 919 kB/s
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  00 00 00 00 00 00 00 00  02 80 00 00 00 00 00 00  |................|
00000410  4c 45 53 00 48 43 53 41  00 61 72 5f 46 49 4c 45  |LES.HCSA.ar_FILE|
00000420  53 00 30 31 31 00 00 00  00 00 00 00 00 00 00 00  |S.011...........|
00000430  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001400
 
Old 01-11-2014, 03:55 PM   #37
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,541

Rep: Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556
NFS should not be an issue. I wasn't sure losetup would work via NFS, but I tried it later and it seemed OK. It's discouraging seeing that same 4K block that was repeated in the other hex dump. Go ahead and see if "e2fsck -n /dev/loop0" finds backup superblocks. If it does (and I presume it will report other damage as well), you could do that same losetup on the 80GB disk, but leave off the "-r" (read-only) option and let e2fsck do what repair it can. Then see what files are recoverable. Remember that fsck repairs filesystem structure, no file contents.

If e2fsck does not find backup superblocks on the image, try the experiment again with the next candidate that testdisk found.
Code:
losetup -r -f --show -o $(( ((13*255+51)*63+6)*512 )) --sizelimit $((110755840*512)) /media/New\ Volume/backup_set_1.img
 
Old 01-11-2014, 06:43 PM   #38
cbtshare
Member
 
Registered: Jul 2009
Posts: 619

Original Poster
Rep: Reputation: 42
Results are below,not sure if it helps.
Code:
[root@vpnusa ~]# losetup -a
/dev/loop0: [0831]:31170 (/media/New Volume/backup_set_1.img), offset 108575744, sizelimit 56706990080
/dev/loop1: [0831]:31170 (/media/New Volume/backup_set_1.img), offset 108576768, sizelimit 56706990080


[root@vpnusa ~]# file -s -k /dev/loop1 
/dev/loop1: data

[root@vpnusa ~]# e2fsck -n /dev/loop0
e2fsck 1.41.12 (17-May-2010)
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/loop0

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 ~]# e2fsck -n -f /dev/loop1 
e2fsck 1.41.12 (17-May-2010)
e2fsck: Superblock invalid, trying backup blocks...
Superblock has an invalid journal (inode 8).
Clear? no

e2fsck: Illegal inode number while checking ext3 journal for /dev/loop1

Last edited by cbtshare; 01-11-2014 at 06:49 PM.
 
Old 01-11-2014, 08:27 PM   #39
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,541

Rep: Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556
That's about what I was afraid you would find. /dev/loop1 appears to have the right starting location for the filesystem, but the expected superblock isn't there, and at this point I'd be willing to bet money that you would find that same 4KB block that keeps showing up elsewhere in the image. It appears that for reasons unknown you never got a good copy of the original disk.

FWIW, I think I understand the reason for that phantom NTFS filesystem that keeps showing up. I believe that testdisk is just finding the backup NTFS header at the end of the 80GB disk and calculating where that filesystem would have started. It's meaningless, since it's just leftover data that was not cleared before the 60GB image was written to the larger disk. You could test that theory by running
Code:
losetup -f --show --sizelimit 60011642880 /dev/sdd
testdisk /dev/loop0
and seeing if you get the same result as when testdisk was run on the image file.

If you want to see what files might be recoverable, you could set up that same "loop1" mapping (-o 108576768, --sizelimit 56706990080) on /dev/sdd without the read-only flag, run e2fsck with the "-y" option to do what it can to patch the filesystem back together, and then mount the loop1 device and see what files you can recover from there. Given the apparent widespread corruption of the image, I'm not optimistic that you will be able to get very much.
 
Old 01-12-2014, 06:50 PM   #40
cbtshare
Member
 
Registered: Jul 2009
Posts: 619

Original Poster
Rep: Reputation: 42
So far its taking a long time:

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

Disk /dev/loop2 - 60 GB / 55 GiB - 117210240 sectors
Analyse cylinder 52527104/117210239: 44%
Read error at 52527015/0/1 (lba=52527015)

Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
Warning: number of heads/cylinder mismatches 255 (NTFS) != 1 (HD)
Warning: number of sectors per track mismatches 63 (NTFS) != 1 (HD)
  HPFS - NTFS                   63 2930272064 2930272002 [New Volume]
check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT32 LBA             3760137091 4941948397 1181811307
  FAT32 LBA             3760137091 4941948397 1181811307
check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT16 >32M            2544836819 2678049257  133212439
  FAT16 >32M            2544836819 2678049257  133212439
check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT12                  489388293 4763653653 4274265361
  FAT12                  489388293 4763653653 4274265361
check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT32                 1723413938 1929378029  205964092
  FAT32                 1723413938 1929378029  205964092
check_FAT: can't read FAT boot sector
Invalid FAT boot sector
 0 D FAT16 >32M            3500995390 4019072230  518076841
  FAT16 >32M            3500995390 4019072230  518076841
 
Old 01-12-2014, 07:17 PM   #41
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,541

Rep: Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556
Looks like it assumes a CHS geometry of 117210240 1 1. It'll get there eventually. Probably better to just let it finish rather than start over with a manually set geometry. Totally weird, though, that it's still finding an NTFS header that references a 255 head geometry when the old 60GB disk was using 240 heads.

That I/O error at LBA 52527015 is a concern. Looks like the 80GB disk has a problem.
 
Old 01-13-2014, 12:34 PM   #42
cbtshare
Member
 
Registered: Jul 2009
Posts: 619

Original Poster
Rep: Reputation: 42
well yes, sdd is a 1 TB external hard drive as well,but I guess --sizelimit 60011642880 is limiting it.Hmm, so you suggest I use another hard drive and dump the backup image on,since you think the 80GB hard drive may have an issue?

Last edited by cbtshare; 01-13-2014 at 12:37 PM.
 
Old 01-13-2014, 04:03 PM   #43
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,541

Rep: Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556
Quote:
Originally Posted by cbtshare View Post
well yes, sdd is a 1 TB external hard drive as well,but I guess --sizelimit 60011642880 is limiting it.
Sorry about the "sdd" reference. I was just mis-remembering what drive the image was on. No, I'm not suggesting moving to another drive. In the overall context, one bad sector isn't worth worrying about.

I didn't realize that testdisk would treat the loop device that differently. It does give a warning that setting the geometry might be a good idea. Is that testdisk task still running? If so, you should probably abort it and start again, this time going into the "Geometry" settings before starting the analysis. I don't know why the run time would be affected that badly. The worst I would expect is that the initial analysis would take as much time as the "Deeper" scan.
 
Old 01-14-2014, 02:06 PM   #44
cbtshare
Member
 
Registered: Jul 2009
Posts: 619

Original Poster
Rep: Reputation: 42
Quote:
Originally Posted by rknichols View Post
Sorry about the "sdd" reference. I was just mis-remembering what drive the image was on. No, I'm not suggesting moving to another drive. In the overall context, one bad sector isn't worth worrying about.
Ahh ok, I stopped it, can you please give me the exact command you'd like me to run , I will also use the geometry settings.
 
Old 01-14-2014, 07:49 PM   #45
rknichols
Senior Member
 
Registered: Aug 2009
Distribution: CentOS
Posts: 3,541

Rep: Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556Reputation: 1556
At this point I'm not sure what I expect to get out of testdisk except perhaps the satisfaction of seeing it report the same thing from the 60GB on the disk as it did from the 60GB image.

I really see only two courses of action that are left. One is to see what e2fsck can do if allowed to do repairs to the ext3 filesystem at CHS 13 51 6. The other is to do the hexedit search to try to find the block with the /etc/lvm/backup file that describes the LVM layout. Trying the e2fsck is easiest, but it's a real stab in the dark without knowing whether the logical volume is actually in one contiguous set of LVM extents, and if that turns out not to be true then e2fsck is going to make a real mess of things. Fortunately you can always reload the disk from the image file.
Code:
losetup -f --show -o $(( ((13*255+51)*63+6)*512 )) --sizelimit $((110755840*512)) /dev/sdc
e2fsck /dev/loop2   # or whatever loop device losetup reports
Note that there is no "-r" option in that losetup command. The content of /dev/sdc is being offered up for sacrifice.

The hexedit search would be done by running "hexedit /dev/sdc" and then searching (ctrl-s starts or continues a search) for the hex string "6465736372697074696f6e203d202243726561746564202a61667465722a20657865637574696e67" that I posted earlier. That search could turn up multiple versions of the file, and you would have to pick out the most recent (the date will be present in the ASCII text) and then use dd with an appropriate offset and count to save that file and post it.
 
  


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 10:15 AM
fresh 9.10 install reboot error no device trying to mount partition mount: can't fin bud1237 Ubuntu 1 06-24-2010 12:44 AM
how mount mount ntfs partition of windows xp kashif2131971 Linux - Newbie 3 07-07-2009 06:34 PM
Fedora 11: Cannot mount partition on Seagate FreeAgent Drive's secondary partition Erik Anderson Linux - Newbie 5 06-25-2009 01:10 AM
This is how I backed up my root partition cragwolf Slackware 3 09-14-2004 06:39 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie

All times are GMT -5. The time now is 01:32 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