ডাটা ব্যাকআপের কিছু সহজ নিয়ম ও নিরাপত্তা
by CIRT Team
ব্যাকআপ কাকে বলে, কত প্রকার, কোন ব্যাকআপ অ্যাপ্লিকেশন ভাল, RPO/RTO কি এগুলো বলার জন্য লিখাটি নয়। এ লেখাটির উদ্দেশ্য ডাটা ব্যাকআপ সম্পর্কে কিছু সহজ টিপস ও ব্যাকআপ ডাটা নিরাপত্তা, অডিট বিষয়ে অবগত করা এবং এটা থেকে কেউ যদি উপকৃত হন তবেই এই লেখাটি সার্থক বলে বিবেচিত হবে। এক যুগের অধিক সময় ডাটা ব্যাকআপ, রিকোভারী, অডিট ও নিরাপত্তার সাথে যুক্ত থাকার সময় যে নিয়ম মেনে কাজকে সহজ করার চেষ্টা করেছি তা তুলে ধরছিঃ
১। ব্যাকআপ, ডাটাবেস ও অ্যাপ্লিকেশন এডমিনিস্ট্রেটর কে একসাথে কাজ করতে হবে ডাটার ব্যাকআপ প্লান, নিরাপত্তা ও ডিজাস্টার রিকভারির সময়।
২। ডেটাবেস ব্যাকআপ নেয়ার সময় আর্কাইভ লগ এর ব্যাকআপ নিশ্চিত করা জরুরী। সুতরাং ডেটাবেস ব্যাকআপ প্ল্যান করার সময় আর্কাইভ লগ এর ব্যাকআপ ডাটাবেস এডমিনিস্ট্রেটর সাথে করতে পারেন। আপনার ডেটাবেসের আর্কাইভ লগ যদি প্রচুর তৈরি হয় তবে নির্দিস্ট সময় পরপর নিয়মিতভাবে আর্কাইভ লগ ব্যাকআপ করে আপনি আর্কাইভ লগের জায়গাটি ফাঁকা রাখতে পারেন।
৩। ব্যাকআপ প্ল্যান করার সময় অবশ্যই অ্যাপ্লিকেশন Owner এর কাছ থেকে জানতে হবে কোন কোন ফাইলগুলো তার আপ্লিকেশন আপ করার জন্য জরুরী। তেমনি ডেটাবেস এডমিনিস্ট্রেটর বলবে ডাটাবেস ব্যাকআপ এবং আর্কাইভ লগ ব্যাকআপ কখন, কিভাবে নিতে হবে। ব্যাকআপ অ্যাডমিন লক্ষ্য রাখবেন কোন ডাটা ডুপ্লিকেট হচ্ছে কিনা, ব্যাকআপ হতে কত সময় লাগছে এবং ডাটা রিস্টোর (restore) করতে কত সময় লাগতে পারে। রিষ্টোর (restore) সময়টি অবশ্যই ডাটাবেস অ্যাডমিন ও অ্যাপ্লিকেশান অ্যাডমিন জানা প্রয়োজন যা তাদের সিস্টেম রিস্টোর (restore) সম্পর্কে একটি ধারণা প্রদান করবে।
৪। অধিকাংশ ক্ষেত্রে দেখা যায় প্রচুর ডুপ্লিকেট ব্যাকআপ করা হয় এবং এতে প্রচুর স্টোরেজ ও সময় নষ্ট হয়। একটি উদাহারণ দেয়া যেতে পারেঃ
যদি সাপ্তাহিক ব্যাকআপ Full Backup হয় এবং মাসিক ব্যাকআপ ও Full Backup হয়, তবে একটি সাপ্তাহিক বাদ দিয়ে সেই সপ্তাহে মাসিক ফুল ব্যাকআপ চালানো হলে একটি সাপ্তাহিক ব্যাকআপ কমে যায়। মাসিক Full Backup এর ডাটা রিটেনশন সবসময়ই বেশী থাকে। তেমনি মাসিক এবং বাৎসরিক ব্যাকআপ এর ক্ষেত্রেও একই কথা প্রযোজ্য।
৫। ব্যাকআপ সময় বেশী লাগার অনেকগুলো কারণ থাকতে পারে। সাধারণত প্রচুর ছোট ছোট ফাইল থাকলে, LAN based ব্যাকআপ হলে, ব্যাকআপ এবং অফিসের জন্য যদি একই LAN হয়, ব্যাকআপ সার্ভার ও যে সার্ভার থেকে ডাটা ব্যাকআপ করা হচ্ছে তাদের যদি দূরত্ব অনেক হয় (different location), একই সময় যদি প্রচুর ব্যাকআপ একসাথে স্টার্ট হয়, একটি সার্ভার থেকে যদি একাধিক ব্যাকআপ চলে ।
৬। ব্যাকআপ বেশী লাগার কারণগুলো কিছু ক্ষেত্রে এড়ানো যায়:
ক। অ্যাপ্লিকেশান ও ডাটাবেস অ্যাডমিন এর সাথে কথা বলে অ্যাপ্লিকেশান টির Pick এবং Off-pick সময় নির্ধারণ করুন এবং Off-pick সময়ে ব্যাকআপ চালান।
খ। যদি আপনার অফিসে একই LAN আফিসের কাজে এবং ব্যাকআপের কাজে ব্যবহৃত হয়, তবে অফিসের পরে মধ্যরাতে ব্যাকআপগুলো Auto Schedule করে দিন।
গ। কোন Folder এ অসংখ্য ছোট File থাকলে, সেগুলো Sub-Folder এ ভেঙে ব্যাকআপ নেয়ার চেষ্টা করুন।
ঘ। একই সার্ভারে একই সময় যেন একটির বেশী ব্যাকআপ না চলে তা লক্ষ্য রাখুন।
ঙ। অধিক দূরবর্তী জায়গা থেকে ব্যাকআপ এর সময় Fiber Optic medium ব্যবহার করার কথা চিন্তা করতে পারেন অথবা যদি সম্ভব হয় ব্যাকআপ সার্ভার লোকাল রাখার চেষ্টা করুন।
৭। ব্যাকআপ অ্যাডমিন ও ডাটাবেস অ্যাডমিন এর কাজটি ডাটা রিকোভারীর সময় আলাদা করা প্রয়োজন। বিপদের মুহূর্তে কে ডাটা রিকোভার করবে , কে ডাটাবেস আপ করবে, কে অ্যাপ্লিকেশান আপ করবে ইত্যাদি বিষয়গুলো আগে থেকে নির্ধারণ করে রাখুন।
৮। বছরে একবার অন্তত ক্রিটিক্যাল অ্যাপ্লিকেশান, ডাটাবেজ এর Drill Test করুন এবং তার একটি SOP তৈরি করে রাখুন। ডাটা রিকোভারীর বড় সাফল্য নির্ভর করে ড্রিল টেস্ট এর উপর যা অডিট কার্যক্রম এর জন্য গুরুত্বপূর্ণ।
৯। ব্যাকআপ যদি Tape এ হয় তবে Tape গুলো ডাটা পূর্ণ হয়ে যাবার পর লাইব্রেরী থেকে বের করে ভল্টে রাখুন এবং ব্যাকআপ অ্যাপ্লিকেশান এ সেটা আপডেট করুন। মনে রাখা প্রয়োজন কোন ব্যাকআপ অ্যাপ্লিকেশানই লাইব্রেরী থেকে বের করা Tape এর Location auto আপডেট করতে পারেনা। ভল্টে রাখা Tape এর লোকেশন আপডেট না করলে আপনি পরে ডাটা রিকোভারীর সময় বিপদে পড়বেন।
১০। Tape Backup সাধারণত Disk Backup এর চেয়ে চেয়ে ধীরগতির হয়। সূতরাং, খুব জরুরী ডাটাগুলো Disk এ এবং যে ডাটা রিকোভারী করতে সময় পাবেন তা Tape এ রাখুন। অবশ্যই প্রত্যেকটি ক্রিটিক্যাল ডাটাবেজ, অ্যাপ্লিকেশানের Full ব্যাকআপ Disk এ রাখার চেষ্টা করুন। লম্বা সময় যে ডাটাগুলো রাখতে হবে, প্রয়োজনে তা Tape এ রাখুন।
১১। ব্যাকআপ অ্যাপ্লিকেশান (ব্যাকআপ সার্ভার) সাধারণত দুই ধরনের লাইসেন্স ব্যবহার করতে পারে। একটি হলো ক্লায়েন্ট বেজ লাইসেন্স এবং অপরটি হলো কেপাসিটি বেইজ লাইসেন্স। ক্লায়েন্ট বেজ লাইসেন্স হলো প্রতিটি ক্লায়েন্টের জন্য একটি লাইসেন্স। আর কেপাসিটি বেইজ লাইসেন্স হলো কেপাসিটি পূর্ণ না হওয়া পর্যন্ত যত ইচ্ছা আপনি ক্লায়েন্ট এর ব্যাকআপ নিতে পারবেন।
১২। সাধারণত ব্যাকআপে যে সময় লাগে, রিষ্টোর (restore) করতে তার দ্বিগুণ সময় সময় লাগবে ধরে নেয়া যায়। তবে আরো কিছু বিষয় বিবেচনা করতে হবে, যে সার্ভার ও স্টোরেজে এর ডাটা ব্যাকআপ করা হয়েছে এবং যে সার্ভার ও স্টোরেজে রিষ্টোর (restore) করা হচ্ছে তা একই ধরনের কিনা বা তার পারফরমেন্স কাছাকাছি কিনা। অনেক সময় ডাটা একই সার্ভারে রিষ্টোর করার প্রয়োজন হয়, সেক্ষেত্রে দ্বিগুণ সময় লাগবে বলে আমরা ধরে নিতে পারি।
১৩। অধিকাংশ ব্যাকআপ অ্যাপ্লিকেশানে, পুর্বের ব্যাকআপের ডাটা রিটেনশন এখন নতুন করে বাড়ানো যায়। ধরা যাক একটি ব্যাকআপ ডাটা ২০১৮ সালের ডিসেম্বর মাসে শেষ হবে, কিন্তু অ্যাপ্লিকেশান অ্যাডমিন বা ডাটাবেস অ্যাডমিন চাচ্ছেন আরো ৬ মাস ডাটা থাকুক। সেক্ষেত্রে অই পুরানো ব্যাকআপের রিটেনশন আরো ৬ মাস বাড়ানো যাবে।
১৪। ব্যাকআপ প্ল্যান করার সময় দুটি কথা মাথায় রাখা প্রয়োজন। আপনি যে ব্যাকআপটি নিচ্ছেন তা কি ডিজাস্টার রিকভারির প্রয়োজনে নাকি compliance ও Regulatory প্রয়োজনে। সাধারণত যদি ডাটাবেস ও অ্যাপ্লিকেশন ব্যাকআপ ছোট হয় তবে প্রতিদিন Full Backup নিতে পারেন। যদি সেটা Disaster Recovery প্রয়োজনে হয়। কেননা এতে ডাটা restore ও রিকভারির সময় process গুলোকে অনেক সহজ করবে।
১৫। কোন অ্যাপ্লিকেশান বা ডাটাবেস এ মেজর চেঞ্জ রিকোয়েস্ট এর আগে অবশ্যই একটি Full ব্যাকআপ Disk এ রাখুন। অ্যাপ্লিকেশান, ডাটাবেজ ও ব্যাকআপ অ্যাডমিন একসাথে ডাটা ব্যাকআপ ও রিকোভারী প্ল্যান করা জরুরী।
১৬। ডাটা এনক্রিপশনে (Encryption) শব্দটি আপনি প্রায়ই শুনবেন, ব্যাকআপ ডাটাও Encryption করা প্রয়োজন হতে পারে, তবে মনে রাখতে হবে অধিকাংশ ব্যাকআপ অ্যাপ্লিকেশান এনক্রিপশনের (Encryption) জন্য লাইসেন্স কিনতে হয়। সাধারনত দুইটি কারনে মুলত ডাটা Encryption এর প্রয়োজন হয়, একটি হল ডাটা মুভমেন্ট এর প্রয়োজন হলে এবং অন্যটি হল নিরাপত্তা অডিট compliance জন্য।
১৭। ব্যাকআপ Tape স্থানান্তরের জন্য “Turtle Case” ব্যবহৃত হয় যা এর নিরাপত্তা ও দুর্ঘটনা হতে রক্ষা করে এবং এটি ব্যাকআপ compliance এর একটি অংশ।
১৮। অনেক ব্যাকআপ অ্যাপ্লিকেশন এ ডাটা ব্যাকআপ নেয়ার আগে Password Protected করে নেয়া যায়। এতে ব্যাকআপ ডাটা দেখার জন্য ও রিষ্টোর (Restore)করার জন্য ওই Password টি প্রয়োজন। তবে এ পদ্ধতিতে ব্যাকআপ নেয়া হলে তা নিরাপত্তা বৃদ্ধির পাশাপাশি জটিলতা বৃদ্ধি করে। কেননা তা রক্ষণাবেক্ষণ করার জন্য প্রত্যেকটি ব্যাকআপ ট্র্যাকিং করা প্রয়োজন।
১৯। প্রত্যেকটি ব্যাকআপ অ্যাপ্লিকেশানে নিজস্ব ডাটাবেজ আছে যাতে প্রত্যেকটি ব্যাকআপের বিস্তারিত সময়, ব্যকআপ কনটেন্ট, ব্যাকআপ টাইপ, ব্যাকআপ মিডিয়া বলা থাকে ফলে ডাটাবেসটি ব্যাকআপ অ্যাপ্লিকেশানের জন্য খুবই গুরুত্তপূর্ণ এবং এর নিরাপত্তাও জরুরী। অধিকাংশ ব্যাকআপ অ্যাপ্লিকেশান নিজে তার নিজের ডাটাবাসের ব্যাকআপ নিতে পারেনা, তাই ব্যাকআপ অ্যাপ্লিকেশানের গুরুত্তপূর্ণ ফাইলগুলো অন্যত্র ব্যাকআপ রাখার দায়িত্ব ব্যাকআপ অ্যাডমিনের।
২০। ব্যাকআপ অ্যাপ্লিকেশানের ব্যবহারকারীদের Access Control একটি গুরুত্তপূর্ণ বিষয়। যারা ব্যাকআপ অ্যাপ্লিকেশানে অ্যাডমিন হিসেবে থাকবেন তারা ব্যাকআপ অ্যাপ্লিকেশানের সকল Root Privilege পাবে। User Privilege ব্যাকআপ এডমিনরা ব্যাকআপ মনিটরিং এবং Start/Stop ধরনের কাজগুলো করতে পারবেন। মনিটরিং Privilege User রা সাধারণত Audit Member/ Senior Management হয়ে থাকে।
২১। আইটি অডিট কার্যক্রম এ ডাটা ব্যাকআপ একটি গুরুত্তপূর্ণ এবং জরুরী অংশ। Disaster Recovery (DR) Test, Media (Tape) Health Check, ব্যাকআপ ও রিষ্টোর(restore) লগ রাখা, ডাটা এনক্রিপশনের (Encryption), ব্যাকআপ ফেইল () হলে বিজনেস টিমকে জানানো কার্যক্রমসমূহ অডিটের জন্য গুরুত্তপূর্ণ।
বি. দ্র. : উপরের টিপস গুলো প্রতিষ্ঠান ও ব্যবসা নীতিমালার ভিত্তিতে পরিবর্তিত হতে পারে।
লেখকঃ মুহম্মদ মইনুল হোসেন (CISA, CISM, ISO 27001 Lead Auditor, ITIL)
আইটি অডিটর,
BGD e-GOV CIRT সক্ষমতা বৃদ্ধি প্রকল্প