अपने ही सर्वर पर रैनसमवेयर के खिलाफ बैकअप को इम्यूटेबल कैसे बनाऊं?

बैकअप के लिए अपरिवर्तनीय (immutable) का क्या अर्थ है?

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

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

यदि आप जिस मशीन की सुरक्षा करते हैं, वह अपने ही बैकअप हटा सकती है, तो उस मशीन पर कब्जा करने वाला कोई भी व्यक्ति भी ऐसा कर सकता है।

restic और Borg append-only मोड में कैसे चलते हैं?

restic के rest-server में एक --append-only फ़्लैग है। इसका README कहता है कि यह मोड नए बैकअप की अनुमति देता है, लेकिन मौजूदा बैकअप के विलोपन और संशोधन को रोकता है। बिना फ़्लैग वाले दूसरे इंस्टेंस के माध्यम से, या सर्वर पर ही, एडमिन मशीन से प्रून करें।

Borg इस मोड को authorized_keys में एक फ़ोर्स्ड कमांड से, या रिपॉजिटरी कॉन्फ़िग में append_only = 1 से लागू करता है। इसका दस्तावेज़ सीमाओं को स्पष्ट रूप से सूचीबद्ध करता है:

• borg delete और borg prune अभी भी चलते हैं; वे केवल डेटा को हटाया हुआ चिह्नित करते हैं।
• सामान्य मोड में अगला लेखन उस डेटा को हमेशा के लिए हटा देता है, इसलिए स्वचालित प्रूनिंग मोड को निरर्थक बना देती है।
• append-only रिपॉजिटरी को प्रून करने से पहले borg check चलाएँ।
• rm अभी भी फ़ाइलों पर काम करता है, इसलिए क्लाइंट को रिपॉजिटरी तक केवल borg serve के माध्यम से पहुँचना चाहिए।

दोनों टूल की तुलना ऑफसाइट बैकअप के लिए restic या Borg पर की गई है।

# restic: rest-server, one private repository per user
rest-server --path /tank/restic --append-only --private-repos --tls \
  --tls-cert /etc/rest-server/cert.pem --tls-key /etc/rest-server/key.pem

# Borg: in ~backup/.ssh/authorized_keys, one line per client key
command="borg serve --append-only --restrict-to-path /tank/borg/web1",restrict ssh-ed25519 AAAA... web1

Proxmox Backup Server और Veeam बैकअप को कैसे लॉक करते हैं?

Proxmox Backup Server भूमिकाओं (roles) के आधार पर काम करता है। DatastoreBackup वाला उपयोगकर्ता अपने स्वयं के बैकअप का बैकअप और रिस्टोर कर सकता है, लेकिन प्रूनिंग के लिए DatastorePowerUser आवश्यक है। गार्बेज कलेक्शन भी चंक्स को हटाने से पहले 24 घंटे और 5 मिनट प्रतीक्षा करता है। इसे ऑफसाइट सर्वर द्वारा खींचे गए सिंक जॉब के साथ जोड़ें, ताकि घरेलू स्थान पर कोई ऑफसाइट लॉगिन न हो। पूरा सेटअप किराए के सर्वर पर ऑफसाइट Proxmox Backup Server पर है।

Veeam का हार्डन्ड रिपॉजिटरी समय के आधार पर काम करता है। फ़ाइलें 7 से 9999 दिनों तक अपरिवर्तनीय रहती हैं, और जिन क्रेडेंशियल्स ने Veeam की सेवाएँ इंस्टॉल कीं, वे कभी संग्रहीत नहीं किए गए। किराए की मशीन के लिए चरण किराए के Linux सर्वर पर Veeam हार्डन्ड रिपॉजिटरी पर हैं।

क्या मैं अपने स्वयं के सर्वर पर S3 Object Lock का उपयोग कर सकता हूँ?

केवल तभी जब आपका S3 सर्वर इसे लागू करता हो, और दो सबसे प्रसिद्ध ओपन-सोर्स विकल्प अलग-अलग हैं।

• MinIO संस्करणित बकेट पर ऑब्जेक्ट लॉकिंग का दस्तावेज़ीकरण GOVERNANCE या COMPLIANCE मोड में करता है। COMPLIANCE मोड में, कोई भी उपयोगकर्ता लॉक किए गए संस्करण को बदल नहीं सकता, रूट उपयोगकर्ता सहित। लेकिन MinIO सामुदायिक रिपॉजिटरी 25 अप्रैल 2026 को संग्रहीत की गई, अब अनुरक्षित नहीं है, और केवल सोर्स कोड के रूप में वितरित की जाती है।
• Garage अपने S3 संगतता पृष्ठ पर Object Lock और बकेट संस्करणन को अनुपलब्ध के रूप में सूचीबद्ध करता है।

