Deduplication works on detection of identical files or blocks of data. Such duplicates occur only with negligible probability in random data, and properly encrypted data ought to be indistinguishable from randomness. Encryption is there to ensure confidentiality and this includes, in particular, hiding from any eavesdropper whether two source data files are identical or not.
In that sense, deduplication can work on encrypted files only if the encryption model is weakened. This is not a light decision: in the case of your database, showing which "blocks" have changed and which have not can be quite revealing on what you did with your database in the meantime. The generic term is traffic analysis. The Wikipedia page lists several famous military cases; traffic analysis is also very good at predicting business tactics of competitors (e.g. noticing in advance preparations for release of new major products).
Assuming that you want to do block-level deduplication, despite the possible leaks alluded to above, there are good ways and bad ways to do it. First you need to split the input data into block-sized chunks, actually a bit smaller because of the need for an extra per-block header (for IV and a MAC). Each block will be encrypted separately. Now the tricky part is that for deduplication to work, the same block data must be reencrypted identically if it did not change between invocations -- so it must reuse the IV. Reusing IV value is a sin; it is deadly when using modes like CTR and in particular its modern derivatives GCM and EAX. The solution here is an IV computed with a one-way function from the block offset in the file, and its contents; the one-way function should be "random looking", and be keyed, because otherwise attackers could try exhaustive search on the data itself, matching with the block IV.
The following scheme should be safe (within the weakened model) but this would require some careful analysis:
There are two keys K1 and K2 (possibly derived from a single master key with a Key Derivation Function.
For block number i, with data d, compute IV = HMAC(K1, i || d) (the IV is the result of HMAC/SHA-256 over the concatenation of i and the data d, using K1 as key -- truncate the IV to its first 128 bits).
Encrypt d with AES, using the IV from previous step and key K2, in CBC mode.
Put the IV and the encryption result together in a block-size chunk.
This uses CBC and MAC-and-encrypt, which is "not ideal" as far as cryptography is concerned, but hey, weakened model. You get what you ask for.
Edit: Important note: though some HMAC is being used here, this does not guarantee integrity of the block data. You may use the IV for decryption and then recompute the IV and see if it matches the one in the file; this will prevent generic alterations, but an active attacker could still replace a block with an older version of this same block. If you need some integrity check on your backups, do the following: in addition to any encryption and MAC described above, compute a MAC or a signature on the complete file and verify that before using the backup (if you are restoring a backup, then I assume that you will read it completely anyway, so you could have the MAC or signature verification "for free").