Q:

Is full disk encryption on a server in a secure data center pointless?

I am having a debate with several people regarding how much protection full disk encryption provides.  dm-crypt is being used to encrypt data which is required by my company to be encrypted at rest.  The Linux servers hosting the data reside in a secure data center with very little risk of unauthorized physical access, let alone someone actually stealing the server.
My argument is that in this situation, that while complying with the letter of the law, they have done little to nothing to actually reduce risk associated with unencrypted data.  In effect, from a logical standpoint, they are in the exact same situation than if no encryption had been implemented at all.  I am curious though if this train of though is correct, thoughts?
To tailor the question more to my specific situation, regarding physical protection, the controls around that are typically very sound.  I am not saying risk is eliminated but it is considered to be low.  Same with disposal of the drives, the destruction controls operate pretty effectively and risk is considered low.  From a logical access standpoint the servers are not Internet facing, are behind a firewall, logical access is well controlled (but many have access), and they are not virtualized. Further, the servers operate 24x7, the only time they are rebooted is if it's needed after a change or during installation of a new one.   
My concern is that in the event an insider goes rogue, or an unauthorized user exploits a logical security flaw, then the full data encryption does nothing to protect the data versus using some of the other field or file level encryption tools available.  Whereas the people I am debating argue that this is not the case.  

A:

Two generic things you apparently have missed:

In case of disk failure, having the data encrypted at rest solves the issue of having potentially sensitive data on a media you can't access any more. It makes disposing of faulty drives easier and cheaper (and it's one less problem)
Full disk encryption also makes it harder for an attacker to retrieve data from the "empty" space on the drives (which often contains trace of previously valid data)

And if you're using VMs:

Encrypting the partition makes you less dependent on the security of your hypervisor: if somehow the raw content of one of your drive "leaks" to another VM (which could happen if the drive space is reallocated to another VM and not zeroed out), that VM will be less likely to have access to the actual data (it would need to obtain the decryption key as well).

A:

If the decryption key is stored in plain on the very same media as the encrypted data, then the encryption is pointless. If you have a set of rules, which require data to be encrypted, but permit storing the key in plain on the very same media, then the rules are flawed. If you ever face such a flawed set of rules, you should point out the flaw.
If the key is not stored on the same media as the data. Then the encryption does serve a purpose. That does however raise the question about where the server gets the key from at boot. There are a few options:

Require a password to be entered during boot. This is not very practical for a server.
Fetch the decryption key from a key server. This can prevent the data from being decrypted if the server was stolen, it just requires the key server to only respond to requests from within the data center.
Secret share the key across multiple disks. Does nothing for the case where the server is stolen. But if you have a RAID where single disks are occasionally replaced, it guarantees that any data left on disks returned under warranty is properly encrypted. When a new disk is added to the RAID, an implementation of this technique would have to do the following:

Generate an encryption key for this individual disk.
Generate a new master key.
Secret share the new master key across all disks.
On each disk write the disk encryption key encrypted under the new master key.

The three approaches described above can be combined. If they are combined, the key server could be implemented using blinded RSA.

A:

There are attacks on the firmware of hard disks. Googling for hard drive firmware attack will return some results about what the NSA does or can do, which probably isn't very relevant to you; but even hobbyists are able to modify the firmware of drives. This guy even installed a linux kernel on his hard disk - no, it wasn't the PC that ran linux, the hard disk controller itself did that.
If someone gains access to the firmware of your disks (for example, that somebody rents a server from your data center for a month, then returns it; the data center company wipes the drives, then assigns that server to you), they might have the drive firmware do something like "Whenever a block that's written to disk contains a special pattern, for the next 5 minutes, in every read block that starts with root:$1$, replace the first bytes with (some password hash)", you have an attack that's nearly undetectable. Your /etc/shadow file will look normal to you except during the 5 minute time window after your attacker requested a file with a name containing the trigger pattern from your web server, which wrote it to its error log.
Unlikely? Sure. Impossible? Definitely not. Is it paranoid to assume this could happen? Probably yes, depending on how interesting your data is. But, encrypting your drives will protect you from this kind of attack, and it won't cost you anything but a few cpu cycles. And, if there are any laws or regulations to follow, in case of a security breach, i certainly don't want to be in the position to have explain why i thought it wouldn't matter.

