Ransomware से बचने वाला backup ── 3-2-1 rule, overwrite न हो सकने वाली storage, और restore हो पाने की जाँच

Ransomware attacks में ऐसे बहुत मामले हैं जहाँ organization के पास backup था, फिर भी restore नहीं हो पाया। सबसे आम कारण यह है कि backup भी बाक़ी data के साथ encrypt हो गया। यह article small और medium-sized businesses के Windows PCs और file servers के लिए समझाता है कि attack झेल सकने वाला backup कैसे बनाएँ।

मुख्य बातें तीन हैं: एक ऐसी copy रखें जिसे infected PC overwrite न कर सके, “Previous Versions” को backup की जगह use न करें, और confirm करें कि सच में restore हो पाता है। 3-2-1 rule से तय होता है कि कितनी copies रखनी हैं और कहाँ, लेकिन सिर्फ़ इससे ransomware से बचाव में कुछ कमियाँ रह जाती हैं।

इस article के commands सिर्फ़ Windows के लिए हैं, और उनका output Windows Server 2022 के administrator command prompt में check किया गया है। Products की settings screens और prices बदल सकते हैं, इसलिए लागू करते समय हर vendor की latest documentation देखें।

Backup होने के बावजूद कई companies restore नहीं कर पाईं

Japan की National Police Agency ransomware से प्रभावित organizations से उनके backup की स्थिति पूछती है। 2025 की पहली छमाही की report में जवाब देने वाली 53 organizations में से 51 ने backup लिया था। लेकिन जिन 48 से पूछा गया कि क्या वे backup से attack से ठीक पहले वाले level तक restore कर पाईं, उनमें सिर्फ़ 7 कर पाईं और 41 नहीं कर पाईं¹।

Restore न हो पाने का कारण बताने वाले 35 मामलों में “backup भी encrypt हो गया” 23, “operational failures” 8 और “अन्य” 4 थे¹। इसी report में लिखा है कि ransomware groups निशान मिटाने और recovery का काम न होने देने के लिए victim company के logs और backups delete कर देते हैं। साथ ही report backup को offline environment में रखने की सलाह देती है²।

flowchart TB
        accTitle: Backup होने पर भी restore न हो पाने का flow
        accDescr: यह diagram दिखाता है कि backup लेने पर भी, अगर वह infected PC की पहुँच में है तो साथ में encrypt हो जाता है, और अगर restore procedure check नहीं किया गया तो operational failure से restore नहीं होता।
        A["Backup ले रहे हैं"] --> B{"क्या infected PC पहुँच सकता है"}
        B -->|"पहुँच सकता है"| C["साथ में encrypt या delete होता है"]
        B -->|"नहीं पहुँच सकता"| D{"क्या restore procedure check किया"}
        D -->|"check नहीं किया"| E["Operational failure से restore नहीं होता"]
        D -->|"check किया"| F["Restore हो सकता है"]

चित्र 1: Backup तभी काम आता है जब infected PC उस तक न पहुँच सके और restore procedure check किया गया हो।

ऐसे मामले भी हैं जहाँ restore हो गया। IPA की “Information Security Guidelines for SMEs” के 4th edition में एक construction company का case है, जिसके file servers और दूसरे systems VPN appliance के रास्ते intrusion के बाद encrypt हो गए थे। Company साल में दो बार restore drill करती थी, इसका भी फ़ायदा मिला, और attack पता चलने के पाँच दिन बाद उसने backup से core systems फिर से चालू कर दिए। फिर भी company के internal systems फिर शुरू करने में 41 दिन और remote access फिर शुरू करने में 4 महीने लगे, और internal files का 20 प्रतिशत से कुछ ज़्यादा हिस्सा खो गया³। Backup से restore हो जाने पर भी नुक़सान ख़त्म नहीं होता।

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 13, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

Attackers पहुँच में आने वाले backup delete करते हैं

