ধারাবাহিকতা এবং পুনরুদ্ধার: পরীক্ষা করা হয়নি এমন রিস্টোর

প্রতিটি ব্যাকআপ ড্যাশবোর্ড সবুজ চেকমার্ক দেখায়। জব সম্পূর্ণ হয়েছে, ধারণ নীতি সন্তুষ্ট, স্টোরেজ প্রত্যাশা অনুযায়ী ব্যবহার করা হয়েছে। এর কোনো কিছুই আপনাকে বলে না যে আপনি একটি প্রকৃত ঘটনার সময় চার ঘণ্টার মধ্যে bare metal থেকে একটি domain controller ফিরিয়ে আনতে পারবেন কি না। "ব্যাকআপ সফল হয়েছে" এবং "রিস্টোর সফল হয়েছে" এর মধ্যে ফাঁক হল যেখানে বেশিরভাগ ধারাবাহিকতা পরিকল্পনা নীরবে ব্যর্থ হয়।

চেকমার্ক কেন মিথ্যা বলে

ব্যাকআপ সফটওয়্যার সাফল্য রিপোর্ট করে যখন এটি একটি গন্তব্যে বাইট লেখা শেষ করে। এটি জানে না যে সেই বাইটগুলি ব্যবহারযোগ্য কিনা। একটি SQL Server ব্যাকআপ পরিষ্কারভাবে সম্পূর্ণ হতে পারে এবং তখনও পুনরুদ্ধারযোগ্য না হতে পারে কারণ transaction log chain তিন দিন আগে ভেঙে গেছে এবং কেউ লক্ষ্য করেনি। VM snapshots কনসোলে ঠিক দেখাতে পারে যখন অন্তর্নিহিত VSS writer অতিথি OS এর ভিতরে নীরবে ব্যর্থ হয়েছে, একটি crash-consistent (application-consistent নয়) ছবি উৎপন্ন করছে।

Ransomware অপারেটররা এটি জানে। অতীত ঘটনায় Conti-স্টাইল playbookগুলি চালানো গ্রুপগুলি ইচ্ছাকৃতভাবে ব্যাকআপ অবকাঠামোকে লক্ষ্য করেছে — vssadmin delete shadows /all /quiet দিয়ে shadow copies মুছে ফেলা, Veeam repositories নিষ্ক্রিয় করা, NAS-ভিত্তিক ব্যাকআপ লক্ষ্যগুলি এনক্রিপ্ট করা যা SMB এর উপর নাগালের মধ্যে ছিল। যদি আপনার ব্যাকআপগুলি production এর মতো একই নেটওয়ার্ক সেগমেন্টে থাকে এবং domain credentials থাকে যা সেগুলি স্পর্শ করতে পারে, তাহলে সেগুলি একটি লক্ষ্য, একটি সুরাপত্র নয়।

একটি ব্যাকআপ নীতি নয়, একটি রিস্টোর runbook তৈরি করুন

একটি ধারাবাহিকতা পরিকল্পনার জন্য ধাপে ধাপে রিস্টোর নির্দেশাবলী প্রয়োজন যা সেই ব্যক্তির জন্য লেখা যিনি সাধারণত এটি করেন না। লিখুন:

• নির্ভুল পুনরুদ্ধার ক্রম (domain controllers এবং DNS প্রথম, তারপর core apps, তারপর বাকি সবকিছু)
• ব্যাকআপ কনসোলের জন্য credentials কোথায় থাকে যদি আপনার password vault ও ডাউন থাকে
• নির্দিষ্ট রিস্টোর কমান্ড বা কনসোল পাথ, "VM রিস্টোর করতে Veeam ব্যবহার করুন" নয়
• প্রকৃত পরিমাপ করা পরীক্ষার উপর ভিত্তি করে প্রতিটি সিস্টেম প্রতি প্রত্যাশিত সময়কাল, বিক্রেতা মার্কেটিং সংখ্যা নয়

Veeam Backup & Replication এর জন্য, এটি প্রকৃত পদক্ষেপ নথিভুক্ত করার অর্থ: কনসোল খুলুন, Backups > Disk এ নেভিগেট করুন, রিস্টোর পয়েন্টে right-click করুন, পরিস্থিতির উপর নির্ভর করে Instant VM Recovery বা Full VM Restore বেছে নিন, এবং পর্যাপ্ত মুক্ত ক্ষমতা সহ লক্ষ্য হোস্ট নির্বাচন করুন। যদি আপনার প্রাথমিক হোস্ট ও আপস করা হয়, আপনার একটি দ্বিতীয়, বিচ্ছিন্ন হোস্ট ইতিমধ্যে চিহ্নিত এবং লাইসেন্স করা প্রয়োজন।

