আপনার অ্যাপের ডেটাবেস কীভাবে ব্যাকআপ নেবেন (এবং সত্যিই রিস্টোর করবেন)

আপনার অ্যাপের ডেটাবেস ব্যাকআপ নিতে হলে নির্দিষ্ট সময়ে এটি একটি ফাইলে এক্সপোর্ট করুন (Postgres-এর জন্য স্ট্যান্ডার্ড টুল হলো pg_dump), কপিগুলো ডেটাবেস থেকে আলাদা জায়গায় রাখুন, আর নিয়মিত একটি ব্যাকআপ খালি ডেটাবেসে রিস্টোর করে দেখুন সেটি সত্যিই কাজ করে কি না। কোনো ঝুঁকিপূর্ণ পরিবর্তনের ঠিক আগে আরেকটি অতিরিক্ত ব্যাকআপ নিন। আপনার কোড ব্যাকআপ, সেটা GitHub রিপোজিটরি হোক বা এক্সপোর্ট, তাতে আপনার ডেটা থাকে না।

এই গাইডটি তাদের জন্য যারা একটি ছোট অ্যাপ চালান এবং সেটি হারানোর ভয় থেকে মুক্ত থাকতে চান। উদাহরণে Postgres ব্যবহার করা হয়েছে, কারণ বেশিরভাগ AI-তৈরি অ্যাপই এটি ব্যবহার করে, তবে মূলনীতিগুলো যেকোনো ডেটাবেসেই প্রযোজ্য।

ব্যাকআপের কী কী কভার করা উচিত

একটি অ্যাপ শুধু তার ডেটাবেসের চেয়ে বেশি কিছু। প্রতিটি ব্যাকআপ কোন অংশ রক্ষা করছে সেটি জানুন।

ডেটাই সেই অংশ যা আপনি আবার তৈরি করতে পারবেন না। কোড আবার লেখা যায়, সেটিংস আবার দেওয়া যায়; কিন্তু আপনার গ্রাহকদের অর্ডার আর ফেরত আসে না।

ধাপ ১: কতটুকু ডেটা হারাতে পারবেন তা ঠিক করুন

দুটি প্রশ্ন আপনার ব্যাকআপ পরিকল্পনা ঠিক করে:

• সাম্প্রতিক কতটুকু ডেটা হারাতে পারবেন? যদি দিনে একবার ব্যাকআপ নেন আর সন্ধ্যায় ডেটাবেস নষ্ট হয়, তাহলে সেদিনের পরিবর্তন হারাবেন। একটি শখের অ্যাপের জন্য এটি ঠিক আছে। যে অ্যাপে অর্ডার নেওয়া হয়, তার জন্য হয়তো নয়।
• রিস্টোর করার সময় অ্যাপ কতক্ষণ বন্ধ থাকতে পারে? একটি ছোট ডেটাবেস কয়েক মিনিটে রিস্টোর হয়। বড় ডেটাবেসে অনেক বেশি সময় লাগতে পারে, আর প্রয়োজনের আগেই সেটি জেনে রাখা ভালো।

বেশিরভাগ ছোট অ্যাপের জন্য প্রতিদিনের স্বয়ংক্রিয় ব্যাকআপ এবং ঝুঁকিপূর্ণ পরিবর্তনের আগে একটি ম্যানুয়াল ব্যাকআপ একটি ভালো শুরু। টাকা-পয়সা বা স্বাস্থ্যের ডেটা জড়িত অ্যাপের জন্য আরও ঘন ঘন ব্যাকআপ, অথবা পয়েন্ট-ইন-টাইম রিকভারি (যেকোনো মুহূর্তে রিস্টোর করার সুবিধা, শুধু শেষ ব্যাকআপে নয়) সহ একটি ম্যানেজড ডেটাবেস দরকার।

ধাপ ২: আপনার হোস্ট আগে থেকে কী করে তা দেখুন

