व्यावहारिक VPS बैकअप रणनीति (3-2-1 नियम)

ApexVPS टीम द्वारा लिखित • अंतिम अद्यतन: जुलाई 2026 • 7 मिनट पढ़ें

एक विश्वसनीय VPS बैकअप रणनीति पाँच मिनट में रिकवरी और बहुत बुरे सप्ताह के बीच का अंतर है। सर्वर विफल हो जाते हैं, डिस्क दूषित हो जाती हैं, डिप्लॉय गलत हो जाते हैं, और एक गलत टाइप किया गया कमांड किसी निर्देशिका को मिटा सकता है। Cloudflare Learning Center और अधिकांश इन्फ्रास्ट्रक्चर टीमें एक ही सरल अनुशासन की ओर इशारा करती हैं: 3-2-1 नियम। यह मार्गदर्शिका दिखाती है कि इसे वास्तविक वर्चुअल सर्वर पर कैसे लागू करें, कौन से टूल का उपयोग करें, और सब कुछ कैसे शेड्यूल और परीक्षण करें ताकि रिस्टोर वास्तव में तब काम करे जब आपको इसकी आवश्यकता हो।

3-2-1 नियम का क्या अर्थ है

3-2-1 नियम एक दशकों पुराना बैकअप सिद्धांत है जो तब भी सत्य रहता है जब आपका सर्वर कहीं भी रहता है:

VPS पर इसका आमतौर पर मतलब है आपका चल रहा सर्वर, एक स्थानीय बैकअप रिपॉजिटरी, और एक एन्क्रिप्टेड कॉपी जो किसी भिन्न स्थान पर रिमोट स्टोरेज में भेजी जाती है। मुद्दा है अतिरेक (redundancy) बिना किसी साझा विफलता बिंदु के।

VPS पर क्या बैकअप करें

पूरी डिस्क को ब्लॉक-दर-ब्लॉक बैकअप करना बेकार और धीमा है। एक अच्छी बैकअप योजना तीन चीज़ों पर लक्षित होती है जिन्हें दोबारा बनाना वास्तव में कठिन है।

एप्लिकेशन डेटा और फ़ाइलें

अपलोड की गई फ़ाइलें, वेबसाइट रूट, कंटेनर वॉल्यूम, और उपयोगकर्ता द्वारा जनरेट की गई कोई भी चीज़। विशिष्ट पथों में /var/www, /srv, /home और आपकी Docker वॉल्यूम निर्देशिका शामिल हैं। यदि आप फ़ाइल सर्वर या विकी जैसे ऐप्स स्वयं-होस्ट करते हैं, तो आपकी अपूरणीय सामग्री यहाँ होती है — उन निर्देशिकाओं के सामान्य लेआउट के लिए सेल्फ-होस्टिंग के लिए VPS चलाने पर हमारी मार्गदर्शिका देखें।

डेटाबेस

सेवा चल रहे समय में लाइव डेटाबेस फ़ाइलों की कभी नकल न करें — आप आधे-लिखे, दूषित स्थिति को पकड़ सकते हैं। इसके बजाय एक सुसंगत डंप निर्यात करें। MySQL या MariaDB के लिए:

mysqldump --single-transaction --routines --triggers \
  -u backup -p mydatabase > /srv/backups/mydatabase.sql

--single-transaction ध्वज InnoDB टेबल्स को लॉक किए बिना एक सुसंगत स्नैपशॉट देता है। PostgreSQL के लिए, pg_dump का उपयोग करें:

pg_dump -U postgres -Fc mydatabase > /srv/backups/mydatabase.dump

सिस्टम और सेवा कॉन्फ़िगरेशन

वे फ़ाइलें जो आपके सर्वर को आपका बनाती हैं: /etc (nginx, systemd इकाइयाँ, cron, SSH कॉन्फ़िग), पैकेज सूचियाँ, TLS प्रमाणपत्र, और फ़ायरवॉल नियम। विफलता के बाद स्मृति से इन्हें फिर से बनाना ठीक वही थकाऊ काम है जिसे बैकअप टालने के लिए होते हैं।

अपने बैकअप टूल चुनना

तीन टूल लगभग हर VPS मामले को कवर करते हैं। डीडुप्लीकेशन और एन्क्रिप्शन के लिए आप कितना महत्व देते हैं, उसके आधार पर चुनें।

restic — एन्क्रिप्टेड, डीडुप्लीकेटेड स्नैपशॉट

restic एक आधुनिक, सिंगल-बाइनरी बैकअप टूल है जो डिफ़ॉल्ट रूप से एन्क्रिप्ट और डीडुप्लीकेट करता है। एक बार रिपॉजिटरी इनिशियलाइज़ करें, फिर उसके विरुद्ध बैकअप चलाएँ:

