随缘惜情Linux下做备份恢复，大多数人第一反应就是tar、rsync，再时髦一点就是BorgBackup、Restic这些新工具。但你要是去问那些管了十年以上生产环境的老运维，他们硬盘角落里大概率还躺着一个叫dump的命令。说真的，在ext2/ext3/ext4文件系统上做备份，dump这套老牌工具到今天依然能打，尤其是它那一套多级增量备份的机制，tar想做到同等效果得费不少劲。这篇文章就专门聊dump命令，从原理到参数，从全量备份到增量恢复，再到我踩过的各种坑，一次性给你梳理清楚。
dump命令不是什么黑科技，它是基于文件系统层面的备份工具，盯的是inode而不是单纯的文件列表，所以它能完整还原整个文件系统的逻辑结构。这篇文章适合谁看？正在维护老旧ext系列服务器的运维，想把某台机器做成可快速恢复的灾备方案的工程师，以及学Linux命令大全想系统掌握备份压缩这块知识的初学者。我尽量把关键参数和实操细节都讲明白，你可以直接照着抄作业。
1. 先搞清楚dump到底在备份什么：文件系统视角
1.1 dump的设计逻辑：盯的是inode，不是文件列表
很多人对dump有个误解，觉得它跟tar一样，就是把一堆文件打包到一起。这个理解不准确。tar的工作方式确实像抄写员，拿着目录清单一个个把文件读出来归档；但dump的工作方式完全不一样，它直接操作的是文件系统的底层结构，也就是inode。
每个文件在ext4文件系统里都对应一个inode，inode里存着文件的元数据，包括权限、属主、属组、时间戳、文件大小、数据块位置这些信息。dump备份的时候，会遍历整个文件系统的inode表，把正在使用的inode连同它们指向的数据块一起读取出来。这意味着什么？意味着它备份的不只是文件的“内容”，而是这个文件在文件系统里的完整“身份”。你用dump备份再恢复出来的目录，时间戳、ACL权限、稀疏文件特征这些细节都能保得住，这一点在很多合规审计场景里非常关键。
这种基于inode的设计还给dump带来了一个天然优势：它天然理解文件系统的结构，知道哪些数据块属于哪个文件。所以恢复的时候不需要像tar那样一个文件一个文件地重建目录树，而是可以按inode直接重放数据块，恢复速度在数据量大的时候优势很明显。当然代价也有，就是dump跟文件系统强绑定，换个不认识的文件系统它直接罢工，这个后面会说。
1.2 什么场景我会优先选dump，而不是tar和rsync
我自己的使用习惯是这样的：如果只是给某个目录打压缩包传走，那tar没问题；如果是两台服务器之间做数据同步，rsync是首选。但如果你需要给整个分区做定期备份，而且希望保留文件系统级别的完整元数据，还要支持多级增量备份，那dump才是正确答案。
举一个我实际做过的例子。之前有一台CentOS 6的旧服务器，上面跑着公司内部的一堆业务数据，文件系统是ext4，数据量大概七八百GB。原来的备份方案是每周用tar全量打包一次到另一台机器上，后来数据量涨上来之后，每次tar都要跑四五个小时，占用大量IO，白天业务高峰期根本不敢动。后来我换成了dump方案：周日凌晨做一次level 0全量备份，周一到周六分别做level 1增量备份，每天增量部分只有几个GB到几十GB，几分钟就跑完了。这样一来，每天都有可用的备份点，恢复的时候先恢复level 0、再叠加level 1，最多丢一天的数据，成本比每天全量低太多。
再一个场景是磁带机备份。很多老机房还有磁带库，tar写磁带当然能用，但dump对磁带介质的支持更完善，包括多卷备份、跨磁带这些操作，dump的参数设计得更顺手。虽然现在磁带越来越少见了，但如果你在维护老设备，这个点值得知道。
1.3 dump的边界：哪些文件系统用不了，别踩坑
dump最大的限制就是文件系统类型。它原生支持的是ext2、ext3、ext4这一脉的Linux文件系统，用在这些上面很顺手。但你要是对新出来的XFS、Btrfs、ZFS用dump，它只会甩给你一句“unknown file system format”，根本不会开工。XFS有专门的xfsdump工具，Btrfs和ZFS一般直接用自身快照功能做备份，这些都不是dump的活儿。
另外有几个硬性条件你必须清楚：
- 得有root权限。dump要读取inode表，需要直接访问块设备，普通用户权限不够。
- 备份目标设备和源设备不能是同一个，否则会出现写入期间数据不一致的问题。
- 对正在挂载且可写的文件系统做dump有风险，因为备份过程中文件可能在变化。稳妥的做法是把分区挂载为只读，或者配合LVM快照来做。
- 单文件超过2GB的老版本dump会有问题，现代发行版打包的dump基本都支持大文件了，但如果你还在用很老的系统，建议先测一下。
搞清楚这些边界之后再下手，能省掉后面一大半的坑。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. dump命令核心参数逐个拆解
2.1 最重要的一组参数：备份级别与目标文件
dump命令最核心的其实是两个参数：备份级别和备份目标。先看备份级别，这是dump增量备份机制的命门。dump把备份分成0到9一共十个级别，级别0表示全量备份，备份整个文件系统；级别1以上的备份，只备份自上次更低级别备份以来发生变化的文件。
我来解释一下这个“更低级别”是什么意思。假设你设定了这样的备份节奏：周日做level 0，周一到周六每天做level 1。那么周一的level 1，会备份周日level 0之后所有变化过的文件；周二的level 1，按理说也是备份自上一次level 0（也就是周日）以来的变化，而不是只备份周一以来的变化。也就是说，level 1备份的是整个周期内变化的文件总和。那如果周一做level 1、周二做level 2呢？周二的level 2就只备份自周一level 1以来变化过的文件，会比level 1小很多。
这个机制给你很大的灵活度，可以设计出金字塔式的备份策略：比如每月做一次level 0，每周做一次level 1，每天做一次level 3。恢复的时候按顺序从低级别到高级别依次恢复就行。我看很多人一上来就用level 1做每日备份，结果每天都备份一整天变化的文件，体积比预想大很多，这就是没理解“更低级别”的含义。
然后是-f参数，它指定备份输出到哪里。常见的有三种写法：
code复制dump -0uf /backup/sda1-level0.dump /dev/sda1
dump -0uf /dev/st0 /dev/sda1
dump -0uf - /dev/sda1 | ssh backup-server "cat > /backup/sda1-level0.dump"
第一种是备份到本地文件，第二种是备份到磁带设备（/dev/st0是常见的SCSI磁带机设备名），第三种是备份到标准输出，再通过管道传给远程主机或者压缩工具。我平时最常用的是第一种和第三种，尤其是第三种，可以组合gzip或者pigz多线程压缩，备份大分区的时候省不少时间。
2.2 实用参数组合：压缩、更新记录、查看状态
接下来这几个参数是我每次用dump基本都会带上的，它们能让你对备份过程和结果有完整的掌控。
-u参数：备份完成后，把这次备份的记录写入/etc/dumpdates文件。这个文件很重要，dump做增量备份的时候要依赖它来判断文件的变化情况，如果你不带-u，后续的增量备份可能无法正确工作。所以我的建议是，不管你做的是全量还是增量，都加上-u，让它把每次备份的级别、时间、设备都记下来。
-j参数：用bzlib库对备份内容做压缩。实测下来，纯文本、配置文件比较多的分区，压缩率非常可观，能压掉百分之六七十；但是对已经压缩过的视频、图片、压缩包就没啥效果了，反而白白消耗CPU。所以我一般是在混合负载的分区上开-j，如果是纯多媒体目录，就不开压缩，靠磁盘容量硬扛。
-W参数：显示哪些文件系统需要备份。这个参数会读取/etc/fstab和/etc/dumpdates，把每个文件系统的最后备份时间和级别列出来，并标注出哪些已经超过建议备份周期。我很喜欢先跑一下dump -W再决定这次要做什么级别的备份，心里有数。
-h参数：指定备份时忽略级别大于某个值的文件。举个例子，如果某个文件被设置了nodump属性（chattr +d testfile），那么dump -h 1就会跳过这个文件。这个参数适合用来排除那些不重要的临时文件或者缓存目录。
2.3 冷门但关键时刻能救命的参数
dump里还有几个参数平时用不到，但真遇到特殊情况时能救命，我说几个我觉得值得记一下的。
-L参数给每卷备份加一个标签。这个标签在恢复的时候会显示，方便你确认手里这卷磁带或者文件是哪个级别的备份、对应哪个分区。做过大量磁带备份管理的人应该都懂，几十盘磁带堆在那，没有标签简直是一场灾难。
-T参数指定一个日期，告诉dump“从这个时间点开始，才算上次备份之后的变化”。这个参数通常配合-u使用，在特殊场景下比如手动补做备份时会用到。比如你上次备份是周一，但数据在周日下午被误删了，你想从周日的某个时刻开始增量备份，就可以用-T指定那个时间点。
-n参数：备份完成后或者出错时，通知所有在/etc/operator组里的用户。这在自动化任务里有点用，出问题能第一时间收到系统日志。不过说实话，现在都有更完善的监控告警手段，这个参数的使用频率不高。
-M参数：启用多卷备份模式。如果你的备份目标是一堆小容量的磁带或者U盘，dump会在写满一卷后停下来提示你换下一卷。这个机制在老旧磁带备份场景下非常经典，我做过一次磁带全量备份就是靠它搞定的。
3. 实操篇：从全量备份到增量恢复的完整流程
3.1 动手前的环境检查与空间估算
直接上手敲dump之前，有几个准备工作要做，不然很容易白干活。先确认你的文件系统类型，用一条命令就能看：
code复制df -hT
如果文件系统类型显示是ext2、ext3、ext4，那就可以用dump。如果显示xfs，换个思路用xfsdump。接着检查一下当前文件系统是不是干净的状态，我习惯在备份前跑一下文件系统检查：
code复制e2fsck -n /dev/sda1
这里加-n表示只读检查，不做修复，避免在系统运行的时候误改动文件系统。输出里有“clean”字样说明文件系统状态正常。如果你拿到的文件系统dirty标记比较严重，建议先找个维护窗口彻底检查，否则备份出来的数据可能有隐患。
然后估算备份体积。我最常用的办法是先看文件系统实际占用了多少空间：
code复制df -h /data
比如显示已用300GB，那么全量备份的体积不会小于这个数太多，因为备份还会带上一些文件系统元数据。如果是-j压缩，体积就看文件类型了。想精确点，可以先做一次“哑备份”测一下大小，所谓哑备份就是把备份写到/dev/null：
code复制time dump -0uf /dev/null /dev/sda1
这个命令会完整执行一次level 0备份流程，但数据不落盘，看它跑的时间和输出信息，你就能估算出真正的备份文件大概有多大，也能测出耗时多少。注意这里的输出会包含块大小、备份级别、总共备份了多少兆字节这些信息，很有参考价值。
3.2 第一次全量备份：level 0执行与验证
做完准备工作，就可以开始第一次全量备份了。我的习惯是先建立一个规范的备份目录，比如：
code复制mkdir -p /backup/hostname/
然后执行level 0备份，这是整个备份体系的基石：
code复制dump -0juf /backup/hostname/sda1-level0.dump /dev/sda1
解释一下这条命令里每个字符的含义：0表示level 0全量，j表示启用压缩，u表示记录备份信息到/etc/dumpdates，f指定备份输出文件。如果你觉得压缩太耗CPU，也可以去掉j，备份速度会快一些，但占用磁盘空间更大。
执行过程里dump会输出一堆信息，包括DUMP日期、备份级别、文件系统标签、inode数量，最后还会统计备份了多少MB、多少秒。第一次跑的时候多留意有没有“file system is busy”这类警告。如果文件系统处于挂载状态且被实时写入，dump会警告数据可能不一致，但一般不会中断备份。
备份完成后要做三件事验证结果。第一件事，查看/etc/dumpdates里是否多了这次备份的记录：
code复制cat /etc/dumpdates | tail -5
第二件事，看一眼备份文件的大小和完整性：
code复制ls -lh /backup/hostname/sda1-level0.dump
restore -tf /backup/hostname/sda1-level0.dump | head -20
restore是dump配套的恢复工具，-t参数是列出备份内容，-f指定备份文件。能列出内容，说明这个备份文件结构是完好的。第三件事，如果条件允许，找一台测试机把备份恢复到临时目录里，确认关键文件能正常读出。这一步很多人会跳过，但我强烈建议至少做一次，因为备份不是为了备份，是为了恢复。
3.3 增量备份实战：level 1配合自动化定时任务
全量备份做完之后，后续的增量备份就轻松了。比如第二天想备份当天变化的数据，跑一条level 1：
code复制dump -1juf /backup/hostname/sda1-level1-$(date +%Y%m%d).dump /dev/sda1
注意这里我习惯把日期写进备份文件名，这样每个备份文件对应哪一天一目了然。level 1备份的执行时间通常比level 0短很多，因为只备份变化部分。
要想让这套备份方案真正变成“日常自动运行”，我一般用crontab来驱动。举个例子，每天凌晨2点做level 1增量备份，每周日凌晨3点做level 0全量备份，可以写两个脚本或者直接用crontab命令行：
code复制# 每天凌晨2点做level 1增量
0 2 * * * /usr/sbin/dump -1juf /backup/hostname/sda1-level1-$(date +\%Y\%m\%d).dump /dev/sda1
# 每周日凌晨3点做level 0全量
0 3 * * 0 /usr/sbin/dump -0juf /backup/hostname/sda1-level0-$(date +\%Y\%m\%d).dump /dev/sda1
注意crontab里%要加反斜杠转义，这是个容易踩的坑。另外，我建议把dump的输出重定向到日志文件里，方便排查问题：
code复制0 2 * * * /usr/sbin/dump -1juf /backup/hostname/sda1-level1-$(date +\%Y\%m\%d).dump /dev/sda1 >> /var/log/dump.log 2>&1
跑上一阵子之后，记得再看一眼dump -W，它会把这些备份记录理清楚，告诉你上次备份是什么级别、什么时间，帮你确认这套自动化策略是否正常运转。
3.4 用restore恢复：交互模式与重建模式
备份做得好不好，最后要看恢复能不能成功。restore是dump的配套恢复命令，主要有三种用法：查看内容、交互式恢复、重建整个文件系统。
查看内容前面已经见过：
code复制restore -tf /backup/hostname/sda1-level0.dump | grep 文件名
交互式恢复适合按需恢复个别文件或目录。举个例子，我想从备份里恢复/etc/nginx/nginx.conf这个文件：
code复制restore -if /backup/hostname/sda1-level0.dump
进入交互界面后，restore会显示类似shell的提示符，支持ls、cd、add、extract、quit这些命令。操作思路是：先用ls和cd浏览备份内容，找到想要的目录后，用add把目录或文件加入恢复列表，最后执行extract开始恢复。恢复出来的文件默认放在当前工作目录下，所以操作前最好先cd到一个临时目录，避免覆盖到系统真实文件。
重建整个文件系统的场景更偏灾难恢复。比如系统崩溃，你重新挂了一块硬盘、重新格式化并挂载到某个目录，然后需要把备份完整倒回去。这时候用restore -r：
code复制restore -rf /backup/hostname/sda1-level0.dump
如果还有增量备份，顺序是先恢复level 0，再依次恢复level 1、level 2……注意顺序不能乱，否则后面的恢复会被前面的覆盖掉。我处理过几次误删找回的需求，都是先用交互模式在临时目录里找到文件，然后单独extract出来，比整个分区恢复要快得多。
4. 常见问题与排查技巧实录
4.1 文件系统不支持的报错排查
用dump最常遇到的报错之一就是文件系统不认识：
code复制dump: unknown file system format
这个报错的原因有几种：文件系统不是ext系列，或者文件系统超级块损坏导致dump识别失败。先用df -hT确认类型，如果确实是xfs，就直接换xfsdump，别跟dump死磕。如果是ext系列但报这个错，多半是超级块有异常，先跑e2fsck -n /dev/sda1看看能不能正常读取。我在一台老机器上遇到过文件系统标识异常的问题，最后是在卸载状态下跑了一遍e2fsck修复，dump才恢复正常。
4.2 设备忙与挂载状态导致的失败
生产中经常碰到这种报错：
code复制dump: Cannot open /dev/sda1: Device or resource busy
这个“busy”并不只是有没有进程在用，更多是文件系统处于挂载且可写状态。dump为了备份一致性，希望文件系统是静止的，所以当它检测到设备正在以可写方式挂载时，会拒绝操作或者警告。
处理方式有三种：
- 把分区临时挂载为只读（如果可以停业务的话）：
mount -o remount,ro /dev/sda1，备份完再改回来。 - 用LVM快照：先创建快照卷，再对快照做dump，业务无感知。
- 如果确实想在线备份，保留警告继续跑，但要清楚风险——备份出来的数据可能不是完全一致的时间点。
我个人的建议是能停业务就停业务，停不了就上LVM快照，不到万不得已别在线硬备。毕竟恢复的时候发现备份数据不一致，那才是真头疼。
4.3 /etc/dumpdates记录文件相关坑
用了-u参数之后，如果/etc/dumpdates文件不存在或者没有权限，dump会提示：
code复制dump: Cannot open /etc/dumpdates: No such file or directory
解决办法很简单，创建这个文件并设置合适的权限：
code复制touch /etc/dumpdates
chmod 0644 /etc/dumpdates
然后重新执行dump命令。还有一个问题是我遇到过几次的，就是dump -W显示的内容不对，感觉少了某个文件系统。这种情况通常是/etc/fstab里的dump字段设置导致的。打开/etc/fstab，每行最后一个参数是dump字段，设为0表示不参与dump的W检查，设为1才会被dump -W扫描。想用dump管理这个分区，就把这个字段从0改成1。
4.4 恢复阶段容易踩的坑
恢复阶段我踩过的坑不少，挑几个重点说。
第一个坑是恢复出来的文件默认带“./”前缀。用restore -r或者交互模式extract恢复后，文件会在当前目录下生成，路径会带上原本的绝对路径结构，比如恢复一个原本在/etc/nginx/nginx.conf的文件，在当前目录下会生成./etc/nginx/nginx.conf。所以操作前一定要先定好你想让恢复文件落到哪个目录，别在根目录下直接extract，否则文件就散落回系统路径了。
第二个坑是恢复时提示“File exists”。这通常是因为目标目录已经存在同名文件，且restore要求文件不存在才能恢复。解决方法是恢复前先把目标路径清理干净，或者用-d参数指定一个不同的恢复位置。
第三个坑是增量恢复顺序颠倒。如果你有level 0、level 1、level 2多个备份文件，恢复顺序必须是从低到高。先恢复level 2，再去恢复level 0，高等级备份里“相比之前级别的增量”就没有意义，因为基础数据已经不对了。我建议在备份目录里放一个README文件，写明每个备份文件的级别和日期，避免恢复时搞错顺序。
5. 写在最后的个人体会
dump命令确实老，但老并不等于没用。我在实际项目中用过它做过几十TB数据的分级备份方案，也用它救回过误删的重要文件。它不像tar那样对新手友好，参数也有点晦涩，但当你真正理解了inode、备份级别、dumpdates这套设计理念之后，你会发现它在ext系列文件系统上的备份能力非常可靠。我个人建议你第一次用dump的时候，先拿一台测试机把全量、增量、恢复这套流程完整走一遍，尤其要亲手测一次从level 0加level 1的组合恢复，确认恢复出来的文件跟源文件一致。毕竟备份系统的价值不在备份本身，而在那个真正需要恢复的紧急时刻。