একটি whim নয়, একটি সময়সূচীতে রিস্টোর পরীক্ষা করুন

একটি ঘূর্ণন বেছে নিন। প্রতি মাসে, একটি গুরুত্বপূর্ণ সিস্টেম একটি বিচ্ছিন্ন VLAN এ রিস্টোর করুন এবং এটি বুট হয়, প্রমাণীকৃত হয় এবং সঠিকভাবে ডেটা পরিবেশন করে তা যাচাই করুন। প্রতি ত্রৈমাসিক, একটি সম্পূর্ণ-স্কোপ পরীক্ষা চালান: আপনার domain controller, আপনার file server এবং আপনার প্রাথমিক database বিচ্ছিন্ন অবকাঠামোতে রিস্টোর করুন, তারপর ব্যাকআপ টিমের বাইরে কেউ লগইন করার চেষ্টা করুক এবং একটি রিপোর্ট টেনে নিন।

ডাটাবেসের জন্য, শুধু .bak ফাইল রিস্টোর করবেন না — এটি যাচাই করুন:

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

তারপর এটি একটি test instance এ প্রকৃতপক্ষে রিস্টোর করুন এবং এর বিরুদ্ধে DBCC CHECKDB চালান। একটি ব্যাকআপ যা VERIFYONLY পাস করতে পারে তখনও logical corruption রাখতে পারে যা শুধুমাত্র যখন আপনি এটি query করেন তখনই দেখা যায়।

Linux সিস্টেমের জন্য Bacula বা restic এর মতো কিছু ব্যবহার করে, প্রকৃত রিস্টোর পাথ পরীক্ষা করুন:

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

তারপর পুনরুদ্ধার করা config ফাইলগুলি production এর বিপরীতে diff করুন যাতে কিছু নীরবে ড্রপ হয়নি তা নিশ্চিত করুন।

Immutable copies এবং 3-2-1-1 নিয়ম

ক্লাসিক 3-2-1 নিয়ম (তিনটি কপি, দুই মিডিয়া প্রকার, এক offsite) ransomware যুগের জন্য আপডেটের প্রয়োজন: 3-2-1-1, যেখানে অতিরিক্ত "1" একটি immutable বা air-gapped কপি। S3-compatible স্টোরেজে Object lock (Wasabi, Backblaze B2, বা AWS S3 with Object Lock enabled) একটি সংজ্ঞায়িত ধারণ উইন্ডোর জন্য মুছে ফেলা বা পরিবর্তন প্রতিরোধ করে, এমনকি admin credentials সহ একটি অ্যাকাউন্টের দ্বারা। এটি দিয়ে কনফিগার করুন:

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

COMPLIANCE মোড মানে কেউই না, root account সহ, ধারণ সংক্ষিপ্ত করতে বা objects প্রাথমিকভাবে মুছতে পারে না। যখন আক্রমণকারী domain admin থাকে তখন এটি গুরুত্বপূর্ণ।

RTO এবং RPO পরিমাপ করুন অনুমান নয়, বাস্তব সংখ্যা দিয়ে

Recovery Time Objective এবং Recovery Point Objective কাগজের ব্যায়াম মনে হয় যতক্ষণ না একজন নির্বাহী প্রশ্ন করেন "আমরা কত ডেটা হারাই এবং আমরা কতক্ষণ ডাউন থাকি।" আপনার শেষ তিনটি পরীক্ষা রিস্টোরের সময় নির্ধারণ করুন। যদি আপনার RPO লক্ষ্য এক ঘণ্টা হয় কিন্তু আপনার ব্যাকআপ জব প্রতি ছয় ঘণ্টায় চলে, আপনার একটি নথিভুক্ত ফাঁক রয়েছে, এবং এটি একটি tabletop ব্যায়ামে সেই ফাঁক খুঁজে পাওয়া ভাল শনিবার সকাল ২টায় একটি প্রকৃত এনক্রিপশন ইভেন্টের সময়ের চেয়ে।

পরীক্ষা চালান, প্রকৃত ঘড়ির সময় লিখুন এবং disaster recovery ডকুমেন্টে আপনি যা প্রতিশ্রুতি দিয়েছেন তার সাথে তুলনা করুন। সেই দুটি সংখ্যার মধ্যে পার্থক্য হল আপনার ধারাবাহিকতা পরিকল্পনার প্রকৃত অবস্থা।

আপনি যে সিস্টেমগুলি রক্ষা করছেন তা শক্তিশালী করা এবং incident response workflows তৈরি করার বিষয়ে আরও জানতে, Korra Studio এর সম্পর্কিত Blue Team এবং Digital Forensics সেগমেন্টগুলি দেখুন।