《高性能Linux服务器构建实战:系统安全、故障排查、自动化运维与集群架构》——3.5 实战:extundelete恢复数据的过程

简介:

本节书摘来自华章计算机《高性能Linux服务器构建实战:系统安全、故障排查、自动化运维与集群架构》一书中的第3章,第3.5节,作者:高俊峰著, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。

3.5 实战:extundelete恢复数据的过程

在数据被误删除后,第一时间要做的是卸载被删除数据所在的磁盘或磁盘分区,如果是系统根分区的数据遭到误删除,就需要将系统进入单用户,并且将根分区以只读模式挂载。这样做的原因很简单,因为将文件删除后,仅仅是将文件的inode结点中的扇区指针清零,实际文件还存储在磁盘上,如果磁盘以读写模式挂载,这些已删除的文件的数据块就可能被操作系统重新分配出去,在这些数据块被新的数据覆盖后,这些数据就真的丢失了,恢复工具也无力回天。所以,以只读模式挂载磁盘可以尽量降低数据块中数据被覆盖的风险,以提高恢复数据成功的比率。
3.5.1 通过extundelete恢复单个文件
1 . 模拟数据误删除环境
在演示通过extundelete恢复数据之前,我们首先要模拟一个数据误删除环境,这里我们以ext3文件系统为例,在ext4文件系统下的恢复方式与此完全一样。简单的模拟操作过程如下:

