1.硬件设备清单：

2.故障描述：

需要进行数据恢复的服务器是一台r520型号存储，共有7块SAS硬盘分别组成raid1和raid5两组磁盘阵列。主要sql server数据库存放在C盘中，在使用过程中，客户发现C盘容量即将占满，于是将数据库路径指向了D盘，在D盘生成了一个.ndf文件。客户在继续使用了大约10天之后，数据库出现故障，连接失效，无法正常附加查询。

3.备份数据：

考虑到数据的安全性以及可还原性，在做数据恢复之前需要对所有源数据做备份，以防万一其他原因导致数据无法再次恢复。使用dd命令或winhex工具将所有磁盘都镜像成文件。

4.故障分析：

(a)分析故障原因；由于数据库文件所在磁盘容量不足，导致数据库无法继续正常运行，出现逻辑错误。

(b)分析RAID组结构；客户服务器上共7块300G硬盘，其中2块硬盘做RAID 1，用于安装操作系统，其余5块硬盘做RAID 5存放数据。分析RAID 1和RAID 5的相关结构，重组虚拟出RAID 1和RAID 5，查看其中数据。

(c)分析原始数据库文件；由于客户在数据库发生故障之后，进行过多次数据库恢复尝试，并且每一次尝试都是在源环境下进行的，导致原始数据库文件被更改覆盖，并且磁盘空间被多次复写，无法使用尝试恢复之后的数据库文件进行修复。询问客户得知，客户在数据库发生故障的时候，备份过一分原始的故障数据库文件。

5.数据库修复：

从虚拟出的RAID 5空间中将客户之前备份的数据库文件拷贝出来，尝试在数据库中附加，附加失败，错误提示如下图一：

错误提示主数据库文件和次级数据库文件不匹配，查看.ndf文件底层，发现.ndf文件中几乎没有数据，尝试取消.mdf文件和.ndf文件之间关联，只用.mdf文件进行附加。尝试后发现，只用.mdf文件附加时也发生错误，但是错误提示改变。图二：

此时错误提示日志文件（.ldf）和数据库文件（.mdf）不匹配。之后对数据库尝试进行无数据库附加，附加成功。但是发现数据库系统表损坏，无法正常使用。图三

对数据库的系统表尝试修复，但由于系统表损坏过于严重，无法修复。数据库记录提取；解析数据库文件中的数据库记录；编写相应的程序提取数据库文件中的数据库记录；根据客户以前的数据库备份获取数据库中的表结构；重构表结构并肩提取出的数据库记录导入到新的表中。

6.数据验证：

由客户对提取出的数据库记录进行验证,所有数据完全恢复，本次数据恢复成功。

7.数据恢复结论：

在数据库使用过程中，要合理分配数据库文件所在磁盘空间，及时清理垃圾数据，保证数据库的正常、安全运行。

高可用性是数据库的关键指标，简单说就是要做到故障时间短，数据不丢失，能够回退到指定位置（时间/事务）。实现高可用的基础是数据库的备份与恢复技术。

PostgreSQL备份与恢复操作涉及的参数和相关文件较多，内部逻辑关系较复杂，恢复分类方式容易混淆，这些都会影响到PostgreSQL高可用方案的实现。

本文首先介绍通常的数据库故障场景与处理方案，然后通过梳理PostgreSQL数据库备份与恢复的相关文件、参数配置与主要流程，对PostgreSQL恢复方式进行了清晰分类，最后给出了应对典型故障，PostgreSQL备份与恢复的配置方案。

一、故障场景和处理方案

数据库采用数据文件加日志文件，两份数据的存储方式。为提高性能，数据库运行时操作的数据位于内存缓冲区，缓冲区的数据延迟写入数据文件，因此数据文件会处于不一致的状态。数据的变更记录称为日志记录，日志记录以日志文件方式存储在磁盘上。日志记录也是先写入日志缓冲区，再写入日志文件。通过两个简单的规则Write-ahead log（将数据写入数据文件前，先将对应的日志记录写入日志文件）和Force log at commit（事务提交时，将其所有日志记录写入日志文件），可以保证通过日志文件完整的恢复数据文件。