# One-time: create an encrypted repository
restic init --repo /srv/backups/restic

# Back up files and your database dump
restic -r /srv/backups/restic backup /etc /var/www /srv/backups/mydatabase.sql

# List what you have
restic -r /srv/backups/restic snapshots

BorgBackup — डीडुप्लीकेटिंग आर्काइव

BorgBackup समान डीडुप्लीकेशन और कम्प्रेशन प्रदान करता है, थोड़े अलग कार्यप्रवाह के साथ:

borg init --encryption=repokey /srv/backups/borg
borg create --stats /srv/backups/borg::'{hostname}-{now}' /etc /var/www

rsync — सरल फ़ाइल मिररिंग

जब आपको किसी अन्य होस्ट पर फ़ाइलों का तेज़ मिरर चाहिए, तो SSH पर rsync को हराना कठिन है:

rsync -aAX --delete /var/www/ [email protected]:/backups/www/

-aAX ध्वज अनुमतियाँ, ACL और विस्तारित विशेषताओं को संरक्षित करते हैं; --delete मिरर को स्रोत के साथ चालू रखता है। rsync अकेले संस्करण इतिहास नहीं रखता, इसलिए कई टीमें इसे restic या borg के साथ जोड़ती हैं।

cron के साथ शेड्यूल को स्वचालित करें

जिस बैकअप को याद रखना पड़े वह बैकअप नहीं होता। अपने चरणों को एक स्क्रिप्ट में रखें, उसे निष्पादन योग्य बनाएं, और cron के साथ शेड्यूल करें। अपना crontab संपादित करें:

crontab -e

फिर ऐसी पंक्तियाँ जोड़ें:

# Full file + config backup every night at 02:15
15 2 * * * /usr/local/bin/vps-backup.sh

# Database dump every hour on the hour
0 * * * * /usr/local/bin/db-dump.sh

आउटपुट लॉग करें, और स्क्रिप्ट को विफलता पर गैर-शून्य निकास दें ताकि आप इसे अपनी योजना के साथ आने वाली निगरानी और अलर्टिंग सुविधाओं से जोड़ सकें। मौन बैकअप विफलता बिना बैकअप से भी बदतर है, क्योंकि यह सुरक्षित लगता है।

वास्तविक ऑफसाइट कॉपी रखें

3-2-1 का "1" वह हिस्सा है जिसे अधिकांश लोग छोड़ देते हैं। जो बैकअप उसी सर्वर पर है जिसकी वह सुरक्षा करता है, वह उस सर्वर के साथ गायब हो जाता है। कहीं स्वतंत्र एन्क्रिप्टेड प्रति भेजें — ऑब्जेक्ट स्टोरेज, रिमोट SFTP बॉक्स, या कोई अन्य प्रदाता। restic और borg दोनों सीधे रिमोट रिपॉजिटरी में लिखते हैं, उदाहरण के लिए SFTP पर:

restic -r sftp:[email protected]:/backups/restic backup /var/www

क्योंकि restic और borg आपके VPS से डेटा निकलने से पहले एन्क्रिप्ट करते हैं, रिमोट होस्ट कभी आपका प्लेनटेक्स्ट नहीं देखता। पुराने स्नैपशॉट को नीति पर प्रून करें ताकि स्टोरेज हमेशा न बढ़े:

restic -r /srv/backups/restic forget --keep-daily 7 --keep-weekly 4 --keep-monthly 6 --prune

अपने रीस्टोर का परीक्षण करें — हर बार

अपरीक्षित बैकअप एक अफवाह है। एक अस्थायी स्थान पर आवधिक रीस्टोर शेड्यूल करें और पुष्टि करें कि फ़ाइलें और डेटाबेस बरकरार लौटते हैं:

# Restore the latest snapshot into a scratch directory
restic -r /srv/backups/restic restore latest --target /tmp/restore-test

# Verify repository integrity
restic -r /srv/backups/restic check

# Re-import a database dump into a scratch database
mysql -u root -p restore_test < /srv/backups/mydatabase.sql

यदि बैकअप सफल होता है और डेटा मेल खाता है, तो आपके पास एक रणनीति है। यदि नहीं, तो आपने अभी सीखा है कि मंगलवार की दोपहर को, वास्तविक आउटेज के बजाय।

स्नैपशॉट एक परत हैं, पूरी रणनीति नहीं

