Backup, Restore و PITR Mental Model

1) مسئله قبل از ابزار

سبز بودن یک job بکاپ فقط می‌گوید فرایندی در یک زمان اجرا شده است؛ هنوز معلوم نیست artifact قابل بازیابی است، target درست انتخاب شده، زنجیره WAL کامل است یا زمان و مرز از‌دست‌رفتن داده واقعاً اندازه‌گیری شده است. در این درس، یک incident محدود روی PostgreSQL 18 داریم: چند credit قانونی ثبت می‌شود و بعد یک bulk update اشتباه رخ می‌دهد. هدف ساخت Backup, Restore & PITR Recovery Evidence Record v1 است؛ نه ادعای disaster readiness برای production.

2) جهت مسیر و مرز درس

DAT-005 به ما discipline تغییر schema و DAT-007 جداسازی intent از database observation را داده‌اند. اینجا مالک outcome فقط recovery reasoning است. دو نیاز متفاوت را جدا می‌کنیم: یک export منطقی قابل‌حمل با pg_dump/pg_restore و یک recovery زمانی با base backup + WAL. هیچ‌کدام جای دیگری نیست. pg_dump یک database منطقی را export می‌کند؛ PITR به chain فیزیکی و WAL وابسته است.

3) مدل ذهنی

دو مسیر را کنار هم نگه دار:

Database → pg_dump archive → pg_restore → isolated restored DB → row/business verification

Base backup + continuous WAL archive → recovery target → isolated recovered cluster → row/business verification

در هر دو مسیر، پایان واقعی verification است، نه ساخته‌شدن archive و نه بالا آمدن server. artifact باید recovery objective، mechanism، scope، components، target، restore steps، integrity check، measured data-loss boundary، measured restore time، failure probe و residual risk را ثبت کند.

4) Recovery classes را قاطی نکن

PostgreSQL بین SQL dump، file-system/physical backup و continuous archiving تفاوت می‌گذارد. SQL dump برای portability و object/data restore مفید است و archive format با pg_restore قابل کنترل است. اما dump یک database، cluster-global objectها و chain زمانی PITR را به‌صورت خودکار پوشش نمی‌دهد. Physical/base backup تصویر cluster را برای recovery فیزیکی فراهم می‌کند، اما برای PITR به WAL موردنیاز هم احتیاج است.

5) Logical restore: چه چیزی ثابت می‌شود؟

در fixture، ابتدا baseline و دادهٔ incident ثبت می‌شود، سپس archive منطقی از database disposable گرفته می‌شود. restore باید در مقصد جدا انجام شود. برای evidence فقط return code کافی نیست: تعداد ردیف‌ها، مقدار creditهای کلیدی، schema fingerprint و object scope باید بررسی شوند. اگر global role/setting لازم باشد ولی در pg_dump تک‌دیتابیسی نیست، باید به‌عنوان limitation ثبت شود، نه اینکه silent فرض شود.

6) PITR chain: base backup به‌تنهایی کافی نیست

PITR از base backup شروع می‌شود و با WAL لازم، state را جلو می‌برد. target باید صریح باشد: زمان، LSN یا marker موردنظر. در سناریوی ما marker قبل از bulk update اشتباه ثبت می‌شود. اگر WAL segment لازم حذف شود، recovery evidence باید fail شود. اینکه cluster فقط start شود، اثبات نمی‌کند state کسب‌وکار درست است؛ باید row-level/business verification انجام شود.

7) Worked incident: نقطهٔ درست کجاست؟

فرض کن accountهای A-100, A-200, A-300 credit دارند. بعد از baseline، دو تغییر قانونی ثبت می‌شود و سپس query اشتباه همه creditها را صفر می‌کند. برای compliance، logical export فعلی ممکن است مناسب باشد. برای incident recovery، هدف «لحظه قبل از destructive update» است. artifact باید target را با marker و expected business state bind کند، سپس recovered state را با queryهای مستقل مقایسه کند.

8) Failure modes اجباری

WAL gap: یک segment لازم حذف شده است؛ نباید PITR موفق claim شود.

Wrong target: server بالا می‌آید اما به target بعد از destructive update رسیده است؛ business verification باید آن را reject کند.

Logical-scope gap: archive تک‌دیتابیسی restore می‌شود ولی یک dependency خارج از scope لازم بوده است؛ scope check باید limitation را ثبت کند.

RPO/RTO overclaim: cadence مثلاً «هر 15 دقیقه» یا یک restore سریع در fixture، guarantee سازمانی نیست. فقط measured scenario evidence ثبت می‌شود.

9) RPO و RTO: promise را از measurement جدا کن

RPO دربارهٔ مرز قابل‌تحمل data loss و RTO دربارهٔ زمان بازگشت سرویس/قابلیت است. configuration به‌تنهایی این دو را ثابت نمی‌کند. در این درس دو مقدار ثبت می‌شود: measured data-loss boundary در recovery انجام‌شده و measured restore/recovery time برای همین fixture. سپس assumptions نوشته می‌شوند: سخت‌افزار، حجم داده، archive availability، operator steps و verification cost.

10) تمرین هدایت‌شده و مستقل

در مسیر هدایت‌شده، اول recovery objective را بنویس؛ بعد mechanism را انتخاب کن. logical archive را روی مقصد جدا restore و verify کن. برای PITR، chain plan و target marker را بساز، preflight ابزارهای local را اجرا کن و فقط روی cluster disposable تمرین کن. starter هیچ production host یا credential را قبول نمی‌کند.

تمرین مستقل: یک support database باید دقیقاً قبل از bulk update اشتباه recover شود، درحالی‌که یک task جدا export قابل‌حمل برای compliance می‌خواهد. برای هر نیاز artifact متفاوت، verification gate متفاوت و residual limitation را مستقل تعیین کن.

11) Verification و evidence

حداقل evidence: recovery objective، mechanism choice، artifact identity/hash، restore destination identity، target marker، row/business verification، failure observation، measured duration، measured data-loss boundary، changed-context transfer و residual limitation. observation را از inference جدا نگه دار. اگر PostgreSQL واقعی یا ابزار physical recovery اجرا نشده، status باید NOT_RUN بماند و runtime claim false باشد.

12) Assessment و transfer

برای قبولی، learner باید بتواند تفاوت logical restore و PITR را توضیح دهد، scope pg_dump را محدود نگه دارد، dependency base backup + WAL را بیان کند، wrong-target و missing-WAL را failure تشخیص دهد، recovered state را با business evidence verify کند و RPO/RTO را فقط در حد measurement انجام‌شده claim کند.

13) منابع و freshness

Source boundary فقط چهار منبع رسمی PostgreSQL 18 است: PG18-BACKUP, PG18-PGDUMP, PG18-PGRESTORE, PG18-RECOVERY-CONFIG. همه در 2026-09-02 retrieved شده‌اند و review_due=2026-12-31 دارند. در 2026-09-15 recheck اجباری نیست و scope توسعه داده نشده است.