MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下产品。MySQL 是最流行的关系型数据库管理系统之一，在 WEB 应用方面，MySQL数据库使用的比较多。

公检法部门在处理涉黄、诈骗的案件时，常常会遇到对涉案网站、论坛的服务器进行取证，有时嫌疑人为了毁灭罪证，故意删除数据，这就涉及到对MySQL数据库进行数据恢复、固定和取证。效率源科技的技术大咖针对一线办案人员遇到的痛点，写了这篇MySQL数据库删除数据的恢复指南，希望对办案人员有所启发。

binlog日志简介:

binlog 就是binary log，二进制日志文件，这个文件记录了MySQL所有的DDL和DML(除了数据查询语句)语句，以事件形式记录，还包含语句所执行的消耗的时间。

binlog日志包括两类文件：

1)二进制日志索引文件(文件名后缀为.index)：用于记录所有的二进制文件;2)二进制日志文件(文件名后缀为.00000*)：记录数据库所有的DDL和DML(除了数据查询语句select)语句事件。

binlog日志对于mysql数据库来说是十分重要的。在数据丢失的紧急情况下，可以尝试用binlog日志功能进行数据恢复操作。正是由于binlog日志以上的特性，在实际的案件取证中也可以通过binlog日志来恢复删除数据。要通过binlog日志恢复mysql数据库删除数据的前提：binlog日志确定是开启的。

查看binlog日志是否开启,有以下三种方法

方法一：打开MySQL数据库的配置文件(windows系统中的配置文件为my.ini，一般在安装目录的根目录下;Linux系统中配置文件为myf，一般在/usr/local/mysql/etc/目录下)，在配置文件中查看log-bin=MySQL-bin有没有被注释掉(每行第一个字符为#号表示该行被注释)，若没被注释表示开启，若被注释表示没有开启。

方法二：在MySQL命令行下使用show variables like ‘log_bin’;命令查看binlog日志是否开启，Value的值为ON表示开启，为OFF表示关闭。

方法三：在存放数据库的文件夹中是否存在mysql-bin.000001类似的文件，有则表示binlog日志功能是开启的。

在数据恢复过程中会用到的binlog日志操作命令

1、查看所有binlog日志列表：

在mysql命令界面输入命令： mysql> show master logs

2、查看master状态，即最后(最新)一个binlog日志的编号名称及其最后一个操作事件pos结束点(Position)值：

在mysql命令界面输入命令： mysql> show master status

3、刷新log日志，自此刻开始产生一个新编号的binlog日志文件：

在mysql命令界面输入命令：mysql> flush logs

注：每当mysqld服务重启时，会自动执行此命令，刷新binlog日志;在mysqldump备份数据时加 -F 选项也会刷新binlog日志

4、重置(清空)所有binlog日志：

在mysql命令界面输入命令：mysql> reset master

如何读取binlog日志中的内容?

1、使用mysqlbinlog自带查看命令法：

注: binlog是二进制文件，普通文件查看器cat more vi等都无法打开，必须使用自带的 mysqlbinlog 命令查看binlog日志与数据库文件在同目录中。

Mysql安装路径下的bin文件夹下输入以下命令：

C:\\xampp\mysql\bin>mysqlbinlog C:\\xampp\mysql\data\mysql-bin.000009

2、上面这种办法读取出binlog日志的全文内容较多，不容易分辨查看pos点信息，这里介绍一种更为方便的查询命令在MySQL的命令界面：

在mysql命令界面输入：mysql> show binlog events [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

选项解析↓

IN 'log_name'：指定要查询的binlog文件名(不指定就是第一个binlog文件)FROM pos：指定从哪个pos起始点开始查起(不指定就是从整个文件首个pos点开始算)LIMIT [offset,]：偏移量(不指定就是0)row_count：查询总条数(不指定就是所有行)

删除数据案例及操作步骤:

下面我们通过一个实例操作来完整查看「如何通过binlog日志恢复MySQL数据库删除数据。

案例介绍:

现有MySQL数据库，其中有名为test的数据库，其中没有任何的表，怀疑数据被删除，在该电脑中还发现了该数据库的备份，备份最后被修改的时间为2018-11-21 15:27:12。

目的:

查看是否有删除的操作，如有删除尝试恢复出删除的表的内容。

思路分析:

1、判断数据库是否开启了binlog日志的功能;

2、通过binlog日志查询是否有删除的操作;

3、若删除了数据，通过binlog日志恢复数据库中的内容。

下图就是通过binlog日志实现增量恢复数据库删除数据的流程：

01.判断数据库是否开启了binlog日志：

在MySQL命令行下使用show variables like‘log_bin’;命令中log_bin的Value为ON，该数据库的binlog日志是开启的。

02.判断数据库是否有被删除的操作：

1)在mysql命令界面通过show master logs;命令查看binlog日志列表，发现一共有8条日志。

2)在mysql命令界面通过命令show binlog events in 'mysql-bin.000008';可以查看最后两条命令为“use ‘test‘;delete from t1，use `test`;DROP TABLE `t1`”由此可判断出数据库test中t1表中的内容被清空了，并且把表也删除了。

