目前,我们使用软件每晚将文件复制到磁带来备份 MSSQL 2000 和 2005 数据库。数据库大小分别为 14-16Gb 和 500Mb。
由于 SQL Server 可以将数据库备份到文件,我们是否最好安排 SQL Server 创建备份文件,然后将这些文件备份到磁带?此外,如果我们使用此方法,是否可以以某种方式创建自上次备份以来已完成的事务日志,以便我们可以重新创建数据库并应用其他事务?
答案1
真的没有理由不使用 SQL Server 的本机备份功能。它很棒,可以理解事务日志,并为您提供所需的大部分功能。(第三方 SQL Server 备份解决方案很棒,因为它们可以与 Microsoft 公开的 API 配合使用,并且通常提供加密和压缩支持 - 压缩不仅可以节省磁盘空间,而且通常还可以减少备份和恢复时间。)
是的...我建议使用 SQL Server 进行备份。
并确保定期进行事务日志备份。(我建议每 15 分钟或更短时间进行一次 - 定期日志文件备份有助于保持日志文件精简1并且由于某种原因,当服务器崩溃时,最终用户总是会感到脾气暴躁,他们必须重做自上次日志文件或完整/差异备份以来过去 x 小时内的所有工作。)然后,出于冗余目的,使用 robocopy、syncback、文件系统复制或其他方式将这些备份的副本移动到另一个位置,以防止硬件/磁盘崩溃或数据中心火灾等。
请随意观看这两个免费视频以获取更多信息和想法:
http://www.sqlservervideos.com/video/backup-options
http://www.sqlservervideos.com/video/sqlbackup-best-practices/
答案2
注意:我对 SQL Server(所有版本)最大的困扰是事务日志备份。
我们每晚对 SQL 数据库进行一次完整备份,每 30 分钟对事务日志进行一次完整备份,备份到磁盘(在另一台服务器、不同的 SAN 上)到带有日期戳的文件(相当简单的 SQL 脚本和 SSIS)。
我们的脚本还创建了“restore.sql”脚本来恢复上次完整备份和截至该日期的所有事务日志。
然后,我们将超过 2 天的文件压缩,删除超过 30 天的文件(但将月底的备份保存在存档中)。我们将此驱动器复制到异地(我们很幸运,大型站点之间有 200 英里,并且它们之间有大型 WAN 连接。)
然后我们将其备份到磁带上。(安全带、支架、更多的支架!主要是出于政治原因)
我们运行许多 SQL Server 数据库,商业工具要么太贵,要么就是不划算。但我建议在较小的安装中使用 RedGate SQLBackup
答案3
您的意思是您目前将数据库 MDF 和 LDF 文件备份到磁带上吗?我认为这是可以的,只要您在执行此操作时数据库处于脱机状态(即数据库分离或 SQL 服务关闭),但是如果您在数据库正在使用时尝试执行此操作,则最终的备份可能会失败,因为文件在复制时会发生更改。
根据我的经验,创建完整的 SQL 备份并将其放到磁带上是更为常见的。
另外,回答你的第二个问题,SQL Server 确实支持事务日志备份。MSDN 文档完全恢复模型是一个开始阅读的好地方。
答案4
脚本备份到磁盘非常简单并且操作非常快捷:
osql-S[服务器 ip]-Q “备份数据库[数据库名称]到磁盘 = 'C:\Backups\Backup.bak' "
使用 UNC 路径无法通过网络备份到不同位置(无论如何这不是一个好主意)。无论如何,在本地进行备份并加密存储更简单。
硬盘很便宜,而且越来越可靠。我们不久前就扔掉了磁带,从此再也没有回头。