Backup ও Restore: RTO, RPO ও recovery পরীক্ষা
Backups, Restore Testing, RTO, and RPO
এই পাঠের সূচিপত্র
এই পাঠে যা শিখবেন
- Replication ও backup আলাদা করা
- RTO এবং RPO business impact দিয়ে নির্ধারণ
- Isolated restore drill চালানো
সমস্যা দিয়ে শুরু
একজন operator ভুল করে orders table মুছে দিলেন। Read replica-তেও deletion চলে গেল। Backup job green ছিল, কিন্তু restore করতে গিয়ে encryption key নেই এবং archive অসম্পূর্ণ। Copy আছে বলা আর recover করা যায় বলা এক নয়। Recovery design-এ data, schema, configuration, keys এবং application compatibility একসঙ্গে ধরতে হবে।
সহজ করে বুঝি
RPO সর্বোচ্চ কত পুরোনো recovery point গ্রহণযোগ্য, অর্থাৎ কত data-loss window সহনীয়। RTO service পুনরুদ্ধারের লক্ষ্য সময়। Backup historical recovery point রাখে; replication current state ছড়ায়, তাই ভুলও ছড়াতে পারে। Logical dump, physical backup এবং database log archiving-এর trade-off আলাদা। PostgreSQL PITR-এর জন্য suitable base backup এবং প্রয়োজনীয় continuous WAL archive লাগে; pg_dump সেই physical chain-এর বিকল্প নয়।
পরিচিত একটি উপমা
খাতার আরেক clerk-এর current copy replica-এর মতো; ভুল কাটা হলে সেখানেও কাটে। প্রতিদিনের dated photocopy historical backup। কিন্তু photocopy পড়া যায় কি না এবং হারানো দিনের হিসাব কীভাবে ফেরাবেন, সেই rehearsal ছাড়া recovery অনিশ্চিত।
নকশাটি দেখুন
Diagram লোড হচ্ছে…
Diagram-এর text flow দেখুন
flowchart LR D[(Production database)] --> B[Versioned encrypted backups] D --> W[Archived change logs] B --> R[Isolated restore] W --> R R --> V[Application integrity checks] V --> T[Measured recovery time]
Production backup ও logs independent protected storage-এ যায়। Isolated environment-এ restore হয়, যাতে drill production data overwrite না করে। Application-level checks known order, constraints এবং recent marker যাচাই করে। Recovery সময় request থেকে usable service পর্যন্ত মাপুন; শুধু download duration নয়। Restore point-এর বয়স actual achieved RPO বোঝায়।
PHP ও Laravel-এ প্রয়োগ
Restore হয়ে যাওয়া isolated database-এ Artisan command fragment। $expectedOrderId protected drill manifest থেকে আসবে; production credential ব্যবহার করবেন না। Count একা পূর্ণ integrity check নয়। এই query backup তৈরি করে না; application record পড়া যাচ্ছে কি না যাচাইয়ের একটি স্তর।
use App\Models\Order;
use Illuminate\Support\Facades\DB;
DB::select('select 1');
$order = Order::query()->findOrFail($expectedOrderId);
if ($order->total_minor < 0) {
throw new \RuntimeException('Restore invariant failed');
}সুবিধা, সীমাবদ্ধতা ও trade-off
Frequent backup RPO কমাতে সাহায্য করে কিন্তু storage, transfer এবং restore complexity বাড়ায়। Large logical restore সময় নিতে পারে; physical/PITR tooling দক্ষতা চায়। Offsite বা cross-account backup common credential failure থেকে রক্ষা করতে পারে। Retention privacy/deletion policy-এর সঙ্গে মেলান। Encryption key unavailable হলে otherwise valid backup-ও কাজে আসে না।
সাধারণ ভুল
- Replica-কে একমাত্র backup ধরা।
- Backup success log দেখে restore tested দাবি করা।
- Drill production network-এ email/payment side effect চালাতে দেওয়া।
আরও একটু গভীরে
Recovery manifest-এ engine version, extension, schema revision, key reference ও object-storage dependency রাখুন। Immutable retention accidental বা malicious deletion-এর ঝুঁকি কমাতে পারে, কিন্তু ভুল retention legal cost বাড়াতে পারে। Backup credentials minimum scope-এ রাখুন। Restore validation-এ row count ছাড়াও financial totals, foreign keys, sampled business record ও application login পরীক্ষা করুন।
মনে রাখুন
Backup-এর মূল্য tested restore-এ; RPO data-loss window এবং RTO usable recovery-এর লক্ষ্য প্রকাশ করে।
নিজে চেষ্টা করুন
একটি isolated PostgreSQL restore drill runbook লিখুন। Clock কখন শুরু ও শেষ হবে, কোন record দিয়ে freshness মাপবেন এবং side effects কীভাবে বন্ধ করবেন বলুন। Failure হলে backup owner-কে কী evidence দেবেন নির্ধারণ করুন।
নিজের বোঝা যাচাই করুন
1. Replica backup নয় কেন?
সাধারণ replication delete বা corruption-ও অনুসরণ করতে পারে। Historical recovery point আলাদা দরকার।
2. RPO ও RTO এক?
RPO data-loss window; RTO service ফিরিয়ে আনার সময়। কম RPO থাকলেও restore ধীর হতে পারে।
3. pg_dump দিয়ে PITR?
Logical dump নিজে physical WAL replay chain-এর base backup নয়। PostgreSQL-এর documented backup method মিলিয়ে নিন।
4. Restore count ঠিক মানেই সব ঠিক?
না। Business invariant, schema, keys, files ও application behaviorও যাচাই করুন।
5. Drill isolated কেন?
Restored data দিয়ে real email, charge বা webhook পাঠালে duplicate side effect হয়। Network ও credentials সীমিত রাখতে হবে।
আরও পড়ুন
এই পাঠের কুইজ
এই পাঠ থেকে ২টি প্রশ্ন। উত্তর দিয়ে ব্যাখ্যা দেখুন; অধ্যায়ের কুইজ আলাদাভাবে দিতে হবে।
এই পাঠের ২টি প্রশ্নের উত্তর দিন। পাস করতে দুটিই সঠিক হতে হবে।
জমা দেওয়ার পর সঠিক উত্তর ও ব্যাখ্যা দেখবেন। ফলাফল এই ব্রাউজারে সংরক্ষিত থাকবে। অনুশীলনের ফল অধ্যায় সম্পন্নের হিসাবে যোগ হয় না।
অগ্রগতি এই ব্রাউজারে সংরক্ষিত থাকে। শুধু পাঠ খুললে সম্পন্ন হয় না।