03.恢复数据库中删除的数据：

1)由于表t1被删除了，没有该表的数据结构无法直接通过binlog日志来恢复删除的数据;但是我们在电脑中发现了该数据库的备份，直接还原后就可以得到表t1的数据结构。(这里不做还原的详细解说，如果您想了解还原详细操作步骤，可在后台留言)。

恢复出的数据结构

2)备份最后修改时间为2018-11-21 15:27:12，MySQL-bin.000008的创建时间为2018-11-20 14:15:40，可以推断出备份后表t1的所有操作都在该日志中。

3)在mysql命令界面使用命令show binlog events in 'mysql-bin.000008';打开最后一个日志文件，找出开始和结尾的pos点，分别为：4和1223，如下图：

4)提取日志文件该段落：在mysql安装界面的bin目录下输入一下命令：mysqlbinlog C:\\xampp\data\mysql-bin.000008 --start-position=4 --stop-position=1223 -r 1.sql，该命令把日志文件中的所有语句提取到了bin目录下的1.sql中。

5)通过分析该sql文件可以发现其中记录了每一条命令的执行的时间，找到备份创建时间2018-11-21 15:27:12之后的所有命令另存为2.sql。如下图：

6)另存为2.sql后，把最后两条删除的命令去除，直接在数据库中运行，就可以恢复出表中的所有数据。

注意事项:

1、在恢复之前一定要确认MySQL数据库的binlog日志是开启的;2、若把表删除一定要想办法把表的数据结构找到，这样才能准确的恢复出数据;3、binlog日志中是记录了每条语句的执行时间的，可以通过时间来恢复;4、在截取插入语句的时候一定要注意不要把最后一条删除的语句截取到，不然恢复的数据又会被删除。

以上就是效率源科技的技术大咖针对使用binlog日志恢复MySQL数据库删除数据的方法，希望上述的问题解决思路能给公检法一线办案人员一些参考和帮助。如对文中的操作、描述有任何疑问，或者有相关数据库恢复案件协助支持也可以直接联系效率源科技，获得技术协助。

随着科技越来越发达，现在手机的花样也越来越多了，什么全面屏、面部解锁、3D表情，真是让人目不暇接。由此也让手机成为了我们生活中必不可少的物品，这样的结果有好也有坏吧，我是比较倾向于好的一面。但是，随着使用手机的频次越来越多，也就意味着手机内产生的数据量越来越大，数据也越发变得重要！如何保护好自己的手机数据是一个问题，目前最好的方法就是开启自动备份数据或者定期手动备份数据了。但有些马大哈的朋友嫌麻烦就不做备份，导致哪一天不小心误删了手机文件或者手机发生意外数据丢失，这时候才来追悔莫及。

事实上，不小心丢失手机文件，及时采取措施的话还是可以将其恢复回来的，这是为什么呢？

