数据恢复技术分享，和案例记录

某保险公司的8盘位AnyShare因异常断电，导致其中6块磁盘无法挂载，另2块可挂载但不确定是否有故障隐患。每块磁盘容量4TB，每块磁盘存储数据2.2TB，超17TB底层数据无法正常访问。客户联系多家数据恢复公司，均表示可以尝试恢复磁盘文件，但无法承诺AnyShare业务可正常访问此数据，更无法承诺AnyShare可以正常下载业务文档。客户联系了数寻工程师，我司保证恢复后AnyShare可正常访问恢复后的数据，保证AnyShare文档可以正常下载上传，且恢复时间可控。

客户在当地A数据恢复公司开盘恢复数据，但A恢复公司仅恢复了分块文件，未能恢复AnyShare专有库中的元信息数据，导致AnyShare无法读取文档云资料，第一次恢复宣告失败。我们收到硬盘后，进入无尘室，打开磁盘，发现磁头不见了，我们换上匹配的磁头，虽然已经是第二次开盘，但好在坏块不数多，真是万幸。之后客户咨询了数寻信息的恢复工程师，我们在了解此情况后，判断可以做二次开盘恢复数据，并且可以恢复专有库中的元信息数据。了解情况后，双方签订合同，客户将故障盘寄到数寻信息公司，我们开始开盘恢复。

第一时间运行DU_MySQL_Search_Linux扫描程序，可以提取到磁盘上所有的mysql碎片数据。如上图所示，已扫描出大量ibdfile数据碎片，以及frmfile表结构碎片，如果mysql曾经开启过binlog，还能扫描出被删除的binlog碎片，这些都可能是恢复出数据的关键，下载后发给恢复工程师即可恢复出数据。不管哪种情况，第一时间是停止所有操作，千万不要再往数据所在磁盘分区写入数据，包括文件复制、打包、解压、下载、安装软件等，都可能往磁盘写入大量数据，从而造成覆盖，导致数据物理上永久丢失。

2023.09.09下午客户联系数寻信息，寻求数据恢复服务，工程师分析后判断可以恢复数据，之后双方达成恢复协议，我们立即安排工程师进行数据恢复。经过工程师加班紧急支持恢复，在次日（9月10日，周日）上午10:55完成恢复，通知了客户进行远程数据验收。按合同工作量是3个工作日完成恢复，但用户非常紧急，我们决定紧急加班恢复，争取周末就为客户恢复业务。2023.09.08用户的MongoDB数据库被勒索病毒攻击，数据全部被清空。185七038七021 (V同号)

客户数据非常重要，数寻信息研发团队针对数据恢复方案与客户深度沟通，我们掌握客户数据的特征，发现其数据是按行保存，每一行都有Unix timestamp时间戳，但问题是时间戳位置不确定，长度也不确定，有的还带小数点。磁盘克隆方案的选择是极重要的，必须根据用户实际现场条件决定方案，此专用设备无法登录后台ssh，因此我们拆下数据盘，将期挂载到另一个干净的Windows下克隆，需要特别注意的是不能在Windows下对磁盘做初始化、格式化等操作，保证对磁盘是只读模式，否则将导致磁盘数据丢失。

湖南xx集团公司，采用MongoDB搭建数据库，保存集团商城订单数据，总数据量约50GB。2022年11月初MongoDB被黑客入侵，并清空全部MongoDB数据，导致集团办商城业宕机停止。为了数据安全考虑，我们不可在生产服务器上直接做恢复工作。对于云端服务器，则会在云端新搭建一套恢复机，用于数据恢复。了解到客户服务器部署在联通云上，我们第一时间让客户做了快照保护，以防止数据被进一步破坏。双方签订正式恢复合同后，我们当天立即启动数据恢复工作。协助客户搭建恢复环境，配置网络安全规则。

某建筑设计公司，采用MongoDB搭建GridFS存储桶，为办公文档流转提供底层存储，总数据量几十GB。2022年11月11日，技术人员清理磁盘空间时，误删除了大量MongoDB的存储文件，导致MongoDB宕机。客户对丢失数据的问题非常“上火“，晚饭都没有吃，我们恢复团队急客户之所急，加班处理，当晚恢复出数据，并帮客户导入到数据库中，MongoDB存储桶中的文件全部可以正常下载、打开也无异常。随后业务系统技术工程师继续做上线适配，直至11月13日全部处理妥当，恢复工作圆满结束。

故障简述平台：私有云存储操作系统：私有云操作系统磁盘数量：12块4TB磁盘某私有云存储安排周末例行升级维护，但运维人员误操作删除了私有云存储所有RAID，导致业务宕机。恢复过程此私有云存储有大量省财政厅办公资料，裸数据量为48T，但申请的业务停机时长仅为2天。要求在2天内完成数据恢复+业务重建上线，对数据恢复方案的效率和重建方案的配合提出了极高的要求。我们第一时间与私有云研发沟通了产品架构，获知私有云的每块磁盘创建raid0，在12个raid0上创建12个xfs文件系统，在每个x

故障简述2020.10.16日，深圳x医院ICU危重症信息系统MongoDB误删的第22号数据文件在运维时被误删，导致MongoDB宕机，ICU危重症信息系统瘫痪，医护人员只能采用“纸质+excel”临时记录。处理过程本司接到客户咨询后，第一时间对数据库目标卷做了dd克隆镜像，以保护数据不会被进一步覆盖破坏，如下命令将/data的分区做一个镜像存入于/backup/disk.img中：dd if=/dev/mapper/vg_fjsl-lv of=/backup/disk.img bs=1M同