অনেক ম্যানেজড ডেটাবেস প্রোভাইডার নিজে থেকেই স্বয়ংক্রিয় ব্যাকআপ নেয়। খুঁজে দেখুন:

• আপনার প্ল্যানে ব্যাকআপ চালু আছে কি না, এবং কত ঘন ঘন চলে?
• কতদিন পর্যন্ত রাখা হয়?
• কোনো নির্দিষ্ট সময়ের মুহূর্তে রিস্টোর করা যায়, নাকি শুধু দৈনিক স্ন্যাপশটে?
• ব্যাকআপ ডাউনলোড করা যায়, নাকি শুধু তাদের সিস্টেমের ভেতরেই রিস্টোর করা যায়?

প্রোভাইডারের ব্যাকআপ কাজের, তবে তার একটি সাধারণ দুর্বলতা আছে: ডেটাবেসের সাথে একই অ্যাকাউন্ট ভাগ করে। অ্যাকাউন্ট বন্ধ, স্থগিত বা প্রজেক্ট মুছে গেলে ব্যাকআপও সাথে চলে যেতে পারে। তাই নিজের একটি কপিও রাখা দরকার।

ধাপ ৩: pg_dump দিয়ে ডাম্প তৈরি করুন

pg_dump একটি Postgres ডেটাবেসকে ফাইলে এক্সপোর্ট করে। এটি একটি সামঞ্জস্যপূর্ণ স্ন্যাপশট পড়ে, তাই টুলটি কাজ করার সময়ও অ্যাপ চলতে পারে।

একটি সাধারণ কমান্ড, যেখানে আপনার অ্যাপের আগে থেকেই থাকা এনভায়রনমেন্ট ভেরিয়েবল থেকে কানেকশন স্ট্রিং নেওয়া হচ্ছে:

pg_dump "$DATABASE_URL" --format=custom --no-owner --file=backup-2026-09-29.dump

অপশনগুলো যা করে:

• --format=custom একটি কমপ্রেসড ফাইল লেখে যা pg_restore পড়তে পারে, এবং পরে আলাদা টেবিল রিস্টোর করার সুবিধা দেয়। পড়া যায় এমন .sql ফাইল চাইলে --format=plain ব্যবহার করুন।
• --no-owner মালিকানা-সংক্রান্ত কমান্ড বাদ দেয়, ফলে অন্য ডেটাবেসে রিস্টোর করা সহজ হয়।
• ফাইলের নামে থাকা তারিখ ব্যাকআপগুলোকে আলাদা রাখে।

pg_dump-এর ভার্সন আপনার ডেটাবেসের Postgres ভার্সনের সমান বা নতুন হওয়া উচিত। পুরোনো pg_dump চালাতে অস্বীকার করতে পারে।

আপনি AI দিয়ে তৈরি করলে এবং কমান্ড লাইনে হাত না দিতে চাইলে এভাবে বলতে পারেন:

pg_dump ব্যবহার করে custom ফরম্যাটে অ্যাপের ডেটাবেসের একটি ব্যাকআপ তৈরি করো, ফাইলের নামে আজকের তারিখ দাও। কোনো কানেকশন স্ট্রিং বা সিক্রেট প্রিন্ট কোরো না। শেষ হলে আমাকে ফাইলের নাম আর সাইজ জানাও।

ধাপ ৪: স্বয়ংক্রিয় করুন

ম্যানুয়াল ব্যাকআপ মনে থাকে না। আপনার সেটআপ যা সমর্থন করে তা দিয়ে এটি স্বয়ংক্রিয় করুন:

• আপনার ডেটাবেস প্রোভাইডারের নির্ধারিত ব্যাকআপ, যদি তারা দেয়।
• একটি নির্ধারিত জব একটি সার্ভার বা CI সার্ভিসে, যা pg_dump চালিয়ে ফাইলটি স্টোরেজে আপলোড করে।
• একটি হোস্টেড ব্যাকআপ সার্ভিস, যা আপনার ডেটাবেসের সাথে সংযুক্ত হয়।