一、为什么丢失的手机文件可以找回来？

这涉及到一个数据恢复的原理了，我们手机内的所有数据都存在数据库中，如果删除了手机数据，这块数据映射的数据库区域就会被标记为“未占用”状态，但此时数据还是存在于数据库中的，直到这块数据块区域被新数据占用了，原本的数据才会完全消失。所以，只要赶在删除数据被占用前就有机会对其进行恢复。

举个简单例子，存储在你手机数据库中的数据是这样子的：

数据丢失/删除后在数据库中是这样子的：

那我们要怎样赶在删除数据被新数据占用前将其恢复呢？

二、如何恢复手机已删除的文件？

切记先做好一件事情：不要再往手机存储新数据了，以免新数据把删除数据给占用了，到那时候神仙都救不回你的数据了。然后我们分别讲解安卓、iOS平台的数据恢复过程。

1、安卓手机恢复方法

安卓手机恢复数据最好先将手机给root了，用“强力一键Root”这个APP就可以给手机Root了，物如其名，一键就能Root，傻瓜化操作，非常简单，效果还不错。

然后再从应用商店下载个“手机数据恢复精灵”APP。

运行“手机数据恢复精灵”，进入界面可以看到他提供给我们的数据恢复功能。

根据需求选择数据恢复功能即可，对了，忘记告诉你一件事，如果是“图片恢复”的话就不用将手机Root哦，也就是说如果只用来恢复手机照片，前面Root手机的操作就不用做了。

进入“图片恢复”后，坐等结果出来，然后点击图片进行恢复即可。

其他的数据类型恢复同理。

2、苹果手机恢复方法

苹果手机的话，在App Store里找到“强力恢复精灵”这个APP并下载。

下载后运行，跟手机数据恢复精灵一样，他也提供了非常多的数据恢复类型选项给我们，根据需求选择即可。

接下来的步骤就跟手机数据恢复精灵差不多了，我就不再多讲。

以上就是手机文件的恢复技巧了，对你有帮助的请点个赞吧。

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

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...

Oracle数据库备份和还原操作说明

使用Oralce数据库导出(expdp)、数据库导入(impdp)程序在Oracle数据库之间传输数据对象，进行数据库的备份和还原。数据泵程序需要在数据库服务端使用。使用导出备份时可能产生数据不一致，所以需要先停止应用程序，再进行导出备份。

以下假设数据库账户为imanage，对同名的schema进行备份和还原。

因为Linux系统中有文件权限控制，请用oracle用户登录操作系统，再进行以下操作。

1. 创建备份目录

1. 在数据库服务器上手工创建文件夹，比如：/home/oracle/data_dp，用于存放备份文件。比如，启动一个终端会话，执行以下命令。

2. 启动一个终端会话，使用sqlplus以system帐户登入数据库，并执行如下语句创建和查看目录EXPDP_DIR。如图1所示。

说明：EXPDP_DIR对应数据库服务器上已存在的路径，请根据实际环境修改。

3. 如果想用8thManage数据库账户来备份，需要授予读写目录EXPDP_DIR的权限，执行如下语句。如图1所示。

图1

2. 备份

启动一个终端会话，先设置NLS_LANG参数，再运行expdp，使用system帐户导出imanage schema。执行以下命令，如图2所示。

参数说明：

ORCL：数据库网络服务名(使用Oracle Net Manager配置)

directory：导出文件保存目录

schemas：要导出的方案的列表

dumpfile：导出备件文件名

logfile：导出的日志文件名

图2

3. 还原

此处假设还原的目标数据库的schema为new_imanage（数据库用户），数据库表空间为new_imanage。

1. 在sqlplus中，使用system帐户连接数据库查看是否存在同名的数据库表空间。查看语句如下：

如果已存在同名的数据库表空间，则跳到第2步操作；

如果不存在相同的数据库表空间，需先创建，执行语句如下：

注意：datafile的路径是数据库服务器操作系统中的路径，请根据实际环境修改。