US की CISA और दूसरी agencies की #StopRansomware Guide लिखती है कि बहुत-से ransomware, फिरौती दिए बिना recovery नामुमकिन बनाने के लिए, पहुँच में आने वाले backups ढूँढकर उन्हें delete या encrypt करने की कोशिश करते हैं। इसलिए guide backup को offline रखना ज़रूरी बताती है⁴।

Microsoft भी लिखता है कि attackers backup software और volume shadow copies जैसे OS features को बेकार करने पर ज़ोर देते हैं⁵। Infected PC की पहुँच में आने वाले backups ऐसे होते हैं:

• PC से हमेशा जुड़ी external drive
• Drive letter assign किया हुआ NAS या file server का shared folder
• Normal account से write होने वाला cloud sync folder
• उसी volume पर रखी shadow copies (Previous Versions)

OS में built-in commands से भी shadow copies और backup catalog delete किए जा सकते हैं। MITRE ATT&CK इस technique को “Inhibit System Recovery” (T1490) के नाम से classify करता है। उसमें vssadmin.exe delete shadows /all /quiet से सारी shadow copies delete करने और wbadmin.exe delete catalog -quiet से Windows backup catalog delete करने के examples दिए गए हैं⁶। CISA की guide भी vssadmin.exe, wbadmin.exe, wmic.exe (shadowcopy) जैसे tools के suspicious use पर नज़र रखने को कहती है⁴।

flowchart TB
        accTitle: Infected PC की पहुँच में आने वाले और न आने वाले backups
        accDescr: यह diagram दिखाता है कि infected PC हमेशा जुड़ी external drive, assign किए गए shared folder, sync folder और shadow copies पर write कर सकता है, लेकिन अलग किए गए media और overwrite न हो सकने वाली storage पर write नहीं कर सकता।
        P["Infected PC"] --> R["Write होने वाली जगहें"]
        P -.-x N["अलग किया गया media और overwrite न होने वाली storage"]
        R --> A["हमेशा जुड़ी external drive"]
        R --> B["Assign किया हुआ shared folder"]
        R --> C["Cloud sync folder"]
        R --> D["Shadow copies"]

चित्र 2: जिन जगहों पर infected PC write कर सकता है, वहाँ रखा backup attack का target बनता है।

धीरे-धीरे चलने वाले attacks से भी सावधान रहना होगा। Microsoft लिखता है कि ransomware कभी-कभी key को system पर छोड़े रखकर थोड़ा-थोड़ा encryption करता है। इस दौरान users अपना data normally use करते रहते हैं, इसलिए encryption का पता नहीं चलता और encrypted data के backups बढ़ते जाते हैं। सब कुछ encrypt होने के बाद key हटा दी जाए, तो हाल के backups भी पढ़े नहीं जा सकते⁵। अगर सिर्फ़ सबसे नया एक generation रखा है, तो ऐसे में restore करने के लिए कोई point नहीं बचता।

“Previous Versions” backup की जगह नहीं ले सकता

Windows का “Previous Versions” और Shadow Copies of Shared Folders, Volume Shadow Copy (VSS) use करते हैं। Windows के साथ आने वाला VSS system provider copy-on-write तरीक़े से काम करता है: block बदलने से पहले उसका content diff area में रख देता है, और इस तरह किसी एक समय की volume को फिर से बना देता है⁷।

Microsoft अपनी VSS documentation में shadow copy और backup का फ़र्क़ इस तरह समझाता है। जब shadow copy से tape जैसे removable media पर data copy किया जाता है, तब उस media का content backup बनता है। Copy करने के बाद shadow copy ख़ुद delete की जा सकती है⁷। यह भी लिखा है कि diff area कम पड़ने पर पुरानी shadow copies क्रम से delete होती जाती हैं⁷।