申明：因甲方保密要求，在不影响事件表达的前提下，案例关键数据信息均采用不准确数，如有图片均对关键信息打码处理。申明：本文章涉及到的技术方法、恢复方案、数据、图片，严禁任何形式的转载/引用/记录，一切转载/引用/记录导致的不良影响及法律后果，均由转载/引用/记录者承担，且本文作者拥有追究转载/引用/记录者法律责任的权利，以及追偿转载/引用/记录者经济赔偿的权利。申明：本CSDN博主为数寻信息官方授权博客，已获准转载此文章。申明：本文章严禁任何形式的转载/引用/记录。故障简述平台

恢复工具及支持DU_MongoDB_Restore v5.2 2021.4.14 版本下载地址：链接：https://pan.baidu.com/s/175LSTgS5yOk6cHw466J2bg提取码：l6ry故障简述平台：华为云ECS云服务器操作系统：CentOS数据库：MongoDB 4.2数据量：数千个集合，共3TB数据2021年4月11日，某客户的 MongoDB遭到黑客勒索病毒攻击入侵，清空了所有库和wt 文件，并留下勒索信息；之后，因为客户业务无法停止，又陆续覆盖写入了20

某前台收银系统恢复日期：3月27日环境及故障：某前台收银系统，使用MS SQL Server ，部署在200GB SSD上，3月25日员工发现收银系统报错无法访问数据库。技术人员第一时间尝试复制数据库mdf和ldf，但复制mdf时报错ECC循环冗余校检失败，尝试用WinRAR打包时也同样失败。用户向多个数据恢复商家寻求帮助，但均被告知无法恢复，最终找到到数寻信息，我们远程查看，判断是SSD个别数据块损坏，导致数据库文件无法完整访问。我们用专业磁盘工具，跳过SSD故障区块，复制出其余完好的数据块，

Bug反馈、最新版本，以及恢复技术支持：QQ 568229095 核心功能1. MySQL 表碎片恢复当mysql被删库、删表、勒索病毒破坏后，因为表文件极易被部分覆盖、损坏，导致用文件恢复工具通常无法恢复出表文件，或者恢复出的表文件内容为乱码，mysql无法正常识别加载，这时需要用mysql碎片扫描工具扫描残存的表数据，可搜索mysql5/8版本InnoDB表碎片，包括独立表空间和共享表空间，上千案例实践经验，通常能恢复出90%以上数据碎片。2. binlog碎片恢复mysql默认自动循环删老旧

使用场景场景一binlog文件默认保存7天，因误删数据，需要用7天前的binlog恢复数据场景二binlog文件被损坏，mysqlbinlog解析时报错，不能解析出完整的binlog sql工作原理普通的文件恢复工具，都不能恢复被删除、部分覆盖的binlog文件。但目前所有binlog的解析工具，都要求用户提供完全正确的binlog文件才能正常工作。实际上，通常binlog文件比较大，就算已被删除，磁盘上仍有大量binlog碎片没被覆盖，如果能解析出这些binlog碎片，就能挽回很多损失。

继8月恢复XX市中国联通100GB 某生产业务库后，10月份又成功恢复了一起XX市中国移动误删30GB MySQL生产库案例故障简述2020年10月26日，XX市中国移动某运维人员不慎删除/usr/local/data下MySQL的整个datadir，涉及11个生产库，2个关键测试库，总数据量超过30GB。恢复过程步骤一：厘清生产环境，保护生产数据datadir在/usr/local/data下，并且与操作系统根目录在同一个50GB的根分区。操作系统会持续产生IO，覆盖被误删的生产数据，属高危场景

故障及环境信息联通内部私有云，部署CentOS系统上的MySQL，采用LVM管理，EXT4文件系统。其中一个1.3T chinaunicomvg-i1243 LV上的MySQL datadir被误删除，之后又初始化了新的datadir 。之后发现被删除的数据库为生产库，需要恢复。恢复思路及过程第一时间卸载目标卷，尝试用普通文件恢复工具扫描，但客户告知已经扫描过，生产库文件已被覆盖，无法恢复。我们采data-unit 自研的MySQL专用碎片扫描工具上传到有足够空间的目录下，扫描chinau

目录故障及环境信息恢复思路及过程故障及环境信息IBM老旧服务器，4块146GB SAS小盘，创建两个RAID1，部署windows系统和数据分区，并安装Oracle8，曾经用于存储关键财务数据，近年已停机。集团本月突然需要调用老的财务数据，而这台尘封多年的老机器，却无法正常开机运行。进RAID卡BIOS查看，发现4块盘中只有一块盘能上线！！！恢复思路及过程确认是硬件故障，立即建议客户停止上电的尝试， 将磁盘做好槽位标记，快递到数寻信息实验室，做专业数据恢复。在专业设备上，发现3号盘敲盘，2号

目录故障及环境信息恢复思路及过程故障及环境信息阿里云 CentOS下部署的MySQL数据库，用户误操作，导入了同名数据库建库，覆盖了生产库。然后用户删除了新建的库。恢复思路及过程1、首先考虑用binlog恢复，但是用户只有近7天的binlog，而生产库已经部署2年，不可能用binlog恢复数据。2、然后考虑恢复表文件，但是用户导入脚本创建的是同名表文件，然后再删除，所以用文件系统恢复工具，都只能找到覆盖的表文件，而不是生产表文件。3、最终只能用MySQL数据块扫描恢复的方案。以下为 MYSQ