2. 在sqlplus中，使用system帐户连接数据库查看是否存在同名的schemas。查看语句如下：

如果已存在相同的schemas，需先删除再创建。

删除schemas语句如下：

创建schemas语句如下：

3. 启动一个终端会话，先设置NLS_LANG参数，再运行impdp，使用system帐户导入imanage schema。执行以下命令：

参数说明：

ORCL：数据库网络服务名(使用Oracle Net Manager配置)

directory：备份文件保存目录(比如值为EXPDP_DIR)

dumpfile：使用的备件文件名

logfile：导入的日志文件名

remap_schema：将一个方案中的对象加载到另一个方案

remap_tablespace：将表空间对象重新映射到另一个表空间

备注：

还原时impdp.log文件中出现以下ORA-编号开头的信息是正常的，可以忽略。

ORA-31684: 对象类型 USER:"XXX" 已存在

ORA-39082: 对象类型 XXX 已创建, 但带有编译警告

ORA-39126: 在 KUPW$WORKER.PUT_DDLS [TABLE_STATISTICS] 中 Worker 发生意外致命错误 （这是最后导入统计信息出错，可以忽略）

phpvod怎么备份数据库，phpvod如何恢复数据库。

登录phpvod网站后台，输入管理员的账号和密码，点击下方"提交"按钮登录。

进入后台之后，点击左侧菜单最下方的"数据库管理"，选择"备份数据库"，如下图所示。

勾选需要备份的数据库表，点击下方的"提交"按钮完成备份。

点击"数据库管理"下方的"恢复数据库",如下图所示。

选择需要恢复的数据库进行操作，如下图所示。

点击"数据库管理"下方的"数据库修复"，如下图所示。

勾选需要修复的数据库表文件，选择修复表或优化表，点击"提交"按钮，如下图所示。

借助专业的工具和手段对数据进行读取、抢救和恢复的技术称为数据恢复技术。

根据不同的存储介质，数据恢复可分为硬盘数据恢复、移动存储设备及多媒体卡数据恢复、光盘数据恢复、软盘数据恢复。本文分别介绍数据无法正常读取的原因及恢复方法。

硬盘数据恢复

故障原因：

1.物理故障

包括电机不转、通电后磁头错位、磁头损坏、盘片划伤等，可采用更换、加载、定位等方法进行数据修复。

2.其他原因

系统不能正常启动密码或权限丢失MBR分区丢失误操作误删除误分区病毒破坏黑客攻击RAID磁盘阵列失效

恢复数据包括：Office文档、图片、视频、数据库文件、邮件等

推荐工具：

R-Studio

美国的R-tools公司的核心产品，目前市面上认可度比较高的数据恢复工具，可针对文档、图片、视频、文件、数据库文件等超过200种文件类型进行恢复，并支持对分区以及Raid阵列的恢复。

Ontrack EasyRecovery

操作简单的数据恢复工具，针对常见的文档、图片、视频、文件等数据类型可以进行快速的扫描和恢复。

Recover数据恢复三件套

澳大利亚经典数据恢复软件，分为文件恢复、图片恢复和邮件恢复三个组件，每个组件各司其职，其中文件恢复组件是核心组件，具备其他两个组件的功能，可以对常见文件、图片、视频、邮件等进行数据恢复。

Stellar Phoenix Windows Data Recovery

印度Stellar公司出品，专门针对Windows系统中的文件恢复，可对文档、图片、视频、邮件以及常用文件恢复。

Stellar SQL Database Toolkit（SQL数据库恢复工具组）

Stellar公司产品，主要针对SQL数据库的文件恢复。

Stellar Outlook Toolkit（Outlook邮件恢复工具组）

Stellar公司产品，针对Outlook的专门工具，可以对损坏Outlook文件进行修复，并支持对Outlook生成的pst文件进行备份、复制、拆分等操作。

移动存储设备及多媒体卡数据恢复

故障原因：

