The bad news is that some of your data may already by irretrievably lost. The good news is you may be able to recover some if not all of what remains. It's quite likely that you will have to reinstall your OS and server software however:
The first thing to do is insure that you don't lose any more data by taking a forensic copy of the drive. I described this process in some detail in this answer. By using this method we can work on the forensic copy (whether on a spare drive by mounting the device) or on an image by mounting the image via the loopback device. Then we can take a number of steps to attempt recovery of the missing data ranging from running the appropriate
fsck to using other data recovery tools such as
If the attempt to image results in errors you can try again using
If you don't have current backups, I cannot stress the importance of this step enough.
Once we have the copy we begin with an analysis of the layout of the partitions.
I prefer to use either
fdisk for this step. I have no doubt that there are other approaches.
sudo fdisk -l DeviceOrFile
sudo parted DeviceOrFile followed by the commands
unit selecting B and then
will do the trick where DeviceOrFile is the device or image file that contains our forensic image.
The latter will be better if working on a multi-partition image, the first provides enough info for working with a physical drive.
Lets check the file system.
For a device just
fsck /dev/sdXy where /dev/sdXy is the device parition whose file system we wish to check.
For an image file we first need to setup the loop device.
$ sudo losetup -o 1048576 /dev/loop0 Stover14.04.img
$ fsck /dev/loop0
If somehow we've made thing worse we still have the original drive and we can start over, however that's not the expected result.
Our next step will be to mount the partition that contains the (possibly repaired filesystem) data we require. How we go about this depends on whether our copy is on a physical device or contained in an image file.
For a device we mount the partition we want normally although we may wish to include the ro option to avoid inadvertent writes to the device as explained below.
For an image file:
We need to ascertain if we have a loop device available to mount to:
$ sudo losetup -f
[sudo] password for me:
If for some odd reason we don't have a loop device we need to create one
we will require the numbers obtained with the parted approach mentioned above. Let's say for example we have a partition table like this:
$ sudo parted /dev/sda
GNU Parted 2.3
Welcome to GNU Parted! Type 'help' to view a list of commands.
Unit? [compact]? B
Model: ATA TOSHIBA THNSNH12 (scsi)
Disk /dev/sda: 128035676160B
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 1048576B 13317963775B 13316915200B primary ext4
2 13317963776B 128034963967B 114717000192B primary ext4 boot
The number in the start column is important as we will use it in the offset of the following mount command.
You'll note that I've previously created the directory
/mnt/boot-sav/sda1 I'll assume you know how to do this or can find that information by consulting
man mkdir (hint: -p might be required)
sudo mount -o loop,ro,offset=1048576 Stover14.04.img /mnt/boot-sav/sda1
the -o indicates that options will follow separated by commas.
loop indicates that we are mounting to the loop device
ro indicates the mount will be read-only to allow us to poke around looking for files without making any changes to the image.
the offset parameter indicates the byte position of the beginning of the file system on the partition in question that we are mounting which completes the options I am using.
All this is followed by the name of the image file and the path to mount to.
At this point we can see if we can locate our missing data by perusing from the mount point or utilizing data recovery tools such as testdisk directly on the file system or loop device depending on the tool and your forensic copy approach.