传统的故障类型包括事务内部故障、系统故障、介质（磁盘）故障。对于事务内部故障和系统故障，数据库使用日志文件自动恢复，不需要人工干预。为应对介质故障，DBA需事先备份数据，发生故障后，使用备份数据恢复数据库。

可靠的磁盘设备可以大幅降低介质故障概率，但不能减少数据备份工作。一个常见的故障是数据误操作，即修改了不应该修改的数据。从数据库的角度看，误操作是正常的操作，不会进行自动恢复，只有使用备份数据才能恢复。同时，提供一段时间内历史数据的访问，也是一个常见的需求。

数据的备份与恢复可以分为逻辑与物理两种方式。

逻辑备份与恢复：备份时，使用工具将数据全量导出为外部文件，恢复时，使用工具，将备份文件导入新建的数据库

物理备份与恢复：备份时，配置实例处于归档模式，将生成的日志文件保持到指定位置。使用热备工具直接拷贝数据的数据目录，作为基线数据。恢复时，使用基线数据和日志文件将数据恢复到一致的状态。

逻辑方式不支持增量方式，适用于数据较小情况下的备份与恢复。物理方式支持增量备份，适合大数据量的备份与恢复。本文只讨论物理备份与恢复，下图为物理备份与恢复的基本流程。

在高可用需求中，当单台实例发生故障，需要快速提供备用实例。备份基线数据+日志文件的方式无法满足时间要求。通常采用主备（master/slave）方案，master与slave通过日志流复制进行同步，slave可以提供只读数据访问，当master发送故障后，直接将应用请求转发到slave。

在高可用方案中，需要支持介质故障恢复，实时故障切换，误操作数据恢复，查看历史数据等功能。流复制技术和物理备份与恢复的结合，可以满足数据库高可用的基本要求。

流复制

物理备份与恢复

介质故障恢复

支持

实时故障切换

不支持

误操作数据恢复

查看历史数据

PostgreSQL备份与恢复相关文件、参数配置与主要流程

PostgreSQL日志文件的命名

日志序号 (lsn:log sequence number) 标识日志记录在日志文件中的位置。lsn是一个64位的整数。PostgreSQL运行时生成的日志文件存放在数据目录下的pg_xlog目录，每个日志文件称为一个segment，日志文件大小固定，由wal_segment_size参数指定，日志文件内部划分为多个wal page，每个page的大小由wal_block_size参数指定。

对于一个64位的lsn，可以计算出其所在的xlog文件名。lsn可以划分segment序号高位，segment序号低位和块内序号三个部分。对于segment大小为64M和16M的情况如下：

16M：segment序号高位（32比特）+segment序号低位（8比特）+块内序号（24比特）

64M：segment序号高位（32比特）+segment序号低位（6比特）+块内序号（26比特）

Xlog文件名由三部分组成，格式为：时间线+segment序号高位+segment序号低位，每个部分都表示为一个8位16进制数字。取出lsn中的segment高位和segment低位数值，就可以确定其所在的xlog文件。

使用pg_current_xlog_location()查询当前lsn为0/1C000090（16进制高32位/16进制低32位），当前时间线为1，wal segment大小为64M，

根据64M大小日志文件名格式，可计算出lsn的segment序号高32位为0x0，segment序号低位为0x7， 块内序号为0x90，xlog文件名为000000010000000000000007

使用pg_xlogfile_name_offset()可以查询lsn对应的文件名文件内偏移，与上述计算一致。

checkpoint与control文件

PostgreSQL的数据文件和日志文件互为冗余。当某lsn之前的操作已经全部写入了数据文件后，则该lsn号之前的日志文件可以丢弃。checkpoint机制实现此功能。

checkpoint操作在以下场景执行：管理员手工执行check命令、数据库启动完成恢复、数据库正常关闭，以及后台Checkpoint进程的定期执行。

