हमलावर अब सबसे पहले आपके बैकअप पर हाथ डालते हैं। जानिए 3-2-1-1-0 नियम, हर सिस्टम के लिए RPO और RTO कैसे तय करें, डेटाबेस के अलावा और क्या बैकअप लें, और सबसे बुरा दिन आने से पहले रिस्टोर ड्रिल कैसे तय करें।
Author
Anichur Rahaman
यह एक गढ़ा हुआ दृश्य है, किसी असली ग्राहक की कहानी नहीं। शुक्रवार, शाम के 4:40। 15 लोगों की एक ऑनलाइन दुकान की मालकिन अपने आईटी कॉन्ट्रैक्टर से कहती हैं कि कल रात का backup एक ख़ाली server पर restore करके दिखाओ। दो साल में किसी ने ऐसा नहीं किया। इसे महज़ औपचारिकता माना जा रहा है, क्योंकि जनवरी से हर सुबह backup dashboard पर हरा टिक दिख रहा है।
restore ग्यारह मिनट में पूरा हो जाता है, और order की टेबल ख़ाली निकलती है। मार्च में डिस्क भर जाने के बाद से रात का जॉब अधूरा डंप लिख रहा था, फिर भी हर बार "सफल" दिखाता रहा, क्योंकि स्क्रिप्ट का एग्ज़िट कोड किसी ने देखा ही नहीं। हर टिक सच्चा था: जॉब चला था। बस यह सवाल किसी ने नहीं पूछा कि फ़ाइल खुलती भी है या नहीं।
जिस backup को कभी restore करके नहीं देखा गया, वह अंदाज़ा भर है, और रैनसमवेयर उस अंदाज़े को नुक़सान में बदल देता है। admin क्रेडेंशियल पाने वाला हमलावर कुछ भी एन्क्रिप्ट करने से पहले आपका backup ढूँढ़ता है, इसलिए पुराना नियम, यानी दो तरह के मीडिया पर तीन कॉपी और एक कहीं और, अब काफ़ी नहीं रहा। आज के नियम में दो संख्याएँ और जुड़ी हैं, और वही शुरू की तीन से ज़्यादा मायने रखती हैं।
इस लेख के बाक़ी हिस्से में हम देखेंगे कि छोटे कारोबार निशाने पर क्यों हैं, 3-2-1-1-0 का व्यावहारिक मतलब क्या है, हर system के लिए रिकवरी का लक्ष्य कैसे तय करें, बिज़नेस एप्लिकेशन में क्या-क्या backup लेना चाहिए, और सब कुछ ठप होने वाले दिन की तैयारी कैसे करें।
हमलावर ब्रांड देखकर शिकार नहीं चुनते। वे खुले login, बिना पैच वाले network डिवाइस और बार-बार इस्तेमाल हुए password ढूँढ़ते हैं, फिर देखते हैं कि जाल में क्या फँसा। छोटी कंपनियों में कमज़ोरियाँ बड़ी कंपनियों जैसी ही होती हैं, बस समस्या पकड़ने वाले लोग बहुत कम होते हैं।
आँकड़े भी यही कहते हैं। Verizon की 2025 Data Breach Investigations Report के मुताबिक़ जाँचे गए ब्रीच में से 44% में रैनसमवेयर मौजूद था, जबकि पिछले साल यह 32% था। छोटे और मझोले कारोबारों में यह हिस्सा कहीं ज़्यादा था: 88% ब्रीच में रैनसमवेयर शामिल था, जबकि बड़े संगठनों में 39%। उसी report में पाया गया कि 64% पीड़ितों ने फिरौती नहीं दी, और दी गई रक़म की मीडियन घटकर लगभग $115,000 रह गई।
यह आख़िरी आँकड़ा एक साथ अच्छी ख़बर भी है और चेतावनी भी। फिरौती देने वाले इसलिए घट रहे हैं कि data वापस ला पाने वाले बढ़ रहे हैं। Sophos की State of Ransomware 2026 report में, जिसमें हमले का शिकार हुए संगठनों के 2,158 आईटी और सिक्योरिटी प्रमुखों का सर्वे है, पाया गया कि जिनका data एन्क्रिप्ट हुआ उनमें से 66% ने backup से data वापस पाया, यानी पिछले साल से 12 पॉइंट ज़्यादा। फिर भी औसत रिकवरी बिल $1.7 million तक पहुँच गया।
हमलावर जानते हैं कि नतीजा backup से तय होता है, इसलिए वे सबसे पहले उसी पर हाथ डालते हैं। Sophos की पहले की एक रिसर्च में सामने आया कि हमलावरों ने जिन संगठनों पर हमला किया उनमें से 94% के backup में सेंध लगाने की कोशिश की, और इन कोशिशों में से 57% कामयाब रहीं। जहाँ वे कामयाब हुए, वहाँ पीड़ित के फिरौती देने की संभावना लगभग दोगुनी हो गई और रिकवरी का बिल क़रीब आठ गुना बढ़ गया। जिस backup तक हमलावर पहुँच सके, वह backup नहीं, एक और निशाना है।
क्लासिक नियम सीधा है: data की 3 कॉपी रखें, 2 अलग तरह की स्टोरेज पर, और 1 कॉपी साइट से बाहर। हार्डवेयर ख़राब होने, चोरी और आग के ख़िलाफ़ यह आज भी काम करता है। लेकिन अड़ियल घुसपैठिए के सामने इसमें एक सुराख़ रह जाता है, क्योंकि तीनों कॉपी तक आम तौर पर एक ही क्रेडेंशियल से पहुँचा जा सकता है।
नए नियम में दो शर्तें जुड़ी हैं:
यह नियम सीमित साधनों में भी निभाया जा सकता है। चालू database पहली कॉपी है। अलग डिस्क या server पर रात का डंप दूसरी कॉपी है। तीसरी कॉपी किसी दूसरे प्रोवाइडर के ऑब्जेक्ट स्टोरेज में जाती है, ऐसे क्रेडेंशियल से जो फ़ाइल जोड़ सकता है पर हटा नहीं सकता, और रिटेंशन लॉक चालू रहता है। यह तीसरी कॉपी ऑफ़-साइट और इम्यूटेबल, दोनों शर्तें एक साथ पूरी कर देती है।
इम्यूटेबल backup का मतलब है एक बार लिखो, बार-बार पढ़ो: फ़ाइल जमा होने के बाद स्टोरेज सर्विस ख़ुद उसे आपकी तय की हुई तारीख़ तक बदलने या हटाने से मना कर देती है। Amazon S3 में इस feature का नाम Object Lock है, और कई S3-संगत स्टोर भी यही feature इसी नाम से देते हैं। इसके दो मोड हैं, और फ़र्क़ मायने रखता है।
पूरा ब्योरा S3 Object Lock डॉक्यूमेंटेशन में है। प्रोवाइडर कोई भी हो, भरोसा करने से पहले तीन बातें जाँच लें: वर्ज़निंग चालू है, लॉक मोड compliance है (या ओवरराइड की अनुमति किसी ऐसे व्यक्ति के पास है जो रोज़ का admin नहीं है), और रिटेंशन उतने समय से लंबा है जितना आपको हमले का पता लगाने में लग सकता है। घुसपैठ हफ़्तों तक किसी की नज़र में नहीं आ सकती।
अगर ऑब्जेक्ट लॉक उपलब्ध नहीं है, तो ऑफ़लाइन कॉपी वही काम करती है: एक एक्सटर्नल ड्राइव या टेप जो रन के बीच में भौतिक रूप से अलग रहता है, या पुल-आधारित backup server जो data ख़ुद खींच लाता है, ताकि प्रोडक्शन system के पास backup तक पहुँचने का कोई क्रेडेंशियल ही न रहे।
backup का हर फ़ैसला दो संख्याओं पर टिका है। RPO (recovery point objective) बताता है कि आप कितना ताज़ा data खोना झेल सकते हैं, समय के हिसाब से। RTO (recovery time objective) बताता है कि आप कितनी देर ठप रह सकते हैं। ये पहले कारोबारी फ़ैसले हैं और बाद में तकनीकी सेटिंग, और हर system के लिए अलग होते हैं।
order सबसे साफ़ मिसाल हैं। जो ऑनलाइन स्टोर घंटे में सौ order लेता है, वह एक दिन के order नहीं खो सकता, क्योंकि ग्राहकों से पैसे कट चुके हैं और मिलान करने को कुछ बचा नहीं। पुराने ब्रोशर वाला शेयर्ड फ़ोल्डर हफ़्ते भर इंतज़ार कर सकता है। लक्ष्य यह पूछकर तय करें: data खोने या system ठप रहने का हर घंटा हमें कितने का पड़ता है?
| स्तर | उदाहरण | लक्षित RPO | लक्षित RTO | तरीक़ा |
|---|---|---|---|---|
| स्तर 1: चलता हुआ पैसा | order, payment, stock ledger, अकाउंटिंग | 5–15 मिनट | 1–4 घंटे | लगातार लॉग shipping या बार-बार इन्क्रीमेंटल डंप, साथ में रोज़ की इम्यूटेबल फ़ुल कॉपी |
| स्तर 2: रोज़मर्रा का काम | ग्राहक, HR और payroll, supplier रिकॉर्ड, अपलोड की गई फ़ाइलें | 24 घंटे | 8–24 घंटे | रिटेंशन लॉक के साथ ऑफ़-साइट स्टोरेज पर रात का स्नैपशॉट |
| स्तर 3: काम की फ़ाइलें | दस्तावेज़, एक्सपोर्ट, report, मीडिया लाइब्रेरी | 24 घंटे | 2–3 दिन | डिलीट प्रोटेक्शन वाला वर्ज़न्ड ऑब्जेक्ट स्टोरेज |
| स्तर 4: आर्काइव | पुराने invoice, बंद हो चुके वित्त वर्ष, क़ानूनी रिकॉर्ड | 1 हफ़्ता | 1 हफ़्ता | मासिक इम्यूटेबल कॉपी, लंबा रिटेंशन, एन्क्रिप्टेड |
ये आँकड़े उदाहरण के तौर पर शुरुआती बिंदु हैं, कोई मानक नहीं। आपके अपने आँकड़े आपके डाउनटाइम की लागत से आने चाहिए। ज़रूरी यह है कि हर system का एक स्तर हो और वह लिखा हुआ हो।
database डंप सबसे पहले याद आता है, पर अकेला शायद ही काफ़ी होता है। अगर आपने कभी कोई system restore किया और वह चालू ही नहीं हुआ, तो नीचे की कोई चीज़ शायद छूटी थी।
हर कॉपी को network से बाहर जाने से पहले एन्क्रिप्ट करें, और encryption कुंजियाँ ऐसी जगह रखें जहाँ backup स्टोरेज न पहुँच सके। चोरी हुआ backup data ब्रीच है, और कई देशों में उसकी सूचना देना क़ानूनन ज़रूरी है।
कमज़ोर कड़ी अक्सर तकनीक नहीं, अलगाव होता है। चार नियम ज़्यादातर काम सँभाल लेते हैं:
सिर्फ़ कल रात का backup रखना ख़तरनाक है, क्योंकि चुपचाप हुई घुसपैठ हफ़्तों पुरानी हो सकती है और कल रात की कॉपी में नुक़सान पहले से घुस चुका हो सकता है। ज़्यादातर छोटे और मझोले कारोबारों के लिए एक व्यावहारिक ढर्रा यह है: 30 दिन तक रोज़ की कॉपी, तीन महीने तक हफ़्ते की कॉपी, और एक साल या जितना आपका अकाउंटेंट और स्थानीय क़ानून माँगे उतने समय तक महीने की कॉपी। रिकवरी के बिल के मुक़ाबले स्टोरेज बहुत सस्ता है।
रिटेंशन आपको अपनी ग़लतियों से भी बचाता है। कोई ग़लती से product catalog डिलीट कर देता है, कोई ग़लत स्प्रेडशीट इम्पोर्ट कर देता है, कोई बग एक महीने के दाम बिगाड़ देता है। restore पॉइंट्स का इतिहास हो तो ये आफ़तें एक दोपहर के काम में बदल जाती हैं।
3-2-1-1-0 का आख़िरी "0" वही है जिसे ज़्यादातर टीमें छोड़ देती हैं। जिस backup को कभी restore नहीं किया गया, उसके काम करने की संभावना अनजानी है। हो सकता है फ़ाइलें ख़ाली हों, कुंजी ग़ायब हो, या restore में तीन घंटे की बजाय 30 घंटे लग जाएँ। यह सब किसी शांत मंगलवार को जान लेना बेहतर है।
छोटी शुरुआत करें और इसे आदत बनाएँ। हर हफ़्ते सबसे नया database backup अपने-आप किसी अस्थायी माहौल में restore हो और कुछ जाँच-query चलें। हर महीने एक फ़ाइल सेट वापस लाकर कुछ फ़ाइलें खोलकर देखें। हर तिमाही किसी साफ़ server पर पूरा system दोबारा खड़ा करें और समय नापें। साल में एक बार टेबलटॉप अभ्यास करें, मानो मुख्य server चला गया हो और पुराने तक कोई पहुँच नहीं सकता।
हर नतीजा दर्ज करें: तारीख़, क्या restore किया, कितना समय लगा, क्या गड़बड़ हुई। अगर कोई ड्रिल वादा किए गए RTO से ज़्यादा खिंचे, तो योजना बदलें या वादा। जो शेड्यूलर स्नैपशॉट लेता है, रिटेंशन लागू करता है और एक ही क़दम में साफ़ जगह पर restore कर देता है, उससे ड्रिल चलाना बहुत सस्ता हो जाता है। नीचे का छोटा वीडियो इसका एक self-hosted उदाहरण दिखाता है, StoreConsole का Backups module, जो ठीक यही चक्र चलाता है।
पहले कुछ फ़ैसलों का क्रम किसी भी एक क़दम से ज़्यादा मायने रखता है। हर restore से पहले दो सवालों के जवाब चाहिए: क्या backup सलामत हैं और हमलावर की पहुँच से बाहर हैं, और क्या restore पॉइंट घुसपैठ से पहले का है? फ़्लोचार्ट पूरा रास्ता दिखाता है, और उसके नीचे की सूची प्रिंट करके रखने लायक़ छोटा रूप है।
जब रैनसमवेयर हमला करता है, तो पहले घंटे में लोग सबसे बुरे फ़ैसले लेते हैं। इसलिए रनबुक शांत रहते हुए लिखें, प्रिंट करें, और एक कॉपी network से बाहर रखें। छोटा रूप कुछ ऐसा है:
सरकारी दिशानिर्देश ज़रूरत पड़ने से पहले पढ़ लेना अच्छा है। अमेरिका की CISA के StopRansomware संसाधनों में एक व्यावहारिक रिस्पॉन्स चेकलिस्ट है, जो अमेरिका के बाहर भी उतनी ही काम आती है।
अब इसी शुक्रवार को सलाह मानकर दोबारा चलाकर देखिए। हर सोमवार सुबह 6 बजे system सबसे नया डंप एक अस्थायी database में restore करता है और order की गिनती प्रोडक्शन से मिलाता है। मार्च में यह जाँच फ़ेल हो जाती है और एक email आता है: order 0, अपेक्षित लगभग 4,200। मालकिन उसे चाय के साथ पढ़ती हैं, कॉन्ट्रैक्टर घंटे भर में स्क्रिप्ट ठीक कर देता है, और उसके पीछे लॉक किए हुए बकेट में वह कॉपी पड़ी रहती है जो ऐसी चाबी से लिखी गई थी जो सिर्फ़ फ़ाइल जोड़ सकती है। जो खोज शुक्रवार शाम की मुसीबत बनती, वह सोमवार सुबह का एक email बन गई।
अनिचुर रहमान सॉफ़्टवेयर आर्किटेक्ट और StoreConsole के संस्थापक हैं। वे बढ़ते कारोबारों के लिए कॉमर्स और ERP सिस्टम डिज़ाइन करते हैं — ख़ास ध्यान event-driven आर्किटेक्चर, डेटा की शुद्धता और अपने सर्वर पर चलने वाले सिस्टम पर।
About the Author
Anichur Rahaman
Continue Reading
