标签: backup

我们在周五晚上 9 点运行每周备份作业，我们遇到了一些关于磁盘空间（有时会变得非常低）和性能方面的问题。我们正在考虑精简/优化所发生的事情，并感谢您的意见。

具体来说：

1. 备份过程大约需要 4 小时才能在备份期间更新统计信息。我们可以安全地禁用此过程以节省时间吗？

2. 我们经常会遇到磁盘空间不足的情况，想知道是否应该重新调整这个过程。目前它创建备份，然后删除以前的备份，这就是占用磁盘空间的原因。我们可以安全地删除前一首，然后做备份？

非常欢迎任何其他评论或意见编辑：服务器上 SQL 文件的总大小约为 35GB。一个 db 的大小约为 25GB，而其他 6 个共享组成了另外 10GB 左右。

您通常会像这样保存 Linux 命令的详细输出：

# command > output.txt

但是，当您使用类似的命令时mysqldump，该>选项会将数据库表的转储输出到所需的文件：

# mysqldump --username=whatever --password=whatever -h localhost database > dump.sql

If you add in the -v (verbose) option to mysqldump, it outputs help information about what the command is doing. How do I save this verbose output to a file since the > option is used to output the database table information to a file?

More specifically, I'm dumping the output of one database into another database like …

首先，我对 stackexchange 很陌生，所以请耐心等待。

我正在运行 SQL Server 9.0.4060。

我的问题是：我的 SQL Server 备份在很多数据库上一直失败。

维护计划运行到不同的备份作业：

每天 20:30 进行 DIFF 备份，每周日 20:30 进行 FULL 备份。

对于无法完成备份的每个数据库，我收到这两个错误：

Date        06-11-2012 20:31:06
Log     SQL Server (Current - 07-11-2012 11:43:00)
Source      Backup
Message
BACKUP failed to complete the command BACKUP DATABASE (dbname) WITH DIFFERENTIAL. Check the backup application log for detailed messages.

Date        06-11-2012 20:31:06
Log     SQL Server (Current - 07-11-2012 11:43:00)
Source      Backup
Message
Error: 3041, Severity: 16, State: 1.

额外的错误。

Date     06-11-2012 17:53:27 
Log      SQL Server …

仅使用EXPorEXPDP命令进行数据库转储（并将其视为备份）而不是使用BACKUP DATABASE命令（via RMAN）进行备份有什么缺点？数据库转储（导出）和数据库备份有什么区别？

在做了一些研究之后，我似乎无法找到这个问题的答案。

背景 我正在尝试设置一个符合以下三个要求的备份计划：

1. 备份的可靠性，每晚进行完整备份
2. 可以从中恢复的事务日志备份
3. 使用的磁盘空间少
4. 备份必须可在本地访问以供审计工具使用

因此，为了满足这些需求，我正在考虑每周进行完整备份、每天进行差异备份和每小时进行交易。然后每天晚上都会运行一个 copy_only 备份，可以将其运送到异地，这个备份完成后日志链不会被破坏，并且我们在异地拥有可靠的夜间完整备份，而不必占用太多本地磁盘空间。

问题 是否可以从copy_only 备份恢复，然后恢复事务日志。

让我举个例子，让你知道我在说什么。

使用下面的列表，我想知道是否可以恢复 FullbackupCOPY_ONLYC.bak 然后是 TransactionbackupG.trn、TransactionbackupH.trn、最后是 TransactionbackupI.trn

> ---List of Backups---   
FullbackupA.bak 01/01/2013 00:00:00   
>  DifferntialbackupA.bak 02/01/2013 00:00:00 
FullbackupCOPY_ONLYA.bak 02/01/2013 00:00:00
>     TransactionbackupA.trn 02/01/2013 01:00:00
>     TransactionbackupB.trn 02/01/2013 02:00:00
>     TransactionbackupC.trn 02/01/2013 03:00:00
>  DifferntialbackupB.bak 03/01/2013 00:00:00 
FullbackupCOPY_ONLYB.bak 03/01/2013 00:00:00
>     TransactionbackupD.trn 03/01/2013 01:00:00
>     TransactionbackupE.trn 03/01/2013 02:00:00
>     TransactionbackupF.trn 03/01/2013 03:00:00
>  DifferntialbackupC.bak 04/01/2013 00:00:00 
FullbackupCOPY_ONLYC.bak 04/01/2013 00:00:00
>     TransactionbackupG.trn 04/01/2013 01:00:00
>     TransactionbackupH.trn 04/01/2013 02:00:00
> …