flowchart TB
        accTitle: Shadow copy और backup का फ़र्क़
        accDescr: यह diagram दिखाता है कि shadow copy original volume का difference है और जगह कम पड़ने या attack से delete हो जाती है, जबकि अलग media पर copy किया गया backup original volume खो जाने पर भी बचा रहता है।
        V["Original volume"] --> S["Shadow copy (difference)"]
        S --> L["जगह कम होने पर पुरानी से delete"]
        S --> K["Attacker vssadmin से delete करता है"]
        S -->|"अलग media पर copy"| B["Backup"]
        B --> R["Original volume खोने पर भी बचा रहता है"]

चित्र 3: Shadow copy original volume के data पर निर्भर होती है; अलग media पर copy की गई चीज़ ही backup है।

Shadow copies तब काम की हैं जब user ग़लती से overwrite की गई file ख़ुद वापस लाना चाहे। लेकिन जैसा पिछले section में बताया, attackers इन्हें delete कर सकते हैं। Mechanism और operation की details “Volume Shadow Copy (VSS) की संरचना और व्यवहार” में हैं।

कौन-सी shadow copies बची हैं, यह administrator command prompt में vssadmin list shadows चलाकर list किया जा सकता है। यह subcommand client और server दोनों पर उपलब्ध है⁸।

vssadmin list shadows

OneDrive और SharePoint की version history और recycle bin भी users के लिए files वापस लाने का ज़रिया हैं। Microsoft सलाह देता है कि users को पूरा OneDrive किसी पिछले समय पर restore करना सिखाएँ। साथ ही यह भी कहता है कि restore तभी करने दें जब पक्का हो जाए कि attacker बाहर कर दिया गया है, और अगर user malware भी वापस ले आए तो उसके लिए उपाय तैयार रखें⁵।

3-2-1 rule copies की संख्या और जगह तय करता है

3-2-1 rule backup copies रखने का एक rule of thumb है। US-CERT के लिए 2012 में बनाया गया “Data Backup Options” इसे इस तरह समझाता है⁹।

• 3: ज़रूरी files की कुल तीन copies रखें, यानी original एक और backup दो।
• 2: अलग-अलग तरह की disasters के लिए दो तरह के media पर रखें।
• 1: एक copy घर या office के बाहर रखें।

यह document source के तौर पर photographer Peter Krogh की digital photo management पर लिखी book “The DAM Book” का नाम देता है⁹। Microsoft भी ransomware से बचाव वाले backup document में यह rule बताता है, और “1” को “off-site या cold copy” कहता है⁵।

3-2-1 rule सिर्फ़ इतना माँगता है कि एक copy बाहर रखी जाए। यह नहीं माँगता कि बाहर वाली copy offline या immutable हो। इसलिए अगर बाहर वाली copy ऐसे cloud में है जिस पर infected PC हमेशा write कर सकता है, तो वह local copies के साथ encrypt हो सकती है। CISA की guide और Microsoft का document ransomware से बचाव के लिए offline storage बताते हैं। Microsoft overwrite न हो सकने वाली storage भी बताता है⁴⁵।

flowchart TB
        accTitle: 3-2-1 rule और ransomware से बचाव
        accDescr: यह diagram दिखाता है कि तीन copies, दो तरह के media और एक copy बाहर रखने वाले 3-2-1 rule में एक offline या overwrite न हो सकने वाली copy जोड़नी है और restore हो पाने की जाँच करनी है।
        A["तीन copies"] --> B["दो तरह के media"]
        B --> C["एक बाहर"]
        C --> D["एक offline या overwrite न होने वाली"]
        D --> E["Restore हो पाने की जाँच"]

चित्र 4: 3-2-1 rule में एक ऐसी copy जोड़ें जिसे infected PC overwrite न कर सके, और restore की जाँच जोड़ें।

Backup product Veeam इसे “3-2-1-1-0 rule” के नाम से promote करता है। Veeam के document में extra “1” का मतलब है एक offline, air-gapped या immutable copy रखना, और “0” का मतलब है regular restore verification में कोई error न होना¹⁰। यह नाम vendor के document का है, कोई official standard नहीं है। फिर भी ये दो extra points उन बातों से मेल खाते हैं जो CISA और IPA भी माँगते हैं।

