چرا این موضوع مهم است؟
برای PITR فقط dump یا فقط WAL کافی نیست. یک base backup سازگار نقطهٔ شروع است و WAL archive تغییرات بعدی را تا نقطهٔ هدف بازپخش می‌کند. retention باید با RPO و فضای ذخیره‌سازی هماهنگ شود.
در یک سیستم واقعی، قبل از انتخاب ابزار باید مدل ذهنی درستی از لایه‌ها داشته باشید. هر بار که یک مشکل را فقط با یک command یا تنظیم حفظی حل می‌کنیم، دانش به نسخه و محیط خاص گره می‌خورد. روش بهتر این است که ورودی، state، policy، مسیر داده و خروجی را مشخص کنیم. بعد ابزار را برای مشاهدهٔ یکی از این لایه‌ها انتخاب کنیم. این رویکرد باعث می‌شود وقتی نسخه یا توزیع عوض شد، هنوز بدانیم دنبال چه evidenceای هستیم.
مدل معماری
در موضوع بازیابی PostgreSQL و پیوند base backup با WAL archive، componentها را روی یک مسیر ساده بکشید و مرز مسئولیت هرکدام را مشخص کنید. state پایدار، state runtime، dependency بیرونی و نقطهٔ اعمال policy را جدا کنید. وقتی diagram ساده دارید، خطا از یک «سیستم بزرگ و مبهم» به چند مرحلهٔ قابل آزمون تبدیل می‌شود.
روش عملی کار
Backup catalog، checksum، off-site copy و test restore داشته باشید. timestamp و timezone recovery target را با دقت ثبت کنید. monitoring archive_command مهم است؛ backup ظاهراً موفق با WAL ناقص ممکن است قابل بازیابی نباشد.
برای Production، تغییر باید قابل اندازه‌گیری و قابل برگشت باشد. baseline قبل از تغییر شامل نسخه، config مؤثر، log سالم، metric اصلی و یک تست end-to-end است. rollout را با canary شروع کنید؛ بعد از هر مرحله هم تست مثبت و هم تست منفی داشته باشید. اگر success criterion از قبل نوشته نشده باشد، بعد از اجرا به‌سادگی هر نتیجه‌ای را می‌توان «موفق» تفسیر کرد. rollback هم باید تمرین شود، نه اینکه فقط یک دستور روی کاغذ باشد.
از دید امنیت
موفقیت job backup اثبات recovery نیست. backupی که ماه‌ها restore نشده، ریسک ناشناخته دارد. همچنین retention کوتاه WAL می‌تواند پنجرهٔ PITR را بی‌صدا از بین ببرد.
از دید امنیت، کم‌کردن سطح دسترسی مهم است اما availability و قابلیت عیب‌یابی هم جزو امنیت عملیاتی‌اند. secretها، tokenها، capabilityها، network path و logهای حساس را جدا بررسی کنید. هر exception باید owner، دلیل و تاریخ بازبینی داشته باشد. کنترل‌هایی که هیچ‌کس نمی‌تواند اثرشان را مشاهده یا علتشان را توضیح دهد، در زمان incident به مانع تبدیل می‌شوند.
آزمایشگاه پیشنهادی
یک دیتابیس آزمایشی بسازید، base backup بگیرید، WAL archive را فعال کنید، چند تراکنش مشخص ایجاد و سپس داده را حذف کنید. تا ثانیهٔ قبل از حذف restore کنید و زمان بازیابی را اندازه بگیرید.
برای هر مرحله timestamp و خروجی را ذخیره کنید. یک failure کنترل‌شده ایجاد کنید تا مطمئن شوید monitoring واقعاً failure را می‌بیند. سپس سیستم را به baseline برگردانید و زمان recovery را ثبت کنید.
عیب‌یابی بر پایهٔ Evidence
Troubleshooting را با تغییر config شروع نکنید. اول محل دقیق failure را پیدا کنید: آیا ورودی وارد سیستم می‌شود؟ آیا state مورد انتظار ساخته شده؟ آیا policy اجازه می‌دهد؟ آیا خروجی از component خارج می‌شود؟ log، packet capture، metric و state API باید به یک timeline مشترک وصل شوند. نبودن event نیز evidence است؛ اگر request قبل از یک component دیده می‌شود و بعد از آن نه، دامنهٔ مسئله کوچک شده است.
Performance و ظرفیت
عملکرد را فقط با average نسنجید. p95/p99 latency، saturation، queue depth، retry و resource pressure تصویر بهتری می‌دهند. تغییری که در lab کوچک سریع است ممکن است زیر concurrency یا dataset واقعی bottleneck متفاوتی نشان دهد. capacity limitها را قبل از rollout بزرگ شناسایی کنید و alert را به thresholdهای قابل اقدام وصل کنید.
Production readiness
قبل از rollout نهایی، owner، change window، blast radius، success metric و rollback trigger باید مشخص باشند. اگر dependency خارجی دارید، رفتار هنگام timeout یا unavailable شدن آن را تست کنید. اگر config به چند host می‌رود، rollout مرحله‌ای و inventory دقیق لازم است. یک تغییر خوب باید observable، explainable و reversible باشد.
Runbook و انتقال دانش
در مستندسازی، فقط «چه دستورهایی اجرا شد» را ننویسید. سؤال، فرضیه، evidence مورد انتظار، نتیجه و دلیل تصمیم را ثبت کنید. اگر همکار دیگری بتواند با همان ورودی آزمایش را تکرار کند و به نتیجهٔ مشابه برسد، runbook ارزش عملیاتی دارد. اگر فقط نویسنده می‌داند چرا مرحله‌ای لازم است، دانش هنوز منتقل نشده است.
قبل از Production چه چیزی را اعتبارسنجی کنیم؟
نتیجهٔ Lab را مستقیم به Production تعمیم ندهید. یک change plan کوتاه بسازید که در آن دامنهٔ تغییر، owner، زمان اجرا، dependencyها، success metric و rollback trigger مشخص باشد. ابتدا روی canary یا درصد کوچکی از workload اجرا کنید و حداقل یک چرخهٔ واقعی restart، credential rotation یا deploy دوم را ببینید؛ بسیاری از خطاها در اولین اجرای سالم ظاهر نمی‌شوند. رفتار هنگام unavailable شدن dependency خارجی، پر شدن disk، timeout شبکه و ورودی نامعتبر را نیز بررسی کنید. اگر feature امنیتی است، test منفی باید نشان دهد مسیر غیرمجاز واقعاً بسته است؛ اگر feature performance است، benchmark باید با load و dataset نزدیک به واقعیت اجرا شود. در پایان، تصمیم rollout را با evidence ثبت کنید، نه با جملهٔ مبهم «به‌نظر خوب است».
نگهداری بلندمدت و بازبینی دوره‌ای
معماری بعد از deploy ثابت نمی‌ماند. نسخهٔ سیستم‌عامل، dependency، policy سازمان، certificate، endpoint و حجم workload تغییر می‌کنند. برای همین باید بازبینی دوره‌ای تعریف شود: نسخه‌های پشتیبانی‌نشده را پیدا کنید، exceptionهای قدیمی را ببندید، alertهای بی‌ارزش را حذف کنید و recovery را دوباره تمرین کنید. اگر configuration در Git نگهداری می‌شود، drift میان state واقعی و repository را اندازه بگیرید. اگر ابزار SaaS یا سرویس خارجی است، تغییر API، pricing، limit و مدل permission را دنبال کنید. مستندات باید تاریخ review داشته باشند تا تیم بداند کدام فرض‌ها هنوز معتبرند. نگهداری خوب یعنی سیستم بعد از شش ماه هم قابل توضیح و قابل بازیابی باشد، نه اینکه فقط روز اول deploy موفق بوده باشد.
جمع‌بندی
هدف این مقاله دربارهٔ بازیابی PostgreSQL و پیوند base backup با WAL archive ارائهٔ یک دستور جادویی نیست؛ هدف ساختن مدل ذهنی است. وقتی معماری را بفهمید، baseline داشته باشید و تغییر را با evidence کوچک کنید، ابزارها قابل تعویض می‌شوند اما روش حل مسئله باقی می‌ماند. منبع اصلی این مقاله از PostgreSQL انتخاب شده تا جزئیات فنی قابل پیگیری باشند.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- component و مرز اعتماد را مشخص کن.
- baseline را قبل از تغییر ذخیره کن.
- یک test مثبت و یک test منفی بساز.
- تغییر را با canary شروع کن.
- evidence را timestampدار نگه دار.
- rollback را واقعاً تمرین کن.
- نتیجه و exceptionها را در runbook ثبت کن.
انتخاب نوع نسخه پشتیبان با یک مثال
فرض کنید یک جدول سفارش در ساعت مشخصی اشتباه حذف شده است. بازیابی یک dump قدیمی می‌تواند اشیای منطقی را برگرداند، اما به خودی خود همه تغییرات میان زمان dump و حذف را بازسازی نمی‌کند. در بازیابی فیزیکی، یک نسخه پایه معتبر را در محیطی جدا باز می‌کنید و زنجیره WAL را تا قبل از عملیات اشتباه بازپخش می‌کنید. این دو روش رقیب مطلق نیستند؛ dump برای انتقال انتخابی و بررسی منطقی مفید است و نسخه فیزیکی برای بازسازی خوشه و بازیابی زمانی کاربرد متفاوتی دارد.
پیش از تهیه نسخه پایه، نسخه عمده PostgreSQL، روش رمزگذاری دیسک، مسیر tablespaceها و تنظیمات لازم برای راه‌اندازی را ثبت کنید. فایل‌های تنظیمات یا کلیدهای بیرون پوشه داده ممکن است همراه روش پشتیبان انتخابی شما ذخیره نشوند. یک آرشیو که داده را دارد ولی کلید رمزگشایی آن گم شده، عملاً قابل استفاده نیست. در عین حال قرار دادن کلید و همه داده‌ها در همان محل و با همان حساب کاربری، جداسازی امنیتی را از بین می‌برد. طراحی دسترسی و طراحی بازیابی باید با هم دیده شوند.
چگونه زنجیره WAL را سالم نگه داریم؟
WAL جریان مرتب تغییراتی است که بازیابی فیزیکی به آن وابسته است. داشتن تعداد زیادی فایل آرشیو، پیوستگی این جریان را ثابت نمی‌کند. اگر یک بخش لازم بین نسخه پایه و زمان هدف موجود نباشد، بخش‌های بعدی نمی‌توانند آن فاصله را جبران کنند. پایش فقط آخرین اجرای موفق پشتیبان کافی نیست؛ باید موفقیت انتقال آرشیو، عقب‌ماندگی، فضای دیسک مبدأ و قابلیت خواندن نسخه مقصد هم بررسی شوند. خرابی آرشیو ممکن است ابتدا به رشد مصرف دیسک و سپس اختلال پایگاه منجر شود.
سیاست حذف را از روی روز تقویمی تنها نسازید. قدیمی‌ترین نسخه پایه‌ای که وعده بازیابی آن را می‌دهید، به بخش‌های معینی از WAL نیاز دارد. حذف فایل‌ها بدون شناخت این وابستگی می‌تواند نسخه ظاهراً موجود را بی‌فایده کند. ابزار مدیریت پشتیبان باید رابطه نسخه پایه، خط زمانی و آرشیو را بفهمد؛ اسکریپتی که صرفاً همه فایل‌های قدیمی‌تر از عددی ثابت را پاک می‌کند، این رابطه را تضمین نمی‌کند. پیش از تغییر نگهداری، یک هدف بازیابی نزدیک مرز قدیمی پنجره انتخاب و آن را واقعاً امتحان کنید.
تمرین بازیابی بدون آسیب به سرویس اصلی
مقصد آزمایش را از شبکه برنامه اصلی جدا کنید تا نمونه بازیابی‌شده ناخواسته پیام، ایمیل یا عملیات تجاری تولید نکند. نسخه سازگار موتور را آماده کنید و محل داده را به شکلی انتخاب کنید که با خوشه زنده اشتباه نشود. ساعت هدف را با منطقه زمانی بنویسید؛ عبارت «قبل از ظهر» برای عملیات بازیابی کافی نیست. اگر هدف تراکنش یا نقطه نام‌گذاری‌شده است، همان قرارداد را در برنامه آزمایش ثبت کنید. شکل دقیق فایل‌های کنترلی و تنظیمات بازیابی باید با مستندات نسخه نصب‌شده تطبیق داشته باشد.
پس از بازپخش، صرف پاسخ دادن سرور به اتصال را موفقیت ندانید. شمارش چند جدول، کنترل ارتباط رکوردها و اجرای پرس‌وجوی واقعی برنامه را انجام دهید. برای مثال سفارش باید وجود داشته باشد و اقلام همان سفارش نیز قابل خواندن باشند. رویدادهای بعد از زمان هدف نباید بی‌توضیح در نتیجه دیده شوند. شناسه چند تراکنش قبل و بعد از حادثه را به عنوان نمونه شاهد نگه دارید. این روش خطای انتخاب زمان و خطای انتخاب نسخه پایه را آشکار می‌کند.
محاسبه زمان بازگشت و تصمیم عملیاتی
زمان بازیابی شامل یافتن فایل‌ها، انتقال نسخه پایه، آماده‌کردن مقصد، بازپخش WAL و تأیید برنامه است. سرعت کپی فقط یکی از این مراحل است. اگر بازیابی آزمایشی طولانی شد، مشخص کنید زمان در انتقال داده مصرف شده یا بازپخش یا هماهنگی افراد. هدف کاهش زمان باید به همان مرحله متصل شود؛ خرید دیسک سریع‌تر مشکل دسترسی فراموش‌شده به مخزن پشتیبان را حل نمی‌کند. نتایج تمرین را همراه حجم داده و طول بازه WAL بنویسید تا مقایسه تمرین بعدی معنادار باشد.
در حادثه واقعی، بازگرداندن کل سامانه به گذشته ممکن است داده سالم تازه را هم حذف کند. گاهی بهتر است خوشه در مقصد جدا بازیابی شود و تنها رکوردهای لازم با روش بررسی‌شده منتقل شوند. این انتخاب به یکپارچگی داده و قرارداد برنامه بستگی دارد. تیم باید پیشاپیش بداند چه کسی میان بازگشت کامل و استخراج انتخابی تصمیم می‌گیرد و چگونه از اجرای هم‌زمان دو سامانه نویسنده جلوگیری می‌شود.