हर ApexVPS प्लान में स्वचालित बैकअप शामिल हैं — Starter Pro पर दैनिक स्नैपशॉट और Business पर प्रति घंटा स्नैपशॉट — और वे खराब डिप्लॉय या आकस्मिक विलोपन के बाद त्वरित रोलबैक के लिए वास्तव में उपयोगी हैं। लेकिन ईमानदार रहें कि वे क्या हैं: एक सुविधाजनक पहली परत जो हमारे प्लेटफ़ॉर्म पर रहती है। वे 3-2-1 नियम के लिए आवश्यक ऑफसाइट, स्वतंत्र रूप से सत्यापित प्रति के विकल्प नहीं हैं। प्लेटफ़ॉर्म स्नैपशॉट को अपने तेज़ स्थानीय रिस्टोर पॉइंट के रूप में मानें, और नियम के ऑफसाइट और परीक्षण-रिस्टोर भागों को पूरा करने के लिए अपना खुद का restic या borg जॉब चलाएं। यह परतदार दृष्टिकोण ही एक आशावान सेटअप को लचीले से अलग करता है, चाहे आप Nextcloud जैसे ऐप्स सेल्फ-होस्ट करें या प्रोडक्शन डेटाबेस चलाएं।

आपकी VPS बैकअप रणनीति चेकलिस्ट

सभी टुकड़ों को जोड़कर, एक वर्चुअल सर्वर के लिए पूर्ण बैकअप रणनीति इस प्रकार दिखती है। इसे एक बार पूरा करें, स्क्रिप्ट करें, और cron को आगे बढ़ाने दें:

ये छह चीजें करें और 3-2-1 नियम सिद्धांत नहीं बल्कि एक आदत बन जाता है जिस पर आपका इंफ्रास्ट्रक्चर भरोसा कर सकता है। सेटअप का एक घंटा उस लागत की तुलना में मामूली है जो यह जानने पर आती है कि आपकी एकमात्र कॉपी उस डिस्क पर थी जो अभी-अभी मर गई।

क्या आपको इसे चलाने के लिए पूरी तरह से नियंत्रित सर्वर चाहिए? ApexVPS आपको 39 डेटा सेंटरों में पूर्ण रूट एक्सेस, NVMe स्टोरेज और समर्पित संसाधन देता है — क्रिप्टो-केवल चेकआउट के साथ, कोई कार्ड नहीं और कोई KYC नहीं। समर्पित VPS प्लानों की तुलना करें →

अक्सर पूछे जाने वाले प्रश्न

क्या प्रदाता स्नैपशॉट एक बैकअप रणनीति माने जाते हैं?

स्नैपशॉट एक उपयोगी परत हैं, लेकिन पूरी रणनीति नहीं। हमारे दैनिक और प्रति घंटा स्नैपशॉट अधिकांश अल्पकालिक गलतियों से बचाते हैं, फिर भी वे आपके सर्वर के समान प्लेटफ़ॉर्म पर रहते हैं। एक पूर्ण 3-2-1 बैकअप रणनीति में अभी भी एक स्वतंत्र, ऑफसाइट प्रति की आवश्यकता होती है जिसे आप नियंत्रित करते हैं और रिस्टोर जिनका आपने वास्तव में परीक्षण किया है।

मुझे VPS का बैकअप कितनी बार लेना चाहिए?

आवृत्ति को इस बात से मिलाएं कि आप कितना डेटा खो सकते हैं। स्थिर फ़ाइलों और कॉन्फ़िगरेशन का दैनिक बैकअप लिया जा सकता है, जबकि सक्रिय डेटाबेस अक्सर प्रति घंटा डंप को उचित ठहराते हैं। शेड्यूल को स्वचालित करने के लिए cron का उपयोग करें ताकि बैकअप कभी भी याद रखने पर निर्भर न रहे।

VPS बैकअप के लिए सबसे अच्छा टूल कौन सा है?

restic और BorgBackup दोनों उत्कृष्ट हैं: वे डीडुप्लीकेट, कंप्रेस और एन्क्रिप्ट करते हैं, और ऑफसाइट रिपॉजिटरी का समर्थन करते हैं। सरल फ़ाइल मिररिंग के लिए rsync ठीक है, और mysqldump या pg_dump डेटाबेस निर्यात को संभालते हैं। कई सेटअप डेटाबेस डंप को restic या borg रन के साथ जोड़ते हैं।

मुझे कैसे पता चलेगा कि मेरे बैकअप वास्तव में काम करते हैं?

शेड्यूल पर रिस्टोर का परीक्षण करें। एक अस्थायी निर्देशिका में रिस्टोर करें, फ़ाइल सामग्री और चेकसम सत्यापित करें, और एक डेटाबेस डंप को स्क्रैच डेटाबेस में आयात करें। एक बैकअप जिसे आपने कभी रिस्टोर नहीं किया है वह केवल एक आशावान अनुमान है, पुनर्प्राप्ति योजना नहीं।