常见短路、过电损坏、芯片损坏、闪存无法读取等

设备包括：U盘、闪存、Mp4、CF、SD、XD、MMC、SM、SMC、记忆棒等

推荐工具：

效率源Flash

光盘数据恢复

故障原因：盘片划伤

推荐工具：

VMI Hybrid2.0光盘修复工具

VMI2550i光盘修复工具

软盘数据恢复

故障原因：

数据介质损坏出现的电路故障、磁头偏移等

恢复方法：采用更换、加载、定位等方法进行数据修复

数据库文件对所有用户都很重要, 并存储大量重要信息。了解有关修复损坏的 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种最受欢迎的编程语言

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

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

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

前面介绍了误删部分数据恢复MySQL恢复delete的数据。部分数据恢复指的是非计划清理的那部分数据，存在恢复的需求的一点建议。通常情况下是碰不到这类问题的，做好准备也可以规避掉类似的问题。

有Delete误删数据，自然就联想到update误更新数据。本文探讨下MySQL update的数据恢复。

实际上update误更新数据的隐蔽性相对于delete更强，少数据了自然相对容易对比数目、数据的连续性等直观感受发现。而数据变更了，尤其是非字符型数据（字符型数据如标题、作者等。非字符型如类别ID，浏览量等）的变更，很难一眼就发现。比如有几十上百个分类属性，文章数几十万，在进行部分特征文章进行分类批量迁移时，误把不需要进行迁移的文章分类一并由编号33更改为了35，而此类文章可能本身就因为什么原因关注度就一般，迁移完都没有感觉哪里不妥。

此类情况很不易发现。虽然举的例子看起来关系很小，只是分类误更新了而已，后续还是可以发现了再调整。但如果这里调整的不是文章，而是有货币属性的，比如积分，代表用户可以透支的信用等级，甚至是利息，存款周期，货物价格等等。

来看一个鲜活的例子：

类似手滑的真实例子远不止这一两例。电商类的平台，想必价格管控复查等规范和流程都是健全的，依然避免不了意外（谁也不知道明天和意外哪个先来）。

虽然啰嗦，依然想再提醒下：后悔药数据恢复再次提醒：

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

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

3，数据库有Update、Delete、Insert、Truncate、Drop类操作，先在测试环境执行一次，看结果和预期是否相符。生产环境执行前，先对要操作的表做一个备份，以防万一。

4，备份，备份，备份。

如果真的按照上面的提醒来操作，也几乎不可能会出现误删的情况除非是SQL自身存在逻辑不严谨问题 :)

如果确实发现误更新了，怎么办？1，和delete相比，update有一个问题，就是要确认哪个数据才是最终更新前的可靠数据。Delete删除时，所删除掉的数据就是本条记录最终版本的数据，找回这条数据即可完整的恢复好本条记录。而update的变更版本多，所以确切的找回那条数据并能确认就是更新前的版本是一大关键，否则找回来的旧版本数据和当前误更新了的数据本质上是没有什么区别的：都不准。

2，如果开启了binlog且日志完整，则相对容易找回数据。将binlog解析出来后，把最终导致误更新数据的那条SQL注释或者删除掉然后恢复数据即可，可以可以参考MySQL恢复误删的数据 。

3，从备份中把数据恢复出来，进行比对。这里需要注意的依然是数据的有效性问题，备份的数据是历史版本旧数据，无法确认更新前的最终版本。可以用于参考，运气好的话，误更新的字段内容也许备份前就是最终版本，可以直接使用。

4，有书面的单据或者其他纸质的内容、邮件等，可以用于确认数据的，都可以用于找回数据。

如何最大限度避免误更新？1，不要使用数据库，则没有烦恼！

2，参考上面的提醒。

3，严谨的操作和执行到位的流程，可以很好的避免这类问题。

4，找我们后悔药数据恢复houhuiyao.cc来提供服务吧，我们又稳又好用，这些操作都熟。

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.数据恢复结论：

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

这世界上有后悔药-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吧！