র‍্যানসমওয়্যারের জন্য তৈরি ব্যাকআপ: ব্যবসার সিস্টেমে 3-2-1-1-0 নিয়ম

একটা বানানো দৃশ্য ভাবুন, কোনো আসল গ্রাহকের গল্প নয়। শুক্রবার, বিকেল ৪টা ৪০। ১৫ জনের একটা অনলাইন শপের মালিক তাঁর আইটি কনট্রাক্টরকে বললেন, গত রাতের backup-টা একটা বাড়তি server-এ restore করে দেখাতে। দুই বছরে কেউ এটা করেনি। কাজটা নিছক নিয়মরক্ষা বলেই ধরা হয়েছিল, কারণ জানুয়ারি থেকে প্রতিদিন সকালে backup dashboard-এ সবুজ টিক জ্বলছে।

এগারো মিনিটে restore শেষ হয়, আর order-এর টেবিল ফাঁকা। মার্চে ডিস্ক ভরে যাওয়ার পর থেকে রাতের জব অসম্পূর্ণ ডাম্প লিখছিল, তবু প্রতিবার "সফল" দেখিয়েছে, কারণ স্ক্রিপ্টের এক্সিট কোড কেউ দেখেনি। প্রতিটা টিক সত্যি ছিল: জব চলেছে। শুধু ফাইলটা আদৌ খোলা যায় কি না, সে প্রশ্ন কেউ কখনো করেনি।

যে backup কখনো restore করে দেখা হয়নি, সেটা আন্দাজ মাত্র, আর র‍্যানসমওয়্যার সেই আন্দাজকে ক্ষতিতে বদলে দেয়। admin password হাতে পাওয়া আক্রমণকারী কিছু এনক্রিপ্ট করার আগেই আপনার backup খুঁজে বের করে, তাই পুরোনো নিয়ম, অর্থাৎ দুই ধরনের মাধ্যমে তিনটা কপি আর একটা অন্য জায়গায়, এখন আর যথেষ্ট নয়। আজকের নিয়মে আরও দুটো সংখ্যা যোগ হয়েছে, আর সেগুলোই প্রথম তিনটার চেয়ে বেশি জরুরি।

এই লেখায় দেখব ছোট ব্যবসা কেন নিশানায় আসছে, বাস্তবে 3-2-1-1-0 মানে কী, প্রতিটি system-এর জন্য রিকভারির লক্ষ্য কীভাবে ঠিক করবেন, একটা বিজনেস অ্যাপ্লিকেশনের কী কী backup রাখতে হয়, আর সবকিছু ভেঙে পড়ার দিনের জন্য কীভাবে আগে থেকে মহড়া দেবেন।

ছোট ব্যবসা কেন নিশানায়

আক্রমণকারীরা ব্র্যান্ড দেখে শিকার বাছে না। তারা খোলা login, প্যাচ না করা network ডিভাইস আর একই password বারবার ব্যবহার করা account খুঁজে বেড়ায়, তারপর দেখে কী জালে উঠল। ছোট কোম্পানির দুর্বলতা বড়দের মতোই, শুধু সমস্যাটা ধরার মতো মানুষ অনেক কম।

পরিসংখ্যানও একই কথা বলে। Verizon-এর 2025 Data Breach Investigations Report অনুযায়ী বিশ্লেষণ করা data ব্রিচের 44%-এ র‍্যানসমওয়্যার ছিল, আগের বছর যা ছিল 32%। ছোট ও মাঝারি ব্যবসায় এই হার অনেক বেশি: ব্রিচের 88%-এ র‍্যানসমওয়্যার জড়িত ছিল, বড় প্রতিষ্ঠানে যেখানে 39%। একই report-এ দেখা গেছে, ভুক্তভোগীদের 64% মুক্তিপণ দেননি, আর দেওয়া অর্থের মাঝামাঝি অঙ্ক নেমে এসেছে প্রায় $115,000-এ।

শেষ তথ্যটা একই সঙ্গে ভালো খবর আর সতর্কবার্তা। মুক্তিপণ কম লোক দিচ্ছেন, কারণ বেশি লোক data ফিরিয়ে আনতে পারছেন। Sophos-এর State of Ransomware 2026 report-এ আক্রান্ত প্রতিষ্ঠানের 2,158 জন আইটি ও সিকিউরিটি প্রধানের জরিপে দেখা গেছে, যাদের data এনক্রিপ্ট হয়েছিল তাদের 66% backup থেকে data ফিরে পেয়েছেন, আগের বছরের চেয়ে 12 পয়েন্ট বেশি। তবু গড় রিকভারি বিল দাঁড়িয়েছে $1.7 million।