एक ऐसी copy रखें जिसे infected PC overwrite न कर सके

Overwrite न हो सकने वाली copy बनाने के मुख्य रूप से दो तरीक़े हैं। एक, media को PC से अलग करके रखना। दूसरा, ऐसी cloud storage use करना जिसमें एक तय समय तक न overwrite हो सके न delete। दोनों में से कोई भी चुनें, backup manage करने की permissions को रोज़ के काम से अलग रखें।

Media को PC से अलग करके रखें

IPA की guidelines self-assessment के उपायों के example के तौर पर कहती हैं कि backup के लिए use होने वाले device या media को सिर्फ़ backup लेते समय PC से जोड़ें। इसके अलावा backup लेने का तरीक़ा तय करना, उसे सुरक्षित जगह रखना, और regularly check करना कि restore हो पाता है, ये भी बताती हैं¹¹।

और आगे बढ़कर काम करने के stage पर guidelines “physical isolation” बताती हैं। इसमें backup को original system से physically दूर जगह रखा जाता है, और external storage या backup tapes को जितना हो सके दूर रखा जाता है। रखने की जगह के examples में bank का safe deposit box, या कोई भरोसेमंद business partner या group company बताए गए हैं¹²।

Production system से इस तरह अलग करके रखे गए backup को offline backup कहते हैं। अलग किए गए media पर infected PC write नहीं कर सकता। बदले में जोड़ना-हटाना और ले जाना इंसान को करना पड़ता है, इसलिए backup लेना भूल जाना या media ले जाना भूल जाना होता है। तय करके रखें कि media को कौन, कब जोड़ेगा, हटाएगा और storage location तक ले जाएगा।

Overwrite न हो सकने वाली cloud storage use करें

Cloud storage में ऐसे features हैं जिनमें तय समय तक data न overwrite हो सकता है न delete। इसमें data को WORM (Write Once, Read Many) state में रखा जाता है।

Azure Blob Storage की immutable storage में time-based retention policy set करने पर उस period में data create और read तो किया जा सकता है, लेकिन modify या delete नहीं¹³। Policy शुरू में unlocked state में बनती है, और test करने के बाद lock की जाती है। Locked policy delete नहीं हो सकती, और उसका retention period बढ़ाया जा सकता है पर घटाया नहीं¹³। Microsoft बताता है कि account की administrator permissions वाले users भी data modify या delete नहीं कर सकते¹³।

Amazon S3 के Object Lock में दो modes हैं। Compliance mode में retention period के दौरान AWS account के root user समेत कोई भी object version overwrite या delete नहीं कर सकता। Governance mode में सिर्फ़ special permissions वाले users retention settings बदल या हटा सकते हैं¹⁴। Object Lock सिर्फ़ उन buckets में use होता है जिनमें S3 versioning enabled हो¹⁴।

flowchart TB
        accTitle: Overwrite न हो सकने वाली storage के दो examples
        accDescr: यह diagram दिखाता है कि Azure Blob Storage की immutable storage में locked policy delete नहीं होती और retention period घटाया नहीं जा सकता, और S3 Object Lock के compliance mode में root user भी delete नहीं कर सकता जबकि governance mode में special permissions से बदला जा सकता है।
        W["Overwrite न होने वाली storage"] --> AZ["Azure Blob Storage की immutable storage"]
        W --> S3["S3 Object Lock"]
        AZ --> AZ1["Lock के बाद retention period घटा नहीं सकते"]
        S3 --> C["Compliance mode"]
        S3 --> G["Governance mode"]
        C --> C1["Root user भी delete नहीं कर सकता"]
        G --> G1["Special permissions से बदल सकते हैं"]

चित्र 5: दोनों storages तय समय तक overwrite और delete को रोकती हैं। Protection कितना मज़बूत है, यह settings पर निर्भर है।