checkpoint流程可以简单描述为，首先构造checkpoint记录（redo字段为当前已写入日志文件的lsn），然后将数据缓冲区中的脏数据写入磁盘，最后写入checkepoint日志记录（包含checkpoint记录），并将checkpoint记录写入control文件。

512字节的control文件是PostgreSQL的关键数据，用于数据库启动时，判断数据库状态和恢复位置。controlfile文件中记录了数据库的状态，最近checkpoint记录，最小恢复lsn信息和基本的参数配置。数据库的状态包括：

DB_SHUTDOWNED（数据库正常关闭）

DB_SHUTDOWNED_IN_RECOVERY（数据库在恢复时关闭）

DB_SHUTDOWNING（数据库启动到正常关闭过程中崩溃）

DB_IN_CRASH_RECOVERY（数据库在恢复过程中崩溃），

DB_IN_ARCHIVE_RECOVERY（数据库处于归档恢复）

DB_IN_PRODUCTION（数据库处于正常工作状态，等待接受事务处理）

日志文件的生成与归档

PostgreSQL日志文件的segment序号从1开始，一个日志文件写完后，会写入下一个序号的日志文件。checkpoint之后，最近一次checkpoint.redo lsn之前的日志文件可以丢弃。PostgreSQL会循环使用日志文件。checkpoint操作中，会将可丢弃的日志文件改名为未来的日志文件名，并该日志文件重新初始化。PostgreSQL在写新的日志文件时，如果该文件已存在，则使用该文件，否则才会创建新的文件。因此不能从pg_xlog目录中的文件名直接判断当前的日志文件，需要使用pg_current_xlog_location和pg_xlogfile_name_offset函数进行判断。

为持久保存日志文件，需要开启日志归档模式。在该模式下，可丢弃日志文件被删除前，被拷贝到指定目录。在postgres.conf配置文件中设置三个参数：

wal_level=replica 或更高archive_mode = onarchive_command = 'cp %p /mnt/server/archivedir/%f'%p表示pg_xlog目录路径和日志文件名，%f表示日志文件名。 日志被拷贝到/mnt/server/archivedir目录

日志的归档过程如下：

checkpoint操作中，当一个日志文件X可丢弃时，在pg_xlog的archive_status目中生成X.ready文件。

后台archive进程负责日志文件的拷贝。该进程监控archive_status目录，当发现有X.ready文件名后，使用archive_command拷贝文件，并将X.ready命名为X.done

下一次checkpoint操作中，将archive_status目中X.done对应的X日志文件改名。

crash recovery

PostgreSQL正常运行中，直接kill主进程，重启PostgreSQL，将进入crash recovery处理流程，从control文件中checkpoint的redo lsn位置开始，

使用pg_xlog目录中的日志文件进行恢复。PostgreSQL能进行上述处理，是因为将其状态和最近的checkpoint记录在在control文件中。

初始化数据库后，control文件DB状态初始值为shutdown。pg启动时，当control文件DB状态为shutdown，则将状态设置为production，退出恢复过程。在正常关闭服务时，执行checkpoint，并将control文件DB状态设置shutdown。pg启动时，当control文件DB状态为production，则说明发生了crash，会从control文件读取最近checkpoint，从redo lsn开始进行恢复，恢复完成后，将状态设置为production。

热备

备份分为冷备和热备。冷备是正常关闭服务后拷贝文件。热备是服务正常运行中拷贝文件。由于采用数据缓冲区机制，拷贝的文件数据会不一致。根据数据库恢复基本原理，只要确定某lsn之前的日志已经全部写入了数据文件，则在拷贝后的数据文件上，应用该lsn号之后的日志文件，可将数据恢复到一致的状态。

热备包括以下步骤

执行pg_start_backup函数:该函数执行checkpoint，将checkpont信息写入数据目录下的backup_label文件。

拷贝数据目录到指定位置

执行pg_stop_backup函数:该命令删除backup_label文件，写XLOG_BACKUP_END日志，并在pg_xlog目录中写入backup文件，该文件记录了热备开始和结束的lsn信息。

