我们正在研究为 SQL Server 使用快照备份的方向,而不是更传统的备份方法。我们正在使用 CommVault(也将用于快照..)
我试图更好地了解它们与传统备份或使用 CommVault 的代理备份相比如何工作。由于我不是一个真正的存储专家,我不太了解恢复过程如何从 SQL 数据库的快照备份中工作。
我确实了解绝对的速度优势,但想了解更多关于使用 SQL Server 快照备份的利弊。
我们正在研究为 SQL Server 使用快照备份的方向,而不是更传统的备份方法。我们正在使用 CommVault(也将用于快照..)
我试图更好地了解它们与传统备份或使用 CommVault 的代理备份相比如何工作。由于我不是一个真正的存储专家,我不太了解恢复过程如何从 SQL 数据库的快照备份中工作。
我确实了解绝对的速度优势,但想了解更多关于使用 SQL Server 快照备份的利弊。
缺点:
需要在运行还原之前为 Commvault 安装插件。在紧急情况下,这可能会增加一个残酷的间接层。
防止单个文件组的零碎恢复,因为必须恢复整个数据库以保持一致。
您需要知道如何使用 Commvault,而不仅仅是内置工具。
备份历史在SQL Server 中被混淆,因此您只能将 guid 视为备份的目标。
优点:
您可能会更好地压缩备份文件
存储人员觉得他们正在管理备份(坦率地说,也许是个骗局)
备份过程可能会更快。
毫无疑问,还有很多我没有想到的其他优点和缺点。
就个人而言,作为 DBA,我更愿意使用 SQL Server 本地备份。
一个可以帮助您决定适当方法的练习可能是让业务人员彻底评估他们的恢复点目标和恢复时间目标。
如果他们能够承受在这些数据库中丢失 24 小时的数据,那么夜间备份可能是可以的。如果您不能损失超过 15 分钟的数据,那么无论何时将数据写入数据库以及完整备份,您都需要 15 分钟的日志备份。如果 VDI/VSS 备份解决方案不提供日志备份,或者他们无法为频繁的完整备份提供空间,那么您就知道您不能使用这种系统。至于恢复时间目标,如果他们可以忍受灾难发生后一周的停机时间,那么您可能可以使用基于 VDI/VSS 的备份系统。