தொடர்ச்சி மற்றும் மீட்டெடுப்பு: சோதிக்கப்படாத Restore

ஒவ்வொரு backup dashboard-ம் பச்சை checkmarks காட்டுகிறது. Jobs முடிந்துவிட்டது, retention policy திருப்திப்படுத்தப்பட்டது, storage எதிர்பார்த்தபடி பயன்படுத்தப்பட்டது. இவற்றில் எதுவும் நீங்கள் ஒரு domain controller-ஐ bare metal-ிலிருந்து உண்மையான incident-க்கு நான்கு மணிநேரத்துக்குள் மீண்டும் கொண்டுவரமுடியுமா என்பதை கூறாது. "backup succeeded" மற்றும் "restore succeeded" என்ற இடைவெளি பெரும்பாலான continuity plans조용히தோல்வியடையும் இடமாகும்.

Checkmark ஏன் பொய் சொல்கிறது

Backup software ஒரு destination-ற்கு bytes எழுத முடிந்ததும் success-ஐ பதிவுசெய்கிறது. அந்த bytes பயன்படுத்தக்கூடியதா என்பது அது அறியாது. SQL Server backup சுத்தமாக முடிந்திருந்தாலும் restore செய்ய முடியாமல் இருக்கலாம் কারணம் transaction log chain மூன்று நாட்களுக்கு முன்பே உடைந்துவிட்டது மற்றும் யாரும் கவனிக்கவில்லை. VM snapshots console-ல் நன்றாக இருக்கலாம் ஆனால் அடிப்படை VSS writer guest OS-ல் silent-ஆக தோல்வியடைந்திருக்கலாம், crash-consistent (application-consistent அல்ல) image உருவாக்கிக் கொண்டிருக்கலாம்.

Ransomware operators இதை அறிந்திருக்கிறார்கள். Conti-style playbooks চালாகும் குழுக்கள் முந்தைய incidents-ல் deliberately backup infrastructure-ஐ aim செய்தார்கள் — shadow copies-ஐ vssadmin delete shadows /all /quiet-ஆல் நீக்கி, Veeam repositories-ஐ disable செய்து, SMB-க்கு மேல் வெளிப்படையாக இருந்த NAS-based backup targets-ஐ encrypt செய்தார்கள். உங்கள் backups production-க்கு same network segment-ல் இருந்து domain credentials உடன் அவற்றைத் touch செய்யக்கூடுமெனில், அவை safety net அல்ல, target ஆகும்.

Restore runbook உருவாக்கு, backup policy அல்ல

ஒரு continuity plan step-by-step restore instructions கொண்டிருக்க வேண்டும் இயல்பாக அதை செய்பவர் இல்லாத ஒருவருக்கு எழுதப்பட்ட. எழுதுங்கள்:

• சரியான recovery order (domain controllers மற்றும் DNS முதல், பிறகு core apps, பின் எல்லாம்)
• உங்கள் password vault-ம் down-ஆக இருந்தால் backup console-க்கான credentials எங்கே இருக்கிறது
• specific restore command அல்லது console path, "use Veeam to restore the VM" என்பது அல்ல
• actual measured tests-ல் அடிப்படையாக expected duration per system, vendor marketing numbers அல்ல

Veeam Backup & Replication-ற்கு, அதன் பொருள் actual steps-ஐ documenting செய்தல்: console-ஐ திற, Backups > Disk-ற்கு navigate செய், restore point-ஐ right-click செய், scenario-க்கு depending Instant VM Recovery அல்லது Full VM Restore-ஐ தேர்வுசெய், adequate free capacity உடன் target host-ஐ தேர்வுசெய். உங்கள் primary host-ம் compromise செய்யப்பட்டிருந்தால், முன்பே identify செய்யப்பட்ட மற்றும் licensed second, isolated host-ஐ நீங்கள் கொண்டிருக்க வேண்டும்.

Schedule-ல் test restores, whim-ல் அல்ல

ஒரு rotation தேர்ந்தெடு. ஒவ்வொரு மாதம், ஒரு critical system-ஐ isolated VLAN-க்கு restore செய் மற்றும் அது boots, authenticates, மற்றும் correctly data serve செய்கிறது என்பதை validate செய். ஒவ்வொரு quarter, full-scope test run செய்: உங்கள் domain controller, உங்கள் file server, மற்றும் உங்கள் primary database-ஐ isolated infrastructure-க்கு restore செய், பிறகு backup team-க்கு வெளியே உள்ள ஒருவரைக் log in செய்து report pull செய்ய முயற்சி செய்யுங்கள்.

Databases-க்கு, வெறும் .bak file-ஐ restore செய்யாமல் — verify செய்:

RESTORE VERIFYONLY FROM DISK = 'D:\Backups\prod_2024.bak'

பிறகு அதை test instance-ல் actually restore செய் மற்றும் அதற்கு DBCC CHECKDB run செய். VERIFYONLY-ஐ pass செய்கிற backup-ம் logical corruption contain செய்யக்கூடும் যা நீ அதை query செய்ததும் மட்டுமே show ஆகும்.

Linux systems-க்கு Bacula அல்லது restic போன்ற ஏதாவது பயன்படுத்தி, actual restore path-ஐ test செய்:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

பிறகு restored config files-ஐ production-க்கு against diff செய் ஒன்றுமே silent-ஆக drop ஆகவில்லை என்பதை confirm செய்.

Immutable copies மற்றும் 3-2-1-1 rule

Classic 3-2-1 rule (மூன்று copies, இரண்டு media types, ஒரு offsite) ransomware era-க்கு ஒரு update வேண்டும்: 3-2-1-1, இதில் extra "1" ஒரு immutable அல்லது air-gapped copy ஆகும். Object lock S3-compatible storage-ல் (Wasabi, Backblaze B2, அல்லது AWS S3 Object Lock enable-ஆக) defined retention window-க்கு deletion அல்லது modification-ஐ தடுக்கிறது, admin credentials உடன் கூட ஒரு account-ல் கூட. அதை configure செய்:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

COMPLIANCE mode என்பது nobody, root account உட்பட, retention-ஐ shorten செய்யவோ அல்லது objects-ஐ early delete செய்யவோ முடியாது. Attacker-க்கு domain admin இருந்தால் அது matter செய்கிறது.

RTO மற்றும் RPO-ஐ guesses அல்ல real numbers-ல் measure செய்

Recovery Time Objective மற்றும் Recovery Point Objective paperwork exercises போல் sound செய்கிறது ஆனால் ஒரு executive "how much data do we lose மற்றும் how long are we down" கேட்டால் வரை. உங்கள் last three test restores-ஐ time செய். உங்கள் RPO target one hour ஆனால் உங்கள் backup job every six-ல் மட்டுமே run ஆனால், நீங்கள் documented gap கொண்டிருக்கிறீர்கள், மற்றும் அந்த gap-ஐ actual encryption event-க்கு Saturday-ல் 2 a.m. during ஓட்ட விட்டுவிடுவதை விட tabletop exercise-ல் கண்டுபிடிப்பது சிறந்தது.

Test run செய், actual clock time-ஐ எழுது, மற்றும் disaster recovery document-ல் நீ promise செய்தது compare செய். அந்த இரண்டு numbers-க்கு இடையிலான difference உங்கள் continuity plan-ன் real state ஆகும்.

நீ protecting-ஐ systems-ஐ hardening செய்து incident response workflows-ஐ கட்டம் வைப்பது பற்றி மேலதிக மகாவிவரத்துக்கு, Korra Studio-ல் related Blue Team மற்றும் Digital Forensics segments-ஐ check செய்.