[root@cloud1 ~]# mkdir /data
[root@cloud1 ~]# mkfs.ext3 /dev/sdc1
[root@cloud1  mount /dev/sdc1  /data
[root@cloud1 ~]# cp /etc/passwd  /data
[root@cloud1 ~]# cp -r /app/ganglia-3.4.0  /data
[root@cloud1 ~]# mkdir /data/test
[root@cloud1 ~]# echo "extundelete test" > /data/test/mytest.txt
[root@cloud1 ~]# cd /data
[root@cloud1 data]# md5sum  passwd 
0715baf8f17a6c51be63b1c5c0fbe8c5  passwd
[root@cloud1 data]# md5sum  test/mytest.txt 
eb42e4b3f953ce00e78e11bf50652a80  test/mytest.txt
[root@cloud1 data]# rm -rf /data/*

2 . 卸载磁盘分区
在将数据误删除后,立刻需要做的就是卸载这块磁盘分区:

[root@cloud1 data]# cd /mnt
[root@cloud1 mnt]# umount /data

3 . 查询可恢复的数据信息
通过extundelete命令可以查询/dev/sdc1分区可恢复的数据信息:

[root@cloud1 /]# extundelete  /dev/sdc1  --inode 2
......
File name                                       | Inode number | Deleted status
.                                                 2
..                                                2
lost+found                                        11             Deleted
passwd                                            49153          Deleted
test                                              425985         Deleted
ganglia-3.4.0                                     245761         Deleted

根据上面的输出,标记为Deleted状态的是已经删除的文件或目录。同时还可以看到每个已删除文件的inode值,接下来就可以恢复文件了。
4 . 恢复单个文件
执行如下命令开始恢复文件:

[root@cloud1 /]# extundelete  /dev/sdc1  --restore-file passwd 
Loading filesystem metadata ... 40 groups loaded.
Loading journal descriptors ... 54 descriptors loaded.
Successfully restored file passwd
[root@cloud1 /]# cd RECOVERED_FILES/
[root@cloud1 RECOVERED_FILES]# ls
passwd
[root@cloud1 RECOVERED_FILES]# md5sum  passwd 
0715baf8f17a6c51be63b1c5c0fbe8c5  passwd

extundelete恢复单个文件的参数是“--restore-file”,这里需要注意的是,“--restore-file”后面指定的是恢复文件路径,这个路径是文件的相对路径。相对路径是相对于原来文件的存储路径而言的,比如,原来文件的存储路径是/data/passwd,那么在参数后面直接指定passwd文件即可,如果原来文件的存储路径是/data/test/mytest.txt,那么在参数后面通过“test/mytest.txt”指定即可。
在文件恢复成功后,extundelete命令默认会在执行命令的当前目录下创建一个RECOVERED_FILES目录,此目录用于存放恢复的文件,所以执行extundelete命令的当前目录必须是可写的。
根据上面的输出,通过md5sum命令校验,校验码与之前的完全一致,表明文件恢复成功。
3.5.2 通过extundelete恢复单个目录
extundelete除了支持恢复单个文件,也支持恢复单个目录,在需要恢复目录时,通过“--restore-directory”选项即可恢复指定目录的所有数据。
继续在上面模拟的误删除数据环境下操作,现在要恢复/data目录下的ganglia-3.4.0文件夹,操作如下:

[root@cloud1 mnt]# extundelete  /dev/sdc1  --restore-directory /ganglia-3.4.0
Loading filesystem metadata ... 40 groups loaded.
Loading journal descriptors ... 247 descriptors loaded.
Searching for recoverable inodes in directory /ganglia-3.4.0 ... 
781 recoverable inodes found.
Looking through the directory structure for deleted files ... 
4 recoverable inodes still lost.
[root@cloud1 mnt]# ls
RECOVERED_FILES
[root@cloud1 mnt]# cd RECOVERED_FILES/
[root@cloud1 RECOVERED_FILES]# ls
ganglia-3.4.0

可以看到之前删除的目录ganglia-3.4.0已经成功恢复了,进入这个目录检查发现:所有文件内容和大小都正常。
3.5.3 通过extundelete恢复所有误删除数据
当需要恢复的数据较多时,一个个地指定文件或目录将是一项非常繁重和耗时的工作,不过,extundelete考虑到了这点,此时可以通过“--restore-all”选项来恢复所有被删除的文件或文件夹。
仍然在上面模拟的误删除数据环境下操作,现在要恢复/data目录下所有数据,操作过程如下:

[root@cloud1 mnt]# extundelete  /dev/sdc1 --restore-all
Loading filesystem metadata ... 40 groups loaded.
Loading journal descriptors ... 247 descriptors loaded.
Searching for recoverable inodes in directory / ... 
781 recoverable inodes found.
Looking through the directory structure for deleted files ... 
0 recoverable inodes still lost.
[root@cloud1 mnt]# ls
RECOVERED_FILES
[root@cloud1 mnt]# cd RECOVERED_FILES/
[root@cloud1 RECOVERED_FILES]# ls
ganglia-3.4.0  passwd  test
[root@cloud1 RECOVERED_FILES]# du -sh  /mnt/RECOVERED_FILES/*
15M     /mnt/RECOVERED_FILES/ganglia-3.4.0
4.0K    /mnt/RECOVERED_FILES/passwd
8.0K    /mnt/RECOVERED_FILES/test

可以看到所有数据全部完整地恢复了。
3.5.4 通过extundelete恢复某个时间段的数据
有时候删除了大量的数据量,其中很多数据都是没用的,我们仅需要恢复其中的一部分数据,此时,如果采用恢复全部数据的办法,不但耗时,而且浪费资源,在这种情况下,就需要采用另外的一种恢复机制有选择地恢复,extundelete提供了“--after”和“--before”参数,可以通过指定某个时间段,进而只恢复这个时间段内的数据。
下面通过一个简单示例描述如何恢复某个时间段内的数据。
首先假定在/data目录下有个刚刚创建的压缩文件ganglia-3.4.0.tar.gz,然后删除此文件,接着卸载/data分区,开始恢复一小时内的文件,操作如下:

[root@cloud1 ~]# cd /data/
[root@cloud1 data]# cp /app/ganglia-3.4.0.tar.gz  /data
[root@cloud1 data]# date +%s
1379150309
[root@cloud1 data]# rm -rf ganglia-3.4.0.tar.gz
[root@cloud1 data]# cd /mnt
[root@cloud1 mnt]# umount /data
[root@cloud1 mnt]# date +%s
1379150340
[root@cloud1 mnt]# extundelete  --after 1379146740 --restore-all /dev/sdc1
Only show and process deleted entries if they are deleted on or after 1379146740
and before 9223372036854775807.
Loading filesystem metadata ... 40 groups loaded.
Loading journal descriptors ... 247 descriptors loaded.
Searching for recoverable inodes in directory / ... 
779 recoverable inodes found.
[root@cloud1 mnt]#  cd RECOVERED_FILES/
[root@cloud1 RECOVERED_FILES]# ls
ganglia-3.4.0.tar.gz

可以看到,刚才删除的文件已经成功恢复,而在/data目录下还有很多被删除的文件却没有恢复,这就是“--after”参数控制的结果,因为/data目录下其他文件都是在一天之前删除的,而我们恢复的是一个小时之内被删除的文件,这就是没有恢复其他被删除文件的原因。
在这个操作过程中,需要注意是“--after”参数后面跟的时间是个总秒数。起算时间为“1970-01-01 00:00:00 UTC”,通过“date +%s”命令即可将当前时间转换为总秒数,因为恢复的是一个小时之内的数据,所以“1379146740”这个值就是通过“1379150340”减去“60*60=3600”获得的。

相关文章
|
4月前
|
运维 应用服务中间件 持续交付
自动化运维的利器:Ansible实战应用
【9月更文挑战第33天】本文将带你深入理解Ansible,一个强大的自动化运维工具。我们将从基础概念开始,逐步探索其配置管理、任务调度等功能,并通过实际案例演示其在自动化部署和批量操作中的应用。文章旨在通过浅显易懂的语言和实例,为读者揭开Ansible的神秘面纱,展示其在简化运维工作中的强大能力。
217 64
|
3月前
|
Prometheus 运维 监控
智能运维实战:Prometheus与Grafana的监控与告警体系
【10月更文挑战第26天】Prometheus与Grafana是智能运维中的强大组合,前者是开源的系统监控和警报工具,后者是数据可视化平台。Prometheus具备时间序列数据库、多维数据模型、PromQL查询语言等特性,而Grafana支持多数据源、丰富的可视化选项和告警功能。两者结合可实现实时监控、灵活告警和高度定制化的仪表板,广泛应用于服务器、应用和数据库的监控。
417 3
|
2天前
|
存储 人工智能 弹性计算
2025年阿里云企业高性能云服务器租用价格与选型详解
随着企业数字化转型,阿里云于2025年推出多款高性能云服务器实例,涵盖计算、通用和内存密集型场景。文章分析了企业选择云服务器的核心要点,包括明确业务需求(如计算密集型任务推荐计算型实例)、性能与架构升级(如第八代实例性能提升20%),以及第九代实例支持AI等高算力需求。同时提供了配置价格参考和成本优化策略,助力企业实现效率与成本的最优平衡。
|
5月前
|
运维 安全 应用服务中间件
自动化运维的利剑:Ansible实战应用
【9月更文挑战第24天】在现代IT基础设施的快速迭代与扩展中,自动化运维成为提升效率、保障稳定性的关键。本文将深入探讨Ansible这一流行的自动化工具,通过实际案例分析其如何简化日常运维任务,优化工作流程,并提高系统的可靠性和安全性。我们将从Ansible的基础概念入手,逐步深入到高级应用技巧,旨在为读者提供一套完整的Ansible应用解决方案。
|
1月前
|
运维 自然语言处理 Ubuntu
解锁高效运维新姿势!操作系统智能助手OS Copilot新功能实战测评
阿里云OS Copilot经过多轮迭代,现已支持多端操作系统(包括Ubuntu、CentOS、Anolis OS等)及aarch64架构,极大扩展了其适用范围。新特性包括阿里云CLI调用、系统运维及调优工具的直接调用、Agent模式实装以及复杂任务处理能力。这些更新显著提升了用户体验和效率,特别是在处理紧急情况时,OS Copilot能快速查找并执行命令,节省大量时间和精力。此外,通过自然语言交互,用户可以轻松完成如系统健康检查、文件操作及日志分析等任务。总之,OS Copilot已从内测时的辅助工具进化为合格的贴身管家,极大地简化了日常运维工作。
|
3月前
|
消息中间件 缓存 架构师
关于 Kafka 高性能架构,这篇说得最全面,建议收藏!
Kafka 是一个高吞吐量、高性能的消息中间件,关于 Kafka 高性能背后的实现,是大厂面试高频问题。本篇全面详解 Kafka 高性能背后的实现。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
关于 Kafka 高性能架构,这篇说得最全面,建议收藏!
|
3月前
|
存储 SQL Apache
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
Apache Doris 是一个基于 MPP 架构的高性能实时分析数据库,以其极高的速度和易用性著称。它支持高并发点查询和复杂分析场景,适用于报表分析、即席查询、数据仓库和数据湖查询加速等。最新发布的 2.0.2 版本在性能、稳定性和多租户支持方面有显著提升。社区活跃,已广泛应用于电商、广告、用户行为分析等领域。
Apache Doris 开源最顶级基于MPP架构的高性能实时分析数据库
|
3月前
|
运维 监控 应用服务中间件
自动化运维的利器:Ansible实战应用
【10月更文挑战第41天】在现代IT运维领域,自动化已成为提高效率、减少错误的关键。Ansible作为一种简单而强大的自动化工具,正被越来越多的企业采纳。本文将通过实际案例,展示如何使用Ansible简化日常运维任务,包括配置管理和批量部署等,旨在为读者提供一种清晰、易懂的自动化解决方案。
56 1
|
3月前
|
运维 Ubuntu 应用服务中间件
自动化运维工具Ansible的实战应用
【10月更文挑战第36天】在现代IT基础设施管理中,自动化运维已成为提升效率、减少人为错误的关键手段。本文通过介绍Ansible这一流行的自动化工具,旨在揭示其在简化日常运维任务中的实际应用价值。文章将围绕Ansible的核心概念、安装配置以及具体使用案例展开,帮助读者构建起自动化运维的初步认识,并激发对更深入内容的学习兴趣。
100 4
|
3月前
|
消息中间件 运维 UED
消息队列运维实战:攻克消息丢失、重复与积压难题
消息队列(MQ)作为分布式系统中的核心组件,承担着解耦、异步处理和流量削峰等功能。然而,在实际应用中,消息丢失、重复和积压等问题时有发生,严重影响系统的稳定性和数据的一致性。本文将深入探讨这些问题的成因及其解决方案,帮助您在运维过程中有效应对这些挑战。
56 1

热门文章

最新文章