背景：我需要修改/改进几年前在一组服务器上创build的自动化过程。 过程如下：
这个过程在技术上是可行的，但是数据库的大小和数量在过去几年中一直在增长，大概在70-100 GB之间。 这个过程每天都在运行，应该切换到利用差异备份来减less涉及的数据量。 现在它执行完整备份。
问题：我遇到的问题是7zip压缩如此大量的数据所花费的时间。 将所有这些数据库压缩成一个.7z文件需要大约14个小时。 有问题的服务器是双核W2008R2 64位，16GB内存的机器，它也为大约300-500个用户提供一个Web服务器的SQL服务器。 关于7zip具体，我们已经设置为执行最高级别的压缩（超/级别9）。
风险是7zip在用户高峰时段消耗太多的CPU能力，所以SQL的性能会受到影响。
问题：是否有可用于Windows的压缩实用程序，可用于压缩SQL数据库备份，从而可以更快地执行此过程（在不到14小时的时间内执行大约80GB）或消耗比7zip更less的CPU使用量？
在大多数情况下，你总是要交易速度压缩。 简单地减less压缩，或select一个效率较低的algorithm将使这个过程更快。 绝对没有能够以极快的速度提供出色压缩的魔力。
您可以使用Sql Server自己的备份压缩，但这也会增加CPU使用率。
直接从服务器B备份到共享驱动器上，然后使用服务器B进行压缩。 或者，从A共享驱动器，然后使用服务器B在将文件复制到B之前进行压缩。
或从辅助数据库（从主数据库有日志传送）进行备份。 据推测，您还没有辅助数据库，但是如果您每天都进行完整备份，那么考虑它可能很重要。 设置从主服务器到辅助服务器的日志传送，并从辅助服务器取回备份，而所有用户继续使用主数据库，因此在进行（压缩）备份时不会损害其性能。
在短期内，使用7zip的较低级别的压缩，但这不是一个永久的解决scheme。
我使用命令行7zip，7za，使用bzip2algorithm和zip格式压缩55GB数据库文件。 压缩文件为5.5GB，服务器使用2个处理器4核E5520 2.27GHz cpu，压缩时间less于2小时
7za a -tzip -mm=BZip2 <destination file> <source dir>