我继承了一个中等规模的业务关键型 SQL Server 2008 数据库，并且正在尝试围绕备份计划进行思考。（我是开发人员，不是 DBA。）

我们的系统现在设置的方式有两个备份系统：

1. 每周完整备份 ( .bak) 和每小时事务日志 ( .trn) 备份。我们保留了多组这些备份，并定期将它们运往异地。
2. SQL Server 日志 ( .ldf)，恢复模式设置为Full. 此文件与主.mdf文件位于不同的驱动器上，但不会备份。

如果发生紧急恢复（或将备份恢复到开发机器），我的程序是使用这些.bak文件，然后应用 .trn 文件。我们有一个脚本可以使这个过程相对简单。

我的问题：

1. 是否可以从.ldf文件中恢复数据库？它到底是为了什么？
2. 拥有这两个事务日志是不必要的冗余吗？
3. 备份.ldf文件很重要吗？

是否有工具可以从表中的选定行导出数据，并将所有数据存储在其他表中的其他表中，并通过关系设计链接？

目的是为了方便临时迁移服务器之间的数据位迁移。我正在寻找一个专门为 MySQL InnoDB 定义外键的工具。

获取 MySQL 数据库架构备份所需的最低权限是什么？我只对模式感兴趣，对数据不感兴趣。

是否需要 SELECT 权限？

我们在客户服务器上安装了一个 SQL Server 2008 实例。客户的 IT 部门负责机器的各种备份。

SQL Server 日志显示每天晚上 7 点都有完整备份，但我们找不到在 SQL Server 中安排任何计划的证据。

我们联系的技术人员无法告诉我们是否有某种自动备份，他们只告诉我们整个机器正在备份。

使用我在这个论坛帖子中找到的脚本，我发现物理设备名称是一个 GUID，这意味着这是一个外部备份过程：

USE [msdb]
GO 
SELECT 
    [bs].[database_name], 
    [bs].[backup_start_date], 
    [bs].[backup_finish_date], 
    [bs].Server_name,
    [bs].user_name AS [BackupCreator] ,
    [bmf].physical_device_name
FROM msdb..backupset bs  
INNER JOIN msdb..backupmediafamily bmf ON [bs].[media_set_id] = [bmf].[media_set_id] 
ORDER BY [bs].[backup_start_date] DESC

这是上述查询中的一行：

db_name 2015-09-16 19:01:23.000 2015-09-16 19:01:28.000
SERVER_NAME NT AUTHORITY\SYSTEM
{424F084A-F35D-4A66-8FC7-0722778A859

此外，备份开始和完成日期仅跨越 5 秒，所以我想很明显这不是 sql server 的工作。

这是日志中的一行：

2015-09-03 19:02:30.71 备份
数据库备份。
数据库：db_name，创建日期（时间）：2012/10/12(20:52:11)，转储页面：3290021，
第一个 LSN：276028:152755:172，最后一个 LSN：276028:152827:1，转储设备数: 1、
设备信息：
（FILE=1, TYPE=VIRTUAL_DEVICE: {'{95380B0A-D50B-408F-B95F-1AB8975BA7F8}5'}）。 …

目前我们对环境中的 SQL Server 2005/2008/2008R2/2012 服务器上的备份使用标准维护计划，并且始终选中“验证备份完整性”框。

有些备份运行时间很长，因此我建议关闭该选项，但管理层需要我记录此更改的影响和风险。

我了解此选项的使用和历史，对我来说似乎没有必要将备份作业的时间加倍（在我看来），任何可能发生的错误都可能发生在备份步骤期间，而不是在验证期间。

我错了吗？如果我备份到磁盘而不是流式传输磁带或其他东西，关闭它的风险是否最小？（如果相关，我们通过网络备份到 EMC DD-800 备份设备。）

是否有任何关于何时可以安全关闭此功能的官方 MS 建议？

您是否对环境中的每个备份运行“验证”？你抽查他们吗？

编辑：澄清一下，当您在维护计划中检查“验证备份完整性”时，SQL 将在每次备份后立即对每个数据库执行完整的RESTORE VERIFYONLY。这与原始备份一样是数据/IO 密集型，并且（基本上）使备份作业的总时间加倍。这是不一样的使备份的“校验”选项（不能在向导中进行，因为据我所知）。