backup文件格式为：热备开始lsn对应的日志文件名.开始lsn的块内偏移.backup

使用归档日志恢复

Crash recovery只能使用pg_log目录中的日志文件进行恢复，启用archive recovery模式后，可以使用其它目录的日志文件（归档日志文件）进行恢复。

在数据目录存创建recover.conf文件，PostgreSQL启动时，读取到该文件，会进入archive recovery流程。在recover.conf中设置日志拷贝命令restore_command，pg恢复过程中，使用该命令将归档日志拷贝到pg_xlog目录后进行恢复。

restore_command = 'cp /mnt/server/archivedir/%f "%p"'%f表示日志文件名 %p表示目标路径和文件名

使用流复制恢复

流复制可以视为archive recovery的一种情况。使用归档日志文件进行恢复时，备机需要获取主机一个完整xlog文件，才可进行恢复。在流复制中，主机产生日志记录后，会及时发送到备机。

在slave节点数据目录的recover.conf中，配置到主机的连接信息primary_conninfo并设置standby_mode为on。

standby_mode = 'on'primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

master节点的postgres.conf文件中指定wal_level和发送日志进程的数目max_wal_senders。

wal_level=replica 或更高max_wal_senders=5

在master的pg_hba.conf文件中允许复制连接建立

host replication postgres 192.168.10.0/24 trust

slave启动后会启动wal reciver进程，根据primary_conninfo向master发送连接请求。master收到请求后，启动wal sender进程，wal sender与reciver建立连接。 wal reciver将起始的lsn信息发送给wal sender，wal sender从该lsn开始，将日志记录持续发送给wal reciver，wal reciver将日志写入pg_xlog目录中的日志文件，并通知恢复进程读取文件进行恢复处理。

恢复的退出与时间线

Crash recovery模式下，应用完pg_xlog目录中的所有可用日志文件后，自动退出恢复，进入运行状态。Archive recovery模式下，recovery.conf文件中参数standby_mode为off时，应用完所有日志后，自动退出恢复，进入运行状态。standby_mode为on时，应用完所有日志后，恢复流程不会退出，持续读取可用日志（来自于归档日志文件或流复制），当收到pg_ctl工具发出的promote命令后，才退出恢复流程，进入运行状态。

可以通过设置Recovery Target，使得archive recovery在指定的位置（时间或事务号）停止恢复。在recovery.conf文件配置如下参数，表示恢复流程在恢复完123947事务后结束。

recovery_target_xid = '123947'

时间线（Timeline）是PostgreSQL中的特有的概念。其初始值为1，退出archive recovery时，timeline增1，退出crash recovery时，timeline不变。Timeline反映在日志的文件名中，日志文件的命名格式为：时间线号+segment序号高位+segment序号低位。

引入时间线概念后，日志位置的唯一标识从lsn变为时间线+lsn，checkpoint的结构中记录了当前的timeline。

发生时间线切换时，在pg_xlog目录写入时间线history文件，文件名为"当前timelime.history"，文件内记录了时间线切换的历史纪录，每一行记录一条时间线信息，格式为。

parentTLI为时间线id，为切换发生后的lsn，为发生切换的原因。

从时间线history文件中，可以计算出每条时间线的开始和结束lsn。

时间线文件00000003.history，内容为1 0/14000060 no recovery target specified2 0/140420D0 no recovery target specified

该文件含义为当前时间线为3，时间线1的lsn范围[0/0,0/14000060)，

时间线2的lsn范围[0/14000060,0/140420D0)，时间线3从0/140420D0开始。

使用timeline有以下优点：

切换逻辑显得清晰。从时间线history文件，可以计算出每条时间线的开始和结束lsn。

避免归档日志的覆盖。当备机与主机的归档目录相同时，备机升级为主机后，生成的日志文件名与原主机不同（时间线不同），拷贝到归档目录后，不会覆盖之前的日志文件。

pg_basebackup、pg_rman工具

