★ FEATURED ARTICLE 1. 先搞清楚你说的 dump 是哪一个接到这个需求时我第一反应不是去敲命令而是先确认提问的人到底要找哪个“dump”。这个词在 Linux 世界里有两个完全不同的含义一个管备份一个管排障但都叫 dump空间估算思路完全不同搞错了方向后面全是白忙。第一个含义是文件系统备份工具 dump。传统的 Unix 文件系统备份命令在 ext2、ext3、ext4 文件系统上做块级别的完整备份通常配合 restore 命令来恢复数据。做 0 级备份完整备份的时候它会把整个文件系统的数据块按顺序读出来写进一个文件或磁带设备里。第二个含义是 core dump。进程崩溃时操作系统把进程的内存映像保存成一个文件这个文件叫 core 文件用于事后调试和分析崩溃原因。很多应用异常退出后服务器上会多出几个 GB 甚至几十 GB 的 core 文件把磁盘塞满这时候也会有人来问“dump 文件占多大空间”。从标题里的“完整备份”三个字来看大概率是第一种场景你要用 dump 命令做完整的文件系统备份提前评估需要多大的磁盘空间来放备份文件。但为了不坑到搜 core dump 的人我后面专门留了一节讲 core 文件的空间问题两种需求都能在本文里找到答案。先记住一个判断方法如果和备份、恢复、磁带、ext4 相关就是文件系统 dump如果和程序崩溃、core 文件、gdb 调试相关就是内核转储那一套。1.1 文件系统 dump 和内核转储的空间逻辑差异这两个概念从“底层视角”上有个本质区别直接决定你怎么估算大小。文件系统 dump 备份的是块设备上的数据块不是一个个文件再复制一遍。它会按照文件系统的布局把所有被占用的块读出来写入目标文件。这个体积完全取决于你当前文件系统里有多少数据在占用空间跟文件数量、单文件大小的关系是间接的。它的备份结果天然近似于“已用空间 少量元数据”和磁盘总容量没有直接关系。core dump 则是把进程运行时的内存地址空间镜像保存下来大小取决于进程崩溃时占用的物理内存RSS大小和磁盘上的数据量没关系。一个只用了 200MB 内存的 Java 进程崩溃后 core 文件可能就是 200MB 左右。两者连工具链都不同前者用 dump / restore后者用 coredumpctl、gdb。下面的空间估算方法我先以文件系统 dump 为主线讲因为这是“完整备份”语境下最主流的诉求。1.2 为什么 dump 完整备份大小不等于磁盘总容量很多人第一次拿 dump 做完整备份时会不由自主地按“我的磁盘总共 1TB备份文件是不是也要 1TB”去准备空间结果发现实际备份下来只有几百 GB然后又开始担心是不是备份不完整。其实都不对。完整备份备份的是已经被占用的块不是整个磁盘的物理空间。一个 500GB 的文件系统如果里面只用了 80GB 的数据块级完整备份出来的 dump 文件就是 80GB 出头而不是 500GB。这就好比你搬家租货车按行李的实际体积租不会因为你家的建筑面积大就多租几辆。不过这里有个容易忽略的点dump 备份的大小会略大于你用 df 看到的“已用空间”原因有两个。一是文件系统的元数据inode 表、目录项、位图、超级块、日志本身就占用了块这些块在备份时也要读出来二是文件系统格式化时默认会保留 5% 的块供 root 使用和维持碎片整理能力dump 备份不影响这些保留块是否被占用它只把已经分配出去的块写进文件。所以严格说dump 文件体积约等于“文件系统已分配块的总字节数”比 df 看到的已用空间略大这个差异我会在下一节用具体数字说明。2. 快速估算空间三组命令交叉验证先说结论如果你不想读太多原理记住一个经验公式就够了——dump 完整备份所需空间 ≈ df 看到的已用空间 × 1.05然后再预留 10% 到 20% 的安全余量就是你要准备的磁盘大小。但只看这一个公式不够稳因为不同文件系统的元数据占比差异很大我建议用下面三组命令做一次交叉验证。2.1 用 df 锁定设备与已用空间第一步永远是确认你的根分区或目标文件系统对应哪个块设备以及已经用了多少空间。命令很简单df -h / df -B1 /第一条输出会以人类可读的单位显示适合快速看第二条用字节为单位输出方便你做精确的比例计算。我在一台测试机上跑出来的结果大概是这样的Filesystem Size Used Avail Use% Mounted on /dev/sda1 98G 46G 47G 50% /这就告诉我根文件系统是 /dev/sda1已用 46G。但“46G”是近似值做预算时要按字节算更稳妥Filesystem 1B-blocks Used Available Use% Mounted on /dev/sda1 105485709312 49398661120 49984950272 50% /这里 Used 是 49398661120 字节换算过来约 46.0 GiB。这个值就是我估算的基准但直接拿它当备份大小还差一口气因为 dump 最终会多个 5% 左右的元数据开销。下面两条命令就是用来确认这个结论的。2.2 用 du 做深度排查与交叉验证df 告诉你文件系统层面占用多少du 则从文件层面统计目录树里所有文件加起来的尺寸。两条命令照理说应该接近但实际上会有差异而这个差异恰恰能帮你判断备份会大多少。sudo du -xsh /这里 -x 参数特别关键它让 du 只在当前文件系统内部统计不穿越到其他挂载点上。如果不加 -x遇到 /proc、/sys、挂载的其他数据盘时du 会把它们的内容也算进来数值会严重失真甚至输出一大堆“无法访问”的报错。du 统计出来的是文件逻辑大小之和不包含文件系统元数据也不包含已删除但仍被进程占用的文件块。它和 df 之间的差值基本就是 inode 表、文件系统日志这些元数据在隐藏的占用。如果两者差异特别大超过总量的 10%那就要怀疑是不是有进程打开了大文件、文件被删除但句柄没释放这时候可以这样查sudo lsof L1 | head -30能看到 deleted 状态的文件这些文件在 df 里还是占着空间在 du 里已经不出现dump 备份时会把它们读出来因为块还是分配状态所以你给备份预留的空间必须覆盖这部分不然很容易出现备份到一半目标磁盘被写满的尴尬。2.3 元数据开销到底怎么加我在前面那台测试机上实际跑了一次 dump最终块数换算出来约 48.86 GiB比 df 看到的 46.0 GiB 多了 2.86 GiB增幅约 6.2%。这个数字就是我说的“元数据 已分配但文件不可见”的典型开销。不同场景下这个比例会浮动普通服务器文件平均 1MB 以上元数据开销约 5%像上面的例子。程序构建目录、代码仓库、大量小文件文件数可能几十万inode 和目录项占用暴涨开销可能到 10% 甚至 15%。数据库数据目录大文件为主元数据占比低但文件系统保留块和日志还是会占一点一般在 4%7%。所以我的建议是先按df Used 值 × 1.05算出基准再根据文件规模特征上调。如果是大量小文件的应用目录直接按 ×1.15 估算。最后无论怎么算备份目标盘的可用空间我都建议至少留出估算值的 1.3 倍这个余量不只是防元数据波动还防备份过程中系统产生新数据以及给后续的恢复验证操作留缓冲。3. 最稳的“试跑”法让 dump 自己报大小估算公式再准也是猜。备份这种操作越接近真实值越好。这里有另一个思路直接让 dump 跑一遍完整备份但不写入任何真实备份文件而是写进 /dev/null 这个“黑洞设备”让 dump 亲口告诉你它会输出多少块。我管这叫“试跑法”比任何估算公式都靠谱。3.1 为什么试跑到 /dev/null 可行/dev/null 是一个特殊的设备文件所有写入它的数据都会被直接丢弃不做实际落盘。把 dump 的输出目标指定为 /dev/nulldump 会一丝不苟地完成整个文件系统的读取和“备份”流程但结果不进磁盘。它的进度输出里会包含一个关键信息总块数。这个块数就是如果真把备份写入文件文件会有多大。这个思路的本质是用一次完整的磁盘读操作换取最准确的体积预估值。因为 dump 备份的耗时大头在读取源文件系统写入备份目标反而是次要的所以试跑的时间消耗和真实备份基本在一个量级。唯一浪费掉的成本就是一点 CPU 和读盘 IO。试跑还有一层好处它能顺带测出这台机器做完整备份需要多长时间。备份耗时数据对后续制定备份窗口很有用你总不能正式备份的时候才发现要跑 8 个小时结果下一个业务高峰期都能赶上。3.2 读懂 dump 输出的块数试跑命令长这样sudo dump -0f /dev/null /dev/sda1注意这里我没有加 -u 参数。-u 表示把本次备份记录写入 /etc/dumpdates试跑时加上它会让系统误以为你真的做过一次备份下次通过 dump -W 查看备份历史时会产生误导信息所以试跑务必避开 -u。运行后dump 会在终端输出进度。我截取关键行DUMP: Date of this level 0 dump: Sun Mar 9 14:22:34 2025 DUMP: Dumping /dev/sda1 (/) to /dev/null DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 51234567 blocks (48.86 GB) DUMP: Volume 1 started with block 1 at: Sun Mar 9 14:22:35 2025 ... DUMP: 51234567 blocks (48.86 GB) on 1 volume(s)出现了两个关键数字开始阶段的 estimated 和结束阶段的最终 blocks。dump 使用的块单位是 1024 字节1KB不是磁盘的 512 字节扇区。所以换算公式是51234567 × 1024 52464196608 字节再除以 1024³得到约 48.86 GiB。这就是真实备份文件的体积。整个过程结束你既拿到了精确体积又拿到了真实的耗时比任何估算都直观。3.3 试跑前的准备与影响评估试跑虽好也不是随手就能跑的。几个实操细节提醒一下首先是确定设备名。df 输出的第一列就是设备路径不要凭记忆写 /dev/sda1有些机器根文件系统在 /dev/nvme0n1p2 上写错直接报错。其次是确认文件系统类型。dump 只支持 ext2/ext3/ext4 这一族如果你的根分区是 xfsdump 会直接拒绝工作。先跑一句df -T /看 TYPE 列。是 ext 系列再往下走是 xfs 就得换用 xfsdumpbtrfs 则建议用快照工具别硬来。再次是执行时间。试跑会完整读一遍全盘对磁盘 IO 有实打实的压力。生产环境的数据库服务器、业务高峰期不要做这种操作选在凌晨业务低谷跑。如果真的在意负载也可以事后把试跑定位为“低峰期的容量预检”本来这个步骤就值得周期性地做一次。最后提醒一句试跑不会写入 /etc/dumpdates但会产生一次完整的读盘记录如果你的系统监控里配了磁盘读取告警阈值事先把告警窗口调整好免得半夜收到一堆误报。4. 完整备份实操从预估到恢复验证试跑拿到体积接下来就是真正把完整备份做出来。这个阶段有几个不能省略的环节确认工具、写对命令、考虑压缩、备份后校验。每一个环节都有经验坑我按顺序过一遍。4.1 先确认文件系统类型再选备份工具这一步很多人跳过但我见过不止一次在 xfs 文件系统上敲 dump 命令、然后盯着报错发愣的场面。顺手一条命令df -Th /输出会包含 TYPE 列几种常见情况对应不同工具选型ext2 / ext3 / ext4用 dump 命令这是它的主场。xfs用 xfsdump命令语法变成 xfsdump -l 0 -f /backup/xfs.dump /dev/sda1恢复用 xfsrestore。btrfs不建议用 dump优先用 btrfs 自带快照功能或 btrfs send 做备份。网络存储、LVM 逻辑卷LVM 本身可以先做 LVM 快照再对快照做 dump这样能拿到一致性的备份点。针对我们示例里的 ext4 场景下面的命令都以 dump 为准。4.2 0 级完整备份的标准写法先看最简单的非压缩写法sudo dump -0uf /backup/root-20250309.dump /dev/sda1参数拆开讲0备份等级为 0也就是完整备份。dump 的等级分 090 级备份全部块非 0 级只备份自上次低级备份以来变更的块。对“完整备份”的需求0 级就是标准答案。u备份完成后把记录写入 /etc/dumpdates方便以后用 dump -W 查看哪些文件系统到期该备份了。f指定输出目标这里是一个普通文件路径。f 后面如果接的是 “-”表示输出到标准输出这为后面做压缩管道留了伏笔。选择备份文件存放路径时有一个铁律备份文件不能放在被备份的同一个文件系统上。你如果往 / 分区本身写 dump 文件等于一边读源数据一边把备份写进同一个盘子空间不够且毫无容灾意义。正确做法是挂载一块独立的备份盘或者网络存储、异地存储目标盘的可用空间以上面估算值为准。备份开始后观察输出里的进度百分比。中途不要 CtrlC 中断ext4 的 dump 过程虽然相对安全但中断后 /etc/dumpdates 里可能留下不完整的记录下次跑 -W 时状态会混乱。如果确实要停宁可等它跑完再删除不想要的备份文件。4.3 压缩备份与空间取舍备份文件如果直接落盘体积就是刚才试跑得到的 48.86 GiB。这个大小对磁盘不算友好尤其备份任务多的时候。更常见的做法是边 dump 边压缩sudo dump -0uf - /dev/sda1 | gzip -c /backup/root-20250309.dump.gzf 的参数是 “-”表示 dump 把备份流写到标准输出管道交给 gzip 压缩最后重定向进文件。恢复的时候要先解压再交给 restoregunzip -c /backup/root-20250309.dump.gz | sudo restore -if -压缩率的差异非常大取决于你的数据构成日志、文本、代码目录为主的系统能压到原体积的 1/3 甚至 1/4。数据库数据文件、视频、图片这类高熵数据压缩率很低可能只省 5%10%就别指望 gzip 帮你省空间了。混合型业务系统一般能压掉 30%50%。实操建议第一次备份可以先不压缩记录原始体积第二次改用压缩对比两次文件大小和耗时建立你自己机器的经验值。以后做备份容量规划时就能按数据特征快速估算压缩比。4.4 备份后的校验与恢复验证备份做完如果不校验这个备份在关键时刻能不能用就是个未知数。我最不推荐的状态就是“备份文件在但没人知道它能不能恢复”。校验分两步走。第一步先看文件大小确认体积接近预期ls -lh /backup/root-20250309.dump第二步用 restore 的 -t 参数列出备份内容相当于只读目录不实际恢复数据sudo restore -tf /backup/root-20250309.dump | head -50看到文件列表正常输出说明备份文件结构完好。再深入一点restore 还支持 -C 参数把当前文件系统与备份内容做差异对比确认数据一致性sudo restore -Cf /backup/root-20250309.dump这个操作会逐项比对备份里的文件与磁盘上对应位置的内容有差异会明确标出来。整个校验过程跑一遍备份才算是真正闭环。我个人的习惯是每次备份完成后立即做 -t 校验每周挑一次备份做 -C 深度对比保证任何一个备份点都能随时拿来恢复。5. 常见问题与避坑速查这块内容不在任何 man page 里写得明明白白全是实操中踩过的坑我整理成速查表格配合简要说明方便你遇到问题直接对号入座。5.1 备份空间相关的典型故障现象原因排查与处理备份到一半报 No space left on device目标盘空间不足备份流写到一半磁盘满了先确认目标盘挂载点可用空间参考估算公式重新评估备份文件不完整要立即删除别占用后续重试的空间dump 文件比 df 的 Used 小很多可能存在稀疏文件、压缩文件系统或者权限不足导致部分文件未统计用 du -xsh 和 df 差值做交叉验证检查是否用了 -x 参数正确限定文件系统边界dump 文件比 df 的 Used 大很多有已删除但未释放的文件或者小文件数量庞大导致元数据开销巨大lsof L1 查看 deleted 文件评估文件数量按 ×1.15 重新预估后续备份试跑输出 Cannot open /dev/sda1设备路径写错或者没有 root 权限df -T / 确认正确设备名全程使用 sudo 执行提示 Only supports ext2/ext3/ext4文件系统类型不是 ext 系列df -T 查看类型xfs 换 xfsdumpbtrfs 用快照机制/etc/dumpdates 记录混乱试跑时误加了 -u 参数编辑 /etc/dumpdates 删除对应设备的错误记录之后试跑严格不加 -u5.2 那些容易忽略的小细节第一备份文件的挂载点检查。这是个低级但高发的错误备份目标盘如果因为某种原因没有被挂载dump 会一路写进根分区的某个目录里把根分区写满。所以开工前先执行 mount 或 df -h 确认备份盘真的在并且路径没拼错。第二备份目标盘的文件系统类型。如果备份盘本身是 exFAT 或 NTFS 这类文件系统文件大小上限和单文件尺寸限制可能与 dump 输出不兼容。备份盘建议也格式化成 ext4 或 xfs。第三dump 的等级参数别搞混。0 级才是完整备份19 级都是增量/差异备份。如果历史上有过低级备份再跑非 0 级备份时体积会小很多这是正常的但如果你要的是完整备份就坚持用 0。第四backup 目录里的旧文件要及时清理。一个常见的悲剧是备份盘里有上个月的两个完整备份没删新备份一跑磁盘直接满了。自动化脚本里最好加上备份文件保留策略比如保留最近 7 天每日备份 最近 4 周每周备份其余的按时间自动删除。5.3 顺便说下 core dump 的空间问题如果你搜到这篇文章实际想问的是“程序崩溃生成的 core 文件为什么那么大怎么控制”方向在这里。先看当前环境对 core 文件的限制ulimit -c输出如果是 0表示当前 shell 环境禁止生成 core 文件输出 unlimited 或一个数字表示允许生成。数字的单位是 1024 字节块比如输出 10240 就是限制在 10MB 以内。再看 core 文件生成到哪cat /proc/sys/kernel/core_pattern常见输出是 core表示生成在当前工作目录下如果是类似|/usr/lib/systemd/systemd-coredump的管道形式说明 core 由 systemd 托管存放在 /var/lib/systemd/coredump 里可以用 coredumpctl list 查看已有列表。core 文件的大小怎么预估它本质是进程崩溃瞬间的内存映像大小近似等于进程占用的物理内存 RSS。某个 Java 服务 RSS 2.3GB崩溃后产生的 core 就在 2GB 出头。要提前看当前进程的 RSSps -o pid,rss,cmd -p 12345RSS 列以 KB 为单位粗算时除以 1024 ² 就是 GiB 数。控制 core 大小的手段有几个层面。临时调整用ulimit -c unlimited持久化修改每个用户或进程的 core 上限写在 /etc/security/limits.confsystemd 服务管理的进程在 service 文件里加 LimitCOREinfinity 或 LimitCORE1G。清理已经生成的 core 文件用 coredumpctl clean 或直接删除对应文件。6. 我的经验补充与收尾建议这套流程走下来我自己的习惯已经固化成几个固定动作新接一台要做备份的机器第一步永远是 df -T 和 df -h 同时看确认设备和文件系统类型第二步直接在低峰期跑一次/dev/null试跑拿到精确块数和耗时第三步用估算公式留 30% 余量再写正式备份命令第四步备份完立刻 restore -t 校验。四个动作做完这个备份任务才算真正“闭环”。备份空间规划这件事最怕的就是想当然。我曾经见过有人拿着磁盘总容量去规划备份盘结果多买了四倍的空间也见过有人按 df 的 Used 值规划结果小文件服务器元数据开销直接突破预期备份写到一半磁盘满了。两种极端都源于没有真正理解 dump 备份的是“已分配的块”以及没有用试跑法去验证预测。强烈建议你第一次做完整备份前花十几分钟跑一次 /dev/null 试跑这段时间的投入比后续抢救磁盘空间要值得多。最后分享一个小技巧把容量估算写进备份脚本的注释里。我每次部署备份任务脚本开头都会放一段注释记录这次备份的源设备、文件系统类型、试跑得出的块数、实际压缩比、备份耗时。等下次扩容或者加新设备时翻出历史记录直接套用省去重新试跑的成本还能看到不同时间段数据增长的趋势。备份是一项长期工程前期留下的每一条实测数据后面都会变成你排障和规划时的底气。
阅读完成 · 觉得有帮助？
