Put a somewhat less descriptive, but more conceptual way, basically you want to provide two different means to get to the same key. This is the idea of having a data key, typically unique to a record, or perhaps to all of a user's records, depending on security needs. You then encrypt that key with a key derived from their password and a key derived by some other piece of information. It could be an alternate thing that they know or it could be something that your server knows. This can either be symmetric cryptography, or for greater security, the information your server knows can use a public key for a private key that is not held on the server.
Then if the user ever loses there password and is thus unable to access the data key, the alternate encryption of it can be decrypted to retrieve the key. In order of security, symmetrically storing the key on the server is least secure as if both the server and DB are compromised, the encryption is rendered useless. The user information might be a little better, but for it to be easily rememberable, it will also likely be easily researchable or guessable, which is insecure even if the server isn't compromised. The asymmetric option where the server doesn't have access to the information necessary for a reset (because it only knows how to encrypt the recovery version of the data key is the most secure, but it is also the most difficult from a usability standpoint as the decryption then has to either be done a) by hand or b) by a secondary, highly secured server, preferably holding the private key in a TPM (trusted platform module) or some other secure hardware keystore.
Either way though, the basic principal is the same. You always make the key unrecoverable without the secret, you just store it multiple times with different secrets.