儲存型 VPS 與一般 VPS 差在哪裡？

儲存型 VPS 與一般 VPS：簡短答案

儲存型 VPS 是按 TB 銷售的虛擬私有伺服器，一般 VPS 則是按 CPU 核心銷售。儲存方案以較低價格提供多得多的磁碟空間，但磁碟通常較慢，每 TB 配置的 CPU 也較少。標準方案則提供快速 SSD，通常是 NVMe（non-volatile memory express），磁碟容量往往小 20 倍，但以相同價格提供更多處理器資源與記憶體。兩種產品的其他部分都相同：使用相同的 hypervisor、相同的 root shell、相同的 Ubuntu 映像檔，以及相同的網路堆疊。

這項差異決定了適用情境。儲存型 VPS 適合用作備份目標、媒體庫、冷資料封存，以及寫入一次後很少讀取的資料。它不適合資料庫，也不適合使用者需要等待載入的頁面，因為這些工作負載需要在約 1 毫秒內完成小型隨機讀取；低價容量之所以便宜，正是因為無法做到這點。

定價頁面上常見的方案名稱

幾乎所有供應商都會使用以下4種標籤，但其中只有2種具有明確定義。

• Standard VPS。 通常配置2至8個 vCPU、2 GB至32 GB RAM，以及20 GB至400 GB的 NVMe 或 SATA SSD，儲存空間位於主機節點本身。有些方案的規格會高出許多：截至2026-10-12，Contabo 的 Cloud VPS 方案最高提供18個 vCPU、96 GB RAM及600 GB SSD。
• Storage VPS。 儲存空間從數百 GB到20 TB以上，通常使用傳統 SATA 硬碟或高容量 SATA SSD，搭配共享 vCPU（通常為1至4個），以及配合儲存容量提供的適量 RAM。入門方案可能遠低於1 TB（Contabo 最小的 Storage VPS 方案截至2026-10-12提供300 GB SSD），最高階方案則可能配置更多核心（其 Storage VPS 50提供14個 vCPU及50 GB RAM）。其每月費用通常與小型 Standard VPS 方案相同。
• VDS。 是 virtual dedicated server 的縮寫。這個詞沒有業界共通的定義，請參閱下方章節，了解應改為查看哪些規格。
• Block storage volume。 這根本不是方案，而是附加至現有 VPS 的網路連接磁碟，按每 GB 每月計費。4種選項中，只有這種儲存空間可以在不搬遷伺服器的情況下擴充。

以上範圍是市場上常見的配置，不代表任何單一公司的方案。方案標籤只代表一個類別，因此只能大致說明伺服器所在的硬體機箱。它不會告訴你磁碟類型、CPU 分配政策或頻寬額度，而真正決定工作負載能否順利執行的，正是這些規格。

兩種方案實際上有哪些差異

磁碟類型與容量。 這是兩者在產品上的全部差異。標準方案通常使用 SSD，且經常是透過 PCI Express 匯流排連接的 NVMe flash，但方案分類不代表一定提供 NVMe：例如 Contabo 的 Core VPS 標示為「with SSD storage」，而「PCIe Gen 4 NVMe storage」則保留給獨立的 Performance VPS 產品線。儲存方案則使用大型傳統硬碟陣列或高容量 SATA SSD。若不確定上述哪些條件對你重要，請先閱讀 什麼是 SSD VPS，以及它與較舊磁碟方案的差異，再閱讀 NVMe 與 SATA SSD 的實際差距。

CPU 配額。 儲存方案每 TB 配置的 vCPU 較少，而且這些 vCPU 幾乎總是與其他租戶共用。這不是缺點。備份目標大多時間都在等待網路，因此不需要太多核心。

RAM。 儲存方案以其價格而言通常提供較少 RAM。這會在檔案系統中繼資料方面造成問題：數百萬個小型檔案需要記憶體保存目錄與 inode 快取；缺少足夠記憶體時，每次列出目錄內容都必須重新讀取磁碟。

網路流量額度。 使用儲存方案時，請仔細查看這項資訊。無法從中還原資料的容量，不能算是真正的備份。請確認每月傳輸額度（TB）與連接埠速度（Gbit/s），因為在 1 Gbit/s 連接埠上，以線速還原完整的 4 TB 約需 9 小時；若連接埠是共用的，所需時間會更久。

