尾日志备份

尾日志备份


原文:
http://www.sqlskills.com/BLOGS/PAUL/post/Disaster-recovery-101-backing-up-the-tail-of-the-log.aspx
一旦你的数据库受损,而且你准备进行还原时,你要做的第一件事便是备份尾日志。
尾日志包含自上次日志备份以来所产生的事务日志。如果你想将你的数据库恢复至灾难发生时,你必须要获得这些日志记录,在后面的恢复中要用到。
这里需要考虑两种情况:1)服务仍然可用;2)服务已不可用。对于第一种情况,你只需要进行正规的尾日志备份即可;对于第二种情况,你需要“假载”(hack-attach)这个日志文件到其他服务上以进行尾日志备份。


情况1:服务仍然可用时备份尾日志
如果数据库受损但是服务仍然可用时,进行尾日志备份非常简单。一个例外是使用大容量日志恢复模型时,若自上次日志备份以来发生过大容量日志操作,则不能进行尾日志备份,这样你将失去自上次日志备份以来的所有的日志记录(译注:此时必须保证数据文件亦完整才能进行尾日志备份)。详细情况可以参看博文:A SQL Server DBA myth a day: (28/30) BULK_LOGGED recovery model
当数据文件受损时,如果你还是试图像平常那样备份日志,那么一定会报错。
比如,我创建一个数据库,然后进行一些事务:
CREATE DATABASE DBMaint2008;
GO
USE DBMaint2008;
GO
CREATE TABLE TestTable (C1 INT IDENTITY, C2 CHAR (100));
GO
-- 进行一次完整备份
BACKUP DATABASE DBMaint2008 TO DISK = 'D:/SQLskills/DemoBackups/DBMaint_Full.bck' WITH INIT;
GO
-- 插入一些行
INSERT INTO TestTable VALUES ('Transaction 1');
INSERT INTO TestTable VALUES ('Transaction 2');
GO
-- 进行一次日志备份
BACKUP LOG DBMaint2008 TO DISK = 'D:/SQLskills/DemoBackups/DBMaint_Log1.bck' WITH INIT;
GO
-- 再插入一些行
INSERT INTO TestTable VALUES ('Transaction 3');
INSERT INTO TestTable VALUES ('Transaction 4');
GO
现在灾难即将来临——我将执行下面的步骤来模拟灾难:
1.置数据库脱机(ALTER DATABASE DBMaint2008 SET OFFLINE )
2.删除数据文件
此时,如果试图读取数据库(置数据库联机),你会得到:
ALTER DATABASE DBMaint2008 SET ONLINE;
GO
Msg 5120, Level 16, State 101, Line 1
Unable to open the physical file "C:/Program Files/Microsoft SQL Server/MSSQL.1/MSSQL/DATA/DBMaint2008.mdf". Operating system error 2: "2(The system cannot find the file specified.)".
Msg 945, Level 14, State 2, Line 1
Database 'DBMaint2008' cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
现在,我像以前进行正常的日志备份:
BACKUP LOG DBMaint2008 TO DISK = 'D:/SQLskills/DemoBackups/DBMaint_Log_Tail.bck' WITH INIT;
GO
Msg 945, Level 14, State 2, Line 1
Database 'DBMaint2008' cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.
Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.
出错了——因为数据文件已经不能存取了。这里的技巧就是使用NO_TRUNCATE选项,即使数据文件不存在也能进行日志备份。
BACKUP LOG DBMaint2008 TO DISK = 'D:/SQLskills/DemoBackups/DBMaint_Log_Tail.bck' WITH INIT, NO_TRUNCATE;
GO
Processed 2 pages for database 'DBMaint2008', file 'DBMaint2008_log' on file 1.
BACKUP LOG successfully processed 2 pages in 0.010 seconds (0.972 MB/sec).
现在,我就可以在恢复的最后阶段使用上面的尾日志,这能恢复出事务3和4。你自己试试。


