1. 先搞清楚你說的 dump 是哪一個接到這個需求時我第一反應(yīng)不是去敲命令而是先確認(rèn)提問的人到底要找哪個“dump”。這個詞在 Linux 世界里有兩個完全不同的含義一個管備份一個管排障但都叫 dump空間估算思路完全不同搞錯了方向后面全是白忙。第一個含義是文件系統(tǒng)備份工具 dump。傳統(tǒng)的 Unix 文件系統(tǒng)備份命令在 ext2、ext3、ext4 文件系統(tǒng)上做塊級別的完整備份通常配合 restore 命令來恢復(fù)數(shù)據(jù)。做 0 級備份完整備份的時候它會把整個文件系統(tǒng)的數(shù)據(jù)塊按順序讀出來寫進一個文件或磁帶設(shè)備里。第二個含義是 core dump。進程崩潰時操作系統(tǒng)把進程的內(nèi)存映像保存成一個文件這個文件叫 core 文件用于事后調(diào)試和分析崩潰原因。很多應(yīng)用異常退出后服務(wù)器上會多出幾個 GB 甚至幾十 GB 的 core 文件把磁盤塞滿這時候也會有人來問“dump 文件占多大空間”。從標(biāo)題里的“完整備份”三個字來看大概率是第一種場景你要用 dump 命令做完整的文件系統(tǒng)備份提前評估需要多大的磁盤空間來放備份文件。但為了不坑到搜 core dump 的人我后面專門留了一節(jié)講 core 文件的空間問題兩種需求都能在本文里找到答案。先記住一個判斷方法如果和備份、恢復(fù)、磁帶、ext4 相關(guān)就是文件系統(tǒng) dump如果和程序崩潰、core 文件、gdb 調(diào)試相關(guān)就是內(nèi)核轉(zhuǎn)儲那一套。1.1 文件系統(tǒng) dump 和內(nèi)核轉(zhuǎn)儲的空間邏輯差異這兩個概念從“底層視角”上有個本質(zhì)區(qū)別直接決定你怎么估算大小。文件系統(tǒng) dump 備份的是塊設(shè)備上的數(shù)據(jù)塊不是一個個文件再復(fù)制一遍。它會按照文件系統(tǒng)的布局把所有被占用的塊讀出來寫入目標(biāo)文件。這個體積完全取決于你當(dāng)前文件系統(tǒng)里有多少數(shù)據(jù)在占用空間跟文件數(shù)量、單文件大小的關(guān)系是間接的。它的備份結(jié)果天然近似于“已用空間 少量元數(shù)據(jù)”和磁盤總?cè)萘繘]有直接關(guān)系。core dump 則是把進程運行時的內(nèi)存地址空間鏡像保存下來大小取決于進程崩潰時占用的物理內(nèi)存RSS大小和磁盤上的數(shù)據(jù)量沒關(guān)系。一個只用了 200MB 內(nèi)存的 Java 進程崩潰后 core 文件可能就是 200MB 左右。兩者連工具鏈都不同前者用 dump / restore后者用 coredumpctl、gdb。下面的空間估算方法我先以文件系統(tǒng) dump 為主線講因為這是“完整備份”語境下最主流的訴求。1.2 為什么 dump 完整備份大小不等于磁盤總?cè)萘亢芏嗳说谝淮文?dump 做完整備份時會不由自主地按“我的磁盤總共 1TB備份文件是不是也要 1TB”去準(zhǔn)備空間結(jié)果發(fā)現(xiàn)實際備份下來只有幾百 GB然后又開始擔(dān)心是不是備份不完整。其實都不對。完整備份備份的是已經(jīng)被占用的塊不是整個磁盤的物理空間。一個 500GB 的文件系統(tǒng)如果里面只用了 80GB 的數(shù)據(jù)塊級完整備份出來的 dump 文件就是 80GB 出頭而不是 500GB。這就好比你搬家租貨車按行李的實際體積租不會因為你家的建筑面積大就多租幾輛。不過這里有個容易忽略的點dump 備份的大小會略大于你用 df 看到的“已用空間”原因有兩個。一是文件系統(tǒng)的元數(shù)據(jù)inode 表、目錄項、位圖、超級塊、日志本身就占用了塊這些塊在備份時也要讀出來二是文件系統(tǒng)格式化時默認(rèn)會保留 5% 的塊供 root 使用和維持碎片整理能力dump 備份不影響這些保留塊是否被占用它只把已經(jīng)分配出去的塊寫進文件。所以嚴(yán)格說dump 文件體積約等于“文件系統(tǒng)已分配塊的總字節(jié)數(shù)”比 df 看到的已用空間略大這個差異我會在下一節(jié)用具體數(shù)字說明。2. 快速估算空間三組命令交叉驗證先說結(jié)論如果你不想讀太多原理記住一個經(jīng)驗公式就夠了——dump 完整備份所需空間 ≈ df 看到的已用空間 × 1.05然后再預(yù)留 10% 到 20% 的安全余量就是你要準(zhǔn)備的磁盤大小。但只看這一個公式不夠穩(wěn)因為不同文件系統(tǒng)的元數(shù)據(jù)占比差異很大我建議用下面三組命令做一次交叉驗證。2.1 用 df 鎖定設(shè)備與已用空間第一步永遠(yuǎn)是確認(rèn)你的根分區(qū)或目標(biāo)文件系統(tǒng)對應(yīng)哪個塊設(shè)備以及已經(jīng)用了多少空間。命令很簡單df -h / df -B1 /第一條輸出會以人類可讀的單位顯示適合快速看第二條用字節(jié)為單位輸出方便你做精確的比例計算。我在一臺測試機上跑出來的結(jié)果大概是這樣的Filesystem Size Used Avail Use% Mounted on /dev/sda1 98G 46G 47G 50% /這就告訴我根文件系統(tǒng)是 /dev/sda1已用 46G。但“46G”是近似值做預(yù)算時要按字節(jié)算更穩(wěn)妥Filesystem 1B-blocks Used Available Use% Mounted on /dev/sda1 105485709312 49398661120 49984950272 50% /這里 Used 是 49398661120 字節(jié)換算過來約 46.0 GiB。這個值就是我估算的基準(zhǔn)但直接拿它當(dāng)備份大小還差一口氣因為 dump 最終會多個 5% 左右的元數(shù)據(jù)開銷。下面兩條命令就是用來確認(rèn)這個結(jié)論的。2.2 用 du 做深度排查與交叉驗證df 告訴你文件系統(tǒng)層面占用多少du 則從文件層面統(tǒng)計目錄樹里所有文件加起來的尺寸。兩條命令照理說應(yīng)該接近但實際上會有差異而這個差異恰恰能幫你判斷備份會大多少。sudo du -xsh /這里 -x 參數(shù)特別關(guān)鍵它讓 du 只在當(dāng)前文件系統(tǒng)內(nèi)部統(tǒng)計不穿越到其他掛載點上。如果不加 -x遇到 /proc、/sys、掛載的其他數(shù)據(jù)盤時du 會把它們的內(nèi)容也算進來數(shù)值會嚴(yán)重失真甚至輸出一大堆“無法訪問”的報錯。du 統(tǒng)計出來的是文件邏輯大小之和不包含文件系統(tǒng)元數(shù)據(jù)也不包含已刪除但仍被進程占用的文件塊。它和 df 之間的差值基本就是 inode 表、文件系統(tǒng)日志這些元數(shù)據(jù)在隱藏的占用。如果兩者差異特別大超過總量的 10%那就要懷疑是不是有進程打開了大文件、文件被刪除但句柄沒釋放這時候可以這樣查sudo lsof L1 | head -30能看到 deleted 狀態(tài)的文件這些文件在 df 里還是占著空間在 du 里已經(jīng)不出現(xiàn)dump 備份時會把它們讀出來因為塊還是分配狀態(tài)所以你給備份預(yù)留的空間必須覆蓋這部分不然很容易出現(xiàn)備份到一半目標(biāo)磁盤被寫滿的尷尬。2.3 元數(shù)據(jù)開銷到底怎么加我在前面那臺測試機上實際跑了一次 dump最終塊數(shù)換算出來約 48.86 GiB比 df 看到的 46.0 GiB 多了 2.86 GiB增幅約 6.2%。這個數(shù)字就是我說的“元數(shù)據(jù) 已分配但文件不可見”的典型開銷。不同場景下這個比例會浮動普通服務(wù)器文件平均 1MB 以上元數(shù)據(jù)開銷約 5%像上面的例子。程序構(gòu)建目錄、代碼倉庫、大量小文件文件數(shù)可能幾十萬inode 和目錄項占用暴漲開銷可能到 10% 甚至 15%。數(shù)據(jù)庫數(shù)據(jù)目錄大文件為主元數(shù)據(jù)占比低但文件系統(tǒng)保留塊和日志還是會占一點一般在 4%7%。所以我的建議是先按df Used 值 × 1.05算出基準(zhǔn)再根據(jù)文件規(guī)模特征上調(diào)。如果是大量小文件的應(yīng)用目錄直接按 ×1.15 估算。最后無論怎么算備份目標(biāo)盤的可用空間我都建議至少留出估算值的 1.3 倍這個余量不只是防元數(shù)據(jù)波動還防備份過程中系統(tǒng)產(chǎn)生新數(shù)據(jù)以及給后續(xù)的恢復(fù)驗證操作留緩沖。3. 最穩(wěn)的“試跑”法讓 dump 自己報大小估算公式再準(zhǔn)也是猜。備份這種操作越接近真實值越好。這里有另一個思路直接讓 dump 跑一遍完整備份但不寫入任何真實備份文件而是寫進 /dev/null 這個“黑洞設(shè)備”讓 dump 親口告訴你它會輸出多少塊。我管這叫“試跑法”比任何估算公式都靠譜。3.1 為什么試跑到 /dev/null 可行/dev/null 是一個特殊的設(shè)備文件所有寫入它的數(shù)據(jù)都會被直接丟棄不做實際落盤。把 dump 的輸出目標(biāo)指定為 /dev/nulldump 會一絲不茍地完成整個文件系統(tǒng)的讀取和“備份”流程但結(jié)果不進磁盤。它的進度輸出里會包含一個關(guān)鍵信息總塊數(shù)。這個塊數(shù)就是如果真把備份寫入文件文件會有多大。這個思路的本質(zhì)是用一次完整的磁盤讀操作換取最準(zhǔn)確的體積預(yù)估值。因為 dump 備份的耗時大頭在讀取源文件系統(tǒng)寫入備份目標(biāo)反而是次要的所以試跑的時間消耗和真實備份基本在一個量級。唯一浪費掉的成本就是一點 CPU 和讀盤 IO。試跑還有一層好處它能順帶測出這臺機器做完整備份需要多長時間。備份耗時數(shù)據(jù)對后續(xù)制定備份窗口很有用你總不能正式備份的時候才發(fā)現(xiàn)要跑 8 個小時結(jié)果下一個業(yè)務(wù)高峰期都能趕上。3.2 讀懂 dump 輸出的塊數(shù)試跑命令長這樣sudo dump -0f /dev/null /dev/sda1注意這里我沒有加 -u 參數(shù)。-u 表示把本次備份記錄寫入 /etc/dumpdates試跑時加上它會讓系統(tǒng)誤以為你真的做過一次備份下次通過 dump -W 查看備份歷史時會產(chǎn)生誤導(dǎo)信息所以試跑務(wù)必避開 -u。運行后dump 會在終端輸出進度。我截取關(guān)鍵行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)出現(xiàn)了兩個關(guān)鍵數(shù)字開始階段的 estimated 和結(jié)束階段的最終 blocks。dump 使用的塊單位是 1024 字節(jié)1KB不是磁盤的 512 字節(jié)扇區(qū)。所以換算公式是51234567 × 1024 52464196608 字節(jié)再除以 10243得到約 48.86 GiB。這就是真實備份文件的體積。整個過程結(jié)束你既拿到了精確體積又拿到了真實的耗時比任何估算都直觀。3.3 試跑前的準(zhǔn)備與影響評估試跑雖好也不是隨手就能跑的。幾個實操細(xì)節(jié)提醒一下首先是確定設(shè)備名。df 輸出的第一列就是設(shè)備路徑不要憑記憶寫 /dev/sda1有些機器根文件系統(tǒng)在 /dev/nvme0n1p2 上寫錯直接報錯。其次是確認(rèn)文件系統(tǒng)類型。dump 只支持 ext2/ext3/ext4 這一族如果你的根分區(qū)是 xfsdump 會直接拒絕工作。先跑一句df -T /看 TYPE 列。是 ext 系列再往下走是 xfs 就得換用 xfsdumpbtrfs 則建議用快照工具別硬來。再次是執(zhí)行時間。試跑會完整讀一遍全盤對磁盤 IO 有實打?qū)嵉膲毫?。生產(chǎn)環(huán)境的數(shù)據(jù)庫服務(wù)器、業(yè)務(wù)高峰期不要做這種操作選在凌晨業(yè)務(wù)低谷跑。如果真的在意負(fù)載也可以事后把試跑定位為“低峰期的容量預(yù)檢”本來這個步驟就值得周期性地做一次。最后提醒一句試跑不會寫入 /etc/dumpdates但會產(chǎn)生一次完整的讀盤記錄如果你的系統(tǒng)監(jiān)控里配了磁盤讀取告警閾值事先把告警窗口調(diào)整好免得半夜收到一堆誤報。4. 完整備份實操從預(yù)估到恢復(fù)驗證試跑拿到體積接下來就是真正把完整備份做出來。這個階段有幾個不能省略的環(huán)節(jié)確認(rèn)工具、寫對命令、考慮壓縮、備份后校驗。每一個環(huán)節(jié)都有經(jīng)驗坑我按順序過一遍。4.1 先確認(rèn)文件系統(tǒng)類型再選備份工具這一步很多人跳過但我見過不止一次在 xfs 文件系統(tǒng)上敲 dump 命令、然后盯著報錯發(fā)愣的場面。順手一條命令df -Th /輸出會包含 TYPE 列幾種常見情況對應(yīng)不同工具選型ext2 / ext3 / ext4用 dump 命令這是它的主場。xfs用 xfsdump命令語法變成 xfsdump -l 0 -f /backup/xfs.dump /dev/sda1恢復(fù)用 xfsrestore。btrfs不建議用 dump優(yōu)先用 btrfs 自帶快照功能或 btrfs send 做備份。網(wǎng)絡(luò)存儲、LVM 邏輯卷LVM 本身可以先做 LVM 快照再對快照做 dump這樣能拿到一致性的備份點。針對我們示例里的 ext4 場景下面的命令都以 dump 為準(zhǔn)。4.2 0 級完整備份的標(biāo)準(zhǔn)寫法先看最簡單的非壓縮寫法sudo dump -0uf /backup/root-20250309.dump /dev/sda1參數(shù)拆開講0備份等級為 0也就是完整備份。dump 的等級分 090 級備份全部塊非 0 級只備份自上次低級備份以來變更的塊。對“完整備份”的需求0 級就是標(biāo)準(zhǔn)答案。u備份完成后把記錄寫入 /etc/dumpdates方便以后用 dump -W 查看哪些文件系統(tǒng)到期該備份了。f指定輸出目標(biāo)這里是一個普通文件路徑。f 后面如果接的是 “-”表示輸出到標(biāo)準(zhǔn)輸出這為后面做壓縮管道留了伏筆。選擇備份文件存放路徑時有一個鐵律備份文件不能放在被備份的同一個文件系統(tǒng)上。你如果往 / 分區(qū)本身寫 dump 文件等于一邊讀源數(shù)據(jù)一邊把備份寫進同一個盤子空間不夠且毫無容災(zāi)意義。正確做法是掛載一塊獨立的備份盤或者網(wǎng)絡(luò)存儲、異地存儲目標(biāo)盤的可用空間以上面估算值為準(zhǔn)。備份開始后觀察輸出里的進度百分比。中途不要 CtrlC 中斷ext4 的 dump 過程雖然相對安全但中斷后 /etc/dumpdates 里可能留下不完整的記錄下次跑 -W 時狀態(tài)會混亂。如果確實要停寧可等它跑完再刪除不想要的備份文件。4.3 壓縮備份與空間取舍備份文件如果直接落盤體積就是剛才試跑得到的 48.86 GiB。這個大小對磁盤不算友好尤其備份任務(wù)多的時候。更常見的做法是邊 dump 邊壓縮sudo dump -0uf - /dev/sda1 | gzip -c /backup/root-20250309.dump.gzf 的參數(shù)是 “-”表示 dump 把備份流寫到標(biāo)準(zhǔn)輸出管道交給 gzip 壓縮最后重定向進文件?；謴?fù)的時候要先解壓再交給 restoregunzip -c /backup/root-20250309.dump.gz | sudo restore -if -壓縮率的差異非常大取決于你的數(shù)據(jù)構(gòu)成日志、文本、代碼目錄為主的系統(tǒng)能壓到原體積的 1/3 甚至 1/4。數(shù)據(jù)庫數(shù)據(jù)文件、視頻、圖片這類高熵數(shù)據(jù)壓縮率很低可能只省 5%10%就別指望 gzip 幫你省空間了?；旌闲蜆I(yè)務(wù)系統(tǒng)一般能壓掉 30%50%。實操建議第一次備份可以先不壓縮記錄原始體積第二次改用壓縮對比兩次文件大小和耗時建立你自己機器的經(jīng)驗值。以后做備份容量規(guī)劃時就能按數(shù)據(jù)特征快速估算壓縮比。4.4 備份后的校驗與恢復(fù)驗證備份做完如果不校驗這個備份在關(guān)鍵時刻能不能用就是個未知數(shù)。我最不推薦的狀態(tài)就是“備份文件在但沒人知道它能不能恢復(fù)”。校驗分兩步走。第一步先看文件大小確認(rèn)體積接近預(yù)期ls -lh /backup/root-20250309.dump第二步用 restore 的 -t 參數(shù)列出備份內(nèi)容相當(dāng)于只讀目錄不實際恢復(fù)數(shù)據(jù)sudo restore -tf /backup/root-20250309.dump | head -50看到文件列表正常輸出說明備份文件結(jié)構(gòu)完好。再深入一點restore 還支持 -C 參數(shù)把當(dāng)前文件系統(tǒng)與備份內(nèi)容做差異對比確認(rèn)數(shù)據(jù)一致性sudo restore -Cf /backup/root-20250309.dump這個操作會逐項比對備份里的文件與磁盤上對應(yīng)位置的內(nèi)容有差異會明確標(biāo)出來。整個校驗過程跑一遍備份才算是真正閉環(huán)。我個人的習(xí)慣是每次備份完成后立即做 -t 校驗每周挑一次備份做 -C 深度對比保證任何一個備份點都能隨時拿來恢復(fù)。5. 常見問題與避坑速查這塊內(nèi)容不在任何 man page 里寫得明明白白全是實操中踩過的坑我整理成速查表格配合簡要說明方便你遇到問題直接對號入座。5.1 備份空間相關(guān)的典型故障現(xiàn)象原因排查與處理備份到一半報 No space left on device目標(biāo)盤空間不足備份流寫到一半磁盤滿了先確認(rèn)目標(biāo)盤掛載點可用空間參考估算公式重新評估備份文件不完整要立即刪除別占用后續(xù)重試的空間dump 文件比 df 的 Used 小很多可能存在稀疏文件、壓縮文件系統(tǒng)或者權(quán)限不足導(dǎo)致部分文件未統(tǒng)計用 du -xsh 和 df 差值做交叉驗證檢查是否用了 -x 參數(shù)正確限定文件系統(tǒng)邊界dump 文件比 df 的 Used 大很多有已刪除但未釋放的文件或者小文件數(shù)量龐大導(dǎo)致元數(shù)據(jù)開銷巨大lsof L1 查看 deleted 文件評估文件數(shù)量按 ×1.15 重新預(yù)估后續(xù)備份試跑輸出 Cannot open /dev/sda1設(shè)備路徑寫錯或者沒有 root 權(quán)限df -T / 確認(rèn)正確設(shè)備名全程使用 sudo 執(zhí)行提示 Only supports ext2/ext3/ext4文件系統(tǒng)類型不是 ext 系列df -T 查看類型xfs 換 xfsdumpbtrfs 用快照機制/etc/dumpdates 記錄混亂試跑時誤加了 -u 參數(shù)編輯 /etc/dumpdates 刪除對應(yīng)設(shè)備的錯誤記錄之后試跑嚴(yán)格不加 -u5.2 那些容易忽略的小細(xì)節(jié)第一備份文件的掛載點檢查。這是個低級但高發(fā)的錯誤備份目標(biāo)盤如果因為某種原因沒有被掛載dump 會一路寫進根分區(qū)的某個目錄里把根分區(qū)寫滿。所以開工前先執(zhí)行 mount 或 df -h 確認(rèn)備份盤真的在并且路徑?jīng)]拼錯。第二備份目標(biāo)盤的文件系統(tǒng)類型。如果備份盤本身是 exFAT 或 NTFS 這類文件系統(tǒng)文件大小上限和單文件尺寸限制可能與 dump 輸出不兼容。備份盤建議也格式化成 ext4 或 xfs。第三dump 的等級參數(shù)別搞混。0 級才是完整備份19 級都是增量/差異備份。如果歷史上有過低級備份再跑非 0 級備份時體積會小很多這是正常的但如果你要的是完整備份就堅持用 0。第四backup 目錄里的舊文件要及時清理。一個常見的悲劇是備份盤里有上個月的兩個完整備份沒刪新備份一跑磁盤直接滿了。自動化腳本里最好加上備份文件保留策略比如保留最近 7 天每日備份 最近 4 周每周備份其余的按時間自動刪除。5.3 順便說下 core dump 的空間問題如果你搜到這篇文章實際想問的是“程序崩潰生成的 core 文件為什么那么大怎么控制”方向在這里。先看當(dāng)前環(huán)境對 core 文件的限制ulimit -c輸出如果是 0表示當(dāng)前 shell 環(huán)境禁止生成 core 文件輸出 unlimited 或一個數(shù)字表示允許生成。數(shù)字的單位是 1024 字節(jié)塊比如輸出 10240 就是限制在 10MB 以內(nèi)。再看 core 文件生成到哪cat /proc/sys/kernel/core_pattern常見輸出是 core表示生成在當(dāng)前工作目錄下如果是類似|/usr/lib/systemd/systemd-coredump的管道形式說明 core 由 systemd 托管存放在 /var/lib/systemd/coredump 里可以用 coredumpctl list 查看已有列表。core 文件的大小怎么預(yù)估它本質(zhì)是進程崩潰瞬間的內(nèi)存映像大小近似等于進程占用的物理內(nèi)存 RSS。某個 Java 服務(wù) RSS 2.3GB崩潰后產(chǎn)生的 core 就在 2GB 出頭。要提前看當(dāng)前進程的 RSSps -o pid,rss,cmd -p 12345RSS 列以 KB 為單位粗算時除以 1024 2 就是 GiB 數(shù)?？刂?core 大小的手段有幾個層面。臨時調(diào)整用ulimit -c unlimited持久化修改每個用戶或進程的 core 上限寫在 /etc/security/limits.confsystemd 服務(wù)管理的進程在 service 文件里加 LimitCOREinfinity 或 LimitCORE1G。清理已經(jīng)生成的 core 文件用 coredumpctl clean 或直接刪除對應(yīng)文件。6. 我的經(jīng)驗補充與收尾建議這套流程走下來我自己的習(xí)慣已經(jīng)固化成幾個固定動作新接一臺要做備份的機器第一步永遠(yuǎn)是 df -T 和 df -h 同時看確認(rèn)設(shè)備和文件系統(tǒng)類型第二步直接在低峰期跑一次/dev/null試跑拿到精確塊數(shù)和耗時第三步用估算公式留 30% 余量再寫正式備份命令第四步備份完立刻 restore -t 校驗。四個動作做完這個備份任務(wù)才算真正“閉環(huán)”。備份空間規(guī)劃這件事最怕的就是想當(dāng)然。我曾經(jīng)見過有人拿著磁盤總?cè)萘咳ヒ?guī)劃備份盤結(jié)果多買了四倍的空間也見過有人按 df 的 Used 值規(guī)劃結(jié)果小文件服務(wù)器元數(shù)據(jù)開銷直接突破預(yù)期備份寫到一半磁盤滿了。兩種極端都源于沒有真正理解 dump 備份的是“已分配的塊”以及沒有用試跑法去驗證預(yù)測。強烈建議你第一次做完整備份前花十幾分鐘跑一次 /dev/null 試跑這段時間的投入比后續(xù)搶救磁盤空間要值得多。最后分享一個小技巧把容量估算寫進備份腳本的注釋里。我每次部署備份任務(wù)腳本開頭都會放一段注釋記錄這次備份的源設(shè)備、文件系統(tǒng)類型、試跑得出的塊數(shù)、實際壓縮比、備份耗時。等下次擴容或者加新設(shè)備時翻出歷史記錄直接套用省去重新試跑的成本還能看到不同時間段數(shù)據(jù)增長的趨勢。備份是一項長期工程前期留下的每一條實測數(shù)據(jù)后面都會變成你排障和規(guī)劃時的底氣。