क्लाइंट साइड पर, Kopia Object Lock का समर्थन करता है: बकेट को निर्माण के समय इसे सक्षम करना होगा, और Kopia अनुपालन मोड की सिफारिश करता है। इसकी अन्य सलाह कहीं भी काम करती है: विलोपन अनुमतियों के बिना एक एक्सेस कुंजी। अन्य S3 सर्वर की तुलना सेल्फ-होस्टेड S3 के लिए MinIO के सर्वश्रेष्ठ विकल्प पर की गई है।

ZFS स्नैपशॉट बैकअप को उसके अपने क्लाइंट से कैसे बचाते हैं?

क्लाइंट को एक साधारण खाते के रूप में SFTP या rsync पर लिखने दें, और रूट को स्नैपशॉट लेने दें। OpenZFS एक स्नैपशॉट को फ़ाइल सिस्टम की केवल-पढ़ने योग्य प्रति के रूप में वर्णित करता है। क्लाइंट के खाते को zfs allow के माध्यम से कोई destroy अधिकार नहीं मिलता, इसलिए वह उन्हें हटा नहीं सकता।

एक होल्ड दूसरा लॉक जोड़ता है। जब तक किसी स्नैपशॉट पर होल्ड है, तब तक उस पर zfs destroy EBUSY के साथ विफल रहता है जब तक कोई होल्ड जारी न करे।

रूट द्वारा लिए गए स्नैपशॉट, उस डेटासेट पर जिसमें क्लाइंट लिखता है, किसी भी rsync या SFTP लक्ष्य को संस्करणित, append-only लक्ष्य में बदल देते हैं।

snap=tank/backup@$(date +%F)
zfs snapshot "$snap"
zfs hold keep "$snap"
zfs holds "$snap"        # lists the hold named keep

किराए के सर्वर पर अपरिवर्तनीय बैकअप को अभी भी क्या हटा सकता है?

दो चीज़ें, और दोनों बैकअप सॉफ़्टवेयर के बाहर हैं।

• बैकअप सर्वर पर रूट। ऊपर की हर विधि अंततः रूट के सामने झुक जाती है। रूट को ऐसी कुंजी पर रखें जो आपके बैकअप किए गए मशीनों पर कभी न हो, और SSH को अपने एडमिन पते तक सीमित करें।
• किराया स्वयं। हर सर्वर का भुगतान आपके क्रिप्टो बैलेंस से पहले से किया जाता है, 30 दिन, 3 महीने, 6 महीने या 12 महीने के लिए, जैसा चेकआउट पर चुना गया हो। ऑटो-रीन्यू उसी अवधि के लिए फिर से उसी कीमत पर चार्ज करता है जिससे आपने शुरू किया था, जब तक आप डैशबोर्ड में अगली रीनीव के लिए दूसरी अवधि नहीं चुनते; जब बैलेंस कम पड़ जाता है, तो सर्वर अपनी अवधि के अंत में बंद हो जाता है, उसकी ड्राइव 7 दिन तक रखी जाती हैं और फिर मिटा दी जाती हैं। रीबूट, रीइंस्टॉल और रद्दीकरण डैशबोर्ड में मांगे जाते हैं और टीम द्वारा संभाले जाते हैं; रीइंस्टॉल हर ड्राइव मिटा देता है, डेटा ड्राइव सहित। भुगतान की गई अवधि से अधिक लंबा लॉक कुछ भी नहीं बचाता।

एक स्टोरेज सर्वर अपना बैकअप नहीं होता: हम आपके डेटा की कोई प्रतिलिपि कहीं और नहीं रखते, इसलिए किसी दूसरी जगह दूसरी प्रतिलिपि रखना आपका ही काम है। लॉक किए गए संस्करणों को भी समय से पहले प्रून नहीं किया जा सकता, इसलिए पूल हर रखे गए संस्करण से बढ़ता है। Basalthold के 2 November 2026 सर्वेक्षण में पाया गया कि KYC के बिना क्रिप्टो स्वीकार करने वाले होस्ट पर 72 TB या अधिक के स्टोरेज सर्वर की लागत प्रति TB प्रति माह औसतन $4.86 थी। Hold 100 की लागत $3.77/TB, रॉ है। 12 महीने तक की शर्तें होल्ड मूल्य सूची पर हैं।