![磁带备份如何影响 SQL Server 等生产系统](https://linux22.com/image/604160/%E7%A3%81%E5%B8%A6%E5%A4%87%E4%BB%BD%E5%A6%82%E4%BD%95%E5%BD%B1%E5%93%8D%20SQL%20Server%20%E7%AD%89%E7%94%9F%E4%BA%A7%E7%B3%BB%E7%BB%9F.png)
我不是系统人员或 DBA,当我审查项目投标时,我开始想知道磁带备份(LTO-5 3000)如何影响实时生产应用程序,例如 Windows Server(2012)中的 Sql Server 数据库。
根据我的经验,数据库文件完全被锁定,无法复制。我的第一个想法是使用 SQL Server 复制到辅助(虚拟)服务器。然后,可以设置服务器按计划执行转储/备份。这是“规定”的方法吗?如果不是,那么备份 SQL Server 数据库的一般方法是什么?
答案1
从您所说的数据库文件被锁定的情况来看,如果您试图复制数据库文件本身并抱怨它们被锁定,我认为您备份数据库的方式完全是错误的。正如您所注意到的,它们不仅被“锁定”,而且简单地复制文件也会导致无法可靠地恢复数据库备份。
我所知道的所有数据库服务器产品都会有某种内部备份系统,您应该使用它来备份数据。它要么是一个完整的备份例程,允许您将数据直接转储到文件或磁带中,要么是一个 API,第三方备份可以连接到该 API 以触发产品完全支持的备份。MSSQL 可以使用这两种方法。
我建议使用 SQL 的内部备份来备份到硬盘上的“文件设备”,然后您可以随时将这些文件备份到磁带上。
编辑 为了回应你的评论,
1)影响使用支持的备份方法应该尽可能少,尽管显然会产生一些影响。我不想只是说“哦,这将是X%较慢”或类似的东西:这是一个“测试一下看看”的事情。我会说它不应该导致数据库不可用。
2) 有两种“标准” - 使用内部备份例程备份到磁盘,然后将备份结果备份到磁带/其他近线存储和/或通过数据库感知备份代理直接备份到磁带。我不会说一种方法比另一种更好(我见过使用这两种方法保护的重要数据库),但我倾向于使用 SQL->磁盘->磁带方法,或者SQL->磁盘->磁带和SQL->备份代理->磁带。
答案2
这是一个适合初学者了解 MSSQL 备份的绝佳链接:
http://msdn.microsoft.com/en-us/library/ms187510.aspx
MSSQL 使用 Windows 卷影复制服务 (VSS) 来获取对数据文件的快照式访问权限;任何时候您都不应尝试手动复制数据文件 - 这根本行不通。
答案3
对你的问题的答案是“视情况而定”,但我会尽力提供足够的信息以便你做出决定。
备份到磁带时,必须考虑到磁带比磁盘驱动器慢得多,这意味着备份/验证/恢复会很慢,如果数据量很大(TB 级),则可能需要几个小时。您可以使用本机 SQL Server 方法来实现此目的,也可以使用某种第三方软件,如 Idera/Redgate/CommVault/等。
另一个选项是备份到本地磁盘,例如:廉价的 SAN 或不同的 Raid 阵列。这里的关键是不同的!您要做的就是使用本机 SQL Server 方法备份到专用备份分区/lun/raid 集/驱动器,确保您有足够的存储空间,以便可以轮换备份文件。关键是要有足够的可用空间来存放您想要在本地保留的 N+1 天。然后,您设置磁带备份以将这些文件备份到磁带。
这里的主要优点是备份作业运行速度更快,这意味着它在 SQL Server 上运行的时间更少,并且由于备份位于与 SQL 数据和日志文件 (MDF、NDF、LDF) 文件不同的存储上,因此对 SQL Server 的影响几乎没有,也不是问题。
另一个重要的优点是,您手头有最新的备份并准备好进行恢复,这种恢复比从磁带恢复要快得多,从而最大限度地减少了这种事件中的停机时间。
我采用第二种方法进行设置。
- 每天执行一次完整备份。
- 每小时执行事务日志备份
- 删除超过 24 或 25 小时的旧备份文件。
- 每天将存储 SQL 备份的位置备份到磁带上。
如果使用事务日志,请确保恢复模型设置为FULL。
如果您有 SQL Enterprise,您甚至可以压缩备份,以便它们占用更少的存储空间。如果没有,可以使用 Idera 或 Red-Gate 等供应商提供的第三方工具为您压缩备份。我使用的还有一个名为压缩的MSSQL
我希望这回答了你的问题。