Hi, Need help on data recovery. Suddenly my disk device's geometry has been changed to something that doesnot make any sense. Its a 1.8TB in size and had only one single partition. Now I can see 3 partitions sde1, sde2 and sde2 of sizes 130M, 140GB and 10GB. Is there any way to recover data from these newly created disk devices? Thanks Paras.
On Thu, 22 Sep 2011, Paras pradhan wrote:> To: CentOS mailing list <centos at centos.org> > From: Paras pradhan <pradhanparas at gmail.com> > Subject: [CentOS] data recovery > > Hi, > > Need help on data recovery. > > Suddenly my disk device's geometry has been changed to > something that does not make any sense. Its a 1.8TB in > size and had only one single > partition. Now I can see 3 > partitions sde1, sde2 and sde2 of sizes 130M, 140GB and > 10GB. > > Is there any way to recover data from these newly created > disk devices?Hi Paras. AFAIK disks don't get partitioned out of the blue. They need some sort of intervention to make this happen. What have you done just before this happened? Did you try to do an installation of Linux, or something else? Also, is it possible for a trojan program to do this to your HDD? Kind Regards, Keith Roberts ----------------------------------------------------------------- Websites: http://www.karsites.net http://www.php-debuggers.net http://www.raised-from-the-dead.org.uk All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
On 09/22/11 3:48 PM, Paras pradhan wrote:> Hi, > > Need help on data recovery. > > Suddenly my disk device's geometry has been changed to something that > doesnot make any sense. Its a 1.8TB in size and had only one single > partition. Now I can see 3 partitions sde1, sde2 and sde2 of sizes > 130M, 140GB and 10GB. > > Is there any way to recover data from these newly created disk devices? >Can you share the output of ... fdisk -l /dev/sde be interesting to see just what these partitions look like in terms of the disk layout. those sizes sort of correlate with a typical /boot / and swap partition -- john r pierce N 37, W 122 santa cruz ca mid-left coast
On Thursday, September 22, 2011 06:48:07 PM Paras pradhan wrote:> Suddenly my disk device's geometry has been changed to something that > doesnot make any sense. Its a 1.8TB in size and had only one single > partition. Now I can see 3 partitions sde1, sde2 and sde2 of sizes > 130M, 140GB and 10GB. > > Is there any way to recover data from these newly created disk devices?Perhaps. It depends totally on how much has been written to these devices. If anything has been written, you have a problem. If nothing has been written, first back up the partition table, then use fdisk to re-partition with a single partition using exactly the same start and end sectors as you had before. You will have to find out what the original first sector of the original partition was; this will depend upon a number of factors, such as which version of CentOS we're talking about. CentOS 3, 4, and 5 will probably default to a starting sector of 63; CentOS 6 defaults to a starting sector of 2048. In CentOS 5 and prior you will have to run fdisk with the -u option to set the actual starting sector, as opposed to the starting cylinder; in CentOS 6 fdisk already is set that way, and -u does something different. There are some recovery tools out there such as testdisk and photorec that don't use the filesystem to do recovery, but look for the raw data instead. There are some other forensic tools, available on specialized distributions like CAINE, Backtrack, and NST, that can help you grab usable data off the drive. But it will not be easy, and will take a long time, especially with that large of a drive. Best thing there is to make an image of the drive and work with it instead of the original drive, though. Once you have the partition table restored to the way it was, you'll probably have to locate a superblock copy somewhere on the drive. I say 'somewhere' simply because the exact locations of the backup copies vary with the size of the device and the block size used in making the filesystem (for ext2,3,and4 filesystems; if it was a different filesystem you'll have to use that filesystem's tools and techniques). But you might get really lucky if absolutely nothing has been written to those three partitions; if you get the start sector correct and absolutely nothing has written to any area of the disk except the partition table your filesystem may be in readable shape. And I mean readable; only attempt read-only mounting of such a filesystem. It's usually a good thing to keep a backup of the partition table and bootloader areas (typically the whole first cylinder-equivalent, up to the start of the first partition) for just such an emergency. As to how this might have happened, a miskeyed 'dd' or 'fdisk' by someone can easily do this. Making a new filesystem on the raw device instead of the partition can do that, too. Look in .bash_history (assuming bash) and any audit logs you might have to anything dealing with that device.
On Friday, September 23, 2011 03:25:10 PM Paras pradhan wrote:> Here is o/p John > > Number Start End Size File system Name > Flags > 1 17.4kB 134MB 134MB Microsoft reserved > partition msftres > 2 135MB 134GB 134GB ntfs Basic data partition > 3 134GB 1100GB 965GB Basic data partitionUh, that's GPT. What version of fdisk did you use to generate that output?
On Friday, September 23, 2011 03:59:17 PM Keith Roberts wrote:> If it's a production box in service, and this has > happened to it, How can it still be running?It's not the boot or root drive.
On Friday, September 23, 2011 03:44:58 PM Paras pradhan wrote:> Thanks for your detailed suggestion. Yes thats a GPT .. the o/p is from parted.Is this a removable or some sort, like USB, firewire, eSATA, hot-plug SCSI, Fibre-channel, or SAS? Could it have been taken out to another machine at any time? What kind of interfaces have sda, sdb, sdc, and sdd attached, and what kind of interface is attached to sde?
Two weeks ago I've been in similar situation on an 80 gig sata drive. Found it with 8 partition; boot was there but nothing of the operating system to load Linux 5.6 My recovery solution was to put the disk on a window system as a secondary drive. Just connected to read data For reading I found a software called ' nucleus kernel linux' from http://www.nucleustechnologies.com/Linux-Data-Recovery-Software.html On partition 3 I found nearly all my data files and their directories but were missiing /etc /bin /dev .... Hope this help. --- Michel Donais
On Friday, September 23, 2011 04:29:39 PM Paras pradhan wrote:> This is a SAN drive mounted. I have checked with my storage > administrator if this has been re mapped or any similar events and he > verified that nothing has happened...(I trust him)May I ask what sort of SAN? Fibre Channel or iSCSI? Are there any access controls (such as EMC's Access Logix or zoning in the switch) in place to prevent multiple initiators connecting to a particular LUN? SAN attachment mildly complicates things; I've seen some odd LUN reshuffling before, but it was an older FLARE than what I'm currently running on our Clariions and it was something that was a corner case but was fixed in a later NDU, and it had to do with Access Logix (I don't remember the Primus number right off, as it has been several years now). If the SAN OS keeps event logs you could try to correlate with the event; beyond that you may just have to do some testing. As you say, someone somewhere had to do a repartition; the hard part is determining where the error is. Good luck.
On Monday, September 26, 2011 06:41:16 PM Ross Walker wrote:> Might it be possible you ran KVM on the host and accidentally set the guest disk to /dev/sda?/dev/sde is the OP's LUN device.
On Monday, September 26, 2011 11:18:06 AM Paras pradhan wrote:> On Mon, Sep 26, 2011 at 5:53 AM, Lamar Owen <lowen at pari.edu> wrote: > > May I ask what sort of SAN? > Its a Hitachi OpenV fibre channel SAN (4Gbps HBA). My storage admin > checked if this LUN can be accessible by others and he found no other > hosts have access to it.Ok.> > I've seen some odd LUN reshuffling before,...> reshuffling here means automatically changing disk's geometry as I am > having an issue? It would be interesting to know if this can happen.No, reshuffling as in a host gained access to LUNs in a 'phantom' manner that it should not have had access to. No longer a problem, and hasn't been for a great while. It was an odd interaction, but I forget the details. If another host were put onto the FC with the exact same WWN onto the fabric it might be possible to see this sort of thing, too, but the WWN's are all supposed to be unique.> Here are some new additional info :...> So my question is: if the LUN has been re partitioned for ex: say to > install windows , why am i seeing our data in these newly created > partitions? Is it possible to see data in a reapportioned drive?Yes, it is. If the recovery tool can look at the raw device it can grab stuff that isn't in any partition, and you can look at that data. Standard forensics. Repartitioning erases nothing except the partition table. Now, in the specific case of GPT, it is further possible to have a GPT and an MBR at the same time, and while the 'shadow' MBR is supposed to match the GPT's partitioning it doesn't have to. If you read through the LVM2 documentation and source code you may be able to find the signature used to mark a partition as being LVM; once you do that you should be able to find the start of the partition, and re-write the partition table(s). I use the plural there since with GPT you can have the GPT and the MBR coexisting; ideally you'd want to wipe the GPT out, but in reality you may not want to. But, being that you really don't want to write anything to this volume, you really should set up an offset, read-only, loop device; that is, find the starting sector of the partition (preferably an image of the LUN, and not the actual LUN; can the Hitachi array do LUN replication (EMC's SANcopy or Snapview or MirrorView being the rough equivalents)?). Then, once you find the starting position of the LVM physical volume: START_OFFSET_BYTE='actual starting sector number * sector size, zero origin' DEVLUN='LUN device, probably /dev/sde in your case' losetup -o $START_OFFSET_BYTE --read-only /dev/loop0 $DEVLUN Then see if you can get LVM to see this physical volume (by default loop devices are included in the scan, but you may want to verify they're not filtered in /etc/lvm/lvm.conf): pvscan vgscan lvscan You may be able to mount (-o ro of course) the LV at that point (I'm going through the LVM business because you mentioned VG names in your post). Hope that helps.