在 AWS EC2 C5.4xl 服务器 (16 vCPU / 32 GB) 上运行 1 TB SQL Server 数据库。完整备份开始接近 3 小时，所以我认为我应该研究多个文件备份。我本来想对 EBS 的大小、类型和数量进行一些实验，但很快发现它们都给出了相同的结果。
使用 Windows 资源监视器，在运行 SQL Server 备份时，我看到数据文件的读取速度约为 140,000 B/秒，备份文件/驱动器的写入速度总计为 130 - 135,000 B/秒。无论我如何更改，结果似乎都一样。2 个文件、4 个文件、IOPS 驱动器、吞吐量驱动器，都无关紧要。
我最终意识到，也许是我的数据驱动器拖慢了速度。写入速度只能和读取速度一样快，对吧？所以我将它升级为 IOPS 驱动器，并将其从 3000 IOPS 翻倍到 6000 IOPS。没有变化。读取速度仍然限制在 140 MB/秒...
我是不是在与 AWS 的严格限制作斗争？我已经在多台不同大小的机器上进行了这项测试，但无论如何都达到了相同的（约）270 MB/秒的限制。
数据驱动基准测试：
其中一个备份驱动器（4 个中的 1 个）的基准测试示例：
答案1
您的数据文件能够以 260 MB/秒的速度读取，因此我接下来将尝试以下步骤：
首先，运行备份到 NUL，如下所示：
BACKUP DATABASE MyDb TO DISK='NUL:'
这将执行备份的读取部分，但不将其写入任何地方，因此写入不会减慢速度。（请记住，这确实是真正的备份，因此如果您正在进行差异备份，则不想这样做，或者您想在非生产数据库上执行此操作。）
在备份结束时，您将看到 MB/秒的数字。这就是您的备份在读取存储时可以运行的速度。您应该看到它接近您获得的 CrystalDiskMark 顺序读取吞吐量。
260 MB/秒并不是很好 - 这大约是单个 GP2 卷的极限。您提到您正在使用 C5.4xl，而 EBS 吞吐量限制无论如何都是 437 MB/秒 - 您可以将数据分条到两个 GP2 卷，然后获得更好的（但不是 2 倍更好）读取吞吐量。要获得更高的读取吞吐量，您需要更改实例类型。如果您考虑到这一点，请使用 EBS 带宽和 EBS 吞吐量列ec2instances.info。
现在，回到您的测试：一旦您能够以 250-260 MB/秒的速度将备份到零，现在就测试写入。确保使用备份压缩，并写入不同 EBS 卷上的备份目标。由于您的 C5.4xl 具有高达 437 MB/秒的吞吐量（假设您已配置 EBS 优化），那么您应该能够获得大约 170MB/秒的写入吞吐量到写入卷，但它必须是不同的 GP2 卷。（如果您尝试写入同一卷，您的吞吐量将超出单个卷的 260MB/秒上限。）