যেটাই বেছে নিন, নিশ্চিত করুন ব্যাকআপ ব্যর্থ হলে সেটি আপনাকে জানায়। যে ব্যাকআপ জব তিন মাস ধরে নীরবে ব্যর্থ হচ্ছে, সেটিই সবচেয়ে পরিচিত ভয়ের গল্প।

ধাপ ৫: কপি অন্য জায়গায় রাখুন

একটি সাধারণ নিয়মকে প্রায়ই বলা হয় 3-2-1: তিনটি কপি, দুই ধরনের স্টোরেজে, আর একটি সাইটের বাইরে। একটি ছোট অ্যাপের জন্য ব্যবহারিক রূপটি হলো:

• লাইভ ডেটাবেস
• প্রোভাইডারের নিজস্ব স্বয়ংক্রিয় ব্যাকআপ
• আপনার নিজের ডাম্প, ভিন্ন অ্যাকাউন্টে থাকা অবজেক্ট স্টোরেজ বাকেটে

এছাড়াও:

• অ্যাক্সেস সীমিত করুন। একটি ব্যাকআপে প্রতিটি ব্যবহারকারীর ডেটা থাকে। এটিকে লাইভ ডেটাবেসের মতোই গণ্য করুন।
• একটি রিটেনশন নীতি রাখুন। উদাহরণস্বরূপ, দৈনিক ব্যাকআপ দুই সপ্তাহ আর মাসিক ব্যাকআপ এক বছর। পুরোনো ব্যাকআপ ইচ্ছাকৃতভাবে মুছুন, এবং মনে রাখবেন গোপনীয়তা আইন অনুযায়ী অনুরোধে ব্যক্তিগত ডেটা মুছতে হতে পারে।
• কখনো Git-এ ব্যাকআপ কমিট করবেন না। রিপোজিটরিতে একটি ডাম্প মানেই ডেটা ফাঁসের অপেক্ষায় থাকা একটি ঝুঁকি।

ধাপ ৬: রিস্টোর পরীক্ষা করুন

একটি ব্যাকআপ ততটুকুই ভালো যতটুকু আপনার শেষ সফল রিস্টোর। অন্তত প্রতি কয়েক মাসে, এবং ব্যাকআপ প্রক্রিয়ায় কোনো পরিবর্তনের পরে:

1. একটি নতুন, খালি ডেটাবেস তৈরি করুন। পরীক্ষা করতে কখনো লাইভটির উপর রিস্টোর করবেন না।
2. সর্বশেষ ব্যাকআপটি সেখানে রিস্টোর করুন:

pg_restore --no-owner --dbname="$TEST_DATABASE_URL" backup-2026-09-29.dump

সাধারণ .sql ফাইলের জন্য বদলে ব্যবহার করুন psql "$TEST_DATABASE_URL" -f backup.sql।

1. সব টেবিল আছে কি না দেখুন, লাইভ ডেটাবেসের সাথে রো সংখ্যা তুলনা করুন, আর কয়েকটি সাম্প্রতিক রেকর্ড দেখুন।
2. যদি পারেন, অ্যাপের একটি কপি এটির সাথে সংযুক্ত করে লগইন করে দেখুন।
3. রিস্টোরে কত সময় লাগল লিখে রাখুন। সেটিই আপনার প্রকৃত রিকভারি সময়।

ধাপ ৭: ঝুঁকিপূর্ণ পরিবর্তনের আগে ব্যাকআপ নিন

নিচের কাজগুলোর ঠিক আগে একটি নতুন ব্যাকআপ নিন:

• কলাম ড্রপ বা নাম বদলায় এমন ডেটাবেস মাইগ্রেশন চালানো
• বাল্ক ইমপোর্ট করা
• কোনো AI এজেন্টকে ডেটা মডেলে বড় পরিবর্তন করতে দেওয়া
• পুরোনো রেকর্ড মুছে ফেলা

