1. 为什么xfs的备份恢复值得单独拎出来讲但凡在生产环境摸过几年Linux的人大概率都遇到过这样的场景某台跑了两年多的业务服务器磁盘分区用的是xfs某天运维同学手一抖删了个关键目录或者文件系统因为异常断电出现了元数据损坏这时候你第一反应是“我有备份吗”第二反应是“xfs的备份到底怎么做才靠谱”。ext4时代大家习惯的那套dump/restore到了xfs这里基本就废了——xfs压根不支持传统的dump工具xfsdump和xfsrestore才是它的正牌搭档。这篇文章就是围绕CentOS7下xfs文件系统的备份和恢复这个主题把我在实际项目里踩过的坑、验证过的方案、以及那些文档里不会写的细节一次性讲透。不管你是刚接手CentOS7服务器的初级运维还是想给现有备份策略做一次体检的老手都能从里面找到能直接抄作业的东西。核心关键词就三个xfsdump备份、xfsrestore恢复、CentOS7 xfs运维。我会从方案选型讲到实操命令从增量备份的坑讲到跨机恢复的注意事项尽量做到你看完就能上手上手就不翻车。先说清楚一个前提本文所有操作基于CentOS7默认的xfs文件系统环境涉及的命令、参数、路径都是通用实践不针对任何特定业务场景。你拿一台测试机跟着敲一遍基本就能把整套流程跑通。2. 方案选型为什么是xfsdump而不是cp或rsync2.1 xfs文件系统的特殊性决定了工具选择很多人第一反应是“备份嘛cp -a或者rsync不就完了”。这话对了一半。如果你只是备份几个目录里的普通文件rsync确实够用甚至更好用因为它支持增量、支持远程、支持断点续传。但问题在于xfs文件系统层面的备份和文件层面的复制是两码事。rsync和cp走的是VFS层它们看到的是文件和目录看不到xfs的元数据、扩展属性、ACL、项目配额这些底层信息。你用它备份出来的东西恢复到新盘上权限可能对但xfs特有的那些属性大概率丢了。更关键的是如果文件系统本身出现了元数据损坏rsync可能连读都读不出来而xfsdump是基于xfs文件系统内部结构来读取的只要文件系统还能挂载它就有机会把数据捞出来。xfsdump的设计目标就是在xfs文件系统层面做备份它直接和xfs的底层打交道能完整保留文件系统的所有属性。这也是为什么CentOS7官方文档里xfs的备份恢复首选就是xfsdump/xfsrestore这一对工具。2.2 xfsdump的三种备份级别怎么选xfsdump支持三种备份级别这个设计借鉴了传统dump的思路但实现方式完全不同级别0全量备份把整个文件系统从头到尾备一遍不管文件有没有变过。这是基础第一次备份必须用级别0。级别1到9增量备份只备份自上一次更低级别备份以来发生变化的文件。注意这里的关键词是“更低级别”不是“上一次备份”。举个例子你就明白了。假设你第一天做了级别0的全量备份第二天做级别1第三天做级别2第四天做级别1。那么第四天的级别1备份对比的是第一天级别0之后的所有变化而不是第三天级别2之后的变化。这个逻辑和很多人直觉里的“增量”不太一样实际用的时候要特别注意。我个人的建议是生产环境用级别0加级别1就够了别搞太复杂的级别链。级别越多恢复的时候依赖的备份集就越多中间任何一个环节的备份文件丢了或者坏了整条链就断了。简单粗暴的“全量加增量”组合恢复逻辑清晰出问题的概率最低。2.3 备份介质的选择文件还是磁带xfsdump默认把备份写到磁带设备但CentOS7时代谁还用磁带啊。实际项目里我们都是用-f参数指定输出到普通文件比如/backup/rootfs.dump。这里有个细节备份文件不能放在你要备份的那个文件系统里面否则就是自己备自己越备越大最后把盘撑爆。正确做法是挂一块独立的备份盘或者备份到远程NFS挂载点上。如果你非要备份到同一个物理盘的不同分区也不是不行但风险很高。一旦这块盘物理损坏数据和备份一起没。所以我的原则是备份文件和源数据必须在不同的物理设备上这是底线。3. 实操前的环境准备与关键参数确认3.1 确认文件系统类型和挂载点动手之前先确认你要备份的到底是不是xfs。CentOS7默认根分区就是xfs但如果你是从CentOS6升级上来的或者手动改过也可能是ext4。用下面这条命令看一眼df -Th | grep -E xfs|ext4输出里Type那一列会明确告诉你文件系统类型。只有xfs才能用xfsdumpext4请出门左转找dump。确认是xfs之后记下挂载点比如/或者/data。后面所有命令里的路径都要和这个挂载点对应。3.2 安装xfsdump工具包CentOS7最小化安装默认不带xfsdump需要手动装yum install -y xfsdump装完之后验证一下版本xfsdump -V你会看到类似xfsdump version 3.1.7的输出。版本号不用太纠结CentOS7仓库里的版本足够稳定。3.3 备份文件存放位置的规划前面说了备份文件不能放在源文件系统里。假设你要备份根分区/那备份文件应该放在另一个分区比如/backup。如果服务器只有一块盘一个分区那就挂个NFS或者外接USB硬盘。规划好之后创建备份目录mkdir -p /backup/xfs这个目录的剩余空间要足够大。全量备份的大小基本等于源文件系统的已用空间但考虑到xfsdump的格式开销建议预留1.2倍的空间。比如根分区用了50G那备份分区至少留60G。注意xfsdump不支持备份已挂载文件系统的同时进行写操作的一致性快照。如果备份期间有大量写入备份出来的数据可能处于不一致状态。生产环境建议在业务低峰期做全量备份或者配合LVM快照使用。4. 全量备份与增量备份的完整操作流程4.1 第一次全量备份级别0全量备份的命令长这样xfsdump -l 0 -f /backup/xfs/rootfs_full.dump -L rootfs_full_backup -M rootfs_full_media /逐个参数解释一下-l 0指定备份级别为0也就是全量。-f /backup/xfs/rootfs_full.dump指定备份文件路径。-L rootfs_full_backup给这次备份的会话打个标签恢复的时候能看出来这是哪次备的。-M rootfs_full_media给备份介质打个标签多个备份文件放一起时方便区分。/要备份的挂载点。执行过程中你会看到进度条和统计信息最后显示xfsdump: Dump Status: SUCCESS就说明成功了。备份完成后检查一下文件大小ls -lh /backup/xfs/rootfs_full.dump4.2 增量备份级别1的正确打开方式全量备份做完之后后续的日常备份用级别1xfsdump -l 1 -f /backup/xfs/rootfs_incr_$(date %Y%m%d).dump -L rootfs_incr -M rootfs_media /这里用$(date %Y%m%d)给备份文件加了日期后缀方便管理。级别1的备份只包含自上次级别0以来变化的文件所以文件会小很多。但这里有个大坑xfsdump的增量备份依赖一个叫备份会话清单的东西它记录在/var/lib/xfsdump/inventory目录下。如果你把这个目录删了或者换了台机器做增量备份xfsdump就找不到上次备份的记录会直接报错退出。所以千万不要清理/var/lib/xfsdump/inventory目录除非你确定不再需要做增量备份了。4.3 备份策略的排期建议结合实际项目经验我一般推荐这样的排期备份类型频率执行时间保留周期级别0全量每周一次周日凌晨2点保留4周级别1增量每天一次每天凌晨3点保留7天级别1增量每月一次每月1号凌晨4点保留3个月这个策略兼顾了恢复速度和存储成本。最坏情况下恢复需要“最近一次全量之后所有增量”最多7个备份文件恢复时间可控。5. 恢复操作从单文件到整机还原5.1 恢复前的准备工作恢复比备份更需要谨慎因为一旦操作失误可能把现有数据覆盖掉。恢复之前必须确认三件事确认要恢复的目标位置。是恢复到原路径还是恢复到临时目录先看看确认备份文件的完整性。用xfsrestore -I可以查看备份文件的内容清单。确认目标文件系统有足够空间。恢复整机的话目标分区大小不能小于源分区。查看备份文件内容的命令xfsrestore -I -f /backup/xfs/rootfs_full.dump这会列出备份集里的所有文件和目录但不会真正恢复。你可以用它来确认某个文件是不是在备份里。5.2 恢复单个文件或目录这是最常见的场景误删了一个文件想从备份里捞出来。用-i参数进入交互模式xfsrestore -i -f /backup/xfs/rootfs_full.dump进入交互界面后用ls、cd浏览备份内容找到目标文件后输入extract命令然后quit退出。文件会恢复到当前工作目录下。如果不想交互也可以直接用-s参数指定要恢复的路径xfsrestore -f /backup/xfs/rootfs_full.dump -s /etc/nginx/nginx.conf /tmp/restore/这条命令把备份里的/etc/nginx/nginx.conf恢复到/tmp/restore/目录下。注意-s后面的路径是备份内的绝对路径恢复目标目录必须提前存在。5.3 整机恢复的完整流程整机恢复通常发生在系统盘损坏、需要换盘重装的场景。流程如下第一步用CentOS7安装盘启动进入救援模式。第二步挂载新的系统盘创建xfs文件系统mkfs.xfs /dev/sda1 mount /dev/sda1 /mnt第三步挂载备份存储执行恢复xfsrestore -f /backup/xfs/rootfs_full.dump /mnt第四步恢复完成后chroot进去修复引导mount --bind /dev /mnt/dev mount --bind /proc /mnt/proc mount --bind /sys /mnt/sys chroot /mnt grub2-install /dev/sda grub2-mkconfig -o /boot/grub2/grub.cfg第五步重启验证系统能否正常启动。注意整机恢复时如果原系统用了LVM新盘也要先建好对应的LVM结构否则恢复出来的/etc/fstab里的UUID对不上系统起不来。5.4 增量备份的恢复顺序如果你有“全量多个增量”的备份链恢复时必须按顺序来xfsrestore -f /backup/xfs/rootfs_full.dump /mnt xfsrestore -f /backup/xfs/rootfs_incr_20240101.dump /mnt xfsrestore -f /backup/xfs/rootfs_incr_20240102.dump /mnt顺序不能乱也不能跳。每个增量备份都依赖前一个备份的状态跳着恢复会导致文件版本错乱。6. 常见问题与排查技巧实录6.1 xfsdump报“session inventory”相关错误现象执行增量备份时提示xfsdump: ERROR: cannot open session inventory。原因/var/lib/xfsdump/inventory目录丢失或权限不对。解决检查目录是否存在权限是否为root:root 755。如果目录被删了只能重新做一次级别0全量备份之前的增量链就断了。6.2 备份文件比源数据大很多现象源分区用了50G备份文件却有70G。原因xfsdump会保留文件系统的元数据和扩展属性加上备份格式本身的开销通常比源数据大10%到20%。如果大得离谱可能是源文件系统里有大量小文件元数据占比高。解决预留足够的备份空间或者考虑用-z参数压缩备份文件但会消耗CPU。6.3 恢复后文件权限不对现象恢复出来的文件属主变成了nobody。原因恢复时没有用-p参数保留权限或者目标文件系统不支持xfs的扩展属性。解决恢复时加上-p参数xfsrestore -p -f /backup/xfs/rootfs_full.dump /mnt6.4 常见问题速查表问题现象可能原因排查命令解决方法增量备份报错inventory目录丢失ls /var/lib/xfsdump/inventory重新做全量备份备份文件过大元数据开销du -sh对比预留1.2倍空间恢复后权限错乱未保留权限ls -l检查加-p参数恢复后系统起不来引导未修复grub2-install救援模式修复引导备份速度慢大量小文件findwc -l6.5 几个文档里不会写的实操心得心得一xfsdump的备份文件是流式的不支持随机读写。这意味着你没法像tar那样直接tar -tf看内容必须用xfsrestore -I。这个命令在大备份文件上执行会比较慢耐心等。心得二如果你要备份的xfs文件系统挂载时用了norecovery或者处于只读状态xfsdump可能无法正常读取。确保文件系统是正常挂载的读写状态。心得三跨机器恢复时如果目标机器的xfs版本比源机器新一般没问题反过来则可能出问题。尽量保持源和目标机器的CentOS7小版本一致。心得四xfsdump不支持备份/proc、/sys、/dev这些虚拟文件系统备份根分区时会自动跳过。这是正常行为不用管。7. 备份方案的自动化与验证7.1 用crontab实现自动备份把备份命令写成脚本丢到crontab里#!/bin/bash BACKUP_DIR/backup/xfs DATE$(date %Y%m%d) if [ $(date %u) -eq 7 ]; then xfsdump -l 0 -f $BACKUP_DIR/rootfs_full_$DATE.dump -L full -M media / else xfsdump -l 1 -f $BACKUP_DIR/rootfs_incr_$DATE.dump -L incr -M media / fi find $BACKUP_DIR -name *.dump -mtime 30 -delete这个脚本的逻辑是周日做全量其他日子做增量自动清理30天前的备份文件。7.2 备份验证别等恢复的时候才发现备份是坏的备份做完不验证等于没备份。我一般用两种方式验证第一种用xfsrestore -I检查备份文件能否正常读取。能列出内容清单说明备份文件结构完整。第二种定期做恢复演练。挑一个备份文件恢复到临时目录对比几个关键文件的MD5值。这个操作每季度做一次确保备份真的能用。7.3 关于备份保留策略的补充备份文件不是越多越好。保留太多会占用大量存储保留太少又不够恢复。我的建议是全量备份保留最近4次增量备份保留最近7次每月做一次归档备份保留12个月归档备份可以放到更便宜的存储上比如NFS或者对象存储。但注意xfsdump的备份文件不能直接传到对象存储需要先落地到本地再上传。8. 一些容易忽略的边界情况8.1 文件系统UUID变化的影响整机恢复后新盘的xfs文件系统UUID和原来不一样。如果/etc/fstab里用的是UUID挂载系统启动时会找不到分区。解决办法有两个要么恢复后修改/etc/fstab里的UUID要么在mkfs.xfs时用-m uuid原UUID指定相同的UUID。8.2 SELinux上下文丢失xfsdump会保留SELinux的扩展属性但恢复时如果目标文件系统没有启用SELinux这些属性会丢失。恢复后可能需要执行restorecon -Rv /重新打上SELinux标签。8.3 大文件系统的备份时间窗口如果文件系统超过1TB全量备份可能需要几个小时。这种情况下建议用LVM快照先做一个瞬时快照然后对快照做备份这样不影响业务运行。具体做法是lvcreate -L 10G -s -n snap /dev/vg00/lv_root mount /dev/vg00/snap /mnt/snap xfsdump -l 0 -f /backup/xfs/rootfs_full.dump /mnt/snap umount /mnt/snap lvremove -f /dev/vg00/snap这个方案的前提是文件系统建立在LVM之上且卷组有足够的剩余空间做快照。8.4 备份文件的校验xfsdump本身不提供校验和功能但你可以用md5sum对备份文件做校验md5sum /backup/xfs/rootfs_full.dump /backup/xfs/rootfs_full.dump.md5恢复前先校验md5sum -c /backup/xfs/rootfs_full.dump.md5这一步能提前发现备份文件在传输或存储过程中是否损坏。9. 我个人在实际操作中的几点体会搞了这么多年CentOS7的xfs备份恢复最大的体会就是备份方案越简单越好恢复流程越熟越好。我见过太多团队搞了复杂的多级增量备份结果真出问题的时候运维同学对着备份文件不知道从哪开始恢复白白浪费了宝贵的恢复时间。另一个体会是定期演练比备份本身更重要。你备份做得再勤没验证过恢复流程真到用的时候大概率会出岔子。我现在的习惯是每季度抽一台测试机完整走一遍“备份-破坏-恢复”的流程把每个命令都重新敲一遍确保手不生。最后说一个细节xfsdump的备份文件在不同CentOS7小版本之间基本兼容但如果你要从CentOS7恢复到CentOS8xfs的版本差异可能导致恢复失败。跨大版本恢复建议用rsync做文件级迁移而不是xfsdump。这个坑我踩过折腾了大半天才搞明白是xfs版本不兼容。