pg_basebackup和pg_rman为备份与恢复提供良好的操作管理界面，避免手工管理配置文件。

pg_basebackup是PostgreSQL自带的一个远程热备工具，可以将远程PostgreSQL热备到本地目录。其工作流程为，连接到一个远程PostgreSQL，执行pg_start_backup，将整个数据目录传输到本地，执行pg_stop_backup命令。

将地址为192.168.0.1的PostgreSQL，备份到本地usr/local/pgsql/data目录pg_basebackup -h 192.168.0.1 -U test -D /usr/local/pgsql/data

pg_basebackup支持在目标数据目录生成用于流复制的recovery.conf文件。

pg_basebackup -h 192.168.0.1 -U test -R -D /usr/local/pgsql/data

会在/usr/local/pgsql...

有的时候因为web服务器掉电或者其他原因意外重启导致数据库损坏，作为站长的我们可以使用mysql自带的mysqlcheck命令来快速修复所有的数据库。

1、在开始运行中输入CMD,启动命令行. 进入MYSQL的bin目录：

入图片描述

2、运行MYSQL自带的mysqlcheck修复命令

运行：mysqlcheck -A -o -r -uroot -p888888

注意，将888888改成你自己的root用户密码

然后就会自动进行修复操作：

注意：在修复过程中，如果看到有error的提示，表示这个表示坏的，无法修复的，对于含有坏表的数据库，你只能删除它，或停止它，不然会影响整个MYSQL的稳定，造成MYSQL自动停止。(提示"The storage engine for the table doesn't support repair"的表不需要处理)

如果修复太快看不到结果,可以运行

mysqlcheck -A -o -r -uroot -p888888 >>C:\mysqlerror.txt

将888888改为你自己的MySQL root密码，运行后打开C:\mysqlerror.txt就可以看到了.

是不是很方便呢，作为站长的我们很轻松的就可以掌握这个方法！

数据库文件对所有用户都很重要, 并存储大量重要信息。了解有关修复损坏的 SQL 数据库文件的手动和专业解决方案。　　今天的MS SQL Server是最常用的关系数据库之一。 它具有先进的内部结构并提供很高的可靠性。 这就是大多数组织使用SQL Server数据库来保存所有关键业务数据的原因。 但是也有一些情况，如病毒感染，操作系统故障，文件系统损坏等等，因为SQL数据库变得损坏，并且存储在其中的所有数据都不可访问。 从SQL Server中的损坏状态修复.mdf文件不是一件容易的事。　　用户可以使用手动技术来修复SQL数据库中损坏的MDF文件，但这不是一种可靠的方法，因为不能保证使用手动方法进行数据恢复。 但是，也有第三方工具，如SysTools SQL Recovery，声称以完美的方式修复.mdf文件。　　因此，在这篇文章中，我们将讨论修复损坏的SQL数据库的最佳解决方案。 但在此之前，了解SQL数据库中损坏的原因很重要。　　损坏的SQL数据库背后的原因　　在SQL Server数据库中出现腐败背后可能有各种可能的原因。 众所周知，SQL数据库的MDF文件是主数据库文件。 它们存储所有用户数据，因此MDF文件中的损坏可能会损坏整个数据库。 因此，首先，我们将讨论MDF文件损坏背后的所有可能的原因：　　存储介质中存储所有MDF文件的损坏。　　如果用户将SQL数据库存储在压缩文件夹中，则MDF文件可能会损坏。　　任何修改或更改都是在SQL Server帐户中完成的。　　用户可能意外删除了一些数据。　　如果文件头损坏，则会导致MDF文件损坏。　　损坏的磁盘驱动程序。　　如果SQL数据库正在使用，并且在两者之间存在网络故障，则会导致MDF文件损坏。　　导致MDF文件损坏的其他可能原因包括病毒攻击，硬盘故障，系统异常关机和突然断电。　　因此，如果MDF文件损坏，那么SQL数据库变得不可访问。 而且，如果用户试图访问损坏的数据库，则可能会遇到一些错误消息。 下面列出了最常遇到的错误消息：　　存储所有MDF文件的存储介质中损坏。　　如果用户将SQL数据库存储在压缩文件夹中，则MDF文件可能会损坏。　　元数据损坏错误。　　用户可能意外删除了一些数据。　　SQL Server/Msg 825 (读取重试) 中 SQL Server/Msg 824 中的 Msg 823 错误。　　除此之外，用户在访问损坏的SQL数据库时可能会遇到其他一些错误消息。 因此，数据库管理员有责任立即采取措施并防止任何类型的数据丢失。　　如何通过手动修复MDF文件　　有几种手动方法可用于修复损坏的SQL数据库，但手动解决方案不能保证数据库恢复。　　为了恢复损坏的数据库，用户可以使用SQL Server的NDF文件（日志文件）。但是, 只有日志文件不足以在大多数损坏情况下还原数据库, 因为有时, 由于严重损坏, 备份文件也会损坏。　　修复和恢复损坏的SQL数据库的另一种可能方法是在数据库控制台命令（即DBCC CHECKDB）的帮助下进行的。这对于在 SQL server 数据库中修复小的损坏问题非常有用。　　使用DBCC CHECKDB修复损坏的MDF文件的步骤　　首先，您需要通过执行以下查询在损坏的SQL数据库上运行DBCC CHECKDB：

