[होम](https://servhidden.com/hi) /
[गोपनीयता होस्टिंग Guides](https://servhidden.com/hi/guides) /
VPS Backup कैसे लें: Encrypted, Off-Site और भरोसेमंद Restore






परिचालन


# VPS Backup जो सच में Restore होता है



No-KYC hosting काग़ज़ी कार्रवाई के साथ-साथ सुरक्षा-जाल भी हटा देती है: कोई backup नहीं रखा जाता, termination के 24 घंटे के भीतर data नष्ट हो जाता है, और कोई ऐसा support रास्ता नहीं जो किसी recovered copy पर ख़त्म हो। यही असली योजना है — क्या copy करें, कहाँ रखें, हमलावर को उसे मिटाने से कैसे रोकें, और यह कैसे साबित करें कि वह restore होता है।


[गाइड पढ़ें](#guide-body)
[FAQ](#guide-faq)






## इस पेज पर




- [गाइड](#guide-body)

- [FAQ](#guide-faq)

- [संबंधित गाइड्स](#guide-related)

- [सुझाए गए पेज](#guide-cta)






KYC नहीं
केवल क्रिप्टो
लॉग नहीं
DMCA अनदेखा
पूर्ण रूट
NVMe SSD





18 मिनट पढ़ें
Aug 2026 को अपडेट किया

इस पेज पर

[01server को असल में बर्बाद कौन करता है](#server-क-असल-म-बरबद-कन-करत-ह)
[02snapshot backup नहीं है, और आपका host भी नहीं](#snapshot-backup-नह-ह-और-आपक-host-भ-नह)
[033-2-1 नियम, उनके लिए फिर से लिखा गया जिन्होंने कभी कोई ID नहीं दिखाई](#3-2-1-नयम-उनक-लए-फर-स-लख-गय-जनहन-कभ-कई-id-नह-दखई)
[04Push, pull, और वह ग़लती जो एक बुरी रात में दोनों copies खा जाती है](#push-pull-और-वह-गलत-ज-एक-बर-रत-म-दन-copies-ख-जत-ह)
[05पहले source पर ही encrypt करें, फिर तय करें key किसके पास रहेगी](#पहल-source-पर-ह-encrypt-कर-फर-तय-कर-key-कसक-पस-रहग)
[06एक ही table में, tool कैसे चुनें](#एक-ह-table-म-tool-कस-चन)
[07जो चल रहा है वह file नहीं है](#ज-चल-रह-ह-वह-file-नह-ह)
[08क्या backup करें, और वे हिस्से जो हर कोई भूल जाता है](#कय-backup-कर-और-व-हसस-ज-हर-कई-भल-जत-ह)
[09जिस restore को आपने आज़माया नहीं, वह बस एक अफ़वाह है](#जस-restore-क-आपन-आजमय-नह-वह-बस-एक-अफवह-ह)
[10इसे automate करें ताकि यह चलता रहे](#इस-automate-कर-तक-यह-चलत-रह)
[11छोटी-सी बात](#छट-स-बत)
[FAQCommon प्रश्न](#guide-faq)
[→सुझाए गए पेज](#guide-cta)







backup strategy की असली परीक्षा उस रात नहीं होती जब server मर जाता है। यह हफ़्तों पहले, तीन खामोश फ़ैसलों में तय हो चुकी होती है जिन्हें कोई लिखकर नहीं रखता: copy कहाँ जाएगी, उसे मिटाने का हक़ किसे है, और क्या किसी ने वाकई उसे वापस पढ़कर देखा है।

जो hosting आपकी पहचान कभी माँगती ही नहीं, वह बदले में कुछ छोड़ भी देती है, और यही जगह है इसे साफ़ कहने की। यहाँ फ़ोन करने के लिए कोई account manager नहीं है, कोई ऐसा ticket नहीं जो मिटा हुआ volume वापस ज़िंदा कर दे, और [हमारी अपनी retention policy](https://servhidden.com/hi/privacy) इसकी वजह साफ़-साफ़ बताती है: termination के 24 घंटे के भीतर server का data नष्ट कर दिया जाता है, disks को format नहीं बल्कि cryptographically wipe किया जाता है, और **कोई भी backup रखा नहीं जाता**। यही खूबी दूसरी तरफ़ से देखने पर इस platform को खरीदने लायक बनाती है। किसी बुरी रात के बाद जो कुछ भी आपको वापस चाहिए, वह पहले से ही कहीं और होना चाहिए — और उसे वहाँ पहुँचाने वाले आप ही हैं।

## server को असल में बर्बाद कौन करता है

लगभग कोई भी अपना server उस तरह से नहीं खोता जैसा वह सोचता है। भयंकर hardware failure सच में होती है, पर कम ही, और यह वह इकलौता मामला है जिसके ख़िलाफ़ एक सक्षम host पहले से ही तैयारी कर चुका होता है। जो नुकसान असल में होते हैं वे उससे कहीं ज़्यादा फीके होते हैं, और हर एक अलग तरह की copy को मात देता है — इसीलिए "मेरे पास backup है" तब तक कोई जवाब नहीं है जब तक आप यह न बताएँ कि इनमें से किससे वह बचता है।

| क्या गड़बड़ होती है | यह आम तौर पर कैसे होता है | वापसी किससे मिलती है |
| --- | --- | --- |
| **आपका अपना हाथ** | एक खाली shell variable के साथ चला rm -rf, production की तरफ़ इशारा करता एक migration, ग़लत table गिरा देने वाला एक deploy | *ग़लती से पहले* की कोई भी off-box copy — यानी retention को आपके ग़ौर करने में लगने वाले समय से कहीं आगे तक पहुँचना होगा |
| **ख़ामोश corruption** | मरता हुआ NVMe, reboot के दौरान अधूरा लिखा गया data, एक हफ़्ते से ख़राब rows लिख रहा database | किसी भरोसेमंद बिंदु तक पहुँचने लायक गहरी versioned copies। एक अकेली mirrored copy नुकसान को भी उतनी ही ईमानदारी से mirror कर देती है |
| **Compromise** | एक चुराई गई key, एक बिना patch वाला application, एक ज़हरीली dependency — और फिर, जान-बूझकर, आपके backups | ऐसी copy जिसे मिटाने की ताक़त compromise हुई machine के पास कभी थी ही नहीं। यहाँ बस यही मायने रखता है |
| **किसी provider या देश से जुड़ी घटना** | Hardware का नुकसान, datacentre पर कोई क़ानूनी कार्रवाई, ऐसा account या token जिस तक अब आपकी पहुँच नहीं | ऐसी copy जो न उस provider के पास हो, न उस jurisdiction के अंदर |
| **key खो देना** | भूला हुआ passphrase, server के साथ ही मिट गई keyfile, कभी export न की गई LUKS header | **कुछ नहीं।** यह इकलौती पंक्ति है जिसमें वापसी का कोई रास्ता नहीं, और यह hardware failure से भी ज़्यादा आम है |

इस table को डर की सूची नहीं, checklist की तरह पढ़ें। एक ही machine की दूसरी disk पर हर रात जाने वाली copy सिर्फ़ पहली पंक्ति का जवाब देती है, और कुछ नहीं। उसी panel में रखा snapshot पहली और दूसरी दोनों पंक्तियों का जवाब देता है। सिर्फ़ वह copy जो server की पहुँच से बाहर, आपके पास मौजूद किसी key के तहत रखी हो, पाँचों का जवाब देती है।

backup target को cores नहीं, बस disk और एक पते की ज़रूरत होती है। किसी दूसरे jurisdiction में सबसे सस्ती दूसरी machine एक सक्षम endpoint है — और वही इकलौती copy है जो पहले provider पर हुई किसी घटना के बाद भी बचती है।

## snapshot backup नहीं है, और आपका host भी नहीं

snapshots जो करते हैं उसमें बेहतरीन हैं: वे किसी ग़लत upgrade को सेकंडों में, बिना कोई transfer किए, वापस पलट देते हैं। जो वे नहीं कर सकते वह है server को ले जाने वाली घटना से बच पाना, क्योंकि वे उसी के साथ हर failure domain बाँटते हैं — वही provider, वही account, वही billing token, वही देश, अक्सर वही storage cluster भी। snapshot आपको *ख़ुद से* बचाता है। backup आपको बाक़ी सब चीज़ों से बचाता है।

यहाँ यह फ़र्क़ किसी mainstream host के मुक़ाबले कहीं ज़्यादा मायने रखता है, क्योंकि आम safety nets जान-बूझकर हटा दिए गए हैं। कोई भी customer के server में लॉग-इन नहीं करता, इसलिए किसी को पता ही नहीं चलता कि आपका backup job मार्च से fail हो रहा है। account से कोई पहचान जुड़ी नहीं होती, इसलिए "साबित करें कि आप कौन हैं और हम इसे restore कर देंगे" जैसा कोई इंसानी रास्ता भी नहीं बचता। और termination सचमुच अंतिम होता है: एक ख़त्म हो चुका balance billing की नहीं, data खोने की घटना है।

**24 घंटे वाली शर्त ही पूरी दलील है।** इस platform पर किसी terminate किए गए server का data एक दिन के भीतर नष्ट कर दिया जाता है, और disks को format नहीं बल्कि cryptographically wipe किया जाता है। यहाँ न कोई undelete है, न कोई चुपचाप चलने वाला cold-storage tier, न ही support का कोई ऐसा नतीजा जो "हमें एक पुरानी copy मिल गई" पर ख़त्म हो — क्योंकि एक copy रखने का मतलब होगा आपके मना करने के बाद भी आपका data पास रखना। safety net और privacy, दोनों एक ही सौदे का हिस्सा हैं, जो एक बार में तय हो चुका।

## 3-2-1 नियम, उनके लिए फिर से लिखा गया जिन्होंने कभी कोई ID नहीं दिखाई

पारंपरिक नियम कहता है: तीन copies, दो तरह के media पर, जिनमें से एक off-site हो। यह tape और spinning disk के ज़माने के लिए लिखा गया था, और media वाली शर्त चुपचाप बेमानी हो चुकी है: आपकी production disk भी NVMe है, आपके backup target की disk भी NVMe है, और इसे "दो media" कहना बस अपने आप को सुनाई गई एक कहानी है। बचाने लायक शर्त दूरी वाली है, और offshore infrastructure में दूरी किलोमीटर में नहीं नापी जाती।

इसे यूँ फिर से लिखें: **तीन copies, दो providers, दो jurisdictions**। जो घटनाएँ दोनों copies को एक साथ ख़त्म करती हैं वे लगभग कभी भौतिक नहीं होतीं — वे होती हैं किसी account तक खो चुकी पहुँच, किसी provider का बुरा हफ़्ता, या किसी एक देश में असर डालने वाला और दूसरे में बेअसर एक क़ानूनी आदेश। एक ही rack में रखे दो servers, अतिरिक्त मेहनत वाली सिर्फ़ एक copy भर हैं; एक ही क़ानूनी दायरे के अंदर दो servers भी मुश्किल से ही बेहतर हैं। हमारी [jurisdiction guide](https://servhidden.com/hi/guides/choosing-an-offshore-jurisdiction) बताती है कि ऐसा दूसरा जुरिस्डिक्शन कैसे चुनें जो पहले के जोखिम को ही न दोहराए।

असल में यह सस्ता पड़ता है। एक backup target को cores की ज़रूरत नहीं, और network की भी मुश्किल से ज़रूरत पड़ती है — उसे बस disk और एक पता चाहिए। सबसे छोटा [VPS tier](https://servhidden.com/hi/vps), हमारे [सात locations](https://servhidden.com/hi/locations) में से किसी अलग location में, एक सक्षम restic या Borg endpoint बन जाता है, और terabytes में नापे जाने वाले archives के लिए असली drives वाला [dedicated box](https://servhidden.com/hi/dedicated) किसी भी object store से प्रति terabyte सस्ता पड़ता है। जहाँ data सचमुच बड़ा हो और कम ही पढ़ा जाता हो, वहाँ अर्थशास्त्र bare metal के पक्ष में काफ़ी झुक जाता है।

एक बात लोग production में तो सही करते हैं पर backup target पर ग़लत: उसके लिए भी उसी तरह भुगतान करें। अपने ही नाम के card से ख़रीदा गया दूसरा server, चुपचाप वही पहचान वापस जोड़ देता है जिसे हटाने में आपने पहले मेहनत की थी — और अब उस पर पहले server की पूरी copy भी मौजूद है। अगर production box का भुगतान [Monero में](https://servhidden.com/hi/guides/how-to-pay-for-hosting-with-monero) हुआ है, तो backup box को भी वही बर्ताव मिलना चाहिए।

तीसरी copy वही है जिसे ज़्यादातर लोग छोड़ देते हैं, और यही इकलौती है जो हर दूर की घटना से एक साथ अछूती रहती है: एक disk जिसे आप ख़ुद अपने हाथ में रखें, कभी-कभार update करें, और offline रखें। ज़्यादातर लोगों के लिए महीने में एक बार काफ़ी है। इसमें बस एक कॉफ़ी जितना ध्यान लगता है, और यही वह copy है जो बाक़ी दोनों के साझा हालात में भी बची रहती है।

## Push, pull, और वह ग़लती जो एक बुरी रात में दोनों copies खा जाती है

यह है वह ढाँचा जो लगभग हर कोई सबसे पहले बनाता है। production server पर हर रात एक job चलती है, जिसके पास backup target की एक key या token होता है, वह जुड़ती है, और data push कर देती है। यह काम करता है, सीधा है, पर इसमें एक खूबी ऐसी है जो server की ज़िंदगी के सबसे बुरे दिन ही दिखाई देती है: **जिसका control production box पर है, उसी का control backups पर भी है।**

यह कोई फ़र्ज़ी बात नहीं। अपनी हरकत का ऐलान करने से पहले पीड़ित के backups मिटा देना या encrypt कर देना, इसे commercially करने वालों के लिए आम तरीक़ा है — credentials किसी cron job या environment file में पड़े होते हैं, और उन्हें ढूँढने में बमुश्किल एक मिनट लगता है। ऐसी copy जिसे आपका हमलावर मिटा सकता है, दूसरी copy है ही नहीं। वह बस पहली का देरी वाला mirror है।

इसके दो साफ़-सुथरे इलाज हैं, और ये आपके पहले से किए हुए [बुनियादी hardening](https://servhidden.com/hi/guides/first-hour-vps-hardening-checklist) के साथ अच्छे से जुड़ते हैं।

- **Append-only targets।** दोनों बड़े tools एक ऐसा mode देते हैं जिसमें client data जोड़ तो सकता है, हटा नहीं सकता। Borg यह target पर SSH key को borg serve --append-only से बाँधकर करता है; restic यह --append-only से शुरू किए गए REST server के ज़रिए करता है। production server हर रात लिखता है और ढाँचागत रूप से history मिटाने में असमर्थ रहता है। पुराने snapshots की छँटाई फिर target पर होती है, ऐसे session में जिसे production box शुरू ही नहीं कर सकता।

- **Push की जगह Pull।** दिशा पलट दें: backup host production से जुड़ता है, पढ़ता है, और संभालकर रखता है। production के पास target के लिए कोई credential होता ही नहीं, तो चुराने को कुछ बचता नहीं। production वाली तरफ़ इस्तेमाल होने वाली key को restrict और एक ज़बरन command= से सीमित करें ताकि चुराई गई backup key किसी shell में न बदल सके।

Pull ज़्यादा मज़बूत तरीक़ा है और चलाने में थोड़ा ज़्यादा काम माँगता है; अगर आप पहले से Borg या restic इस्तेमाल कर रहे हैं तो append-only लगभग मुफ़्त पड़ता है। दोनों में से कोई भी "हमलावर ने मेरे backups मिटा दिए" को नतीजे से घटाकर सिर्फ़ एक कोशिश बना देता है। अगर इस guide से बस एक चीज़ लेनी हो, तो यही हिस्सा लें।

## पहले source पर ही encrypt करें, फिर तय करें key किसके पास रहेगी

दोनों गंभीर tools जिस machine का backup लिया जा रहा है उसी पर, network पार करने से पहले, data encrypt कर देते हैं। target ऐसे blobs रखता है जिन्हें वह पढ़ ही नहीं सकता — और यही वह चीज़ है जो cross-provider copy को सुरक्षित बनाती है। आपके दूसरे host का भरोसेमंद या दोस्ताना होना ज़रूरी नहीं; बस उस तक पहुँचा जा सके और उसके पास disk हो, इतना काफ़ी है। यही एक खूबी "एक ऐसा देश जिसके बारे में मुझे कुछ पता नहीं" वाले server को जोखिम से बदलकर infrastructure बना देती है।

यह server की अपनी disk को encrypt करने से अलग तरीक़ा है, और दोनों अलग-अलग सवालों के जवाब देते हैं — [VPS पर full-disk encryption](https://servhidden.com/hi/guides/full-disk-encryption-on-a-vps) पर हमारी guide इस बात में जाती है कि machine के चलते रहने के दौरान disk encryption क्या बचाता है और क्या नहीं। backup encryption इन दोनों में आसान भी है और ज़्यादा क़ीमती भी, क्योंकि इसका threat model ईमानदार है: data आराम की हालत में है, ऐसे hardware पर जिस पर आपका control नहीं, और key वहाँ कभी जाती ही नहीं।

इससे पूरा जोखिम key की हिफ़ाज़त पर आ टिकता है। passphrase अब पूरी तरह खोने का इकलौता बिंदु है, और यह लोगों की सोच से भी बुरा बिंदु है, क्योंकि इसे खोना ख़ामोशी से होता है — कुछ भी टूटता नहीं, backups चलते रहते हैं, और आपको इसका पता ठीक उसी पल चलता है जब आपको इनकी ज़रूरत होती है। तीन आदतें इसे ठीक करती हैं:

- passphrase को server पर सिर्फ़ ऐसी file के रूप में रखें जिसे सिर्फ़ root पढ़ सके, और उसे --password-file के ज़रिए इस्तेमाल करें, ताकि वह कभी किसी process list या shell history में न दिखे।

- इंसान के पढ़ने लायक एक copy इसमें शामिल हर machine से बाहर रखें। दराज़ में रखा काग़ज़ सचमुच उस password manager से बेहतर है जो किसी ऐसे account से sync होता है जिसकी पहुँच भी आप खो सकते हैं।

- repository में एक दूसरी key जोड़ें — restic key add, या export की गई Borg key — ताकि एक भूला हुआ passphrase बस एक झंझट बने, archive का अंत नहीं।

तीनों के पीछे का नियम यही है: **अगर key की इकलौती copy उसी machine पर रहती है जिसकी जगह यह backup लेने के लिए है, तो आपके पास backup है ही नहीं।** आपके पास बस encrypted blocks का एक ढेर है, और उनके बारे में एक कहानी।

## एक ही table में, tool कैसे चुनें

tool का चुनाव connection की दिशा और आपकी key की हालत जितना मायने नहीं रखता, इसीलिए यह पहले नहीं छठे नंबर पर आया है। फिर भी, फ़र्क़ असली हैं, और काम के लिए ग़लत ढाँचा चुनना बाद में मेहनत बढ़ा देता है।

| Tool | निकलने से पहले encrypt करता है | Deduplicate करता है | Append-only target | कहाँ फ़िट बैठता है |
| --- | --- | --- | --- | --- |
| **restic** | हाँ, पूरी repository | हाँ | हाँ, अपने REST server के ज़रिए | डिफ़ॉल्ट चुनाव। SFTP, object storage और अपना server बोलता है, इसलिए target लगभग कुछ भी हो सकता है |
| **BorgBackup** | हाँ, पूरी repository | हाँ, समूह में सबसे बेहतर | हाँ, SSH पर native रूप से | SSH से पहुँचा जाने वाला एक Linux target। जब data बड़ा और दोहराव वाला हो तो बेजोड़ |
| **rotations के साथ rsync** | नहीं — target सब कुछ देख सकता है | आंशिक, hardlinks के ज़रिए | नहीं | पूरी तरह आपके control वाली machine पर mirror करना, जब privacy से ज़्यादा तुरंत आंशिक restore मायने रखे |
| **rclone** | सिर्फ़ rclone crypt के साथ | नहीं | storage provider पर निर्भर | पहले से मौजूद किसी archive को object storage में, या एक provider से दूसरे में ले जाना |
| **ZFS replication** | सिर्फ़ encrypted dataset के साथ | हाँ, block स्तर पर | snapshot permissions के ज़रिए | दो ZFS machines के बीच replicate करना। बेहद तेज़, दोनों सिरों पर बेहद सख़्त |
| **age या GPG के साथ tar** | हाँ, अगर आप archive को encrypt करें | नहीं | लागू नहीं | छोटे, कभी-कभार, हमेशा रखे जाने वाले archives जहाँ सादगी दक्षता पर भारी पड़े |

अकेले server के लिए, दूसरे VPS पर restic सही नतीजे तक पहुँचने का सबसे छोटा रास्ता है। किसी seedbox, media archive या मिलती-जुलती बड़ी files के ढेर के लिए, Borg का deduplication ही भरी हुई disk और आरामदायक disk के बीच का फ़र्क़ है — [seedbox guide](https://servhidden.com/hi/guides/seedbox-setup-guide) इस तरह के काम के storage पहलू को विस्तार से बताती है।

## जो चल रहा है वह file नहीं है

दुनिया का सबसे आम ख़राब backup, एक live database की सीधी file copy होता है। यह बिना किसी error के पूरा होता है, सही वज़न का लगता है, और restore होकर ऐसे table में बदल जाता है जिसे engine खोलने से मना कर देता है। copy गुज़रते वक़्त database बीच-लेखन में था; जो आपने बचाया वह पलटे जा रहे पन्ने की एक तस्वीर भर है।

इससे निकलने के तीन तरीक़े हैं, मेहनत के हिसाब से बढ़ते क्रम में। इसे dump करें: mysqldump --single-transaction बिना writers को lock किए एक सुसंगत InnoDB dump देता है, और PostgreSQL के लिए pg_dump भी वही करता है। इसे snapshot करें: filesystem को freeze करें या एक LVM या ZFS snapshot लें, snapshot से copy लें, फिर उसे छोड़ दें — बहुत बड़े data sets के लिए, जिन्हें रोज़ रात dump करना संभव नहीं, यही तरीक़ा है। या इसे रोक दें: किसी छोटी service के लिए, सुबह 04:00 बजे दो मिनट का downtime एक पूरी तरह भरोसेमंद consistency रणनीति है, और यही इकलौती है जिसमें कोई edge case नहीं बचता।

यही तर्क database से आगे भी लागू होता है। container की writable layer डिस्पोज़ेबल है, पर उसके volumes नहीं, और न ही उनके साथ रखी docker compose file और environment — ऐसा backup जो data तो लौटा दे पर definition नहीं, आपको पूरा stack याददाश्त से फिर बनाने पर मजबूर कर देता है। Message queues, persistence चालू किए हुए Redis, और किसी MTA द्वारा लिखा जा रहा mail spool — इन सबको वही बर्ताव चाहिए: रोकें, snapshot लें, या dump करें, पर कभी सीधी copy लेकर उम्मीद न लगाएँ।

## क्या backup करें, और वे हिस्से जो हर कोई भूल जाता है

ज़्यादातर लोग साफ़ दिखने वाला payload — database और application directory — backup करते हैं, और बाक़ी सब दबाव में हाथ से फिर से बनाते हैं। घंटे यहीं ख़र्च होते हैं। जो backup सही data के ढेर की बजाय एक चलती हुई system वापस दे, उसमें यह उबाऊ परत भी शामिल होनी चाहिए:

- पूरा /etc, साथ ही आपके लिखे systemd units और timers, और उससे बाहर रहने वाले कोई भी crontabs।

- TLS certificates और उनकी private keys, या कम से कम ACME account key, ताकि certificates शून्य से शुरू होने की बजाय renew हो सकें।

- Firewall नियम और package list, जो साथ मिलकर machine का ढाँचा किसी भी याददाश्त से तेज़ फिर खड़ा कर देते हैं।

- Application secrets और environment files — वे जो जान-बूझकर आपकी code repository से बाहर रखी गई हैं, और इसलिए कहीं और मौजूद ही नहीं।

- text के रूप में export किए गए DNS records, जिनमें reverse-DNS और PTR entries भी शामिल हैं, जो provider के पास रहती हैं, server पर नहीं।

**कुछ keys data नहीं हैं — वे पहचान हैं।** किसी Tor onion service की private key ही *वह* पता है: इसे खो दें तो साइट चाहे बाक़ी सब restore हो जाए, वही [.onion नाम](https://servhidden.com/hi/guides/how-to-host-a-tor-hidden-service) लेकर वापस नहीं आ सकती। WireGuard server key खोने का मतलब है आपके दिए हर client configuration को दोबारा जारी करना। mail server की DKIM key खोने का मतलब है एक नया selector और [deliverability](https://servhidden.com/hi/guides/offshore-mail-server-setup) पर एक नई शुरुआत। किसी Lightning node का seed और channel state, files नहीं बल्कि funds जैसा मामला हो सकता है — [node hosting guide](https://servhidden.com/hi/guides/crypto-node-hosting-guide) इसे साफ़ शब्दों में कहती है। इन्हें अलग से copy करें, offline रखें, और इन्हें उस data से भी ज़्यादा क़ीमती मानें जिसकी वे रक्षा करती हैं।

## जिस restore को आपने आज़माया नहीं, वह बस एक अफ़वाह है

backup software अपने बारे में रिपोर्ट देता है, और वह ग़लत चीज़ के बारे में ईमानदार रिपोर्ट देता है। "Snapshot completed" का मतलब बस इतना है कि repository में data लिख दिया गया। यह कुछ नहीं बताता कि क्या उस repository को किसी और machine पर, किसी ऐसे इंसान द्वारा पढ़ा जा सकता है जिसे ग्यारह महीने पहले की गई अपनी configuration याद ही नहीं।

सस्ती integrity जाँच से शुरू करें — किसी schedule पर restic check --read-data-subset=5% या borg check --verify-data — और यह समझें कि ये archive को परखती हैं, आपकी इस्तेमाल करने की क़ाबिलियत को नहीं। असली अभ्यास अलग है और एक दोपहर लेता है, बस एक बार। किसी ऐसे location में घंटे के हिसाब से एक नया server लें जिसे आप वैसे इस्तेमाल नहीं करते। सिर्फ़ repository का पता, passphrase, और अपने नोट्स के सहारे उस पर restore करें। service को चालू करें। पूरी प्रक्रिया का समय नापें। फिर machine मिटा दें। कुल ख़र्च: कुछ ही dollars, और यही इकलौती कवायद है जो कोई भरोसेमंद संख्या देती है।

यह जो भरोसे से उजागर करता है वह कभी data नहीं होता। यह होता है वह package जिसे किसी ने लिखकर नहीं रखा, वह config जो backup किए गए paths से बाहर रहती थी, वह passphrase जो सिर्फ़ उस server की shell history में मौजूद थी जिसे आप अभी बदलने की कोशिश कर रहे हैं, और वह tool version जो आपकी repository का format पढ़ पाता है। इनमें से हर एक को पहले से ठीक करना आसान है, और किसी outage के बीच खोजना बेहद तकलीफ़देह।

यह अभ्यास जो दो संख्याएँ देता है उन्हें लिख लें: restore में कितना समय लगा, और schedule कितना काम खो सकता है। यही backup policy है। बाक़ी ऊपर लिखा सब कुछ बस इन्हीं की सेवा में उठाया गया implementation detail है।

## इसे automate करें ताकि यह चलता रहे

job को cron की बजाय एक systemd timer से चलाएँ। इससे आपको logs एक ही जगह मिलते हैं, आख़िरी run का असली रिकॉर्ड मिलता है, और एक ऐसा schedule मिलता है जो reboot के बाद भी बचा रहता है — यह सब cron बिना अतिरिक्त मेहनत के नहीं देता। passphrase को unit file से बाहर रखें, क्योंकि shell access वाला कोई भी इंसान उसे सीधे systemctl cat से पढ़ सकता है।

फिर उस failure mode को ठीक करें जो लोगों को असल में पकड़ता है — यह कोई error नहीं, ख़ामोशी है। छह हफ़्ते पहले चलना बंद कर चुका backup बिल्कुल वैसा ही दिखता है जैसा सही चला हुआ backup, क्योंकि दोनों कोई output नहीं देते। **अनुपस्थिति पर alert करें, विफलता पर नहीं।** job को कामयाबी पर किसी monitor को ping करने दें, और monitor को शिकायत करने दें जब ping न पहुँचे — और उस monitor को उस server के अलावा कहीं भी रखें जिसे वह देखता है, क्योंकि जो box बंद पड़ा है वह यह रिपोर्ट नहीं कर सकता कि वह बंद है।

Retention डिफ़ॉल्ट पर नहीं, जान-बूझकर तय करें। --keep-daily 7 --keep-weekly 4 --keep-monthly 6 जैसा कुछ, बिना हमेशा के लिए बढ़ते रहे, आज रात दिखने वाली ग़लतियों और बसंत में दिखने वाले corruption दोनों को समेट लेता है। अगर आपने append-only अपनाया है तो छँटाई target की तरफ़ चलाएँ, आख़िर append-only अपनाने का यही मक़सद है। हमारे network पर transfer की मात्रा शायद ही कभी रुकावट बनती है — हर plan पर bandwidth unmetered है — इसलिए schedule किसी quota के लिए नहीं, स्थिरता के लिए तय करें, और उसका समय अपने ख़ामोश घंटों से मिलाकर देखें। इससे जुड़ी बाक़ी आदतें [server OpSec guide](https://servhidden.com/hi/guides/server-opsec-staying-anonymous) में बताई गई हैं।

## छोटी-सी बात

अगर इस page से बस इतना ही लें, तो ये छह काम करें, तक़रीबन इसी क्रम में:

- एक copy दूसरे provider के पास, दूसरे jurisdiction में रखें, और उसका भुगतान पहले जितना ही private रखें।

- उस copy को append-only बनाएँ, या उसे target से pull करें, ताकि कोई compromise हुआ server उसे मिटा न सके।

- tool को source पर ही encrypt करने दें, और key को दोनों जुड़ी हुई machines से दूर रखें।

- databases dump करें और जो कुछ चल रहा है उसे रोकें या snapshot करें; live state की कभी सीधी copy न लें।

- पहचान वाली keys — onion, WireGuard, DKIM, node seeds — अलग से backup करें, क्योंकि इन्हें दोबारा बनाया नहीं जा सकता।

- एक बार किसी उपयोग-के-बाद-फेंक देने वाले server पर restore करके देखें, समय नापें, और जो कुछ छूटा हो उसे लिख लें।

इसमें से कुछ भी असाधारण नहीं है, और न ही इसमें कोई पूरा weekend लगता है। यह बस एक दोपहर की तैयारी और एक अभ्यास है, उस तरह के नुकसान के ख़िलाफ़ जो पूरे project ख़त्म कर देता है। ऐसे platform पर जो जान-बूझकर आपके बारे में कुछ भी नहीं रखता, वहाँ सिर्फ़ वही copy मौजूद रहती है जो आपने ख़ुद बनाई हो — यही इस पूरे इंतज़ाम की क़ीमत है, और एक वाजिब क़ीमत भी। अपने पहले वाले से अलग किसी jurisdiction में [दूसरा server शुरू करें](https://servhidden.com/hi/vps), और आज रात के backup को उतरने के लिए कोई जगह दें।





FAQ

## VPS backups — अक्सर पूछे जाने वाले सवाल





### 01
क्या ServHidden मेरे VPS का backup लेता है?



नहीं, और यह चूक नहीं बल्कि जान-बूझकर लिया गया फ़ैसला है। हमारी retention policy साफ़ कहती है कि कोई backup नहीं रखा जाता, termination के 24 घंटे के भीतर server का data नष्ट कर दिया जाता है, और disks को format नहीं बल्कि cryptographically wipe किया जाता है। आपके मना करने के बाद भी आपका data रखना, इस platform के होने की वजह के ही ख़िलाफ़ जाएगा। जो कुछ भी आप server से आगे बचाना चाहते हैं, उसे आपको ख़ुद वहाँ से copy करना होगा — बेहतर हो कि किसी दूसरे provider के पास, किसी दूसरे jurisdiction में।





### 02
क्या snapshot और backup एक ही चीज़ हैं?



नहीं। snapshot उस server के साथ हर failure domain बाँटता है जहाँ से वह आया है — वही provider, वही account, वही देश, अक्सर वही storage भी। यह किसी ग़लत upgrade को पलटने में बेहतरीन है, पर account, provider या machine खो जाने के सामने बेकार है। snapshots को undo बटन और backups को बीमा समझें; दोनों अलग-अलग समस्याएँ हल करते हैं और आपको दोनों चाहिए।





### 03
restic या BorgBackup — मुझे कौन-सा इस्तेमाल करना चाहिए?



अगर target object storage, SFTP या कोई ऐसी चीज़ हो सकता है जो आपने अभी तय नहीं की, तो restic लें, क्योंकि यह सबसे ज़्यादा back ends बोलता है। अगर target SSH से पहुँचा जाने वाला एक Linux machine है और data बड़ा व दोहराव वाला है, तो BorgBackup लें, क्योंकि इसका deduplication समूह में सबसे मज़बूत है। दोनों ही data के machine से निकलने से पहले source पर उसे encrypt कर देते हैं, और दोनों append-only target को सहारा देते हैं, जो इन दोनों के बीच के चुनाव से कहीं ज़्यादा मायने रखता है।





### 04
मैं किसी हमलावर को अपने backups मिटाने से कैसे रोकूँ?



मक़सद नहीं, क्षमता हटाएँ। या तो target को append-only बना दें, ताकि production server पर मौजूद credentials data जोड़ तो सकें पर उसे कभी हटा न सकें, या connection ही पलट दें ताकि backup host production से pull करे और production server के पास कोई credential रहे ही नहीं। अपनी हरकत का ऐलान करने से पहले backups मिटा देना, इसे commercially करने वालों के लिए आम बात है, और जिस copy को आपका हमलावर मिटा सकता है वह दूसरी copy है ही नहीं।





### 05
दूसरी copy कहाँ रखनी चाहिए?



एक अलग provider के पास, एक अलग jurisdiction में, और आपके production server जितनी ही privacy के साथ भुगतान किया हुआ। दोनों copies को एक साथ ख़त्म करने वाली घटनाएँ शायद ही कभी भौतिक होती हैं — वे होती हैं कोई खोया हुआ account, किसी provider का बुरा हफ़्ता, या कोई क़ानूनी आदेश जो एक देश तक पहुँचे और दूसरे तक नहीं। एक ही rack में रखे दो servers, अतिरिक्त मेहनत वाली बस एक copy हैं। चूँकि tools source पर ही encrypt कर देते हैं, दूसरे host का भरोसेमंद होना ज़रूरी नहीं।





### 06
मुझे कितनी बार backup लेना चाहिए?



इस हिसाब से पीछे से सोचें कि आप कितना काम दोबारा करने को तैयार हैं। कोई blog बिना किसी के ध्यान दिए एक दिन खो सकता है; कोई store एक घंटे के orders नहीं खो सकता। ज़्यादातर single-server setups के लिए हर रात backup लेना सही डिफ़ॉल्ट है, और अगर writes क़ीमती हैं तो database dumps और बार-बार लें। frequency से ज़्यादा retention की गहराई मायने रखती है: corruption का पता अक्सर हफ़्तों बाद चलता है, इसलिए इतना इतिहास रखें कि उसके शुरू होने से पहले वाले बिंदु तक पहुँचा जा सके।





### 07
क्या ऐसे server पर encrypted backup सुरक्षित है जिस पर मेरा control नहीं?



सामग्री के लिहाज़ से, हाँ — restic और Borg data के source से निकलने से पहले उसे encrypt कर देते हैं, इसलिए target ऐसे blobs रखता है जिन्हें वह पढ़ नहीं सकता, और key कभी वहाँ जाती ही नहीं। target को जो पता चलता है वह है metadata: लगभग कितना data आपके पास है, वह कैसे बदलता है, और आपकी jobs कब चलती हैं। यह आम तौर पर मंज़ूर करने लायक होता है। अगर नहीं, तो schedule में बदलाव करते रहें और repository को ऐसी machine पर रखें जिसका मालिकाना production वाली मशीन से जुड़ा न हो।





### 08
अगर मैं backup passphrase खो दूँ तो क्या होगा?



archive हमेशा के लिए चला जाता है, और किसी के पास भी कोई इलाज नहीं बचता। यह पूरे विषय में सबसे आम पूर्ण नुक़सान है, और इकलौती ऐसी विफलता जिसका कोई वापसी रास्ता नहीं। passphrase को इसमें शामिल हर machine से बाहर कहीं रखें, किसी ऐसे account से बेहतर काग़ज़ को समझें जिसे आप भी खो सकते हैं, और repository में एक दूसरी key जोड़ें ताकि एक भूला हुआ password बस एक झंझट बने, archive का अंत नहीं।




संबंधित गाइड्स

## पढ़ते रहें


[### How to चुनें an ऑफशोर होस्टिंग न्यायक्षेत्र in 2026

खरीदारी


ऑफशोर न्यायक्षेत्र चुनने के लिए एक व्यावहारिक decision framework: data-retention कानून, MLAT exposure, DMCA stance, अदालत की speed, और real-world प्रवर्तन — देश दर देश।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/choosing-an-offshore-jurisdiction)
[### Privacy-Critical Workloads के लिए VPS बनाम Dedicated सर्वर

खरीदारी


कब VPS पर्याप्त है, कब shared tenancy liability बन जाती है, और कब bare metal ही ईमानदार जवाब है। Hardware isolation, हाइपरवाइज़र risk, और cost बनाम जोखिम मॉडल।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/vps-vs-dedicated-for-privacy)
[### No-KYC VPS पर Self-Hosted VPN: WireGuard बनाम OpenVPN

परिचालन


स्व-होस्टेड VPN व्यावसायिक प्रदाताओं को क्यों मात देता है, और 2026 में WireGuard और OpenVPN गोपनीयता, प्रदर्शन और परिचालन जोखिम पर वास्तव में कैसे तुलना करते हैं।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### AI Inference के लिए RTX 4090 बनाम H100 SXM5 (और RTX 5090 कहाँ फिट होता है)

खरीदारी


2026 में self-होस्टेड LLM, image, video, voice और finetuning वर्कलोड के लिए कौन सा NVIDIA GPU चुनें: RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token और कब कौन जीतता है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/rtx-4090-vs-h100-for-ai-inference)
[### MT4 / MT5 / cTrader Forex Trading के लिए ऑफशोर Windows RDP

परिचालन


पूर्ण guide: forex trading के लिए Windows RDP क्यों, low-latency offshore क्षेत्राधिकार कैसे चुनें, MT4/MT5/cTrader/Expert Advisor सेटअप, broker servers पर latency, और no-KYC checkout path।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/offshore-windows-rdp-for-forex-trading)
[### DMCA-Ignored Hosting समझाया गया: 2026 में इसका असली मतलब क्या है

खरीदारी


"DMCA ignored" hosting वास्तव में आपको क्या देती है, कौन-सी jurisdictions इसे सच में back करती हैं, किन workloads को इसकी ज़रूरत है, और कौन-से copyright जाल इस शब्द के दायरे में नहीं आते।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/dmca-ignored-hosting-explained)
[### Crypto से Anonymous Domain Registration: 2026 में WHOIS Privacy

गोपनीयता


2026 की practical guide: बिना identity reveal किए domains register करने का तरीका — TLD के अनुसार WHOIS regimes, registrar चुनाव, crypto payment options, और वे operational गलतियाँ जो आपको leak करती हैं।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/anonymous-domain-registration-with-crypto)
[### क्रिप्टो Payments for होस्टिंग: Monero vs Bitcoin vs USDT

गोपनीयता


भुगतान कॉइन आपके होस्ट को आपके बारे में क्या पता चलता है इसे कैसे प्रभावित करता है। XMR, BTC और USDT के लिए गोपनीयता, शुल्क, finality और चेन विश्लेषण जोखिम — स्पष्ट सिफारिश के साथ।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### क्या Offshore Hosting सच में Anonymous है? एक ईमानदार जवाब

गोपनीयता


Offshore, no-KYC hosting वह identity हटा देती है जो एक normal host collect करता है — लेकिन "anonymous" होना payment, provider logging और आपकी अपनी opsec पर निर्भर करता है। यहाँ बताया गया है कि असल में क्या traceable है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/is-offshore-hosting-truly-anonymous)
[### VPS Hardening का पहला घंटा: एक Checklist

परिचालन


एक नए VPS को एक घंटे से कम में secure करने के लिए एक concrete, ordered checklist: SSH keys, एक firewall, fail2ban, automatic updates, और वह attack-surface reduction जो ज़्यादातर opportunistic attacks को रोकती है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/first-hour-vps-hardening-checklist)
[### No-KYC होस्टिंग क्या है? परिभाषा, वैधता और यह कैसे काम करती है

गोपनीयता


No-KYC होस्टिंग आपको बिना किसी पहचान सत्यापन के सर्वर किराये पर लेने देती है — न नाम, न ईमेल, न ID। यहाँ जानें इसका अर्थ, यह तकनीकी रूप से कैसे काम करता है, क्या यह कानूनी है, और असली प्रदाता को कैसे पहचानें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/what-is-no-kyc-hosting)
[### क्या ऑफशोर होस्टिंग कानूनी है? 2026 का स्पष्ट जवाब

खरीदारी


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


6-प्रश्न FAQ](https://servhidden.com/hi/guides/is-offshore-hosting-legal)
[### Monero (XMR) से होस्टिंग का भुगतान कैसे करें — चरण-दर-चरण मार्गदर्शिका

गोपनीयता


VPS या डेडिकेटेड सर्वर के लिए Monero (XMR) से भुगतान की चरण-दर-चरण मार्गदर्शिका: XMR सबसे निजी विकल्प क्यों है, इसे कैसे प्राप्त करें, और चेकआउट प्रक्रिया कैसे काम करती है — इनवॉइस से लेकर कुछ ही मिनटों में चालू सर्वर तक।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-pay-for-hosting-with-monero)
[### गुमनाम तरीके से वेबसाइट होस्ट कैसे करें — एक व्यावहारिक 2026 गाइड

गोपनीयता


एक व्यावहारिक, बहु-स्तरीय गाइड जो बताती है कि बिना किसी पहचान के वेबसाइट कैसे होस्ट की जाए — अकाउंट, भुगतान, डोमेन, अधिकार क्षेत्र, कनेक्शन और कंटेंट — हर परत को विस्तार से समझाया गया है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-host-a-website-anonymously)
[### VPS पर WireGuard VPN कैसे सेटअप करें — चरण-दर-चरण गाइड

परिचालन


WireGuard से अपना निजी VPN बनाएं एक VPS पर: यह जानें कि self-hosted VPN किसी व्यावसायिक VPN से बेहतर क्यों है, इंस्टॉलेशन से लेकर कनेक्टेड क्लाइंट तक का पूरा सेटअप, और इसे कैसे सुरक्षित करें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### GPU सर्वर पर LLM को स्व-होस्ट कैसे करें — 2026 गाइड

परिचालन


किराये के GPU सर्वर पर अपना खुद का लार्ज लैंग्वेज मॉडल चलाएँ: API की तुलना में स्व-होस्टिंग क्यों बेहतर है, कौन-सा GPU और मॉडल चुनें, Ollama या vLLM के साथ सेटअप कैसे करें, और इसकी लागत क्या है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof Hosting बनाम Offshore Hosting — क्या है अंतर?

खरीदारी


Bulletproof hosting और offshore hosting को अक्सर एक-दूसरे का पर्याय मान लिया जाता है — लेकिन ये एक नहीं हैं। यहाँ जानें असली अंतर, यह क्यों मायने रखता है, और आपको वास्तव में किसकी जरूरत है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/bulletproof-vs-offshore-hosting)
[### Bitcoin से VPS कैसे खरीदें — चरण-दर-चरण गाइड (2026)

खरीदारी


Bitcoin से VPS खरीदने की शुरुआती-अनुकूल मार्गदर्शिका: BTC प्राप्त करना, प्लान चुनना, इनवॉइस का भुगतान करना और क्या मिलता है — बिना कार्ड और बिना नाम के एक चालू सर्वर।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-buy-a-vps-with-bitcoin)
[### 2026 में DMCA-ignored होस्टिंग के लिए सर्वश्रेष्ठ देश

खरीदारी


जब आप ऐसे सर्वर चाहते हैं जो US-शैली के टेकडाउन से परे हों — तो कहाँ होस्ट करें: वे क्षेत्राधिकार जो काम करते हैं, DMCA-ignored का वास्तविक अर्थ, और सही चुनाव कैसे करें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/best-countries-for-dmca-ignored-hosting)
[### Tor हिडन सर्विस (.onion साइट) कैसे होस्ट करें — 2026 गाइड

परिचालन


VPS पर Tor onion सर्विस सेट करें: हिडन सर्विस क्या है, यह अनाम होस्टिंग का सबसे मज़बूत रूप क्यों है, पूरा सेटअप, और इसे वास्तव में अनाम कैसे रखें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/how-to-host-a-tor-hidden-service)
[### ऑफशोर मेल सर्वर सेटअप — 2026 में खुद का प्राइवेट ईमेल होस्ट करें

परिचालन


एक ऑफशोर VPS पर अपना खुद का प्राइवेट ईमेल सर्वर चलाएं: सेल्फ-होस्ट ईमेल क्यों करें, इसके लिए क्या चाहिए, ऑल-इन-वन मेल स्टैक के साथ व्यावहारिक सेटअप, और डिलीवरेबिलिटी कैसे सही रखें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/offshore-mail-server-setup)
[### क्रिप्टो नोड होस्टिंग गाइड — VPS पर ब्लॉकचेन नोड चलाएं

परिचालन


सर्वर पर ब्लॉकचेन नोड कैसे होस्ट करें: अपना नोड चलाने के फायदे, Bitcoin, Ethereum, Monero आदि के लिए सर्वर का आकार, सेटअप प्रक्रिया और इसे निजी रखने के तरीके।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/crypto-node-hosting-guide)
[### Stable Diffusion के लिए GPU होस्टिंग — अपना खुद का इमेज सर्वर चलाएं

परिचालन


अपने खुद के GPU सर्वर पर Stable Diffusion चलाएं: इमेज जनरेशन को सेल्फ-होस्ट क्यों करें, कौन सा GPU चुनें, वेब UI के साथ सेटअप कैसे करें, और होस्टेड सेवा की तुलना में इसकी लागत क्या है।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/gpu-hosting-for-stable-diffusion)
[### सर्वर OpSec — सर्वर चलाते समय गुमनाम कैसे रहें

गोपनीयता


गुमनाम सर्वर चलाने वाले किसी भी व्यक्ति के लिए परिचालन सुरक्षा: वे गलतियाँ जो पहचान उजागर करती हैं, वे आदतें जो उन्हें रोकती हैं, और पहचान को वास्तव में अलग कैसे रखें।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/server-opsec-staying-anonymous)
[### Seedbox सेटअप गाइड — 2026 में अपना निजी Seedbox बनाएँ

परिचालन


अपने सर्वर पर खुद का seedbox कैसे बनाएँ: seedbox क्या होता है, उसकी साइज़िंग, web UI के साथ torrent client की इंस्टॉलेशन, और उसे निजी व सुरक्षित रखना।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/seedbox-setup-guide)
[### अपने खुद के VPS से DPI सेंसरशिप को कैसे बायपास करें (2026 गाइड)

गोपनीयता


आपका VPN काम करना बंद कर चुका है? अपने खुद के VPS से DPI सेंसरशिप बायपास करने का तरीका: डीप पैकेट इंस्पेक्शन असल में क्या पहचानता है, 2026 के पांच प्रोटोकॉल में से कौन-सा किस ब्लॉक को मात देता है, और एक पूरा VLESS+REALITY वॉकथ्रू।


6-प्रश्न FAQ](https://servhidden.com/hi/guides/bypass-dpi-censorship-with-your-own-vps)
[### VPS पर फुल-डिस्क एन्क्रिप्शन: LUKS सेटअप और यह असल में क्या सुरक्षित करता है

परिचालन


LUKS से VPS एन्क्रिप्ट करने का तरीका: एन्क्रिप्टेड डेटा वॉल्यूम, SSH पर रिमोट अनलॉक वाला फुल-रूट एन्क्रिप्शन, छोटे सर्वर पर मायने रखने वाली सेटिंग्स, और डिस्क एन्क्रिप्शन असल में क्या रोकता है इसका ईमानदार ब्योरा।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/full-disk-encryption-on-a-vps)
[### ओरिजिन सर्वर IP छुपाना: CDN, रिवर्स प्रॉक्सी और जो फिर भी लीक होता है

गोपनीयता


ऑफ़शोर सर्वर के आगे CDN लगाएँ या नहीं: यह क्या छुपाता है, साथ में कौन-सी शिकायत डेस्क मिलती है, वे छह तरीके जिनसे ओरिजिन IP फिर भी लीक होता है, और अपना ऑडिट कैसे करें।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/hiding-your-origin-server-ip)
[### खुद का Matrix Server Self-Host करें: Federation, Metadata और E2EE की सीमाएँ

परिचालन


अपने खुद के Matrix homeserver से असल में क्या मिलता है: Synapse बनाम Conduit, वह server_name जिसे आप बदल नहीं सकते, डिस्क भरने वाला media, और federation का एक्सपोज़र।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/self-host-a-matrix-server)
[### Website को Offshore Hosting पर बिना Downtime के कैसे Migrate करें

परिचालन


host migration को उबाऊ बनाने वाला क्रम: DNS TTL दिनों पहले घटाएँ, दोनों servers साथ चलाएँ, writes को घंटों की बजाय मिनटों तक freeze करें — और migration के पीछे छूटी passive-DNS, Certificate Transparency और WHOIS trail को साफ़ करें।


8-प्रश्न FAQ](https://servhidden.com/hi/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

परिचालन


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


8-प्रश्न FAQ](https://servhidden.com/hi/guides/self-host-a-crypto-payment-gateway)




## आज रात के backup को उतरने के लिए एक जगह दें



सात jurisdictions, हर plan पर unmetered bandwidth, और $7.50/माह से शुरू होने वाले servers जो सक्षम restic या Borg endpoints बनते हैं। न KYC, न email, सिर्फ़ crypto — production जितना ही backup target के लिए भी।


[VPS प्लान देखें](https://servhidden.com/hi/vps)
[डेडिकेटेड सर्वर](https://servhidden.com/hi/dedicated)
[सभी लोकेशन](https://servhidden.com/hi/locations)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servhidden.com/#organization",
    "name": "ServHidden",
    "url": "https://servhidden.com",
    "description": "7 ऑफशोर न्यायक्षेत्रों में ऑफशोर VPS और डेडिकेटेड सर्वर। KYC नहीं, लॉग नहीं, केवल क्रिप्टो। आर्किटेक्चर से ही गोपनीयता।",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servhidden.com/ServHidden.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servhidden.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servhidden.com/canary",
        "https://servhidden.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servhidden.com/#website",
    "url": "https://servhidden.com",
    "name": "ServHidden",
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "VPS Backup कैसे लें: Encrypted, Off-Site और भरोसेमंद Restore",
    "description": "आपका host कोई backup नहीं रखता। server को असल में क्या बर्बाद करता है, push backup साथ में क्यों मरता है, restic बनाम BorgBackup, और restore टेस्ट करने का तरीक़ा।",
    "image": "https://servhidden.com/assets/img/guides/vps-backup-strategy.webp?v=1787218773",
    "author": {
        "@type": "Organization",
        "@id": "https://servhidden.com/#editorial",
        "name": "ServHidden Editorial",
        "url": "https://servhidden.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servhidden.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servhidden.com/#organization"
    },
    "datePublished": "2026-08-20T00:00:00+00:00",
    "dateModified": "2026-08-20T00:00:00+00:00",
    "mainEntityOfPage": "https://servhidden.com/guides/vps-backup-strategy",
    "inLanguage": "hi",
    "keywords": "VPS backup kaise len, encrypted VPS backup, restic vs BorgBackup, no-KYC server backup, VPS ka backup lena, append-only backup kya hai, offsite backup 3-2-1 rule, backup restore test kaise karein",
    "articleSection": "परिचालन",
    "wordCount": 3505
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "क्या ServHidden मेरे VPS का backup लेता है?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "नहीं, और यह चूक नहीं बल्कि जान-बूझकर लिया गया फ़ैसला है। हमारी retention policy साफ़ कहती है कि कोई backup नहीं रखा जाता, termination के 24 घंटे के भीतर server का data नष्ट कर दिया जाता है, और disks को format नहीं बल्कि cryptographically wipe किया जाता है। आपके मना करने के बाद भी आपका data रखना, इस platform के होने की वजह के ही ख़िलाफ़ जाएगा। जो कुछ भी आप server से आगे बचाना चाहते हैं, उसे आपको ख़ुद वहाँ से copy करना होगा — बेहतर हो कि किसी दूसरे provider के पास, किसी दूसरे jurisdiction में।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या snapshot और backup एक ही चीज़ हैं?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "नहीं। snapshot उस server के साथ हर failure domain बाँटता है जहाँ से वह आया है — वही provider, वही account, वही देश, अक्सर वही storage भी। यह किसी ग़लत upgrade को पलटने में बेहतरीन है, पर account, provider या machine खो जाने के सामने बेकार है। snapshots को undo बटन और backups को बीमा समझें; दोनों अलग-अलग समस्याएँ हल करते हैं और आपको दोनों चाहिए।"
            }
        },
        {
            "@type": "Question",
            "name": "restic या BorgBackup — मुझे कौन-सा इस्तेमाल करना चाहिए?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "अगर target object storage, SFTP या कोई ऐसी चीज़ हो सकता है जो आपने अभी तय नहीं की, तो restic लें, क्योंकि यह सबसे ज़्यादा back ends बोलता है। अगर target SSH से पहुँचा जाने वाला एक Linux machine है और data बड़ा व दोहराव वाला है, तो BorgBackup लें, क्योंकि इसका deduplication समूह में सबसे मज़बूत है। दोनों ही data के machine से निकलने से पहले source पर उसे encrypt कर देते हैं, और दोनों append-only target को सहारा देते हैं, जो इन दोनों के बीच के चुनाव से कहीं ज़्यादा मायने रखता है।"
            }
        },
        {
            "@type": "Question",
            "name": "मैं किसी हमलावर को अपने backups मिटाने से कैसे रोकूँ?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "मक़सद नहीं, क्षमता हटाएँ। या तो target को append-only बना दें, ताकि production server पर मौजूद credentials data जोड़ तो सकें पर उसे कभी हटा न सकें, या connection ही पलट दें ताकि backup host production से pull करे और production server के पास कोई credential रहे ही नहीं। अपनी हरकत का ऐलान करने से पहले backups मिटा देना, इसे commercially करने वालों के लिए आम बात है, और जिस copy को आपका हमलावर मिटा सकता है वह दूसरी copy है ही नहीं।"
            }
        },
        {
            "@type": "Question",
            "name": "दूसरी copy कहाँ रखनी चाहिए?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "एक अलग provider के पास, एक अलग jurisdiction में, और आपके production server जितनी ही privacy के साथ भुगतान किया हुआ। दोनों copies को एक साथ ख़त्म करने वाली घटनाएँ शायद ही कभी भौतिक होती हैं — वे होती हैं कोई खोया हुआ account, किसी provider का बुरा हफ़्ता, या कोई क़ानूनी आदेश जो एक देश तक पहुँचे और दूसरे तक नहीं। एक ही rack में रखे दो servers, अतिरिक्त मेहनत वाली बस एक copy हैं। चूँकि tools source पर ही encrypt कर देते हैं, दूसरे host का भरोसेमंद होना ज़रूरी नहीं।"
            }
        },
        {
            "@type": "Question",
            "name": "मुझे कितनी बार backup लेना चाहिए?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "इस हिसाब से पीछे से सोचें कि आप कितना काम दोबारा करने को तैयार हैं। कोई blog बिना किसी के ध्यान दिए एक दिन खो सकता है; कोई store एक घंटे के orders नहीं खो सकता। ज़्यादातर single-server setups के लिए हर रात backup लेना सही डिफ़ॉल्ट है, और अगर writes क़ीमती हैं तो database dumps और बार-बार लें। frequency से ज़्यादा retention की गहराई मायने रखती है: corruption का पता अक्सर हफ़्तों बाद चलता है, इसलिए इतना इतिहास रखें कि उसके शुरू होने से पहले वाले बिंदु तक पहुँचा जा सके।"
            }
        },
        {
            "@type": "Question",
            "name": "क्या ऐसे server पर encrypted backup सुरक्षित है जिस पर मेरा control नहीं?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "सामग्री के लिहाज़ से, हाँ — restic और Borg data के source से निकलने से पहले उसे encrypt कर देते हैं, इसलिए target ऐसे blobs रखता है जिन्हें वह पढ़ नहीं सकता, और key कभी वहाँ जाती ही नहीं। target को जो पता चलता है वह है metadata: लगभग कितना data आपके पास है, वह कैसे बदलता है, और आपकी jobs कब चलती हैं। यह आम तौर पर मंज़ूर करने लायक होता है। अगर नहीं, तो schedule में बदलाव करते रहें और repository को ऐसी machine पर रखें जिसका मालिकाना production वाली मशीन से जुड़ा न हो।"
            }
        },
        {
            "@type": "Question",
            "name": "अगर मैं backup passphrase खो दूँ तो क्या होगा?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "archive हमेशा के लिए चला जाता है, और किसी के पास भी कोई इलाज नहीं बचता। यह पूरे विषय में सबसे आम पूर्ण नुक़सान है, और इकलौती ऐसी विफलता जिसका कोई वापसी रास्ता नहीं। passphrase को इसमें शामिल हर machine से बाहर कहीं रखें, किसी ऐसे account से बेहतर काग़ज़ को समझें जिसे आप भी खो सकते हैं, और repository में एक दूसरी key जोड़ें ताकि एक भूला हुआ password बस एक झंझट बने, archive का अंत नहीं।"
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "होम",
            "item": "https://servhidden.com/hi/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "गोपनीयता होस्टिंग Guides",
            "item": "https://servhidden.com/hi/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "VPS Backup कैसे लें: Encrypted, Off-Site और भरोसेमंद Restore",
            "item": "https://servhidden.com/hi/guides/vps-backup-strategy"
        }
    ]
}
```