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