Backup কৌশল: ৩-২-১ নিয়ম ও restore পরীক্ষা

Server নষ্ট হয়, disk মরে, মানুষ ভুল জিনিস মুছে ফেলে, আর ransomware আছে। ভালো backup-ই একমাত্র জিনিস যা এসব বিপর্যয়কে খারাপ একটি বিকেলে নামিয়ে আনে।

৩-২-১ নিয়ম

• ৩ কপি data (আসলটি আর দুটি backup)।
• ২ ভিন্ন ধরনের storage বা সিস্টেম।
• ১ কপি বাইরে (offsite), অন্য জায়গা বা provider-এ।

একই disk বা একই server-এ backup সেই ব্যর্থতাগুলো থেকে বাঁচায় না যেগুলো আসলে ঘটে। কিছু দল একটি immutable বা offline কপিও রাখে, যাতে ransomware বা হ্যাক হওয়া অ্যাকাউন্ট তা মুছতে না পারে।

আগে দুটি সংখ্যা ঠিক করুন

• RPO (recovery point objective): কতটা data হারানো সইতে পারবেন। এক ঘণ্টা হলে অন্তত ঘণ্টায় একবার backup লাগবে।
• RTO (recovery time objective): কতক্ষণ বন্ধ থাকতে পারবেন। এটি ঠিক করে কীভাবে restore করবেন ও কতটা স্বয়ংক্রিয় করবেন।

কী backup নেবেন

• Database (সবচেয়ে গুরুত্বপূর্ণ)।
• ব্যবহারকারীর upload ও media।
• Configuration ও secret (নিরাপদে রেখে): service ফাইল, web server config, environment variable-এর নাম এবং কীভাবে আবার বানাবেন।
• কোড Git-এ আছে, যা-ও একটি backup। কীভাবে deploy করবেন লিখে রাখুন।
• যা আবার বানানো কঠিন। cache ও node_modules-এর মতো সহজে বানানো যায় এমন জিনিস বাদ দিন।

Database সঠিকভাবে backup

চলমান database-এর ফাইল কপি করলে ভাঙা backup হতে পারে। সঠিক টুল ব্যবহার করুন:

• PostgreSQL: logical backup-এর জন্য pg_dump; সূক্ষ্মতর recovery-র জন্য WAL archiving বা managed service-এর point-in-time recovery।
• MySQL: mysqldump বা সামঞ্জস্যপূর্ণ snapshot।
• SQLite: .backup কমান্ড বা VACUUM INTO, লেখার সময় সাধারণ কপি নয়।
• অনেক managed database স্বয়ংক্রিয় backup ও point-in-time restore দেয়। Retention দেখুন এবং তবু পরীক্ষা করুন।

Full, incremental ও snapshot

• Full: প্রতিবার সবকিছু। সহজ, বড়।
• Incremental: শেষ backup-এর পর শুধু বদল। বানাতে ছোট ও দ্রুত, restore একটু জটিল।
• Snapshot (disk বা filesystem): দ্রুত, কাজের, কিন্তু একই disk ছাড়া অন্য কোথাও রাখুন।
• restic ও borg-এর মতো টুল অনেক গন্তব্যে encrypted, deduplicated, incremental backup করে।

Backup নিজেকে সুরক্ষিত রাখুন

• Encrypt করুন এবং key আলাদা জায়গায় রাখুন। সব secret খোলা অবস্থায় থাকা backup দ্বিতীয় ফাঁসের অপেক্ষা।
• সম্ভব হলে এমন credential ব্যবহার করুন যা backup লিখতে পারে কিন্তু পুরোনো মুছতে পারে না।
• কে পড়তে পারবে সীমিত করুন। এগুলোকে ভেতরের production data-র মতোই দেখুন।

Retention ও স্বয়ংক্রিয়তা

• কয়েক প্রজন্ম রাখুন, যেমন এক সপ্তাহের দৈনিক, এক মাসের সাপ্তাহিক, এক বছরের মাসিক।
• Timer বা scheduler দিয়ে স্বয়ংক্রিয় করুন এবং backup ব্যর্থ বা অনুপস্থিত হলে alert পান। নীরব ব্যর্থতাই সাধারণ উপায় যাতে মানুষ জানে তাদের backup নেই।
• আকার লক্ষ্য রাখুন যাতে backup disk ভরে না ফেলে।

Restore পরীক্ষা করুন

এই ধাপটাই মানুষ বাদ দেয়। নিয়মিত:

১. সর্বশেষ backup আলাদা মেশিন বা database-এ restore করুন। ২. তার বিরুদ্ধে অ্যাপ চালিয়ে data ঠিক দেখাচ্ছে কি না দেখুন। ৩. সময় মাপুন এবং RTO-র সাথে তুলনা করুন। ৪. ধাপগুলো runbook-এ লিখে রাখুন।

সবচেয়ে খারাপ অবস্থাও অনুশীলন করুন: server নেই, শুধু backup আর আপনার নোট দিয়ে আবার বানাতে হবে।

মূল কথা: দুই ধরনের storage-এ তিন কপি রাখুন, একটি বাইরে; সঠিক টুলে database backup নিন; কপিগুলো encrypt ও সুরক্ষিত রাখুন; ব্যর্থতায় alert পান; এবং কাজ করে কি না প্রমাণ করতে নিয়মিত restore করুন।

---

Linux ও DevOps সিরিজ, পর্ব ২ (delivery ও পরিচালনা): 4 নম্বর (মোট 5)। আগের লেখা: Monitoring-এর গোড়া: metrics, Prometheus, Grafana ও alert.