企业官网建设流程全解析

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或rsync

2.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才能用xfsdump，ext4请出门左转找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.dump

4.2 增量备份：级别1的正确打开方式

全量备份做完之后，后续的日常备份用级别1：

xfsdump -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 备份策略的排期建议

结合实际项目经验，我一般推荐这样的排期：

这个策略兼顾了恢复速度和存储成本。最坏情况下，恢复需要“最近一次全量+之后所有增量”，最多7个备份文件，恢复时间可控。

5. 恢复操作：从单文件到整机还原

5.1 恢复前的准备工作

恢复比备份更需要谨慎，因为一旦操作失误，可能把现有数据覆盖掉。恢复之前必须确认三件事：

1. 确认要恢复的目标位置。是恢复到原路径，还是恢复到临时目录先看看？
2. 确认备份文件的完整性。用xfsrestore -I可以查看备份文件的内容清单。
3. 确认目标文件系统有足够空间。恢复整机的话，目标分区大小不能小于源分区。

查看备份文件内容的命令：

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 /mnt

6.4 常见问题速查表

6.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恢复到CentOS8，xfs的版本差异可能导致恢复失败。跨大版本恢复，建议用rsync做文件级迁移，而不是xfsdump。这个坑我踩过，折腾了大半天才搞明白是xfs版本不兼容。