In the end, it’s actually quite simple (politics aside). If Mailcow is hosted in the cloud, i.e., on a VPS, there should be at least one backup stored somewhere else, either in another cloud storage location or on-premises.
If Mailcow is hosted on-premises, then at least one backup should be off-site. In most cases, that will be the cloud, unless you’re a company that has multiple physical locations or you’re doing some kind of “buddy backup” arrangement.
The cloud provider doesn’t have to be a US company. In practice, though, it doesn’t matter that much, because backups stored in the cloud should be encrypted anyway, as @esackbauer already said.
Personally, I run Mailcow (persona/homel use only) on a VPS. I create backups using the integrated Mailcow backup script to /opt/backups/, and then store them encrypted on Backblaze via Rclone. In addition, I run a local MailPiler instance at home where all emails are archived.
The “Mailcow backup script to Backblaze backup” is primarily intended to beable to restore the entire instance, not to restore individual emails. For that purpose, I use my MailPiler instance, where you can actually search and retrieve old emails if needed. In my case (as I sad, home user), I can count on one hand how often I’ve actually needed to do that.
Alternatively, if your Mailcow instance is on a VPS, for example, and you would prefer to keep your backups on-premises, you could use rsync to pull them from the VPS to your NAS/on-prem server instead of sending them to cloud storage. However, if your NAS or on-premises server fails, you might then be without a backup for days or weeks, especially given the current HW supply chain situation. 😉
Also, in the event of a catastrophic event such as a fire or burglary, having another backup in the cloud may be beneficial. 😉