情况2:服务已不可用时备份尾日志
这种情况下服务发生崩溃,且不能启动了。如果你此时还能够读取数据库的所有的数据文件和日志文件,那么你可以将这些文件附加到另外的服务上,那么灾难恢复便会自动启动了。如果你只能读取日志文件,那么就需要一些另外的步骤来备份尾日志——我称这些步骤为“假载”。
假定我还是运行上面的脚本来创建一个数据库,这次我执行下面的步骤来模拟灾难:
1.置数据库脱机(ALTER DATABASE DBMaint2008 SET OFFLINE )
2.删除数据文件
3.拷贝日志文件到其他地方
4.删除数据库(DROP DATABASE DBMaint2008 )
现在,我有一些备份文件和一个日志文件。我需要将这个日志文件附加到SQL Server数据库中以便能进行尾日志备份。步骤如下:
1.创建一个同名的“哑”数据库
2.置数据库脱机(或者关闭服务)
3.删除“哑”数据库中的所有文件。
4.将日志文件替换进来。
步骤1和2,如下:
CREATE DATABASE DBMaint2008;
GO
ALTER DATABASE DBMaint2008 SET OFFLINE;
GO
现在进行步骤3和4,此时我需要将数据库联机:
ALTER DATABASE DBMaint2008 SET ONLINE;
GO
Msg 5120, Level 16, State 101, Line 1
Unable to open the physical file "C:/Program Files/Microsoft SQL Server/MSSQL.1/MSSQL/DATA/DBMaint2008.mdf". Operating system error 2: "2(The system cannot find the file specified.)".
Msg 945, Level 14, State 2, Line 1
Database 'DBMaint2008' cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.
Msg 5069, Level 16, State 1, Line 1
ALTER DATABASE statement failed.
现在我又可以像前面那样备份尾日志,用这个尾日志可以将数据恢复至灾难发生时。
注意 :如果我用一个较新版本的SQL Server来进行“假载”过程并不能起作用。我试着将2005的日志附加到2008数据库中,然后能正常的备份尾日志,但是这个尾日志并不能和以前的2005的备份一起使用。这是因为备份好的尾日志中的版本为655(SQL SERVER 2008),而以前备份的版本为611(SQL SERVER 2005)。当在2008上进行恢复时,要直到恢复完成才会升级数据库——所以就SQL SERVER 2008来说,我的2008版本的尾日志备份就不能用在实际上还是2005版本的数据库上。希望我已经讲清楚了。

总结
灾难恢复时,检查是否需要进行尾日志备份是非常重要的,而且做起来也不难。不管什么灾难恢复过程,要确保你事先已实践过。