Azure में policy lock करने के बाद अगर settings में ग़लती पता चले, तो भी retention period घटाया नहीं जा सकता¹³। CISA की guide बताती है कि कुछ cloud providers overwrite न हो सकने वाली storage देते हैं, और साथ में सावधान करती है कि ग़लत configuration से बड़ा ख़र्च हो सकता है। यह भी बताती है कि यह कुछ ख़ास regulations की requirements पूरी न करे, ऐसा हो सकता है⁴। लंबा retention period set करके lock करने पर उस पूरे period में data delete नहीं होता और storage का charge लगता रहता है। शुरुआत unlocked state या छोटे period से test करें, और restore हो पाने की पुष्टि करने के बाद ही production settings लगाएँ।

Backup manage करने की permissions अलग रखें

Overwrite न हो सकने वाली storage use करने पर भी, अगर backup settings या policies normal administrator account से बदली जा सकती हैं, तो attacker उन्हें बदल सकता है। Microsoft सलाह देता है कि online backups modify या delete करने से पहले multifactor authentication या security PIN जैसा एक अलग step माँगा जाए। Backup और restore के operations तय roles वाले users तक सीमित करने, और file shares में ऐसी स्थिति कम करने की भी सलाह देता है जहाँ बहुत-से users write या delete कर सकें⁵।

अगर PCs का management और backup का management एक ही व्यक्ति करता है, तब भी backup storage manage करने वाला account रोज़ PC sign-in के लिए use न करें, और उस पर multifactor authentication लगाएँ।

Generations रखें

IPA की guidelines कई समय के backups रखने वाले “generation management” की बात करती हैं। इससे data ख़राब होने या खो जाने पर किसी ख़ास समय तक पीछे जाकर restore किया जा सकता है¹²। जैसा पिछले section में बताया, अगर encryption का पता चलने में समय लगे, तो सबसे नया backup encryption के बाद का data होता है। कितनी generations रखनी हैं, यह इससे तय करें कि encryption का पता चलने में कितना समय लग सकता है और storage का ख़र्च कितना है।

flowchart TB
        accTitle: Overwrite न हो सकने वाली copy रखने के तीन तरीक़े
        accDescr: यह diagram दिखाता है कि media को अलग करके रखें या overwrite न हो सकने वाली storage use करें, backup manage करने की permissions normal account से अलग रखें, और कई generations रखें।
        A["Overwrite न होने वाली copy"] --> B["Media अलग करके रखें"]
        A --> C["Overwrite न होने वाली storage"]
        B --> D["Management permissions अलग रखें"]
        C --> D
        D --> E["कई generations रखें"]

चित्र 6: जगह तय करने के बाद management permissions अलग रखें, और generations रखें ताकि देर से पता चलने पर भी restore हो सके।

Restore हो पाने की जाँच करें

National Police Agency की report में restore न हो पाने का दूसरा सबसे आम कारण “operational failures” था¹। लिया गया backup सच में restore होता है या नहीं, यह restore करके देखे बिना पता नहीं चलता। Backup से सच में restore करके यह confirm करने के काम को restore test कहते हैं।

IPA की guidelines backup operations को लेने, रखने और recovery, इन तीन हिस्सों में बाँटती हैं। Recovery के लिए recovery plan बनाने और यह confirm करने को कहती हैं कि recovery सही से हो पाती है³। Business के लिए ज़रूरी systems के लिए कहती हैं कि recovery time objective (RTO) और recovery point objective (RPO) के हिसाब से backups लेने और procedures को तैयार करें, और drills से उनकी effectiveness check करें। RTO वह समय है जो target level तक restore करने में लगता है, और RPO वह point है जिस पर restore होगा, यानी सबसे नए backup का समय¹⁵। CISA की guide भी disaster recovery को ध्यान में रखकर regularly check करने को कहती है कि backups available हैं और ख़राब नहीं हुए⁴।

