Is the decompression of compressed and encrypted data without decryption also theoretically impossible? We have two communication points in an information system, call them A(lice) and B(ackup).

B has to store encrypted data received from A. The storage of B is encrypted, but not compressed1.

B should have no option to decrypt the data of A2.

However, the data channel between A and B are too narrow, compared to the data volume, making the compression of the communication a requirement. However, encryption maximizes the entropy of the content, making it incompressible.

Another option would be to compress the data, and then encrypt it, but then B should be able to decrypt the data to decompress it.

My first idea was that these requirements are contradicting, as it seems with the practical tools known to me. But I am not sure, how does it look from a theoretical view?

Is an encryption possible, what does not worsens the compressibility of the data in it, despite that it is "enough" secure?

1The reason is here data safety and the support of incremental backups, if it matters (I think, it doesn't).

2It has obvious security reason - a backup storage having all data of a complex network becomes a security bottleneck.
The decompression of compressed-then-encrypted data is not possible without the decryption key, at least for compression and encryption schemes independent of each other. We can make a theoretical argument for that: compression schemes compress only a small portion of possible plaintexts (that happen to be the ones where compression is used in practice), and slightly expand the others (e.g. random data). Encryption makes it impossible to distinguish if two ciphertexts of equal size correspond to plaintext that compression compressed, or not; thus prevents any meaningful decompression.

In the question's situation, the classical solution (described as "Another option" in the question) is to compress at A, then encrypt, then transfer the compressed+encrypted data to B. On retrieval, that same compressed+encrypted data is forwarded from B to A (or A'), decrypted, then decompressed. This reduce bandwidth for backup and retrieval, and storage requirements at B.

B does not need to decompress or decrypt the data at any point: the question's "but then B should be able to decrypt the data to decompress it" is true, but a non-issue. B does not need the key, and (thus) can't decrypt.

What is an issue is direct access to a portion of a huge data set: for many common compression algorithms, that requires transfer of all the data before the point being accessed (sometime, all the data). This is solved by a split-then-compress-then-encrypt strategy, where the plaintext is split in segments that are compressed independently, then enciphered independently (or mostly so). But the splitting tends to reduces compression, especially for short segments.

Another issue is that the compression ratio leaks to an eavesdropper, and that reveals something about the data. This can be a serious issue: for voice, it has been shown to be enough to understand what's being said!