[
  {
    "plan": "Storage VPS, HDD",
    "usd_per_tb_month": 3
  },
  {
    "plan": "Storage VPS, SATA SSD",
    "usd_per_tb_month": 9
  },
  {
    "plan": "Standard VPS, NVMe",
    "usd_per_tb_month": 40
  },
  {
    "plan": "Block storage add-on",
    "usd_per_tb_month": 90
  }
]

上述數字是根據 2026 年 8 月多家供應商公開的價格頁面四捨五入整理而成，不代表任何單一公司的報價，而且價格會變動。長期不變的是整體趨勢。使用傳統硬碟的儲存方案，每 TB 每月約需 3 美元。標準方案中的相同 NVMe 容量每月約需 40，而網路連接的區塊儲存區則是 4 個選項中最昂貴的方案，每月為 90。如需了解每月帳單由哪些項目組成，請參閱 VPS 每月實際費用是多少。

為什麼每 TB 價格與每核心價格會朝相反方向變化

儲存節點是配備 12 到 16 顆大型磁碟的機箱，前端只有一顆效能普通的處理器。計算節點則相反：具備許多核心、大量 RAM，以及 2 或 4 顆 NVMe 磁碟。供應商會銷售該機箱的剩餘資源。因此，每 TB 價格低的方案，每核心價格就高；每核心價格低的方案，每 TB 價格就高。不存在兩者都便宜的方案，因為沒有機箱是以這種方式建置的。

因此，對於「我應該買哪一種」這個問題，誠實的答案通常是「兩種都買」。使用小型 NVMe VPS 執行應用程式，再使用儲存 VPS 保存備份，成本低於購買一台足以妥善執行兩項工作的機器。若確實需要讓同一台機器同時負責兩項工作，就已經超出 VPS 的適用範圍：請參閱 專用伺服器勝過 VPS 的情況。

廉價磁碟無法應付隨機讀取

[
  {
    "disk": "7200 rpm SATA HDD",
    "random_read_iops": "180",
    "typical_latency_ms": 8.5
  },
  {
    "disk": "SATA SSD",
    "random_read_iops": "75,000",
    "typical_latency_ms": 0.2
  },
  {
    "disk": "NVMe SSD",
    "random_read_iops": "600,000",
    "typical_latency_ms": 0.08
  }
]

這些是資料表等級的數據，不是任何供應商的基準測試結果。7200 rpm 磁碟每秒大約只能處理 180 次隨機 4k 讀取，因為磁頭必須實際移動到磁軌，然後等待碟片將磁區轉到磁頭下方；每次約需 8.5 ms。Flash 不需要移動元件，因此 SATA SSD 約可達 75,000 IOPS，NVMe 裝置則約可達 600,000 IOPS，延遲為 0.08 ms。兩者差距超過 3000 倍，再多的 RAM 或 CPU 也無法彌補。

循序作業則完全不同，這也是儲存方案仍然有用的原因。單一轉盤磁碟仍可持續提供 150 MB/s 至 250 MB/s，多顆磁碟組成的陣列則能提供更高速度。就原始硬體而言，這已足以跑滿 1 Gbit/s 連接埠，但你的 guest 不一定能取得這樣的速度：供應商可能限制每台伺服器的吞吐量。例如 Time4VPS 的文件記載，其儲存伺服器的 I/O 上限為 50 MB/s，約為 400 Mbit/s。假設備份上傳能以完整網路速度執行前，請先查看方案是否設有 I/O 上限。實際數據也取決於陣列的建置方式，因為 striping 會將資料分成區塊，輪流寫入多顆磁碟，因此大型請求可能同時由多顆磁碟處理：RAID 10 如何改變儲存方案效能 會說明這一點。

VDS 是什麼意思？

通常這只是行銷標籤。這個縮寫有 3 種常見含義，而供應商很少說明實際採用哪一種。有些供應商以 VDS 表示綁定或專用的 CPU 核心，因此不會有其他租戶與你的工作負載競爭 CPU 時間。有些供應商以 VDS 表示完整虛擬化，例如 KVM，藉此區別於 LXC 或 OpenVZ 等容器虛擬化；後者會與主機共用 kernel。有些供應商則完全沒有額外含義，只是採用一個聽起來比 VPS 更強的名稱。

