我们的数据库管理员离开了,由于我是唯一一个懂 SQL 的人,所以我接手了这些职责,但我仍在学习。
我们有一台装有多个 SQL Server 数据库的服务器。
我已将它们设置为完全恢复,以尽量减少数据丢失。
上周末,我发现其中一个数据库的日志文件膨胀失控,最终占满了整个磁盘,事务日志文件备份也占满了备份驱动器,幸好我在它引发许多问题之前就发现了。
我对数据库日志进行了缩减,并删除了许多旧的事务日志备份,所以目前一切正常。
我正在尝试找出保留备份的最佳策略,而且由于这是我不熟悉的领域,所以我希望进行健全性检查。
目前,我们每周日晚上进行一次完整备份,其他晚上进行每日差异备份,并且为了确保白天不会丢失数据,我们每 15 分钟进行一次事务日志备份。
每周的完整备份也会移至异地,这样我们就不会出现单点故障。
我的想法是,为了节省空间,一旦周日进行完整备份,差异和事务日志备份就不再需要了,所以也许可以清除它们,然后我会保留几个月的每周备份以防万一。
或者这是个坏主意?
让我总结一下。
您的备份策略:每周完整备份、每日差异备份和每 15 分钟日志备份看起来很合理,但是(根据您的问题)我发现您和企业主之间缺乏沟通。
不应该由互联网上的随机人员建议您删除或保留备份,而应该由支付账单(您的工资、SQL 服务器许可证和存储费用)的人来回答这个问题。
这些人并不关心你的备份,他们需要的是恢复能力。他们必须定义需要恢复到何种程度的备份,并向你提问
作为新人,请随时与他们安排会议并清除:
如果你们都意见一致 - 太好了。如果他们不满意(我想要全部,我现在就想要),还有选择和价格。
以下是我的建议。
每 15 分钟备份一次,会有很多文件(最多 24 * 4 * 7=672 个),手动备份很困难,而且容易出错,所以我建议使用sp_DatabaseRestore
我希望您不是在本地服务器上而是在网络共享上运行备份,这样您就可以设置一个仅用于测试从该共享恢复数据库的服务器,这样如果失败了您就有时间修复它。
作为奖励,您可以在恢复后运行 CHECKDB。此外,您还为数据库预先分配了空间。您甚至可以使用它进行查询,但请注意:如果您阅读它,则必须获得许可。
那么其他等式部分又如何呢?例如登录名、SQL Server 登录密码、登录的服务器角色、证书、SQL 代理作业、SSIS 包、链接服务器等?
它存储在系统数据库中,但这些数据库的恢复并不频繁,因此您可以定期编写脚本。