/opt/zimbra/backup is an efficient, reliable, consistent disk-to-disk backup of constantly changing transactional data in /opt/zimbra/{store,db/data,index,openldap-data,redolog}. You definitely don't need to back up those subdirectories again, and if you do, they won't be consistent or useful.
zmbackup doesn't necessarily get everything in conf, and logs are also nice to back up (for forensics, not DR). I let my traditional backup software get everything with the exception of the transactional data above and temporary queue files in /opt/zimbra/data.
I don't run a traditional backup of /opt/zimbra/backup, because it's already a perfectly good backup, and as you've noticed, traditional backup software can't handle millions of small files. Consider snapshots, replication, or simply geographic isolation instead.
To satisfy extraordinary compliance requirements, put /opt/zimbra/backup on storage with WORM/ILM features, such as a Centera, DataDomain, or NetApp NearStore.
What's your end goal? Even if you achieve a "good" and "fast" backup of the backup in /opt/zimbra/backup, you'll still need to restore it somewhere, then zmrestore, and you can expect zmrestore to take longer than the original zmbackup. At some point it makes sense to stop spending money on traditional backup and invest in a delayed-asynchronous-replicating SAN that would let you bring up a DR site immediately, without multiple restore procedures. /opt/zimbra/backup is still necessary for recovery from user or sysadmin mistakes, but it's not a DR solution for large volumes of mail.
If you can't afford asynchronous replication for all of /opt/zimbra (minus backup), activate Zimbra HSM and replicate your primary store, but not your HSM store. You'll be able to restore access to email newer than your Zimbra HSM migration period immediately. Older mail would require recourse to backup.
Yes, asynchronous replication means very recent mail may be lost, but that's a heck of a lot better than rolling back to the last backup. Sites concerned about saving every last byte, regardless of dollar and potential performance cost, can do synchronous replication of redolog and data/postfix/spool only.  |