backup-ই যে ফলাফল ঠিক করে দেয়, আক্রমণকারীরা তা জানে। তাই তারা আগে backup-এ হাত দেয়। Sophos-এর আগের একটি গবেষণায় দেখা গেছে, আক্রান্ত প্রতিষ্ঠানগুলোর 94%-এর backup-এ তারা ঢোকার চেষ্টা করেছে, আর সেই চেষ্টার 57% সফল হয়েছে। যেখানে সফল হয়েছে, সেখানে ভুক্তভোগীর মুক্তিপণ দেওয়ার সম্ভাবনা প্রায় দ্বিগুণ হয়েছে, আর রিকভারির খরচ হয়েছে প্রায় আট গুণ। আক্রমণকারী যে backup-এ পৌঁছাতে পারে, সেটা backup নয়, আরেকটা টার্গেট।

3-2-1 থেকে 3-2-1-1-0

ক্লাসিক নিয়মটা সহজ: data-র 3টা কপি রাখুন, 2 ধরনের স্টোরেজে, আর 1টা কপি অন্য জায়গায়। হার্ডওয়্যার নষ্ট হওয়া, চুরি বা আগুনের বিরুদ্ধে এটা এখনও কাজ করে। কিন্তু একজন দক্ষ অনুপ্রবেশকারীর সামনে এতে একটা ফাঁক থেকে যায়, কারণ তিনটা কপিতেই সাধারণত একই ক্রেডেনশিয়াল দিয়ে ঢোকা যায়।

আধুনিক নিয়মে যোগ হয়েছে দুটো শর্ত:

• 1টা ইমিউটেবল বা অফলাইন কপি। এমন একটা কপি, যেটা রিটেনশন শেষ না হওয়া পর্যন্ত কেউ বদলাতে বা মুছতে পারে না: আপনার নিজের অ্যাডমিনরাও না, আর তাদের password হাতে পাওয়া আক্রমণকারীও না।
• 0টা ত্রুটি। কোনো backup তখনই গোনায় ধরা হবে, যখন তার restore test ত্রুটি ছাড়া শেষ হয়েছে। তার আগে সেটা শুধুই ভরসা।

সামান্য আয়োজনেই নিয়মটা মানা যায়। চালু database প্রথম কপি। আলাদা ডিস্ক বা server-এ রাতের ডাম্প দ্বিতীয় কপি। তৃতীয় কপি যায় অন্য কোনো প্রোভাইডারের অবজেক্ট স্টোরেজে, এমন ক্রেডেনশিয়ালে যা ফাইল যোগ করতে পারে কিন্তু মুছতে পারে না, আর সঙ্গে রিটেনশন লক চালু। এই তৃতীয় কপিই অফ-সাইট আর ইমিউটেবল, দুই শর্ত একসঙ্গে মেটায়।

ইমিউটেবিলিটি, সহজ ভাষায়

ইমিউটেবল backup হলো একবার লেখা, বারবার পড়া: ফাইল জমা হয়ে গেলে আপনার ঠিক করা তারিখ পর্যন্ত স্টোরেজ সার্ভিস নিজেই সেটা বদলাতে বা মুছতে দেয় না। Amazon S3-এ এই feature-এর নাম Object Lock, আর S3-সামঞ্জস্যপূর্ণ আরও কয়েকটা স্টোরেও একই নামে এটা পাওয়া যায়। এর দুটো মোড আছে, আর তফাতটা গুরুত্বপূর্ণ।

• Compliance মোড। রিটেনশনের তারিখ পার হওয়ার আগে লক করা ভার্সন কেউ মুছতে বা ওভাররাইট করতে পারে না, account-এর root user-ও না, আর মেয়াদ কমানোও যায় না।
• Governance মোড। বেশির ভাগ user অবজেক্ট মুছতে পারে না, কিন্তু বিশেষ permission থাকা user লক ওভাররাইড করতে পারে। কিছু না থাকার চেয়ে এটা ভালো, কিন্তু compliance মোডের চেয়ে দুর্বল, কারণ সঠিক permission পেলে আক্রমণকারীও এটা ব্যবহার করতে পারে।

