在我们的环境中，我们有一些位于 Always On 可用性组中的服务器，还有一些是独立的。
我们通常备份到网络共享，但我们最近观察到，随着数据库变得越来越大，所花费的时间越来越长，这会减慢整个网络的速度。
Ola hallengren 的脚本用于压缩和拆分备份文件。我只执行每日“完整”备份。备份将转到网络共享 EMC isilon 驱动器。
我对 EMC DD Boost 从来都不满意。唯一的选择是进行本地备份，然后复制到同一个网络共享。
除了上述方法，还有什么有效的方法吗？
AskOverflow.Dev
有一些方法可以通过使用不同的旋钮来调整备份，比如MAXTRANSFERSIZE 或 BUFFERCOUNT，或者对文件进行条带化（你已经注意到你已经在这样做了）。
问题在于，触摸这些旋钮可能仍会导致您的网络和/或存储达到限制，并且它们对备份时间没有任何实际影响。
您的第一项工作应该是使用Crystal Disk Mark或DiskSpd对要备份的存储进行基准测试。这将使您对期望写入达到最佳状态的速度有所了解。
您需要测试的下一件事是从您要备份的驱动器中读取数据。如果您将备份运行到 NUL，您可以计算备份的读取部分所需的时间，而无需将其写入磁盘。
考虑到这两个数字，您可以开始使用其他旋钮来查看哪些旋钮让您最接近它们，无论您的备份目标是本地还是网络。
您提到的替代方案似乎是最佳选择。
你可以做的是一个两步的过程：
这样，您的备份是本地的，而且速度很快。您将需要更多的磁盘空间和明显的冗余（如果备份磁盘出现故障怎么办 - 您不想丢失所有备份）。
或者，将 Robocopy 作为备份作业中的一个步骤执行，以确保仅在备份成功完成时发生 robocopy，并且在备份完成后尽快发生。备份与数据的风险相同，只要它保持在本地。
此外，定期测试您的恢复，因为如果您无法恢复备份 - 它有什么用途！
另外，请参阅我对SQL Backup 调整大型数据库的回答
几个潜在的解决方案：
您可以在 Ola 的脚本中调整许多与性能相关的参数，您可以调整这些参数以获得所需的性能：
BlockSize
以字节为单位指定物理块大小。
DatabaseBackup 中的 BlockSize 选项使用
BLOCKSIZESQL Server BACKUP 命令中的选项。BufferCount
指定用于备份操作的 I/O 缓冲区的数量。
DatabaseBackup 中的 BufferCount 选项使用
BUFFERCOUNTSQL ServerBACKUP命令中的选项。MaxTransferSize 指定要在 SQL Server 和备份媒体之间使用的最大传输单位（以字节为单位）。
DatabaseBackup 中的 MaxTransferSize 选项使用
MAXTRANSFERSIZESQL ServerBACKUP命令中的选项。有许多可能的选择，但是随着数据库变得更大并且完整备份需要更长的时间，您可能必须合并差异备份，如果您还没有：
我的理解是，Ola 的脚本甚至可以设置为使用 ModificationLevel 参数根据数据库中的更改量来决定是完全备份还是差异备份。
我们使用 EMC DD Boost，欢迎您对它提出自己的看法，但我们发现，由于它使用的客户端重复数据删除方法，即使是多 TB 数据库的完整备份也可以非常快，以至于我们不必担心 SQL Server 差异备份。实际上，通过使用 EMC DD，您正在执行差异备份，而不是在 SQL Server 中。使用多个目标文件也大大提高了速度，即使在 DDBoost 上也是如此。