你可以在伺服器內部確認其中一部分。systemd-detect-virt 在完整虛擬機器上會輸出 kvm，在容器上則會輸出 lxc；使用容器表示你無法載入 kernel module，也無法執行自有 kernel。至於專用 CPU 的說法，必須使用下文的 steal time 檢查進行測量。將方案上的縮寫視為提示，並以規格列出的內容作為合約依據。

不要只看名稱，應改為檢查這些規格

• 容量旁邊列出的磁碟類型：NVMe、SSD、SATA 或 HDD。如果頁面上完全沒有出現任何磁碟相關字樣，則假設採用符合該價格的最低成本硬體。
• 磁碟是節點本機儲存，還是透過網路連接。網路連接儲存會讓每次請求增加延遲，且可在節點故障後繼續保留資料。本機磁碟速度較快，但會隨節點一同故障。
• CPU 的描述是「dedicated」或「pinned」，還是「shared」、「fair share」或完全未標示。
• 方案是否標示 IOPS 或 MB/s 上限。若上限為 500 IOPS，磁碟類型幾乎無關緊要。
• 每月傳輸流量額度與連接埠速度。這兩者會決定完整還原需要多久。
• snapshots、backups 與額外 IP 位址是否包含在方案內，或須另行計費。

如何檢查你實際取得的磁碟

先查看 kernel 回報的資訊，接著不要再盲目信任這些資訊。

lsblk -d -o NAME,ROTA,SIZE,MODEL
df -h /
nproc
free -h

ROTA 對旋轉式裝置回報 1，對 flash 回報 0。在 VPS 中不要依賴這項資訊：virtio 磁碟通常會回報 ROTA=0，不論底層使用的是什麼裝置，因為 hypervisor 會呈現通用的 block device，而 guest 看不到實體磁碟。MODEL 也會基於相同原因保持空白。這個旗標描述的是 hypervisor 宣告的類型，不是機架中實際旋轉的裝置，因此應改用測量結果判斷。

sudo apt update && sudo apt install -y fio
fio --name=randread --filename=/var/tmp/fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.test

--direct=1 會略過 page cache，因此測量的是磁碟而非 RAM。應查看的欄位是 read: IOPS=，其下方的發行版位於 clat percentiles (usec)。標準 NVMe 方案通常會回報數萬 IOPS，99 百分位低於 1 毫秒。旋轉式儲存方案通常只會回報數百 IOPS，99 百分位則為兩位數毫秒。若 fio 回報 libaio engine 無法載入，請使用 --ioengine=psync --iodepth=1，並預期數值較低，因為該 engine 會一次只發出一個請求。

vmstat 1 5
sudo apt install -y sysstat
iostat -x 1 5

在 vmstat 中，st 欄位是 steal time：你的 vCPU 已準備執行，但 host 將這些 CPU 週期提供給另一個 guest 的時間比例。穩定高於 5 表示該節點已過度超額配置，這才是檢驗「dedicated CPU」宣稱的實際方式。在 iostat -x 中，請監看 %util、r_await 和 w_await。對於一次只能處理一個請求的裝置，例如單一旋轉式磁碟，若 %util 接近 100，且 w_await 達到數十毫秒，表示磁碟已飽和；只有能減少或重新安排 IO 的變更才有幫助。對於可平行處理請求的 RAID 陣列和 SSD，sysstat manual 警告 %util 無法反映其效能上限，因此應以 await 數值和 fio 測試結果為準。若要進行 flash 專用檢查，確認 NVMe 磁碟確實是 NVMe 一節會提供更深入的說明。

依工作負載選擇

• 作為 restic、Borg 或 rsync 的備份目標。 選 Storage VPS，這正是它的設計用途。寫入量大且連續，重複資料刪除在來源主機上完成，不需要等待處理結果。需要注意的是：restic prune 和 restic check --read-data 會以小區塊讀取整個儲存庫，因此應預留數小時，並排程執行。請參閱 將 restic 備份執行至 VPS。
• Immich 或 Jellyfin 媒體庫。 檔案可放在 Storage VPS，但需注意 CPU 效能。Immich 匯入時會產生縮圖並執行機器學習工作，Jellyfin 則會在播放時進行轉碼。2 個共用 vCPU 處理 200 GB 的照片初次匯入時，速度會非常緩慢。請將資料庫與縮圖快取放在該主機中速度最快的磁碟上。將 Immich 自架為 Google Photos 替代方案說明容量配置方式。
• PostgreSQL 或 MySQL。 選標準 NVMe 方案。使用預設的持久化提交設定（PostgreSQL 中為 synchronous_commit = on）時，每次提交都必須等到 fsync 寫入持久化儲存後，交易才會返回。因此，提交延遲就是磁碟延遲；索引查詢則是隨機讀取 1 個頁面（PostgreSQL 為 8 kB，MySQL 的 InnoDB 預設為 16 kB），而這正是傳統硬碟最不擅長的工作。
• Web 應用程式、API 或控制平面。 選標準方案。這類工作負載需要 CPU 核心與可預期的延遲，通常不需要超過 100 GB。
• CI 快取或成品儲存庫。 取決於檔案大小。大型 tarball 可從儲存方案順暢串流，速度取網路速度與方案 I/O 上限兩者中較低者。若快取包含數十萬個小檔案，且由多個 runner 平行擷取，實際上就是隨機 IO，效能會令人失望。

