我不是一个系统人员或DBA,当我正在审查一个项目的出价时,我开始怀疑磁带备份(LTO-3000)如何影响Windows Server(2012)中的Sql Server数据库等实时生产应用程序, 。
根据我的经验,数据库文件被完全locking,不能复制。 我首先想到的是,将SQL Server复制到辅助(虚拟)服务器。 然后,可以将服务器设置为按计划执行转储/备份。 这是“规定”的方法吗? 如果没有,备份Sql Server数据库的一般方法是什么?
通过谈论数据库文件被locking的问题,我想如果你想自己复制数据库文件并抱怨自己被locking了,那么你会用完全错误的方式来备份数据库。 不仅如你所注意到的那样,它们被“locking”,简单地复制这些文件将是一个很好的方式,最终得到一个无法可靠恢复的数据库备份。
我所知道的所有数据库服务器产品都会有某种内部备份系统用来备份数据。 它可以是一个完整的备份例程,可以直接将数据转储到文件或磁带上,也可以是第三方备份可以连接的API,以触发产品完全支持的备份。 MSSQL可以使用这两种方法。
我build议做的事情是使用SQL的内部备份来备份到硬盘上的“文件设备”,然后您可以将这些文件备份到磁带上。
编辑为了解决您的评论,
1) 使用受支持的备份方法的影响应该是最小的,但显然必须有一些影响。 我不想只说“噢会慢x% ”或类似的东西:这是一个“testing和看到”的东西。 我会说,它不应该导致数据库不可用。
2)有两个“标准” – 使用内部备份程序备份到磁盘,然后将结果备份到磁带/其他近线存储和/或通过数据库感知备份代理直接备份到磁带。 我不会说一种方法比另一种更好(我已经看到严格的数据库用这两种方法保护),但我倾向于使用SQL-> Disk-> Tape方法或 SQL-> Disk-> Tape 和 SQL->备份代理 – >磁带。
这是一个适合初学者学习MSSQL备份的优秀链接:
http://msdn.microsoft.com/en-us/library/ms187510.aspx
MSSQL使用Windows卷影复制服务(VSS)获得对数据文件的类似快照的访问; 你不应该尝试手动复制数据文件 – 它不会工作。
你的问题的答案是“它取决于”,但我会尽力给予足够的信息,以便你可以决定。
备份到磁带时,必须考虑到磁带比磁盘驱动器要慢得多,这意味着备份/validation/恢复将会很慢,并且如果有大量数据(TB)可能需要几个小时。 您可以使用本地sql服务器方法来实现这一点,或者使用Idera / Redgate / CommVault /等某种第三方软件。
另一种select是备份到本地磁盘,例如:便宜的SAN或不同的Raidarrays。 这里的关键是不同的! 你所做的就是使用本地sql服务器方法备份到专用备份分区/ lun / raid set / drive确保你有足够的存储空间,这样你可以旋转备份文件。 关键是要有足够的自由空间来保存N + 1天的时间。 然后您设置您的磁带备份将这些文件备份到磁带。
这里的主要优点是备份作业运行速度更快,这意味着它在SQL Server上的运行时间更短,并且由于备份位于与SQL数据和日志文件(MDF,NDF,LDF)文件不同的存储上,所以影响在SQL Server上几乎没有什么,是不是问题。
另一个重要的优点是您拥有最新的备份,并且可以进行恢复,恢复速度比从磁带恢复要快很多,从而最大限度地缩短了这种情况下的停机时间。
我会设置它的方式是第二种方法。
如果使用事务日志,请确保您的恢复模式设置为FULL。
如果你有SQL企业,你甚至可以压缩备份,所以他们占用更less的存储空间。 如果没有,有第三方工具可以从Idera或Red-Gate等供应商为您压缩。 还有一个很好的开源项目,我使用命名为MSSQLCOMPRESSED
我希望这回答了你的问题。