flowchart TB
        accTitle: Restore test कैसे करें
        accDescr: यह diagram flow दिखाता है: restore order तय करें, अलग environment में restore करें, लगे समय और restore हुए point को RTO और RPO से मिलाएँ, और runbook ठीक करें।
        A["Restore order तय करें"] --> B["अलग environment में restore करें"]
        B --> C["लगे समय को RTO से मिलाएँ"]
        B --> D["Restore हुए point को RPO से मिलाएँ"]
        C --> E["Runbook ठीक करें"]
        D --> E
        E -.->|"अगली जाँच"| A

चित्र 7: Restore करके देखें कि समय और point targets से मिलते हैं या नहीं, और नतीजे runbook में वापस डालें।

क्या check करें

IPA और Microsoft के documents के आधार पर check करने की बातें इस तरह रखी जा सकती हैं।

Microsoft सलाह देता है कि पहले business के लिए ज़रूरी systems तय करें और उनका regularly backup लें। इस तरह बनी backup priorities की list ही restore order की list बन जाती है। Priority वाली चीज़ों में Microsoft सबसे पहले Active Directory जैसे authentication systems का नाम लेता है, जो बाक़ी सभी systems में जाने के लिए ज़रूरी हैं⁵। यह भी सलाह देता है कि सारे systems बंद होने की स्थिति से business फिर शुरू करने की drill regularly करें। उस समय मानकर चलें कि email और chat भी use नहीं हो सकते⁵।

Microsoft लिखता है कि restore runbooks और network diagrams attackers जान-बूझकर target करते हैं। इन्हें protect करने या print करके पास रखने की सलाह देता है⁵। अगर runbook सिर्फ़ file server के अंदर है, तो उस file server के encrypt होने पर उसे पढ़ा नहीं जा सकता।

Attack के बाद restore करते समय ध्यान रखने की बातें

असली attack के बाद पहले ransomware को environment से हटाएँ, फिर restore करें⁵। Microsoft बताता है कि ऐसे समय का backup चुनें जिसके बारे में पता हो कि तब infection नहीं था, और restore करने से पहले backup में malware scan करें⁵। National Police Agency की report लिखती है कि ransomware groups कभी-कभी remote control करने वाला software backdoor के रूप में install कर देते हैं, ताकि entry point बंद होने पर भी फिर से अंदर आ सकें²। Restore से पहले intrusion का रास्ता और छोड़े गए mechanisms की जाँच करनी होगी।

flowchart TB
        accTitle: Attack के बाद backup से restore करने का क्रम
        accDescr: यह diagram दिखाता है कि ransomware और intrusion का रास्ता हटाएँ, infection से पहले के समय का backup चुनें, उसमें malware scan करें, और फिर ऊँची priority वाले systems से restore करें।
        A["Ransomware हटाएँ"] --> B["Intrusion का रास्ता और mechanisms जाँचें"]
        B --> C["Infection से पहले का point चुनें"]
        C --> D["Backup scan करें"]
        D --> E["ऊँची priority वाले से restore करें"]

चित्र 8: Attack के बाद attacker के mechanisms हटाएँ और confirm करें कि point infection से पहले का है, फिर restore करें।

कितनी बार check करें

IPA की guidelines और CISA की guide दोनों restore की जाँच “regularly” करने को कहती हैं, लेकिन कोई संख्या नहीं देतीं¹¹⁴। ऊपर बताए IPA case वाली company साल में दो बार restore drill करती थी³। तय करें कि business कितनी देर रुक सकता है और restore होने वाला point कितना पुराना चल सकता है, और इतनी बार check करें कि confirm हो सके कि आप इन्हें पूरा कर पा रहे हैं।

पहले क्या तय करें

अब तक की बातों को SMEs के लिए पहले तय करने वाली चीज़ों के रूप में summarize करते हैं।

flowchart TB
        accTitle: Ransomware से बचने वाला backup तय करने का क्रम
        accDescr: यह diagram क्रम दिखाता है: scope तय करें, copies की जगह और overwrite न होने वाली copy तय करें, permissions और generations तय करें, RTO और RPO तय करें, और restore हो पाने की जाँच करें।
        A["Scope तय करें"] --> B["Copies की जगह तय करें"]
        B --> C["Overwrite न होने वाली copy तय करें"]
        C --> D["Permissions और generations तय करें"]
        D --> E["RTO और RPO तय करें"]
        E --> F["Restore हो पाने की जाँच करें"]