注意：您还可以使用DBCC CHECKDB定义一些选项，如no_infomsgs和infomsgs。　　之后，您需要检查索引ID。　　情况1：如果索引ID> 1，则将其放下并重新创建。　　情况2：如果索引ID为0或1，则再次运行DBCC CHECKDB并使用适当的修复选项，如repair_rebuild，repair_fast或repair_allow_data_loss。　　

现在，为了确保零损坏，执行DBCC CHECKDB并显示一条消息，即DBCC CHECKDB在name_of_your_corrupt_database中显示0个分配错误和0个一致性错误。　　如果手动方法失败怎么办？　　手动解决方案并不总是一个万无一失的解决方案。 他们可能有一些限制。 例如，在严重损坏的MDF文件的情况下，手动失败很容易。 而且，手动解决方案要求用户在技术上强大。 因此，建议使用一些可靠的第三方软件来修复损坏的SQL数据库。 SQL数据库恢复程序是修复MDF文件中任何类型的损坏问题的最佳实用程序之一。　　SQL恢复工具能够修复损坏的SQL数据库文件 - MDF和NDF。 它是一款无风险软件，可恢复存储在其中的所有数据项，如表格，规则，触发器，函数等。除此之外，软件只需几次点击即可修复数据库，而不会浪费任何时间。　　从MDF文件修复损坏的SQL数据库的步骤　　在本地机器上下载并运行SQL Recovery Program。　　

之后，打开您选择的损坏的SQL数据库文件（.mdf文件）。　　

选择扫描模式，然后单击确定。　　

该工具将提供存储在损坏的MDF文件中的数据项的预览。　　

点击导出保存恢复的数据库。　　

结论　　数据库文件对于任何用户都非常重要，因为它们存储大量重要信息。 SQL数据库中的任何类型的损坏问题都可能给用户造成麻烦。 因此，为了克服所有这些问题，我们讨论了手动和专业解决方案来修复损坏的SQL数据库文件。

　更多阅读

12种最受欢迎的编程语言

软考网络工程师准备篇（二）：上午答题技巧

软考网络工程师备考篇（一）：考前准备

软件：用友，速达，管家婆，远光，奇安、金蝶、美萍、百威、广联达……等各种财务软件、医药软件、医院软件、汽配软件、服装软件、宾馆软件、书店软件、超市软件、OA办公自动化……等各种行业软件。

数据库：SQL，Oracle，Sybase，Access、dBase，FoxBase……等各种版本的新老数据库。

故障：数据库质疑，删除库内表，格式化，重做系统，重分区，系统还原，软件报错，数据错乱，备份覆盖，硬盘损坏……

