> the problem is, if you intend to use the data within the application, you need to be able to decrypt it
... which requires the encryption keys to be know at the point of use - but it doesn't mean that they need to be kept with the database. It doesn't necessitate asymmetric encryption either.
If you keep the keys in a different location, completely away from the database server(s), then a compromised database or backup does not compromise any of the information. Of course there are attack routes that would still give access to the keys too, but you have covered quite a few common attack vectors.
As others have said, this appears to be a total dump of the system and not just the database. It looks like the encryption keys were not kept with the database, but all of the SSL keys and everything are included inside the full dump. Seemingly it was another server with the keys that was dumped too.
The only way to protect against this would be some type of hardware key store with limited access to all employees and servers. I think there are a few (expensive) options which can do this, but nearly all services - especially startup services like this one - do not have this available to them.
Who knows if those hardware options aren't just as vulnerable to an experienced attacker though? I don't think they are generally well tested - probably half of the available options are snake oil.
If the keys are only ever held in memory then getting a dump of all the stored data from all the database and font-end servers would not reveal the keys.
To achieve that you would need human interaction to bring up a new box (or after an existing box is restarted) in order to hand over the keys (if the server could request the key from somewhere on the local network, then perhaps so can an attacker if they get access to run arbitrary things rather than just getting access to the filesystem or a copy thereof) which might be impractical for some environments, but it is possible.
For instance when my offsite backup server reboots it can't access the encrypted volumes until I login to mount them manually, sending the keys over SSH in such a way as they don't get stored.
The weak point then becomes the humans and the process they use to transmit the keys from the keystore to the servers.
One more weak spot: if they have full access to the server, they can just dump the ram. This is incredibly simple to do on Linux for example.
In a big company though, having that one developer with full keys to the kingdom and is the only way to start up new servers is obviously out of the picture. Especially if the system works by having the keys on an easily stolen or damaged laptop...
They keys would need to be much better looked after than that, of course. They just need to not be easily accessible from the machine they protect. You'd need a procedure in place so anyone with access to the relevant machines is able to obtain and use the keys as needed in an emergency.
Being able to dump RAM pretty much breaks the protection that this offers though, as you correctly point out.
... which requires the encryption keys to be know at the point of use - but it doesn't mean that they need to be kept with the database. It doesn't necessitate asymmetric encryption either.
If you keep the keys in a different location, completely away from the database server(s), then a compromised database or backup does not compromise any of the information. Of course there are attack routes that would still give access to the keys too, but you have covered quite a few common attack vectors.