Storage VPS बनाम Regular VPS: मुख्य अंतर क्या हैं?

Storage VPS बनाम regular VPS: संक्षिप्त उत्तर

Storage VPS एक ऐसा virtual private server है जिसे terabyte के आधार पर बेचा जाता है, जबकि regular VPS को core के आधार पर बेचा जाता है। Storage plan में आपको कम CPU share के साथ कई terabyte की धीमी disk मिलती है। Standard plan में आपको एक तेज़ NVMe (non-volatile memory express) disk मिलती है, जो अक्सर बीस गुना छोटी होती है, लेकिन उसी कीमत में अधिक processor और अधिक memory मिलती है। इन दोनों products के अन्य सभी पहलू समान हैं: एक ही hypervisor, एक ही root shell, एक ही Ubuntu image और एक ही network stack।

यह एक अंतर ही तय करता है कि कौन सा विकल्प उपयुक्त है। Storage VPS backup targets, media libraries, cold archives और ऐसी किसी भी चीज़ के लिए सही है जिसे आप एक बार लिखते हैं और शायद ही कभी पढ़ते हैं। यह database के लिए, या किसी ऐसे page के लिए गलत है जिसका इंतज़ार user को करना पड़ता है, क्योंकि उन workloads को पूरा होने के लिए लगभग एक millisecond में small random reads की आवश्यकता होती है, और सस्ती capacity इसलिए सस्ती होती है क्योंकि वह ऐसा नहीं कर सकती।

Pricing page पर मिलने वाले plan के नाम

चार labels लगभग हर provider को कवर करते हैं, और उनमें से केवल दो का ही कोई विशिष्ट अर्थ होता है।

• Standard VPS. दो से आठ vCPU, 2 GB से 32 GB RAM, और host node पर ही स्थित 20 GB से 400 GB NVMe या SATA SSD।
• Storage VPS. 1 TB से 20 TB या अधिक, आमतौर पर spinning SATA disks या उच्च क्षमता वाली SATA SSDs, एक से चार shared vCPU और सीमित RAM के साथ। इसकी मासिक लागत अक्सर एक छोटे standard plan के बराबर होती है।
• VDS. यह virtual dedicated server का संक्षिप्त रूप है। इस शब्द की कोई एक साझा परिभाषा नहीं है, और नीचे दिया गया section बताता है कि इसके बजाय क्या देखना चाहिए।
• Block storage volume. यह कोई plan नहीं है: यह एक network attached disk है जिसे आप मौजूदा VPS में जोड़ते हैं और प्रति GB प्रति माह के हिसाब से भुगतान करते हैं। यह इन चारों में से एकमात्र विकल्प है जिसे आप सर्वर को migrate किए बिना बढ़ा सकते हैं।

ये ranges पूरे बाज़ार में सामान्य रूप से पाई जाती हैं, न कि किसी एक कंपनी की पेशकश। plan पर लगा label एक category है, इसलिए यह आपको मोटे तौर पर बताता है कि आपका सर्वर किस chassis पर स्थित है। यह disk के प्रकार, CPU allocation policy या bandwidth allowance के बारे में नहीं बताता, और यही वे बिंदु हैं जो तय करते हैं कि आपका workload ठीक से चलेगा या नहीं।

दोनों प्लान के बीच वास्तव में क्या बदलता है

डिस्क का प्रकार और मात्रा। उत्पाद में यही मुख्य अंतर है। स्टैंडर्ड प्लान आपको PCI Express बस के माध्यम से NVMe फ्लैश पर रखता है। स्टोरेज प्लान आपको स्पिनिंग डिस्क या उच्च क्षमता वाले SATA SSDs के एक बड़े ऐरे (array) पर रखता है। यदि आप सुनिश्चित नहीं हैं कि इनमें से कौन सा शब्द आपके लिए मायने रखता है, तो SSD VPS क्या है और यह पुराने डिस्क प्लान से कैसे अलग है से शुरुआत करें और फिर NVMe और SATA SSD के बीच व्यावहारिक अंतर देखें।

CPU अनुपात। स्टोरेज प्लान में प्रति टेराबाइट vCPU कम होते हैं, और वे vCPU लगभग हमेशा अन्य किरायेदारों (tenants) के साथ साझा किए जाते हैं। यह कोई कमी नहीं है। एक बैकअप टारगेट अपना अधिकांश समय नेटवर्क पर प्रतीक्षा करते हुए बिताता है, इसलिए इसे अधिक कोर की आवश्यकता नहीं होती है।