收费：根据故障轻重和数据库文件的容量收费，500元起，数据库文件容量越大，工作量越大，耗时越长，收费越高。

涉密：如果客户数据涉密和隐私，可以签订《数据保密协议》，保证数据不会有任何形式的泄露。

一、数据库备份

1、打开企业管理器，如图所示操作

2、一般选择完全备份，添加备份目的

3、选择备份目录，输入备份数据库名称，接着按下图操作即可，直至完成备份

二、数据库还原

2、如果之前备份了库，在此处可以直接还原，请选择“在现有数据库上强制还原”

2、从设备还原，比如从别的服务器上拷过来的备份库，选择设备，添加还原设备，如下图操作即可，直至还原完成

3、如果还原时提示数据库正在被占用，可通过分离功能清除连接再进行还原；注意：使用分离功能只是清除连接，不要点“确定”真的分离数据库

这世界上有后悔药-houhuiyao.cc 后悔药数据恢复 站长语

前面介绍了MySQL数据库在使用InnoDB引擎时，如果误删了数据表，在共享表空间MySQL数据表InnoDB引擎表误删恢复(共享表空间ibdata1)和独立表空间MySQL数据表InnoDB引擎表误删恢复(独立表空间innodb_file_per_table=1)的情况下如何恢复数据。

本文将探讨下MySQL数据库误删恢复。

后悔药数据恢复提醒您：

1，首先需要说明的是，生产环境下慎重执行删除操作，除非你确实明白自己在做什么，否则不执行危险动作。

2，有条件的情况下，依靠系统来管理数据和数据库，尽可能降低依潜在的管理的风险。

3，数据库有Update、Delete、Insert、Truncate、Drop类操作，先在测试环境执行一次，看结果和预期是否相符。生产环境执行前，先对要操作的表做一个备份，以防万一。后续将针对每个危险动作如何在生产执行时即准备好危机应对动作做一个探讨。

4，备份，备份，备份。

数据库误删，不管是使用的rm -rf testdb还是drop database testdb，最终的效果都是一样的：数据目录下的testdb目录及目录下的文件都不可见了(和之前介绍的Linux下恢复删除的情况一致)，实际上文件内容依然还在那里如果没有数据覆盖上去的话。

#测试环境准备命令：mysql> create database testdb;Query OK, 1 row affected (0.08 sec)mysql> mysql> use testdb; Database changed mysql> mysql> create table aa(id int not null primary key, name varchar(20)); Query OK, 0 rows affected (0.34 sec)mysql> mysql> insert into aa values(1,'a'),(2,'b'),(3,'c'),(4,'d'); Query OK, 4 rows affected (0.17 sec) Records: 4 Duplicates: 0 Warnings: 0mysql> select * from aa; +----+------+ | id | name | +----+------+ | 1 | a | | 2 | b | | 3 | c | | 4 | d | +----+------+ 4 rows in set (0.00 sec)

testdb数据库表文件：

#删除数据库：#使用SQL命令 drop database testdb;#使用rm rm -rf testdb/

那么，这种情况下的数据库恢复动作就简单了，参考前面介绍Innodb引擎时的恢复方法即可：

1，完整的恢复testdb目录及目录下的文件即可找回删除掉的库名和表数据，然后针对具体的表引擎，将数据重新导入到数据库中即可。

2，如果找回的是非完整的，那么操作思路是一样的，能恢复多少恢复多少，剩余的如果实在找不回来，从最近一次的备份里提取，然后依靠其他手段比如单据来补全数据。

还是不知道怎么恢复MySQL数据库？找后悔药MySQL数据恢复houhuiyao.cc吧！

一、附加数据库与分离数据库相反，只有分离的数据库才能附加，分离后的数据库不能再正常读取，只有附加后才能读取；而还原数据库是指在原有数据库的基础上进行，一般选择覆盖原有数据库，SQL中如果不存在这个库是不能还原的（物理设备上要有库文件）。客户的服务器需要重装，小编是先备份原库（使用软件或SQL备份或停止SQL直接拷走数据库文件或在PE下拷走），重装完成后拷回原位置直接附加（个人经验附加始终比还原快），使用还原的情况比较少。还原数据库小编之前已经分享过，这里不再赘述。今天小编来分享下数据库的分离与附加。