<think>我们正在讨论SQLServer2019AlwaysOn配置下的备份与还原关键点:在AlwaysOn可用性组(AG)环境中,备份通常可以在主副本或辅助副本上进行(取决于备份类型和配置),还原则需要特别考虑,因为数据库处于可用性组中根据引用[1]提到的“日志备份”在还原中的重要性,以及引用[2]中关于在副本服务器上还原数据库的描述,我们可以整合信息用户的问题:SQLServer2019AlwaysOn配置下,如何备份和还原数据库步骤:1.备份策略-完整备份、差异备份和事务日志备份都可以在AG中进行-备份位置:默认情况下,备份发生在主副本上。但是,可以通过配置备份首选项(在AG的属性中设置)来决定备份可以在哪些副本上执行(例如,优先辅助副本、仅辅助副本等)-特别地,事务日志备份可以在辅助副本(可读的辅助副本)上执行,这有助于减轻主副本的负载(但完整备份和差异备份在辅助副本上需要SQLServer2014及以上,且要求可读的辅助副本)2.还原操作-当数据库属于可用性组时,直接还原操作会受限制,因为数据库处于可用性组中。通常,我们需要先将数据库从可用性组中移除(或删除可用性组)?但实际上,还原操作可以在可用性组中的数据库上进行,但需要特殊步骤:a.如果还原到主副本,则必须确保没有活动的事务(可能需要暂停数据同步)b.如果还原到辅助副本,则通常不需要,但还原后需要重新同步-重要:还原前必须进行日志备份(引用[1]提到)。在AG环境中,日志备份必须在主副本上进行(因为只有主副本可以执行日志备份,除非在辅助副本上配置了日志备份,但日志备份通常在主副本做)-步骤:在还原前,对主数据库执行日志备份(WITHNORECOVERY),这样数据库将处于还原状态,然后就可以进行还原操作。但是,在AG中,我们需要考虑如何将还原操作整合到整个可用性组中。-注意:引用[2]提到在副本服务器上还原数据库,但这是在配置可用性组之前的操作(初始化辅助副本时)。在AG运行期间,如果我们想要还原整个数据库(例如,由于数据损坏),则需要:*从可用性组中移除数据库(或暂停数据移动)*在主副本上执行日志备份(将数据库置于还原状态)*然后还原备份(完整、差异、日志)到主副本*重新将数据库加入可用性组(需要重新同步)3.在可用性组中还原单个损坏页(页面还原):-在AG中,可以从备份中还原单个数据页。这必须在主副本上进行,并且会使用自动页修复功能(如果启用了)来从次要副本获取页,但在手动还原时,步骤类似:-在损坏页的数据库上,使用RESTOREDATABASE...PAGE='file:page'WITHNORECOVERY-然后应用日志备份(如果有)-最后恢复数据库(RESTOREDATABASE...WITHRECOVERY)4.在辅助副本上还原-辅助副本上的数据库通常处于“正在还原”状态(不可读写)。如果我们想在辅助副本上还原(例如,用于报表),则不能直接还原,但可以创建一个数据库快照。不过,还原整个数据库到辅助副本并脱离可用性组是可能的(但会破坏同步),因此不建议在辅助副本上直接还原主数据库备份,除非是为了创建独立的报告数据库。5.推荐的步骤(完整还原主数据库):-步骤1:从可用性组中移除数据库(或者暂停可用性组的数据移动)-步骤2:在主数据库上执行日志备份:BACKUPLOG[dbname]TODISK='...'WITHNORECOVERY-步骤3:此时数据库处于“正在还原”状态,还原最新的完整备份(如果有差异备份,则先还原完整备份,再还原差异备份,最后还原日志备份,包括日志备份)-步骤4:恢复数据库:RESTOREDATABASE[dbname]WITHRECOVERY-步骤5:重新将数据库加入可用性组(需要重新进行数据同步,因为还原后的数据库可能比辅助副本的数据库新,或者更旧,需要重新初始化?因此,通常还原后需要重新配置辅助副本)注意:在SQLServer2016及更高版本中,支持“分布式可用性组”,但备份还原的基本逻辑类似。由于可用性组中数据库的还原操作较为复杂,通常建议:-定期备份(在配置可用性组时设置备份首选项,利用辅助副本进行备份)-在还原前,了解当前的数据同步情况,并确保数据一致性参考引用:[^1]提到了日志备份在还原中的重要性,尤其是在数据库处于在线状态时,要还原必须捕获日志。[^2]提到了在副本服务器上还原数据库的情况,那是在配置可用性组之前初始化辅助副本的步骤(使用还原而不是备份同步)。因此,在AlwaysOn可用性组中,还原数据库的步骤与独立数据库还原类似,但需要额外的步骤处理AG状态(暂停或移除)。现在,我们根据用户问题,给出具体的操作步骤:一、备份操作(在AlwaysOn可用性组中)1.配置备份首选项:在可用性组属性中,可以设置备份优先在哪个副本上进行(主副本、辅助副本或任意副本等)。2.例如,如果希望备份在辅助副本上执行(减轻主副本负担),需要将辅助副本设置为可读(Readablesecondary),然后配置备份首选项为“首选辅助副本”。3.执行备份:可以使用SQLServer代理作业或者维护计划来执行备份,注意备份位置应该是一个所有副本都能访问的位置(共享文件夹)。二、还原操作(以主数据库损坏需要从备份恢复为例)1.暂停可用性组的数据移动(在发生问题的主副本上操作):```sqlALTERDATABASE[dbname]SETHADRSUSPEND;```2.在主数据库上执行日志备份:```sqlBACKUPLOG[dbname]TODISK='\\shared\\backup\\tlog.trn'WITHNORECOVERY;```此时,主数据库将处于“正在还原”状态。3.还原完整备份(在同一个主副本上):```sqlRESTOREDATABASE[dbname]FROMDISK='\\shared\\backup\\full.bak'WITHNORECOVERY;```如果有差异备份,则还原:```sqlRESTOREDATABASE[dbname]FROMDISK='\\shared\\backup\\diff.bak'WITHNORECOVERY;```然后还原日志备份(包括日志):```sqlRESTORELOG[dbname]FROMDISK='\\shared\\backup\\tlog1.trn'WITHNORECOVERY;RESTORELOG[dbname]FROMDISK='\\shared\\backup\\tlog.trn'WITHNORECOVERY;```4.恢复数据库:```sqlRESTOREDATABASE[dbname]WITHRECOVERY;```5.恢复数据移动:```sqlALTERDATABASE[dbname]SETHADRRESUME;```注意:此时,因为主副本的数据库已经恢复到一个新的点,而辅助副本的数据库可能是旧的,所以可用性组会自动同步(可能需要重新初始化辅助副本,或者通过日志重做来同步,这取决于日志备份的时间点)。但是,上述步骤在实际生产环境中可能会遇到问题,因为当主副本暂停数据移动后,如果恢复数据库(WITHRECOVERY)后,再恢复数据移动,实际上数据库在可用性组中的状态会变成“未同步”,因为主数据库已经恢复到一个时间点,而这个时间点可能与辅助数据库不一致。因此,更安全的做法是:-在还原完成后,重新将数据库加入可用性组(需要先移除,再添加)?但是这会带来中断。因此,在AlwaysOn可用性组中,还原主数据库通常会导致数据丢失(因为我们可能使用了以前的备份),并且需要重新初始化辅助数据库。所以,更好的做法是使用数据库镜像(在损坏时自动故障转移)或者在辅助副本上创建一个新的可用性组数据库副本。实际上,在AG中,如果主数据库损坏,我们通常执行故障转移(到辅助副本)来保证服务连续,然后在辅助副本成为主副本后,再对新的主数据库进行备份和还原操作(此时,原主副本可以脱离可用性组,然后重新初始化)。所以,在实际操作中,还原操作在AG中很少直接对主数据库进行,而是采用故障转移或重新初始化节点。因此,对于用户的问题,我们强调备份策略的制定,以及在AG中还原操作需要考虑的可用性组状态管理。如果确实需要还原主数据库,最好在维护窗口中进行,并且准备好重新初始化辅助副本。根据引用[2],在初始化辅助副本时,我们使用还原操作(通过共享文件夹),所以在AG运行期间,还原操作要复杂得多。因此,我们给出更安全的建议:当主数据库出现严重损坏时:1.执行手动故障转移(到同步的辅助副本)2.在新的主副本上检查数据库状态3.在旧的主副本上,移除损坏的数据库,然后重新加入可用性组(此时,新主副本的数据库会自动同步到旧的主副本)而备份操作则按常规策略执行,并利用辅助副本进行备份(如果配置)。相关问题:1.在AlwaysOn可用性组中,如何配置事务日志备份在辅助副本上执行?2.如果主数据库发生页面损坏,如何在最小化中断的情况下修复?3.在AlwaysOn可用性组中,故障转移后如何恢复旧主副本?</think> ### SQL Server 2019 Always On 配置下的数据库备份与还原方法 在 Always On 可用性组(AG)环境中,备份还原需遵循特殊规则以保证高可用性。以下是关键操作指南: #### 一、备份操作(遵循自动化协调) 1. **备份首选项配置** 在 AG 属性中设置备份优先级: ```sql -- 查看备份首选项 SELECT replica_server_name, backup_priority FROM sys.availability_replicas; ``` - 主副本自动处理所有备份类型 - 辅助副本可承担**只读辅助备份**(需满足: • 可读辅助副本配置(`ALLOW_CONNECTIONS = ALL`) • 使用 `COPY_ONLY` 避免破坏日志链[^1] 2. **辅助副本备份示例** ```sql -- 在可读辅助副本执行 BACKUP DATABASE YourDB TO DISK = '\\SharedPath\YourDB_Full.bak' WITH COPY_ONLY, FORMAT; ``` #### 二、还原操作(主副本专属) 1. **还原前强制步骤** ```sql -- 1. 暂停数据同步 ALTER DATABASE YourDB SET HADR SUSPEND; -- 2. 执行日志备份(关键) BACKUP LOG YourDB TO DISK = '\\SharedPath\YourDB_TailLog.trn' WITH NORECOVERY; ``` > 说明:日志备份确保数据完整性[^1] 2. **完整还原流程** ```sql -- 3. 还原完整备份(保留待恢复状态) RESTORE DATABASE YourDB FROM DISK = '\\SharedPath\YourDB_Full.bak' WITH NORECOVERY, REPLACE; -- 4. 应用日志备份 RESTORE LOG YourDB FROM DISK = '\\SharedPath\YourDB_Log.trn' WITH NORECOVERY; -- 5. 恢复数据库 RESTORE DATABASE YourDB WITH RECOVERY; -- 6. 恢复AG同步 ALTER DATABASE YourDB SET HADR RESUME; ``` #### 三、特殊场景处理 1. **数据库损坏修复** - 主副本损坏:故障转移到辅助副本后再还原 - 辅助副本损坏:移除AG成员 → 还原 → 重新加入 2. **副本初始化** 新副本加入时直接通过AG自动还原(无需手动操作)[^2]: ```sql -- AG配置向导中选择"自动种子设定" ALTER AVAILABILITY GROUP YourAG MODIFY REPLICA ON 'NewNode' WITH (SEEDING_MODE = AUTOMATIC); ``` ### 关键注意事项 1. **备份位置**:所有备份需存储在所有副本可访问的共享路径(如 SMB/NFS) 2. **AG 状态监控**:还原前检查 `sys.dm_hadr_database_replica_states` 同步状态 3. **权限要求**:执行账号需具有`sysadmin`角色及共享路径写入权限 > **备份策略建议**: > - 每日完整备份(主副本) > - 每15分钟日志备份(辅助副本) > - 每月验证备份还原测试 --- ### 相关问题 1. 如何在 Always On 可用性组中配置自动备份故障转移? 2. Always On 环境下事务日志备份的最佳实践是什么? 3. 主副本故障时,如何在不丢失数据的情况下恢复可用性组? 4. Always On 可用性组与日志传送的备份方案有何本质区别? [^1]: 日志备份确保还原点与故障点一致,是 Always On 还原的核心步骤。 [^2]: 自动种子设定简化了新副本初始化过程,避免手动还原操作。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值