Is this a sensible cryptographic protocol intending to reduce the impact of compromised security? I'm in the process of designing a cryptographic protocol which will reduce the impact an attacker will have if they gained root access to a server storing data.

The basic crux of it is that keys which were used to encrypt data are not stored on the server and are only ever in memory for a short period of time. 

The basic description is that:


a Public/Private Key pair is generated on both client and server.
The data is encrypted with both public keys by the client and transmitted to the server
The server's private key is used to decrypt the data by one level (Still encrypted using client's pub) and stored on the server
If the server needs to decrypt the data for ananlysis, this is initiated by the client who does this by sending their private key, encrypted by the server's public key (*This is the weakest point I think?)
The client's private key is decrypted and use to decrypt the data (Then thrown away)
Analysis results are then stored using client's public key (And optionally transmitted to the client)


A picture showing this can be seen : 

Please be as brutal as you like - I'd like to try to get this right.

Also please note - I'm aware that if a baddie has root access to the box he'd be able to listen for the client's key transmission and decrypt that using the stored server private key and then compromise the data, but I'm trying to minimise the impact of server compromise, not remove it completely.  I want to work with the assumption, that a hack would be detected before they had time to wait for a client to send their key.

EDIT:
To Clarify - there's an assumption that the data can't be transmitted back tot he client for analysis - lets say because it's too large to make that efficient
There's also an assumption that network traffic is monitored so an attacker would only ever have limited time on the server to attempt to steal the data.
I don't think the approach you sketched helps very much.  If the server is compromised, the attacker can pretty easily modify the server-side software to log and record all the cryptographic keys, and then you haven't gained anything.  Therefore, I don't think the approach you sketch is likely to be a great way to spend your limited software development budget.

If you want to mitigate the risks of server compromise, let me suggest two alternative approaches that I think might actually be worth your time:


Privilege separation. Rather than have one server that does everything, split it up into two servers.  One server does just the crypto decryption, and the other does all of the other application functionality.  Install these on two separate servers, with separate passwords etc. so that if the latter is compromised, it won't compromise the former.  The former server is super security-sensitive, but if you also keep its functionality very simple and if you administer it carefully, you may be able to reduce the likelihood of compromise of that server.
Client-side cryptography. Don't ever allow the keys to be on the server.  Do all of the encryption purely on the client side.  The client generates the cryptographic keys, and never allows the secret key to leave the client (never shares it with the server); encryption or decryption with the private key is done entirely on the client side (not by the server).  However, it takes additional work to make this work, and make it secure, and address the resulting key management and usability challenges, so this is not a no-brainer: it comes with some non-trivial disadvantages.