背景：我需要修改/改进几年前在一组服务器上创建的自动化流程。过程如下：
- 生成特定 SQL 实例中可用的所有 SQL 数据库的完整备份（托管在服务器 A 上）
- 抓取所有文件并使用 7zip 压缩实用程序将它们压缩成一个文件（压缩过程在服务器 A 上进行）
- 通过本地网络发送单个压缩的 7z 文件以存储在单独的服务器上（托管在服务器 B 上）
这个过程在技术上是可行的，但多年来数据库的大小和数量已经增长到 70-100 GB 之间。该过程每天运行，应该切换以利用差异备份，以减少所涉及的数据量；现在它执行完整备份。
问题：我遇到的问题是 7zip 压缩如此大量的数据所需的时间。7zip 大约需要 14 个小时才能将所有这些数据库压缩成一个 .7z 文件。有问题的服务器是双核、W2008R2 64 位、16GB RAM 机器——它还为大约 300-500 个用户的 Web 应用程序托管 SQL 服务器。具体来说，关于 7zip，我们将其设置为执行最高级别压缩（超 / 级别 9）。
风险是 7zip 在我们的用户高峰时段消耗过多的 CPU 功率，因此 SQL 的性能受到威胁。
问题：是否有适用于 Windows 的压缩实用程序可用于压缩 SQL 数据库备份，从而更快地执行该过程（约 80GB 在不到 14 小时内）或消耗比 7zip 更少的 CPU 使用率？
在大多数情况下，您总是会以速度换取压缩。简单地降低压缩率或选择效率较低的算法将使此过程更快。绝对没有什么灵丹妙药可以同时提供出色的压缩和极快的速度。
您可以使用 Sql Server 自己的备份压缩，但这也会增加 CPU 使用率。
从服务器 B 直接备份到共享驱动器上，然后使用服务器 B 进行压缩。或者，从 A 共享驱动器，并在将文件复制到 B 之前使用服务器 B 进行压缩。
或者从辅助数据库（具有来自主数据库的日志传送）进行备份。大概您还没有辅助数据库，但如果您每天进行完整备份，那么考虑它可能就足够重要了。设置从主数据库到辅助数据库的日志传送，并从辅助数据库进行备份，同时您的所有用户继续使用主数据库，因此在您进行（压缩）备份时不会影响他们的性能。
在短期内，使用 7zip 进行较低级别的压缩，但这不是永久的解决方案。
我使用命令行 7zip、7za，使用 bzip2 算法和 zip 格式压缩 55GB 的数据库文件。压缩文件为5.5GB，服务器使用2处理器4核E5520 2.27GHz cpu，压缩时间少于2小时