二、分离数据库

1、选中要分离的库—右键“所有任务”—分离数据库

2、如果存在数据库连接可“清除”，点击“确定”

3、分离成功

三、附加数据库

1、要在“数据库”上右键—所有任务—附加数据库

2、附加数据库界面：点击按钮

3、选择要附加的数据库文件，注意要选择.MDF的文件，.LDF是日志文件

4、选择好后的界面，注意“指定数据库所有者”，有的是sa，有的是其它的，比如科脉是km

5、点击“确定”，附加成功

四、有时候轻度数据库置疑也可以通过“分离—附加”来修复，不过还是不建议这样做。我是百家号作者小白信息说，专注电子信息领域经验分享、技术交流，感谢关注！

一、上期我们分享了SQL2000数据库的备份与还原，这期我们再来分享下SQL2008数据库的备份与还原。

二、SQL2008数据库的备份

1、登录sql server management studio

2、选择要备份的数据库，右键—任务—备份

3、添加备份目标，并输入备份文件的名称

4、这是选择好后的显示页面，确定再确定即开始备份并完成

三、数据库还原

1、选择要还原的数据库—右键—任务—还原

2、如图，刚才备份的数据库会直接显示，可以直接还原

3、注意选项中要勾选“覆盖现有数据库”，“还原为”的路径一定确保正确

4、另外一种情况是通过源设备选择还原的文件

5、“文件类型”要选择所有文件，否则看不到备份是文件

6、勾选“还原”，确定即可完成还原

故障描述：

5块2T硬盘组建RAID5，划分LUN供windows服务器使用。在windows服务器内装有Sql Server2008数据库。存储空间内共有三个逻辑分区，大小分别为500G、800G、2.3T。数据库文件丢失，主要涉及五个数据库，表个数约为6000个左右。丢失原因未知，且不能确定数据存储位置。三个数据库的大小分别为8G、15G、20G。在文件丢失后服务器仍处于开机状态，但并未写入大量数据。

初检流程：

1、使用RAID信息及内部数据块信息重组RAID。

2、提取LUN内三个分区镜像。

3、扫描文件系统内丢失文件，未找到被删除数据库文件。

4、初检结果为数据库文件丢失，通过文件系统角度无法恢复。

恢复流程：

1、制定恢复方案。在数据库文件被删除且判定为无法恢复文件后，只能通过扫描数据页，并提取页内记录的方式进行恢复。

2、使用北亚自主编数据页扫描程序扫描分区内数据页并提取。在分别扫描两个分区镜像后发现500G系统盘内数据页数量极少且数据页断裂情况严重，另一分区内扫描到数据页个数较多。暂定此分区为数据库文件存储空间。

3、重组系统表。Sql Server数据库使用系统表来管理所有用户表，在这些系统表内记录了各表的列数、数据类型及约束信息等。解析系统表过程中发现提取出的数据页内系统表损坏，无法正常读取信息。在与客户沟通后得知有备份文件，且备份完成后没有大量改动表结构，系统表可用。

4、还原备份。

5、分别提取三个库中各表表结构信息

6、解析表结构脚本。将各表的列信息存入数据库内便于后续使用。

7、解析系统表获取用户表id信息、关联表结构与数据页。（为保护客户隐私，后续步骤涉及用户表表名及数据页内数据部分均未截图）

8、新建数据库，使用北亚自主编写软件解析记录并导入到恢复环境内。

9、整理恢复结果。在此分区内除数据库文件外还存有备份文件若干，所以在导出记录后可能存在重复数据，必须去重。编写SQL存储过程进行去重。

10、客户验证数据。客户在查验过数据后表示数据可以接受，移交数据到客户存储设备，恢复成功。