বিস্তারিত আছে S3 Object Lock ডকুমেন্টেশনে। যে প্রোভাইডারই নিন, ভরসা করার আগে তিনটা জিনিস মিলিয়ে নিন: ভার্সনিং চালু আছে, লক মোড compliance (অথবা ওভাররাইডের permission এমন একজনের হাতে যিনি প্রতিদিনের admin নন), আর রিটেনশন এত লম্বা যে আক্রমণ টের পেতে আপনার যত সময় লাগতে পারে তার চেয়ে বেশি। অনুপ্রবেশ সপ্তাহের পর সপ্তাহ কারও নজরে না-ও আসতে পারে।

অবজেক্ট লক না থাকলে অফলাইন কপি একই কাজ করে: যে এক্সটার্নাল ড্রাইভ বা টেপ backup-এর মাঝখানে খুলে রাখা থাকে, অথবা পুল-ভিত্তিক backup server, যেটা নিজে গিয়ে data টেনে আনে, ফলে প্রোডাকশন system-এর কাছে backup-এর কোনো ক্রেডেনশিয়ালই থাকে না।

প্রতিটি system-এর জন্য রিকভারির লক্ষ্য ঠিক করুন

backup-এর প্রতিটা সিদ্ধান্ত দুটো সংখ্যার ওপর দাঁড়িয়ে। RPO (recovery point objective) হলো সময়ের হিসাবে আপনি কতটা সাম্প্রতিক data হারাতে পারেন। RTO (recovery time objective) হলো কতক্ষণ বন্ধ থাকা আপনার পক্ষে সহ্য করা সম্ভব। এগুলো আগে ব্যবসায়িক সিদ্ধান্ত, পরে টেকনিক্যাল সেটিং, আর সিস্টেমভেদে আলাদা।

order-এর উদাহরণটাই সবচেয়ে পরিষ্কার। ঘণ্টায় একশো order নেওয়া অনলাইন স্টোর একদিনের order হারাতে পারে না, কারণ গ্রাহকের কাছ থেকে টাকা কাটা হয়ে গেছে অথচ মেলানোর মতো কিছু আর নেই। পুরোনো ব্রোশিয়ারের শেয়ার্ড ফোল্ডার এক সপ্তাহ অপেক্ষা করতে পারে। লক্ষ্য ঠিক করুন এই প্রশ্ন করে: প্রতি ঘণ্টা data হারালে বা system বন্ধ থাকলে কত খরচ হয়?

স্তর	উদাহরণ	লক্ষ্য RPO	লক্ষ্য RTO	পদ্ধতি
স্তর ১: চলমান টাকা	order, payment, stock ledger, অ্যাকাউন্টিং	৫–১৫ মিনিট	১–৪ ঘণ্টা	ক্রমাগত লগ shipping বা ঘন ঘন ইনক্রিমেন্টাল ডাম্প, সঙ্গে প্রতিদিনের ইমিউটেবল ফুল কপি
স্তর ২: দৈনন্দিন কাজ	customer, HR ও payroll, supplier-এর রেকর্ড, আপলোড করা ফাইল	২৪ ঘণ্টা	৮–২৪ ঘণ্টা	রিটেনশন লকসহ অফ-সাইট স্টোরেজে রাতের স্ন্যাপশট
স্তর ৩: কাজের ফাইল	ডকুমেন্ট, এক্সপোর্ট, report, মিডিয়া লাইব্রেরি	২৪ ঘণ্টা	২–৩ দিন	ডিলিট প্রটেকশনসহ ভার্সনড অবজেক্ট স্টোরেজ
স্তর ৪: আর্কাইভ	পুরোনো invoice, বন্ধ হওয়া অর্থবছর, আইনি রেকর্ড	১ সপ্তাহ	১ সপ্তাহ	মাসিক ইমিউটেবল কপি, দীর্ঘ রিটেনশন, এনক্রিপ্টেড

এই সংখ্যাগুলো উদাহরণ হিসেবে শুরুর বিন্দু, কোনো স্ট্যান্ডার্ড নয়। আপনার সংখ্যা আসবে আপনার নিজের ডাউনটাইমের খরচ থেকে। আসল কথা হলো, প্রতিটা system-এর একটা স্তর থাকতে হবে, আর সেটা লিখে রাখতে হবে।

