WordPress 的圖片、PDF、備份或快取把 VPS 根目錄塞滿時，Linode Block Storage Volume 是很實際的擴充方式。不過「新增一顆 Volume」、「把既有 Volume 加大」，以及「用 bind mount 接回 wp-content/uploads」是三件不同的事。這篇整理一套可重複使用的流程，讓 Volume 在重開機後仍能正確掛載，也避免把原本的媒體資料遮住或格式化掉。
先記住一句話：新的空白 Volume 要建立檔案系統；既有 Volume 擴容才需要擴大檔案系統。兩種情境都不能混用
mkfs與resize2fs。
先分清楚：第一次掛載與既有 Volume 擴容
| 情境 | 要做的事 | 不要做的事 |
|---|---|---|
| 剛建立、完全空白的 Volume | 確認沒有檔案系統後，建立 ext4、掛載、設定開機自動掛載。 | 不需要先跑 resize2fs。 |
| 已有資料的 Volume，第一次掛到另一台主機 | 辨識裝置、掛載既有檔案系統、確認資料與權限。 | 不可跑 mkfs.ext4，它會清除資料。 |
| 既有 Volume 在控制台加大容量 | 依檔案系統進行檢查與擴容，再確認 df 看到新空間。 | 不能只看控制台或 lsblk 就以為可用空間已增加。 |
Linode 官方的設定流程也明確區分新 Volume 與既有 Volume：新 Volume 才建立檔案系統；若要保留既有資料，應先用 blkid 檢查，而不是重新格式化。Akamai Cloud 官方文件
Step 1：新增 Linode Volume 後，先確認裝置而不是猜 sdb 或 sdc
在 Cloud Manager 建立並 attach Volume 後，先透過 SSH 登入主機。Linux 的 /dev/sdb、/dev/sdc 可能因為掛載順序改變，不建議寫死。Linode 提供的 /dev/disk/by-id/ 路徑通常更容易辨識 Volume label。
先把 label 規劃好：它會成為裝置路徑的一部分，例如 /dev/disk/by-id/scsi-0Linode_Volume_wp-uploads-client01。若 Cloud Manager 不接受 wp-uploads，先確認同一帳戶是否已有同名 Volume；實務上應讓每顆 Volume 使用可辨識的唯一 label，例如 wp-uploads-client01、wp-uploads-web02 或 wp-uploads-tokyo-a。主機內的掛載點仍可統一使用 /mnt/wp-uploads，不必跟著 label 改名。
lsblk -f
ls -l /dev/disk/by-id/scsi-0Linode_Volume_*
# 將下列值換成自己的 Volume 裝置
VOLUME_DEVICE=/dev/disk/by-id/scsi-0Linode_Volume_your-volume-label
blkid "$VOLUME_DEVICE"若 blkid 沒有輸出，而且這顆 Volume 確認是剛建立、沒有資料，才進入下一步。若已有 UUID 或檔案系統類型，代表它可能承載過資料，先停下來確認來源。
Step 2：新空白 Volume 建立 ext4 並掛載
這一步是第一次掛載新 Volume 的必要動作。它是在建立檔案系統，不是在調整容量，所以不需要使用 resize2fs。
# 僅限全新、空白、確認可格式化的 Volume
sudo mkfs.ext4 "$VOLUME_DEVICE"
sudo mkdir -p /mnt/data-volume
sudo mount "$VOLUME_DEVICE" /mnt/data-volume
df -hT /mnt/data-volume
findmnt /mnt/data-volume建議把 Volume 先掛在獨立根目錄，例如 /mnt/data-volume，而不是直接掛到 WordPress 的 uploads。這樣每個網站可在 Volume 下有清楚的子目錄，未來要備份、遷移或排查權限時都較容易。
/mnt/data-volume/
├── example.com/
│ ├── uploads/
│ └── cache/
└── another-site.example/
└── uploads/Step 3：用 bind mount 讓 WordPress 繼續使用原本 uploads 路徑
bind mount 的好處是 WordPress、外掛與 Nginx 不必知道實體資料移到哪裡；它們仍使用原本的 wp-content/uploads 路徑。但它不是資料搬移工具：一旦掛上去，原本目標資料夾的內容會被遮住。因此正確順序是先同步、驗證，再掛載。
WEB_ROOT=/srv/www/example.com
SOURCE=/mnt/data-volume/example.com/uploads
TARGET="$WEB_ROOT/wp-content/uploads"
sudo mkdir -p "$SOURCE"
sudo rsync -aH "$TARGET/" "$SOURCE/"
# 先確認 SOURCE 內已有檔案，再建立 bind mount
sudo mount --bind "$SOURCE" "$TARGET"
findmnt "$TARGET"媒體檔是長期資料，最適合優先搬移 uploads。cache 是否要搬，則要看快取外掛與磁碟壓力；很多 cache 可重建，不應把它和正式媒體的備份策略混為一談。若網站準備走多台 Web 主機，Volume 仍只解決單台 VPS 的容量；媒體共用應評估 Object Storage。可延伸閱讀Linode WordPress 三台 Web HA 架構與WordPress Offload 儲存服務比較。
Step 4：設定重開機後自動掛載，順序比指令更重要
開機時必須先掛 Volume 根目錄，再掛各網站的 bind mount。最基本的作法是以 UUID 寫入 /etc/fstab，避免裝置名稱因開機順序變動。先取得 UUID：
sudo blkid -s UUID -o value "$VOLUME_DEVICE"以下是概念範例。第一行掛 Volume；第二行才把 Volume 內的子目錄 bind 到 WordPress。nofail 可以避免外接 Volume 暫時不存在時卡住整個開機流程；x-systemd.requires-mounts-for 則讓 systemd 先處理 Volume 根目錄。
UUID=<your-volume-uuid> /mnt/data-volume ext4 defaults,noatime,nofail 0 2
/mnt/data-volume/example.com/uploads /srv/www/example.com/wp-content/uploads none bind,nofail,x-systemd.requires-mounts-for=/mnt/data-volume 0 0修改後不要直接重開機賭運氣。先執行 sudo mount -a，再用 findmnt、df -hT 與實際上傳一個測試檔驗證。站台較多時，可以做一個開機後的檢查服務：掃描 Volume 內已登錄的 uploads／cache 目錄，確認每一個都對應到正確的 WordPress 路徑。重點是「確認與補掛」，不是每次開機強制卸載再重掛。
Step 5：既有 Volume 擴容後，為什麼 df 還是舊容量？
這是最容易誤判的地方。Linode 控制台把 Block Storage Volume 放大後，區塊裝置與檔案系統是兩層不同的容量。lsblk 看到新大小，只表示作業系統已辨識較大的裝置；真正可寫入空間仍要以 df -hT 為準。
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
df -hT /mnt/data-volume例如 lsblk 顯示 100G、df 卻仍顯示 50G，新增的 50G 還不能使用。對 ext2/ext3/ext4，Linode 的官方流程是先關機、在控制台擴容、再開機；之後卸載 Volume、執行檢查與 resize2fs，再掛回去。官方擴容步驟
# ext4 範例：先卸載所有指向這顆 Volume 的 bind mounts，再卸載 Volume
sudo umount /mnt/data-volume
sudo e2fsck -f "$VOLUME_DEVICE"
sudo resize2fs "$VOLUME_DEVICE"
sudo mount /mnt/data-volume
df -hT /mnt/data-volume如果是 XFS，不要使用 resize2fs；應依 XFS 的方式用 xfs_growfs /mnt/data-volume 擴大。無論哪一種，先用 findmnt、lsblk -f 確認裝置與檔案系統，不要靠猜測下指令。
上線前的 6 個安全檢查
- 先確認 Volume 是否全新：有資料或不確定時，絕不執行
mkfs。 - 先備份再搬移：uploads 是正式媒體，不是可隨時重建的 cache。
- 先 rsync、後 bind mount：掛載後目標資料夾會被遮住，不能把「看不到」誤認為「已搬好」。
- 確認 Web 使用者權限：PHP-FPM 執行帳號要能建立資料夾、上傳檔案與產生縮圖。
- 先測 fstab：每次改完都跑
mount -a，再檢查findmnt。 - 分清 Volume 與 HA：Block Storage 擴充的是單台主機磁碟；多台 Web 的媒體一致性仍要使用 Object Storage 或其他共享儲存策略。
常見問題 FAQ
第一次建立 Linode Volume 要跑 resize2fs 嗎？
不用。全新的空白 Volume 要先建立檔案系統，例如 ext4，再掛載到 Linux。resize2fs 是既有 ext 系列檔案系統在底層裝置已變大後，用來擴展可用空間的工具。
我可以對既有 Volume 執行 mkfs.ext4 嗎？
不可以，除非你確認這顆 Volume 不需要保留任何資料。mkfs 會建立新的檔案系統，原有資料將無法正常保留。先以 blkid、lsblk -f 與備份確認狀態。
bind mount 後原本 uploads 資料夾看起來空了，是不是資料遺失？
不一定。bind mount 會讓掛載來源覆蓋目標資料夾的視圖，原本目標內的資料可能只是被遮住。先卸載並檢查，再確認 rsync 是否完整複製；不要急著刪除原目錄或備份。
Linode Volume 可以讓多台 WordPress Web 共用 uploads 嗎？
不建議把它當成多台 Web 的共享檔案系統。Volume 適合擴充單一 Linode 的區塊儲存；當架構有多台 Web 時，媒體應評估 S3 相容的 Object Storage、Media Offload 或專用共享儲存方案。
為什麼另一台主機不能用同一個 wp-uploads label？
Volume label 會用在 Linode 的裝置路徑。若建立時被拒絕，先確認帳戶內是否已有同名 Volume。建議每顆 Volume 都使用唯一且可辨識用途與主機的名稱，例如 wp-uploads-client01；Linux 內部掛載點仍可維持統一的 /mnt/wp-uploads。
結論：先把資料路徑與開機順序設對，再追求自動化
Linode Volume 很適合替單台 WordPress VPS 擴充 uploads、備份或特定資料目錄。真正穩定的關鍵不在一條 mount 指令，而在於先分辨新 Volume 與擴容 Volume、保留可回復的資料副本、用 fstab 管理開機順序，並在每次重開機後確認掛載狀態。先把這些基本功做好，之後無論要導入 Object Storage、Media Offload 或多台 Web HA，資料層都會更容易演進。
