标签: backup

我正在我的 Dev 上运行一些恢复测试，我注意到存储的例程没有被 innobackupx 恢复。这是可以实现的吗？难道我做错了什么 ？

我只使用 innodb 表，所以最好只使用 innobackupx 来恢复数据库。

谢谢你。

哪些数据库包含在由生成的转储中mysqldump --all-databases？

根据我的经验，这应该是所有用户创建的数据库，加上mysql数据库。information_schema仅在明确提及时才备份数据库，并且performance_schema从不备份。这样对吗？

我正在调查其他 DBA 如何对其数据库备份执行自动定期测试以确保发生灾难时的可恢复性，我对我在该主题上发现的稀疏主题感到非常失望。

我将尝试在评论中描述我为我的公司提出的解决方案，但是你们如何确保您的备份实际上是可恢复的？

1. 您是否定期恢复备份以测试服务器？使用脚本？
2. 具有此功能的第三方软件？
3. 在备份上运行仅验证？
4. 让您的初级 DBA 进行恢复测试？

让我知道我是否应该在问题中改写或添加任何内容。

更新

经过一段时间和完善，我决定如果有人感兴趣，我决定发布我的脚本。https://github.com/curiebabz/SSARS

我的数据库大约 10 GB，我使用完整恢复模式。

有时我必须一次添加大量数据，在此期间，我将恢复模式从完整更改为批量记录。

• 你怎么认为？
• 这是一个好主意吗？
• 还是有风险？

我已经在我的 SQL Server 2008R2 服务器上使用 Ola Hallengren 解决方案近两年了。昨晚备份失败，系统数据库和用户数据库均出现以下错误。

系统数据库错误示例：

日期和时间：2016-05-31 20:00:01 命令：DECLARE @ReturnCode int EXECUTE @ReturnCode = [master].dbo.xp_create_subdir N'E:\SQLBackups\Server1\master\FULL' IF @ReturnCode <> 0 RAISERROR('创建目录时出错。', 16, 1) HResult 0x5620，级别 16，状态 1 xp_create_subdir() 返回错误 183，“当该文件已存在时无法创建文件。” 消息 50000，级别 16，状态 1，服务器 Server1，第 1 行 创建目录时出错。结果：失败持续时间：00:00:00 日期和时间：2016-05-31 20:00:01

用户数据库错误示例：

日期和时间：2016-05-31 20:00:12 数据库：[Dummy_1] 状态：ONLINE 待机：无 可更新性：READ_WRITE 用户访问：MULTI_USER 是否可访问：是 恢复模式：SIMPLE 差分基 LSN：423000000014100036 上次日志备份 LSN： 342000000037500001 日期和时间：2016-05-31 20:00:12 命令：DECLARE @ReturnCode int EXECUTE @ReturnCode = [master].dbo.xp_create_subdir N'E:\SQLBackups\Server1\Dummy_1\ReturnCode <>IF 0 RAISERROR('创建目录时出错。', 16, 1) HResult 0x5620，级别 16，状态 1 xp_create_subdir() 返回错误 183，“当该文件已存在时无法创建文件。” …

在完全恢复模式下，差异备份会“破坏”之前的日志备份吗？

让我举个例子：假设我们有以下备份：

• 完整备份 1
• 日志备份 1
• 日志备份 2
• 差异备份 1
• 日志备份 3
• 日志备份 4

在这种情况下，通常要恢复，可以按如下方式恢复：

• 完整备份 1
• 差异备份 1
• 日志备份 3
• 日志备份 4

我的问题如下：如果 DIFF Backup 1 文件以某种方式损坏，那么我是否可以仅使用 FULL 和 LOG 备份来恢复数据库？像这样：

• 完整备份 1
• 日志备份 1
• 日志备份 2
• 日志备份 3
• 日志备份 4

任何帮助表示赞赏。如果这已在另一篇文章中得到解答，请告诉我（我尝试搜索）。

在 MS SQL Server 2014 AlwaysOn AG 设置中，我想为给定的可用性组安排备份作业。最终目标是在同步的辅助节点上运行定期备份，最重要的是，不受特定辅助节点的可用性限制。

到目前为止，我看到的方法是使用 SQL Server 调度程序，在所有正在运行的实例上设置相同的作业，并将条件逻辑引入调度程序步骤，以确定角色是主要角色还是次要角色。由于以下几个原因，这对我的用例不起作用：

1. 我只想在辅助节点上运行一次计划操作，但我有多个辅助节点
2. 我想确保它最终运行，无论是否有任何辅助节点 - 如果没有辅助节点，它应该在主节点上运行

备份作业包括BACKUP LOG [...] WITH COMPRESSION, NOINIT, NOFORMAT每 15 分钟运行一次。

现在，我正在考虑创建一个绑定到相应 AG 的故障转移集群角色的集群计划任务，但想知道是否有更简单和简化的方法来实现这一点。

我们设置了 SQL Server 2014 Always ON，其中包含一个主要副本和一个辅助副本。我一直在使用 Dell LiteSpeed 在辅助副本上进行数据库备份（完整和 tlog），以便从主副本卸载该流量。我们让一位开发人员截断了一个重要的表，因此我们不得不从完整备份和 tlog 备份中恢复主数据库。在恢复之前，我首先在主数据库上进行了完整的数据库备份，并注意到它只有 34 GB，而辅助数据库的备份几乎是 70 GB。恢复后，人们抱怨性能很慢。我的问题是为什么辅助副本上的数据库备份是主副本的两倍。TIA。

最近有人告诉我我应该在 dbcc checkdb 之前和 checkdb 之后进行一次完整备份，即使在完全恢复中也是如此。有人可以解释我为什么要这样做吗？

我认为在 checkdb 之前进行完整备份是不必要的（在完整恢复中），因为我总是可以恢复上次完整备份 + 差异备份 + t-log 备份。这是一个错误的假设吗？

我们有一个大约 3 TB 的 SQL Server 2014 企业版数据库。我们每周都进行压缩完整备份，直到上周它都运行良好，现在突然需要 18 个小时才能完成。

备份完成后，备份大小约为 550 GB。

备份驱动器有大约 950 GB 的可用磁盘空间。

可能是什么问题？