বিজনেস অ্যাপ্লিকেশনের কী কী backup রাখবেন

database ডাম্পের কথাই সবার আগে মনে আসে, কিন্তু একা সেটাই যথেষ্ট হয় কদাচিৎ। restore করা system চালু না হলে নিচের কোনো একটা সম্ভবত বাদ পড়েছিল।

• database। চালু data ফাইল কপি না করে সামঞ্জস্যপূর্ণ ডাম্প বা স্ন্যাপশট নিন, আর সঙ্গে স্কিমা মাইগ্রেশনের ভার্সন রাখুন।
• আপলোড করা ফাইল। product-এর ছবি, invoice, অ্যাটাচমেন্ট আর ডকুমেন্ট সাধারণত database-এর বাইরে থাকে। ফাইল ছাড়া database restore করলে সবখানে ভাঙা link দেখা যায়।
• কনফিগারেশন। এনভায়রনমেন্ট ফাইল, শিডিউলড জবের সংজ্ঞা, server ও প্রক্সির কনফিগারেশন, payment ও courier-এর সেটিং।
• সিক্রেট ও কী। অ্যাপ্লিকেশন কী, encryption কী, সাইনিং কী। অ্যাপ্লিকেশন কী ছাড়া নিখুঁত database backup-এর এনক্রিপ্টেড কলামগুলো পড়াই যায় না। এগুলো যে data সুরক্ষা করে, তার থেকে আলাদা জায়গায় রাখুন।
• লাইসেন্স ও integration। লাইসেন্স ফাইল, webhook সিক্রেট, API ক্রেডেনশিয়াল, ডোমেইন আর DNS রেকর্ড। চাপের মধ্যে এগুলো নতুন করে বানাতে কয়েক ঘণ্টা চলে যায়।
• পুনর্গঠনের রেসিপি। ছোট একটা নথি, যাতে লেখা থাকবে software-এর কোন ভার্সন, কোন server ইমেজ আর কোন ধাপে শূন্য থেকে system দাঁড় করানো যায়।

প্রতিটা কপি network-এর বাইরে যাওয়ার আগেই এনক্রিপ্ট করুন, আর encryption কী রাখুন এমন জায়গায়, যেখানে backup স্টোরেজ পৌঁছাতে পারে না। চুরি যাওয়া backup মানেই data ব্রিচ, আর অনেক দেশে সেটা জানানো আইনত বাধ্যতামূলক।

চাবিগুলো আলাদা রাখুন

দুর্বল জায়গাটা সাধারণত প্রযুক্তি নয়, আলাদা করে না রাখা। চারটা নিয়ম মানলেই অনেকটা পথ নিরাপদ হয়:

1. ইমিউটেবল কপির জন্য স্টোরেজ প্রোভাইডারে আলাদা account খুলুন, আদর্শভাবে ভিন্ন মালিকের login-এ, নিজস্ব মাল্টি-ফ্যাক্টর অথেনটিকেশনসহ।
2. প্রোডাকশন server-কে দিন শুধু-লেখার ক্রেডেনশিয়াল: সে backup যোগ করতে পারবে, আর কিছু নয়। তালিকা দেখা, পড়া, বদলানো বা মোছা, কিছুই না।
3. backup স্টোরেজের admin ক্রেডেনশিয়াল password ম্যানেজার আর সিঙ্গেল সাইন-অনের বাইরে রাখুন, কারণ আক্রান্ত ল্যাপটপ দিয়ে আক্রমণকারী সেখানে পৌঁছে যায়।
4. backup-সংক্রান্ত ঘটনায় alert রাখুন: জব ব্যর্থ হওয়া, মোছার চেষ্টা, রিটেনশন বদলানো, কিংবা কোনো নতুন backup ছাড়াই একটা পুরো দিন পার হওয়া।

রিটেনশন: কত পেছনে যাবেন