發生這種錯誤時的情況

故障不會立即發生。使用單一使用者時，採用傳統硬碟儲存方案的資料庫看似運作正常；但使用者增加到 10 人後就會崩潰。原因是原本可從 RAM 取得的查詢開始讀取磁碟，每次操作的成本也從微秒增加到毫秒。Load average 持續上升，但 top 顯示 CPU 大多處於閒置狀態，且 %wa 數值偏高。這表示程序不是在執行運算，而是阻塞並等待磁碟。iostat -x 1 則顯示 %util 幾乎固定在 100。

PostgreSQL 會直接在自己的 log 中說明問題，因為從 version 15 開始，log_checkpoints 預設已啟用：

LOG:  checkpoint complete: wrote 8241 buffers (2.5%); ... write=112.402 s, sync=9.318 s, total=121.914 s

真正重要的是 sync= 數值。這是 checkpoint 等待 fsync 完成所花的時間，因此若數值以秒計算，就表示磁碟處理寫入的速度跟不上資料庫產生寫入的速度。在這段期間，即使查詢本身很便宜，client connection 仍會停滯。解決方法不是修改設定，而是將 data directory 移到 NVMe，並保留儲存方案，用於存放該資料庫的 backup。

FAQ

Storage VPS 是否比一般 VPS 慢？

對隨機讀寫而言，是的，而且差距很大。機械式儲存方案每秒只能處理幾百個小型隨機請求，每次約需 8 ms；NVMe 方案每秒則可處理數萬個請求，延遲遠低於 1 ms。至於循序傳輸，兩者的差距小得多，因為機械式磁碟陣列在裸機硬體上的串流速度可達 150 MB/s 以上，足以填滿 1 Gbit/s 連接埠；但若供應商限制 guest I/O，速度可能更低（Time4VPS 將其儲存伺服器限制為 50 MB/s）。請先使用 fio --rw=randread --bs=4k --direct=1 測量自己的環境，再做決定。

可以在 storage VPS 上執行 PostgreSQL 嗎？

可以啟動，而且在工作集尚未超過 RAM 容量前都能正常運作。超過後，使用預設的同步提交設定時，每次提交都必須等待慢速磁碟上的 fsync；Postgres 會在 checkpoint complete 中，以秒為單位記錄 sync= 數值，而 iostat -x 1 會顯示 %util 接近 100，並伴隨較高的 w_await。常見的配置是使用小型 NVMe VPS 執行資料庫，再使用 storage VPS 作為 dump 的儲存目標。

VDS 是否代表我會取得專用硬體？

不能可靠地這樣判斷。VDS 沒有標準定義。有些供應商用它表示 CPU 核心已固定分配；有些用來表示完整的 KVM 虛擬化，而不是共用核心的容器；也有些只把它當作名稱。執行 systemd-detect-virt，確認目前使用的是 kvm 還是 lxc；再執行 vmstat 1 5，查看 st 欄位，確認其他租戶是否正在占用你的 CPU 週期。

如何確認我的 VPS 磁碟確實是 NVMe？

不要相信 lsblk -d -o NAME,ROTA,MODEL，因為無論底層使用何種硬體，virtio 磁碟通常都會回報 ROTA=0，而且 model 字串會是空白。使用 --direct=1 執行 30 秒的 fio 隨機讀取測試，並查看 IOPS 與第 99 百分位延遲。若只有數百 IOPS，且延遲達兩位數毫秒，代表使用的是機械式磁碟陣列。若 IOPS 達數萬，且延遲低於 1 ms，則代表使用的是 flash 儲存裝置。