Here is a simple seeming question you might wind up asking someday. Suppose that for some reason you need to keep encrypted copies of your backups. Does it matter if you use symmetric encryption for this (where the encryption key is also the decryption key), or do you need some form of asymmetric encryption (where the encryption key is not the decryption key)? Well, it depends on what your threats are (a threat model, in the jargon).

To start with, the difference between the two options is that with symmetric encryption, any system that can create encrypted backups necessarily has access to the key needed to decrypt them; if it's compromised, the attacker can likely decrypt all of your backups. Similarly, any system with the ability to restore your backups (which requires decrypting them) can create new encrypted backups that can potentially look exactly like they came from your original systems. With asymmetric encryption, neither is true. Provided that you keep the systems separate, the backup creating system can't decrypt the backups afterward and the backup restoring system can't forge them.

Of course, if all the backups are made (and encrypted) on a single machine, such as an Amanda backup server, you don't need to get the decryption key to read current backups. An attacker can just read them as they stream into your single backup server, before it encrypts them. We can extend this to a single security domain; if all of your backup servers can be compromised from a central management server, then compromising the central management server gives access to all backups as they're being made. Neither the type of encryption the backup servers are using nor the number of keys matter.

Partly because of this, often people aren't worried about their backup servers being compromised (or to put it the other way, backup server compromise is not part of the thread model). Instead, they're worried about the backups being stolen or copied while they're at rest somewhere else. They might be on tapes in an offsite disaster recovery location, on disk at a replicated data center, stored in the cloud, or stashed at someone's home as a very small scale offsite backup storage. In this case, that the backup servers can decrypt backups as well as encrypt them is not a vulnerability, because our threat model starts out by assuming that the backup servers are secure. It's only the "at rest" backups that we need to safeguard with encryption, and they are as safe with good symmetric encryption as they are with asymmetric encryption.

(Most backup threat models also aren't concerned about fake backups being inserted into your backup collection.)

You might also have a more nuanced threat model, where you assume that your backup servers are secure against code execution compromise but an attacker might somehow be able to read otherwise secret data from them. An attacker who can read a file of their choice might well be able to recover the encryption key that the backup server uses. This would make symmetric encryption more risky; now an attacker who can read the key and get a copy of your encrypted backups can decrypt them.

Another issue to consider in your threat model is key management (and its friend, key rotation). The more keys you have to manage, the higher the chance is that something will go wrong, which could make some of your backups inaccessible to you, make them decryptable by other people, or both. Asymmetric encryption has the property that you can often destroy the ability to make new backups before you destroy the ability to decrypt old ones, by discarding only one side of a keypair. Does this matter? It depends on your threat model.

PS: As with disk encryption, encrypting your backups is implicitly prioritizing non-disclosure over availability. There are possible situations where you will have intact backups but be unable to use them.