শুধু গত রাতের backup রাখা বিপজ্জনক, কারণ নীরব অনুপ্রবেশ কয়েক সপ্তাহের পুরোনো হতে পারে, আর গত রাতের কপিতেই হয়তো ক্ষতি ঢুকে গেছে। বেশির ভাগ ছোট ও মাঝারি ব্যবসার জন্য একটা বাস্তবসম্মত ছক হলো: ৩০ দিন পর্যন্ত দৈনিক কপি, তিন মাস পর্যন্ত সাপ্তাহিক কপি, আর এক বছর বা আপনার হিসাবরক্ষক ও স্থানীয় আইন যতদিন চায় ততদিন মাসিক কপি। রিকভারির বিলের তুলনায় স্টোরেজ অনেক সস্তা।

রিটেনশন আপনাকে নিজেদের ভুল থেকেও বাঁচায়। কেউ ভুল করে product catalog মুছে ফেলল, কেউ ভুল স্প্রেডশিট ইমপোর্ট করল, কোনো বাগে একমাসের দাম নষ্ট হলো। restore পয়েন্টের ইতিহাস থাকলে এগুলো বিপর্যয় থাকে না, হয়ে যায় এক বিকেলের কাজ।

restore ড্রিল থাকুক ক্যালেন্ডারে

3-2-1-1-0-র শেষ "0"-টা বেশির ভাগ দলই বাদ দিয়ে যায়। যে backup কখনো restore করা হয়নি, সেটা কাজ করবে কি না কেউ জানে না। ফাইল হয়তো খালি, কী হয়তো হারানো, আর restore হয়তো তিন ঘণ্টার বদলে ৩০ ঘণ্টা নেবে। এটা জানার সবচেয়ে ভালো সময় একটা শান্ত মঙ্গলবার।

ছোট করে শুরু করুন, তারপর অভ্যাসে পরিণত করুন। প্রতি সপ্তাহে সবচেয়ে নতুন database backup একটা অস্থায়ী পরিবেশে নিজে থেকে restore হোক, আর কয়েকটা যাচাইয়ের query চলুক। প্রতি মাসে একটা ফাইল সেট ফিরিয়ে এনে কয়েকটা ফাইল খুলে দেখুন। প্রতি তিন মাসে একটা পরিষ্কার server-এ পুরো system নতুন করে বানিয়ে সময় মাপুন। বছরে একবার টেবিলটপ অনুশীলন করুন, যেন মূল server নেই আর পুরোনোটায় কেউ ঢুকতে পারছে না।

প্রতিটা ফলাফল লিখে রাখুন: তারিখ, কী restore করলেন, কত সময় লাগল, কী ভুল হলো। কোনো ড্রিল প্রতিশ্রুত RTO-র চেয়ে বেশি সময় নিলে হয় পরিকল্পনা বদলান, নয় প্রতিশ্রুতি। যে শিডিউলার স্ন্যাপশট নেয়, রিটেনশন প্রয়োগ করে আর এক ধাপে পরিষ্কার জায়গায় restore করে, তাতে ড্রিল চালানো অনেক সস্তা হয়ে যায়। নিচের ছোট ভিডিওতে দেখুন এর একটা self-hosted উদাহরণ, StoreConsole-এর Backups module, ঠিক এই চক্রটাই চালাচ্ছে।

এক পাতার ইনসিডেন্ট রানবুক

প্রথম কয়েকটা সিদ্ধান্তের ক্রম যেকোনো একটা ধাপের চেয়ে বেশি গুরুত্বপূর্ণ। প্রতিটা restore-এর আগে দুটো প্রশ্নের উত্তর লাগে: backup কি অক্ষত আর আক্রমণকারীর নাগালের বাইরে, আর restore পয়েন্টটা কি অনুপ্রবেশের আগের? ফ্লোচার্টে পুরো পথটা দেখুন, তার নিচের তালিকাটা প্রিন্ট করে রাখার মতো সংক্ষিপ্ত রূপ।

র‍্যানসমওয়্যার আঘাত হানলে প্রথম ঘণ্টায় মানুষ সবচেয়ে খারাপ সিদ্ধান্তগুলো নেয়। তাই রানবুক লিখে রাখুন শান্ত অবস্থায়, প্রিন্ট করুন, আর একটা কপি রাখুন network-এর বাইরে। সংক্ষিপ্ত রূপটা এরকম:

