If you have a hardware RAID controller, I’d find out if you can read its log (if 3Ware, use tw_cli). And, whether you have hardware or software RAID, you can look at the SMART parameters of the disks (if the disks are connected to a RAID controller, you may need special commands to access them. See the smartctl manpage).

If you do:

# smartctl -a /dev/sdX

I always primarily look at:

Reallocated sector count. Is especially bad when its increasing over time. And, I don’t fully trust a disk that has any reallocated sectors.
Look at the SMART error log. It’s tricky to read at first, but the primary thing is to see if there are events, and at what time (expressed in disk age in hours) they occurred.

You can see the current disk age as one of the SMART parameters. If it’s recent, it may be related.
Also, keep an eye on dmesg and syslog to see if you have get errors over time. For example, disk errors often show up long before it’s a fatal problem as ata exceptions. We have a central logging server (using rsyslog) that notifies me about ata exceptions. A quick example on how to set that up:

# /etc/rsyslog.d/60-smtp.conf:

$ModLoad ommail
$ActionMailSMTPServer localhost
$ActionMailFrom noreply@example.com

/etc/rsyslog.d/70-mail-ata-errors:

$ActionMailTo you@yexample.com
$template mailSubjectATA,"ATA error on %hostname%"
$template mailBodyATA,"You have ATA errors. Mostly it's the disk and you get these errors before a possible mdraid setup kicks the drive.\r\nBEWARE: ata1.00 is first ata, first disk. Ata1.01 is first ata, second disk. Use the ata-to-device-names.sh script to identify devices.\r\n msg='%msg%'"
$ActionMailSubject mailSubjectATA
$ActionExecOnlyOnceEveryInterval 3600
:msg, regex, "ata.*exception" :ommail:;mailBodyATA

Another thing you can do is a memtest. Ubuntu installation DVDs/CDs have those in the boot menu, and I believe any Ubuntu server has one in its regular boot menu as well. Let is make one pass at least, more if possible.

Do you have ECC RAM BTW? ECC RAM is important for long term stability and data integrity.

/var/log/syslog is a good place to start for Ubuntu systems. Find the first log messages after the reboot. They will say something about syslog starting and what kernel version you are running.

Then scroll up and find the last line, which was logged before the system crashed. Scroll up further to see if you can find any log messages from the kernel itself.

Go through other logs in /var/log to see if you can find any lines with a time stamp between the last log line from before the crash and the first from after.

It is highly probably that all of this effort can only narrow down the time of the crash, but not tell you anything about why the server crashed. In particular if it is a hardware fault, it can be difficult to get proper log messages.

First, you want to check /var/log/syslog. If you are not sure what to look for, you can start by looking for the words error, panic and warning.

grep -i error /var/log/syslog

Red Hat family distributions (including CentOS and Fedora) use /var/log/messages and /var/log/secure where Debian-family distributions use /var/log/syslog and /var/log/auth.log

If you have system graphs available (e.g. Munin). Check them and look for abnormal patterns. If you do not have munin installed, it might be an idea to install it (apt-get install munin munin-node)

You should also check root-mail for any interesting messages that might be related to your system crash.

Other logfiles you should check is application error-logs. E.g /var/log/apache2/error.log or similiar. They might contain information leading you to the problem.