With a good encryption mechanism, knowing any number of plaintext-ciphertext pairs $\{(P_i,C_i)\}$ should reveal nothing about the plaintext corresponding to some extra ciphertext $C$, other than its length. In particular, given the knowledge that $P_1$ encrypts to $C_1$, an adversary should have no way to know whether some ciphertext $C$ also decrypts to $P_1$. This is a consequence of semantic security.
You may wish to weaken the security of the system to allow recognizing ciphertexts corresponding to a previously processed plaintext. That is, knowing plaintext-ciphertext pairs $\{(P_i,C_i)\}$ reveals no information about some ciphertext $C$ which is not one of the $C_i$.
This has dangerous implications that may not be obvious at first glance. In many cases, an adversary can convince the user to encrypt some plaintext (e.g. arrange for the user to download some files). So an adversary who wanted to decrypt some ciphertext file names could make guesses for the plaintext, arrange for the user to create files with this name, and compare the resulting ciphertext to verify these guesses.
Using non-repeated IVs in encryption algorithms avoids this by causing two plaintexts to never be encrypted to the same ciphertext, even if the plaintexts are equal, because the IVs will differ.
If you don't mind considerably weakening the confidentiality of file names, you can use a deterministic IV. Beware that you can't just use any old IV; for example, with CTR or GCM mode, repeating a counter value reveals the xor of the corresponding plaintext blocks, which leaks a lot of information. One method that is safe, other than enabling the encryption oracle guessing method I described earlier, is to make the IV a cryptographic hash of the file name. If the hash function is independent of the block cipher (which it typically is in practice, e.g. the SHA families are independent of AES) then the hash function can be idealized as a random oracle and so using a hash as the IV is equivalent to using a random IV as long as plaintexts are not repeated.
However, I wonder why you need to be able to recognize identical ciphertexts. Your backup tool has the symmetric key, so it can decipher the name of previously backed-up files. To avoid downloading ciphertexts from the server for local decryption, you would keep a local log of what has already been backed up, but backup programs usually have this anyway in some form.
Regarding your updates:
Use AES/GCM (or CBC) with the same IV for all filenames?
No. GCM requires a unique IV. Repeating the IV with GCM can not only break the confidentiality and integrity of the message, but can even leak information about the key. See How bad it is using the same IV twice with AES/GCM?
CBC with a repeated IV, in addition to making common prefixes obvious, leaks a little information about the plaintext. It also doesn't guarantee integrity.
Or use ECB mode which does not require IV?
No. ECB is not a proper encryption mode. It is implemented in some libraries for convenience but does not provide any security.
I can't really use IV for filename encryption (need to save the IV into the crypted filename, which is problematic)
You generally can't use the encrypted filename as a filename anyway, because the encrypted filename is longer than the original, even without counting the IV. Filesystems have forbidden characters, so you'd need some encoding scheme, which costs you bytes in the filename. Most filesystems have a limited filename length. The only case in which you can map plaintext filenames to encrypted filenames is if the source filesystem's filename length limit is sufficiently smaller than the target filename filesystems's length limit.