RAM। स्टोरेज प्लान अपनी कीमत के हिसाब से RAM के मामले में कमतर होते हैं। यह एक विशिष्ट जगह पर समस्या पैदा करता है: फाइलसिस्टम मेटाडेटा। लाखों छोटी फाइलों को डायरेक्टरी और inode कैश के लिए मेमोरी की आवश्यकता होती है, और इसके बिना हर लिस्टिंग डिस्क पर वापस जाती है।

नेटवर्क भत्ता। स्टोरेज प्लान पर इस पंक्ति को ध्यान से पढ़ें। जिस क्षमता से आप डेटा रिस्टोर नहीं कर सकते, वह बैकअप नहीं है। TB में मासिक ट्रांसफर भत्ता और Gbit/s में पोर्ट स्पीड की जाँच करें, क्योंकि 1 Gbit/s पोर्ट पर 4 TB का पूर्ण रिस्टोर लाइन रेट पर लगभग नौ घंटे लेता है, और यदि पोर्ट साझा है तो इसमें काफी अधिक समय लगता है।

[
  {
    "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 में कई प्रदाताओं के सार्वजनिक मूल्य पृष्ठों से लिए गए अनुमानित आंकड़े हैं, न कि किसी एक कंपनी का कोटेशन, और ये बदलते रहते हैं। इनका स्वरूप स्थायी है। एक स्पिनिंग स्टोरेज प्लान पर एक टेराबाइट की लागत लगभग 3 अमेरिकी डॉलर प्रति माह है। स्टैंडर्ड प्लान पर NVMe के उसी एक टेराबाइट की लागत लगभग 40 है, और नेटवर्क अटैच्ड ब्लॉक वॉल्यूम 4 विकल्पों में सबसे महंगा है, जिसकी लागत 90 है। मासिक बिल किन चीजों से बनता है, इसके व्यापक दृष्टिकोण के लिए, VPS की वास्तविक मासिक लागत क्या है देखें।

कीमत प्रति TB और कीमत प्रति core विपरीत दिशाओं में क्यों जाती हैं

एक storage node एक ऐसा chassis है जिसमें बारह से सोलह बड़ी disks होती हैं और उनके आगे एक साधारण processor लगा होता है। एक compute node इसका उल्टा होता है: इसमें बहुत सारे cores, अधिक RAM और दो या चार NVMe drives होती हैं। प्रदाता वही बेचता है जो उस chassis में अतिरिक्त उपलब्ध होता है। इसलिए, जो plan प्रति terabyte सस्ता है, वह प्रति core महंगा होता है, और जो plan प्रति core सस्ता है, वह प्रति terabyte महंगा होता है। ऐसा कोई plan नहीं है जो दोनों में सस्ता हो, क्योंकि ऐसा कोई chassis बनाया ही नहीं गया है।

यही कारण है कि "मुझे कौन सा खरीदना चाहिए" का ईमानदार उत्तर अक्सर "दोनों" होता है। एक छोटा NVMe VPS जो application चलाता है, और उसके साथ एक storage VPS जो उसका backup रखता है, उस एक machine से सस्ता पड़ता है जो दोनों काम ठीक से करने में सक्षम हो। जब एक ही machine को वास्तव में दोनों काम करने पड़ते हैं, तो आप VPS के दायरे से बाहर निकल जाते हैं: देखें जब dedicated server VPS से बेहतर होता है।

Random reads सस्ते डिस्क की क्षमता से बाहर हैं

[
  {
    "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 का समय लगता है। फ्लैश में कोई भी हिस्सा हिलता नहीं है, इसलिए एक SATA SSD लगभग 75,000 और एक NVMe डिवाइस लगभग 600,000 IOPS तक 0.08 ms पर पहुँच जाता है। यह तीन हजार गुना से अधिक का अंतर है, और इसे RAM या CPU की कोई भी मात्रा कम नहीं कर सकती।

Sequential कार्य पूरी तरह से अलग स्थिति है, यही कारण है कि स्टोरेज प्लान उपयोगी होते हैं। एक सिंगल स्पिनिंग डिस्क अभी भी 150 MB/s से 250 MB/s की गति से स्ट्रीम करती है, और उनका एक ऐरे इससे भी अधिक स्ट्रीम करता है। यह 1 Gbit/s पोर्ट को सैचुरेट कर देता है, इसलिए बैकअप अपलोड पूरी नेटवर्क गति पर चलता है और डिस्क कभी भी बाधा नहीं बनती। आपके आंकड़े इस पर भी निर्भर करते हैं कि ऐरे कैसे बनाया गया है, क्योंकि स्ट्रिपिंग एक अनुरोध को कई डिस्क में फैला देती है: how RAID 10 changes storage plan performance में इसे विस्तार से समझाया गया है।

VDS का क्या अर्थ है?

आमतौर पर यह एक मार्केटिंग लेबल है। इसके तीन अर्थ प्रचलित हैं, और प्रदाता शायद ही कभी स्पष्ट करते हैं कि कौन सा लागू होता है। कुछ प्रदाता VDS का उपयोग pinned या dedicated CPU cores के लिए करते हैं, ताकि कोई अन्य tenant आपके cycles के लिए प्रतिस्पर्धा न करे। कुछ इसका उपयोग KVM जैसी full virtualization के लिए करते हैं, जो LXC या OpenVZ जैसी container virtualization के विपरीत है, जहाँ आप host kernel साझा करते हैं। कुछ इसका उपयोग केवल एक ऐसे नाम के रूप में करते हैं जो VPS से अधिक प्रभावशाली लगता है।

आप सर्वर के अंदर से इसका कुछ हिस्सा स्पष्ट कर सकते हैं। systemd-detect-virt एक full virtual machine पर kvm प्रिंट करता है और container पर lxc, और container का अर्थ है कि आप kernel modules लोड नहीं कर सकते या अपना स्वयं का kernel नहीं चला सकते। dedicated CPU के दावे को आपको मापना होगा, जिसके लिए नीचे दिए गए steal time check का उपयोग करें। प्लान पर लिखे अक्षरों को केवल एक संकेत मानें, और spec लाइनों को ही अनुबंध समझें।

नाम के बजाय किन spec लाइनों की जाँच करें

• क्षमता के बगल में लिखा शब्द: NVMe, SSD, SATA या HDD। यदि पेज पर कहीं भी डिस्क का प्रकार नहीं लिखा है, तो उस सबसे सस्ते हार्डवेयर को मानें जो कीमत के दायरे में आता है।
• क्या डिस्क नोड के लिए local है या network attached है। Network attached storage हर request पर latency बढ़ाता है और नोड फेल होने पर भी सुरक्षित रहता है। Local disk तेज होती है और नोड के साथ ही नष्ट हो जाती है।
• CPU का विवरण: "dedicated" या "pinned" बनाम "shared", "fair share" या कुछ भी न लिखा होना।
• प्लान में लिखा कोई भी IOPS या MB/s का cap। 500 IOPS का cap होने पर डिस्क का प्रकार लगभग अप्रासंगिक हो जाता है।
• मासिक transfer allowance और port speed, जो यह तय करते हैं कि पूरा restore होने में कितना समय लगेगा।
• क्या snapshots, backups और अतिरिक्त IP addresses शामिल हैं या उनके लिए अलग से शुल्क लिया जाता है।

आपको वास्तव में मिली डिस्क की जाँच कैसे करें

कर्नेल (kernel) जो रिपोर्ट करता है, उससे शुरुआत करें, लेकिन फिर उस पर भरोसा करना बंद कर दें।

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

ROTA रोटेशनल डिवाइस के लिए 1 और फ्लैश के लिए 0 होता है। VPS के अंदर इस पर भरोसा न करें: एक virtio डिस्क आमतौर पर ROTA=0 रिपोर्ट करती है, चाहे उसके पीछे कुछ भी हो, क्योंकि हाइपरवाइजर एक जेनेरिक ब्लॉक डिवाइस प्रस्तुत करता है और गेस्ट को कभी भी भौतिक ड्राइव दिखाई नहीं देती। इसी कारण से MODEL खाली रहता है। यह फ्लैग बताता है कि हाइपरवाइजर ने क्या घोषित किया है, न कि रैक में क्या घूम रहा है, इसलिए इसके बजाय मापें।

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 पेज कैश को बायपास करता है, इसलिए आप RAM के बजाय डिस्क को मापते हैं। पढ़ने वाली लाइन read: IOPS= है, जिसके नीचे clat percentiles (usec) के अंतर्गत वितरण दिया गया है। एक मानक NVMe प्लान एक मिलीसेकंड से कम के 99वें परसेंटाइल के साथ हजारों IOPS की रिपोर्ट करता है। एक स्पिनिंग स्टोरेज प्लान कुछ सौ IOPS की रिपोर्ट करता है, जिसका 99वां परसेंटाइल दो अंकों वाले मिलीसेकंड में होता है। यदि fio रिपोर्ट करता है कि libaio इंजन लोड करने योग्य नहीं है, तो --ioengine=psync --iodepth=1 का उपयोग करें और कम संख्या की अपेक्षा करें, क्योंकि वह इंजन एक बार में एक ही अनुरोध जारी करता है।

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

vmstat में, st कॉलम 'steal time' है: वह समय का हिस्सा जब आपका vCPU चलने के लिए तैयार था, लेकिन होस्ट ने वे चक्र किसी अन्य गेस्ट को दे दिए। 5 से ऊपर का स्थिर आंकड़ा यह दर्शाता है कि नोड ओवरसब्सक्राइब है, जो "डेडिकेटेड CPU" के दावे का वास्तविक परीक्षण है। iostat -x में, %util, r_await और w_await पर नज़र रखें। 100 के करीब %util और दहाई मिलीसेकंड में w_await का मतलब है कि डिस्क ही बाधा (bottleneck) है और कोई भी एप्लिकेशन ट्यूनिंग मदद नहीं करेगी। फ्लैश-विशिष्ट जाँचों के लिए, यह सत्यापित करना कि NVMe डिस्क वास्तव में NVMe है अधिक गहराई से जानकारी देता है।

वर्कलोड के आधार पर चयन

• restic, Borg या rsync के लिए बैकअप टारगेट। यह एक Storage VPS है और इसे इसी उद्देश्य के लिए बनाया गया है। इसमें writes बड़े और sequential होते हैं, deduplication source machine पर होता है, और परिणाम के लिए किसी चीज़ को प्रतीक्षा नहीं करनी पड़ती। एक सावधानी: restic prune और restic check --read-data पूरे repository को छोटे टुकड़ों में पढ़ते हैं, इसलिए उनके लिए घंटों का समय रखें और उन्हें एक schedule पर चलाएं। देखें VPS पर restic बैकअप चलाना।
• Immich या Jellyfin मीडिया लाइब्रेरी। फाइलों के लिए Storage VPS का उपयोग करें, लेकिन CPU के बारे में सावधानी बरतें। Immich import के दौरान thumbnails बनाता है और machine learning jobs चलाता है, जबकि Jellyfin playback के दौरान transcoding करता है। दो shared vCPU के साथ 200 GB फोटो का पहला import बहुत धीमा होगा। डेटाबेस और thumbnail cache को सर्वर की सबसे तेज़ डिस्क पर रखें। Google Photos के विकल्प के रूप में Immich को self-host करना में sizing की जानकारी दी गई है।
• PostgreSQL या MySQL। Standard NVMe प्लान का उपयोग करें। हर commit एक fsync पर समाप्त होता है जिसे transaction पूरा होने से पहले durable storage तक पहुँचना होता है, इसलिए commit latency ही डिस्क की latency है। इंडेक्स लुकअप 8 kB का random read होता है, जो spinning disk के लिए सबसे खराब प्रदर्शन वाला कार्य है।
• Web application, API या control plane। Standard प्लान का उपयोग करें। इन्हें cores और predictable latency की आवश्यकता होती है, और इन्हें शायद ही कभी 100 GB से अधिक की आवश्यकता होती है।
• CI cache या artifact store। यह फाइल के आकार पर निर्भर करता है। बड़े tarballs स्टोरेज प्लान से पूरी नेटवर्क गति पर स्ट्रीम होते हैं। लाखों छोटी फाइलों का cache, जिसे कई runners द्वारा समानांतर (parallel) रूप से pull किया जाता है, वास्तव में random IO है और यह आपको निराश करेगा।

जब आप इसे गलत तरीके से कॉन्फ़िगर करते हैं तो क्या होता है

विफलता कभी भी तुरंत नहीं होती है। एक स्पिनिंग स्टोरेज प्लान पर चल रहा डेटाबेस एक उपयोगकर्ता के साथ ठीक काम करता है, लेकिन दस उपयोगकर्ताओं के आने पर बैठ जाता है। ऐसा इसलिए होता है क्योंकि जो क्वेरी पहले RAM से पूरी हो जाती थीं, वे अब डिस्क पर जाने लगती हैं। प्रत्येक क्वेरी में अब माइक्रोसेकंड के बजाय मिलीसेकंड का समय लगता है। लोड एवरेज बढ़ जाता है जबकि top यह दिखाता है कि CPU ज्यादातर खाली है और %wa का आंकड़ा बहुत अधिक है। इसका मतलब है कि प्रोसेस कुछ भी गणना करने के बजाय डिस्क का इंतजार कर रही हैं। iostat -x 1 यह दिखाता है कि %util लगभग 100 पर स्थिर है।

PostgreSQL इसे अपने लॉग में स्पष्ट रूप से बताता है, क्योंकि log_checkpoints वर्जन 15 से डिफ़ॉल्ट रूप से चालू रहता है:

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

sync= का आंकड़ा सबसे महत्वपूर्ण है। यह वह समय है जो चेकपॉइंट ने fsync के रिस्पॉन्स का इंतजार करने में बिताया। यदि यह मान सेकंड में है, तो इसका मतलब है कि डिस्क डेटाबेस द्वारा उत्पन्न किए जा रहे राइट ऑपरेशंस को उतनी तेजी से प्रोसेस नहीं कर पा रही है। उस दौरान क्लाइंट कनेक्शन रुक जाते हैं, भले ही क्वेरी बहुत सरल क्यों न हो। इसका समाधान कोई कॉन्फ़िगरेशन बदलाव नहीं है। डेटा डायरेक्टरी को NVMe पर ले जाएं और स्टोरेज प्लान का उपयोग केवल उसी काम के लिए करें जिसके लिए वह उपयुक्त है, यानी उस डेटाबेस का बैकअप रखने के लिए।

FAQ

क्या storage VPS एक सामान्य VPS की तुलना में धीमा होता है?

रैंडम रीड और राइट के लिए, हाँ, काफी बड़े अंतर से। एक spinning storage प्लान प्रति सेकंड कुछ सौ छोटे रैंडम अनुरोधों को लगभग 8 ms में पूरा करता है, जबकि एक NVMe प्लान 1 ms से काफी कम समय में हजारों अनुरोधों को पूरा कर देता है। सीक्वेंशियल ट्रांसफर के लिए दोनों के बीच का अंतर कम होता है, क्योंकि एक स्टोरेज ऐरे भी 150 MB/s या उससे अधिक की स्पीड से डेटा स्ट्रीम कर सकता है, जो 1 Gbit/s पोर्ट को भरने के लिए पर्याप्त है। निर्णय लेने से पहले fio --rw=randread --bs=4k --direct=1 के साथ स्वयं मापें।

क्या मैं storage VPS पर PostgreSQL चला सकता हूँ?

आप इसे शुरू कर सकते हैं, और यह तब तक काम करेगा जब तक कि वर्किंग सेट RAM में फिट रहता है। उसके बाद, हर कमिट धीमी डिस्क पर fsync की प्रतीक्षा करता है, और Postgres इसे checkpoint complete के अंदर sync= के रूप में सेकंड में लॉग करता है, जबकि iostat -x 1 उच्च w_await के साथ %util को 100 के करीब दिखाता है। सामान्य व्यवस्था यह है कि डेटाबेस के लिए एक छोटा NVMe VPS और उसके डंप के लिए एक storage VPS का उपयोग किया जाए।

क्या VDS का मतलब है कि मुझे dedicated hardware मिलता है?

विश्वसनीय रूप से नहीं। VDS का कोई मानक अर्थ नहीं है। कुछ प्रदाता इसका उपयोग pinned CPU cores के लिए करते हैं, कुछ shared kernel container के विपरीत पूर्ण KVM वर्चुअलाइजेशन के लिए, और कुछ इसे केवल एक नाम के रूप में उपयोग करते हैं। यह देखने के लिए कि आप kvm पर हैं या lxc पर, systemd-detect-virt चलाएँ, और यह देखने के लिए कि क्या अन्य tenants आपके CPU cycles का उपयोग कर रहे हैं, vmstat 1 5 चलाएँ और st कॉलम पर नज़र रखें।

मैं कैसे बता सकता हूँ कि मेरी VPS डिस्क वास्तव में NVMe है?

lsblk -d -o NAME,ROTA,MODEL पर भरोसा न करें, क्योंकि virtio डिस्क सामान्य रूप से ROTA=0 और एक खाली मॉडल स्ट्रिंग रिपोर्ट करती है, चाहे हार्डवेयर कुछ भी हो। --direct=1 के साथ 30 सेकंड का fio रैंडम रीड टेस्ट चलाएँ और IOPS तथा 99th percentile लेटेंसी पढ़ें। डबल डिजिट मिलीसेकंड में सैकड़ों IOPS का मतलब है कि यह एक spinning ऐरे है। एक मिलीसेकंड से कम समय में हजारों IOPS का मतलब है कि यह फ्लैश है।