0

Where to start... So I have three dedicated servers hosted overseas. All three are running CentOS 6.7, two are used for webservers while the third is used as only for MySQL databases connecting to the two webservers.

On Friday, the database server had started to drop connections randomly one after the other so I thought I'd check the error logs for anything unusual - There was nothing out of the ordinary so I backed up my MySQL databases (As I do before every reboot) and then done a reboot on the operating system.

This is where everything just went wrong, the server failed to boot into CentOS reading

Error: 25 Disk read error

This to me meant BIOS problem (I may be wrong) Now the server host has given me IPMI/KVM to maintain the server remotely, however I could not get the infuriating pile of java crap to work so I sent a support ticket asking for assistance. They replied 12 hours later saying nothing more than "Your SSD has failed, we have ordered you a new one"

Uh... Hello? I need my data from it.

It's been a back and forth discussion (nearly an argument) explaining a new SSD is useless if I don't have my database backup to even go on it. Finally, I got them to reinstall CentOS on another drive so I can try to mount the "broken" SSD and recover my data.

I am using only SSH as I cannot get IPMI/KVM to work and they've since disconnected the IPMI connection anyway.

When I run fdisk -l I get the following:

[root@localhost /]# fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00023d5d

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1      121602   976760832   83  Linux

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000ebd75

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1          64      512000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sdb2              64      121602   976248832   8e  Linux LVM

And after an 8 minute wait, finally displays the rest:

Disk /dev/mapper/VolGroup-lv_root: 53.7 GB, 53687091200 bytes
255 heads, 63 sectors/track, 6527 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000


Disk /dev/mapper/VolGroup-lv_swap: 12.7 GB, 12666798080 bytes
255 heads, 63 sectors/track, 1539 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000


Disk /dev/mapper/VolGroup-lv_home: 933.3 GB, 933320720384 bytes
255 heads, 63 sectors/track, 113469 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

I cannot get it to read the 250GB SSD for mounting. So my question is, is there any alternative way to get my data from the drive? ANYTHING at all, I have nothing to lose as of now.

  • 4
    You start wrong. Start with "I was arrogant enough to not make backups". Bad news: Data recovery from SSD is harder than from hard discs, and I doubt you would like to pay that in the worst case. You should have done regular backups. Now you pay the price. – TomTom Jan 26 '16 at 14:21
  • @TomTom's tenor may be harsh, but he's absolutely right. You'll be learning a hard lesson today unfortunately. Backups are always required, regardless of how much redundancy (or not) you build into a system. – EEAA Jan 26 '16 at 14:23
  • Was there no RAID? – ewwhite Jan 26 '16 at 14:27
  • @TomTom, I have a monthly backup OFF of the server itself. It is too big to do frequently. The databases currently sit at 114GB. They are backed up daily ON the server. It's not that I was arrogant enough not to make backups, it's just I don't have daily off-site backups. I have an internet usage cap that will very quickly be gone if I kept taking this amount from it daily. – SmurfTheSmurf Jan 26 '16 at 14:32
  • 1
    If you cannot perform regular daily backups, perhaps consider adding a second non-SSD drive to your system only for backup use. – EEAA Jan 26 '16 at 14:38
0

Unfortunately, if your backups were also on the disk that failed, you're out of luck. Generally, unlike a failing mechanical disk, a SSD failure generally means the controller is dead, rather than just certain blocks or areas. Looking at the dmesg or /var/log/messages output may tell you more, but it's not likely to be good news.

  • I was afraid of this. It's not the end of the world, I have a backup from last month so I guess that will have to do. Thanks. – SmurfTheSmurf Jan 26 '16 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.