चित्र 9: Scope से शुरू करके आख़िर में restore की जाँच तक, सब एक क्रम में तय करें।

IPA की guidelines के 4th edition में शुरुआत में follow किए जाने वाले “5 Information Security Rules” में “Backup लें!” जोड़ा गया, जिससे ये 6 rules हो गए¹⁶। पूरी guidelines पर कैसे काम करें, यह “Where Should SMEs Start on Security?” में summarize किया गया है। अगर servers बदलने का plan है, तो “Preparing for Windows Server 2016 End of Support” भी देखें।

संबंधित लेख

• Where Should SMEs Start on Security? — A Walkthrough of IPA’s ‘Information Security Guidelines for SMEs,’ 4th Edition
• Volume Shadow Copy (VSS) की संरचना और व्यवहार — in-use फ़ाइल का backup क्यों लिया जा सकता है
• Preparing for Windows Server 2016 End of Support

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये इस विषय से जुड़े topic पृष्ठ हैं। लेख से शुरू करके आप संबंधित सेवाओं और दूसरे लेखों तक जा सकते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख नीचे दिए गए सेवा पृष्ठों से जुड़ता है। जो प्रवेश-बिंदु आपके सबसे क़रीब हो, वहाँ से देखिए।

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

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

अगर backup लेते हैं, तो क्या ransomware infection के बाद सब restore हो जाएगा?

अक्सर सिर्फ़ backup लेना restore के लिए काफ़ी नहीं होता। Japan की National Police Agency ने 2025 की पहली छमाही के जो मामले compile किए, उनमें backup लेने वाली और जवाब देने वाली 48 organizations में से 41 attack से ठीक पहले वाले level तक restore नहीं कर पाईं। सबसे आम कारण यह था कि backup भी encrypt हो गया था। आपके पास एक ऐसी copy होनी चाहिए जिसे infected PC overwrite न कर सके, और यह confirm करना चाहिए कि उससे restore हो सकता है।

अगर Windows में Previous Versions है, तो क्या फिर भी backup चाहिए?

हाँ, चाहिए। Previous Versions असल में volume shadow copies हैं, यानी original volume पर रखे गए differences। Microsoft shadow copy से tape जैसे media पर copy किए गए data को backup मानता है। Ransomware कभी-कभी vssadmin जैसे tools से shadow copies delete कर देता है, इसलिए इन्हें अलग media पर रखे backup के साथ use करें।

क्या 3-2-1 rule follow करना ransomware से बचाव के लिए काफ़ी है?

हमेशा नहीं। 3-2-1 rule तीन copies, दो तरह के media और एक copy office के बाहर रखने को कहता है, लेकिन यह नहीं कहता कि बाहर वाली copy offline या immutable हो। जिस cloud copy पर infected PC हमेशा write कर सकता है, वह भी उसी तरह encrypt हो सकती है। Offline media पर या overwrite न हो सकने वाली storage में एक copy और जोड़ें।

Backup से restore हो पाता है या नहीं, यह कितनी बार check करना चाहिए?

IPA की guidelines और CISA की guide दोनों "regularly" कहती हैं, कोई संख्या नहीं देतीं। IPA की guidelines में एक case है जिसमें साल में दो बार restore drill करने वाली company ने attack पता चलने के पाँच दिन बाद अपने core systems फिर से चालू कर दिए। तय करें कि business कितनी देर रुक सकता है और restore होने वाला point कितना पुराना चल सकता है, और इतनी बार check करें कि confirm हो सके कि आप इन्हें पूरा कर पा रहे हैं।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच पर केंद्रित; जिन परियोजनाओं में मौजूदा assets बचे हैं, उनमें और जिन खराबियों का कारण आसानी से नहीं दिखता, उनकी जाँच में हमारी विशेष ताकत है।