1. আলাদা করুন। আক্রান্ত মেশিন network আর backup স্টোরেজ থেকে বিচ্ছিন্ন করুন। মেমোরির প্রমাণ লাগতে পারে ভেবে মেশিন বন্ধ করবেন না।
2. সঠিক মানুষদের ডাকুন। আগে থেকে নাম ঠিক রাখুন: দায়িত্বপ্রাপ্ত ব্যক্তি, আইটি যোগাযোগ, বিমা প্রতিষ্ঠান, আইনজীবী, আর যিনি গ্রাহকদের সঙ্গে কথা বলবেন।
3. backup রক্ষা করুন। একটা নিরাপদ ডিভাইস থেকে সব backup ক্রেডেনশিয়াল বদলান, আর ইমিউটেবল কপি অক্ষত আছে কি না নিশ্চিত করুন।
4. ঢোকার পথ খুঁজুন। restore-এর আগে বের করুন আক্রমণকারী কীভাবে ঢুকেছিল, আর পথটা বন্ধ করুন, নইলে কয়েক দিনের মধ্যে আবার এনক্রিপ্ট হবেন।
5. স্তর অনুযায়ী restore করুন। পরিষ্কার ইমেজ থেকে system গড়ুন, স্তর ১ restore করে যাচাই করুন, তারপর তালিকা ধরে নিচে নামুন।
6. সব সিক্রেট বদলান। password, API কী, token, আর নিরাপদ হলে অ্যাপ্লিকেশন কী।
7. জানান ও পর্যালোচনা করুন। আইনে যেখানে বাধ্যতামূলক, সেখানে নিয়ন্ত্রক সংস্থা ও আক্রান্ত গ্রাহকদের জানান, তারপর লিখে রাখুন কী কী বদলাবেন।

সরকারি নির্দেশিকা প্রয়োজনের আগেই পড়ে রাখার মতো। যুক্তরাষ্ট্রের CISA-র StopRansomware সংকলনে একটা বাস্তবসম্মত রেসপন্স চেকলিস্ট আছে, যা যুক্তরাষ্ট্রের বাইরেও বেশ কাজে লাগে।

এবার সেই শুক্রবারটাই আবার কল্পনা করুন, তবে উপদেশগুলো মানা হয়েছে। প্রতি সোমবার সকাল ৬টায় system নিজেই সবচেয়ে নতুন ডাম্প একটা অস্থায়ী database-এ restore করে, আর order-এর সংখ্যা প্রোডাকশনের সঙ্গে মেলায়। মার্চে চেকটা ফেল করে, আর একটা email আসে: order ০, প্রত্যাশিত প্রায় ৪,২০০। মালিক চা খেতে খেতে email-টা পড়েন, কনট্রাক্টর এক ঘণ্টার মধ্যে স্ক্রিপ্ট ঠিক করে দেন, আর তার পেছনে লক করা বাকেটে পড়ে থাকে এমন একটা কপি, যেটা লেখা হয়েছে শুধু ফাইল যোগ করা যায় এমন চাবিতে। যে আবিষ্কার শুক্রবার বিকেলের বিপদ হতে পারত, সেটা হয়ে গেল সোমবার সকালের একটা email।

মূল কথা

• আক্রমণকারীরা আগে backup-এ হাত দেয়। আপনার সাধারণ admin ক্রেডেনশিয়ালে যে কপিতে পৌঁছানো যায়, বাকি সবকিছুর সঙ্গে সেটাও এনক্রিপ্ট বা মুছে যাবে।
• 3-2-1-1-0 মানুন: তিন কপি, দুই মাধ্যম, এক অফ-সাইট, এক ইমিউটেবল বা অফলাইন, আর restore test-এ শূন্য ত্রুটি।
• প্রতিটি system-এর RPO ও RTO ঠিক করুন ডাউনটাইমের খরচ দেখে, কনফিগার করতে যেটা সুবিধাজনক তা দেখে নয়।
• শুধু database নয়: ফাইল, কনফিগারেশন, সিক্রেট, লাইসেন্স আর লিখিত পুনর্গঠনের রেসিপিও backup-এ রাখুন, সবই এনক্রিপ্টেড।
• আলাদা account, শুধু-লেখার ক্রেডেনশিয়াল, আর অনুপ্রবেশকারীর লুকিয়ে থাকার সময়ের চেয়ে লম্বা রিটেনশন ইমিউটেবল কপিকে নিরাপদ রাখে।
• restore ড্রিল ক্যালেন্ডারে রাখুন, ফলাফল লিখে রাখুন। backup-এর প্রমাণ restore, সবুজ টিক চিহ্ন নয়।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।