AI-তৈরি অ্যাপে, একটি ফিচারের অংশ হিসেবে এজেন্ট টেবিলের কাঠামো বদলে দিতে পারে। চেকপয়েন্ট ও ভার্সন কন্ট্রোল আপনার কোড ফেরত আনতে পারে, কিন্তু মুছে যাওয়া রো ফিরিয়ে আনে না। বড় পরিবর্তনের আগে ত্রিশ সেকেন্ডের একটি ব্যাকআপ একটি সস্তা বিমা।

সাধারণ ভুলসমূহ

• ধরে নেওয়া যে Git বা কোড এক্সপোর্ট একটি ব্যাকআপ। এতে কোড থাকে, ডেটা থাকে না।
• কখনো রিস্টোর পরীক্ষা না করা। অনেক ব্যাকআপ প্রয়োজনের সময়ই দেখা যায় খালি, অসম্পূর্ণ বা পড়া যায় না।
• ব্যাকআপ ডেটাবেসের একই অ্যাকাউন্টে রাখা। একটি আপসযুক্ত বা বন্ধ হওয়া অ্যাকাউন্ট দুটোই হারায়।
• আপলোড করা ফাইল ভুলে যাওয়া। ডেটাবেসে ফাইলের পাথ থাকে; ছবিটি থাকে স্টোরেজে।
• ব্যাকআপ স্ক্রিপ্টে সিক্রেট রাখা। কানেকশন স্ট্রিং স্ক্রিপ্টের লেখা থেকে নয়, এনভায়রনমেন্ট ভেরিয়েবল থেকে পড়ুন। দেখুন কীভাবে API কী নিরাপদ রাখবেন।

ব্যাকআপ এবং Mythex

Mythex প্রজেক্টে একটি নির্দিষ্ট Postgres ডেটাবেস থাকতে পারে, এবং এর কানেকশন তথ্য ওয়ার্কস্পেস ও প্রকাশিত অ্যাপে ইনজেক্ট করা হয়। Mythex ডক্সে ডেটাবেস ব্যাকআপ বা রিস্টোর ফিচারের বর্ণনা নেই, তাই নিজের পরিকল্পনা নিজে করুন: এজেন্টকে একটি ডাম্প তৈরি করতে বলুন, সেটি ডাউনলোড করুন এবং নিরাপদ জায়গায় রাখুন, বিশেষ করে বড় পরিবর্তনের আগে। একটি প্রজেক্ট এক্সপোর্ট (Pro) আপনার কোড ধারণ করে, যেখানে সিক্রেট ও node_modules বাদ থাকে; এতে ডেটাবেসের রো থাকে না। দেখুন ডক্সের Database ও Data ownership। ডেটাবেস সম্পর্কে আরও জানতে পড়ুন Postgres কী।

ব্যাকআপ চেকলিস্ট

• কতটুকু ডেটা হারাতে পারবেন আর কতক্ষণ বন্ধ থাকতে পারবেন তা ঠিক করেছেন
• আপনার ডেটাবেস হোস্ট কী স্বয়ংক্রিয় ব্যাকআপ দেয় তা দেখেছেন
• আপনার নিজের ডাম্প সময়সূচি অনুযায়ী চলে, আর ব্যর্থতায় সতর্কবার্তা আসে
• কপিগুলো ডেটাবেস থেকে আলাদা জায়গায়, সীমিত অ্যাক্সেসসহ রাখা হয়
• রিটেনশন নীতি লিখিতভাবে ঠিক করা আছে
• আপলোড করা ফাইলেরও ব্যাকআপ নেওয়া হয়, শুধু ডেটাবেসের নয়
• একটি খালি ডেটাবেসে রিস্টোর পরীক্ষা করা হয়েছে, রো সংখ্যা মিলিয়ে
• প্রতিটি ঝুঁকিপূর্ণ পরিবর্তনের আগে একটি ব্যাকআপ নেওয়া হয়

প্রশ্নোত্তর