Backup/Restore Smoke و Independent Watchdog

1. Backup موجود، معادل Recovery آماده نیست

داشتن یک فایل Backup فقط نشان می‌دهد چیزی ذخیره شده است. Recovery readiness زمانی معنا دارد که Backup به source generation و digest مشخص متصل باشد، در یک مقصد ایزوله restore شود، integrity و invariantهای برنامه را پاس کند و نتیجه قابل ممیزی بماند. هم‌زمان، زنده‌بودن workload باید از بیرون workload نیز قابل سنجش باشد.

2. مرز مالکیت LOC-018

این درس فقط Evidence Contract مربوط به Backup/Restore Smoke و Independent Watchdog را مالک است. Drift reconciliation در LOC-016 و progressive rollout در LOC-017 است. Restore موفق نیز به‌تنهایی liveness supervision را ثابت نمی‌کند و restart موفق هم صحت داده restoreشده را ثابت نمی‌کند.

3. Backup را به محتوای منبع Bind کن

حداقل باید backup_id، source_generation، source_digest، backup_created_at و backup_digest ثبت شوند. filename یا وجود فایل برای اثبات کافی نیست. اگر digest یا generation منبع معلوم نباشد، نمی‌توان گفت این Backup دقیقاً نماینده کدام state بوده است.

4. SQLite Online Backup چه چیزی ثابت می‌کند

SQLite Online Backup API محتوای یک database را به database دیگر کپی می‌کند و می‌تواند این کار را incremental انجام دهد تا source برای تمام مدت عملیات lock نماند. این مکانیزم برای ساخت snapshot مناسب است، اما completion آن به‌تنهایی application restore correctness را ثابت نمی‌کند.

5. Restore Smoke باید Isolated باشد

Restore را روی target جداگانه انجام بده تا تست Recovery روی داده فعال overwrite نشود. restore_target، زمان شروع/پایان و isolation_confirmed باید ثبت شوند. اگر restore روی همان مسیر زنده انجام شود، evidence از recovery test به عملیات مخرب تبدیل می‌شود.

6. Integrity Check فقط یک لایه از Proof است

PRAGMA integrity_check consistency سطح پایین SQLite را بررسی می‌کند و در حالت بدون خطا ok برمی‌گرداند. خطاهای foreign key مرز جدا دارند و باید با foreign_key_check بررسی شوند. حتی ok نیز business invariant یا صحت application behavior را تضمین نمی‌کند.

7. Application Smoke را بعد از Structural Check اجرا کن

پس از restore، حداقل یک invariant قابل مشاهده اجرا کن؛ مثلاً وجود schema مورد انتظار، شمار رکورد bounded، یا state marker شناخته‌شده. application_smoke_result و expected_invariant باید کنار integrity evidence ثبت شوند. اگر invariant شکست خورد، نتیجه RESTORE_FAILED است حتی اگر integrity_check برابر ok باشد.

8. Content Binding را با Digest دوباره ببند

Backup و Restore باید از نظر محتوایی به هم وصل شوند. source_digest، backup_digest و در صورت استفاده restored_digest کمک می‌کنند corruption یا اشتباه در artifact را آشکار کنیم. فایل با همان نام می‌تواند خراب شده باشد؛ نام artifact proof نیست.

9. Watchdog باید خارج از Workload تصمیم بگیرد

Heartbeatی که فقط خود workload تولید و خودش تفسیر می‌کند independent supervision نیست. watchdog_owner باید یک supervisor بیرونی باشد؛ در Linux می‌تواند service manager باشد. هدف این است که workload نتواند هم failure را ایجاد کند و هم evidence سلامت خودش را کنترل کند.

10. WatchdogSec و Heartbeat Deadline

در systemd، WatchdogSec deadline را تعیین می‌کند و service با WATCHDOG=1 keep-alive می‌فرستد. عبور از deadline باید یک event قابل‌ردیابی بسازد. صرف فعال بودن process یا UI کافی نیست؛ event loop می‌تواند wedged باشد در حالی که process هنوز وجود دارد.

11. Restart Budget باید Finite باشد

Automatic restart بدون سقف می‌تواند failure loop بسازد. restart_count و restart_budget را ثبت کن. تا وقتی budget باقی است، restart ممکن است مجاز باشد؛ پس از exhaustion، state باید به WATCHDOG_EXHAUSTED یا escalation واضح برود، نه retry بی‌نهایت.

12. Post-restart Readiness یک Gate مستقل است

Restart شدن process موفقیت recovery نیست. بعد از restart باید readiness یا application probe دوباره اجرا شود. اگر post_restart_readiness=false باشد، state نباید RECOVERED شود؛ باید escalation یا halt رخ دهد.

13. Worked Example: Backup سالم، Heartbeat از دست‌رفته

Node یک backup content-bound دارد و restore isolated تمام checkها را پاس می‌کند. بعداً worker heartbeat را از دست می‌دهد؛ supervisor مستقل آن را restart می‌کند، budget هنوز باقی است و post-restart readiness پاس می‌شود. در Evidence Pack دو claim جدا داریم: RESTORE_PROVEN برای داده و RECOVERED برای watchdog path.

14. Failure Probeهای قطعی

چهار mutation را بررسی کن: یک صفحه restoreشده خراب ولی filename ثابت؛ integrity_check برابر ok ولی application invariant شکست‌خورده؛ process زنده ولی heartbeat دیرتر از deadline؛ restart budget تمام‌شده و readiness هنوز false. هر mutation باید state تایپ‌شده و دلیل قابل‌ممیزی تولید کند.

15. Transfer: Windows به‌جای systemd

در Transfer، data directory عوض می‌شود و supervisor به Windows service failure actions تغییر می‌کند. Contract را حفظ کن: backup content binding، isolated restore، structural + application checks، supervisor مستقل، deadline، restart budget، post-restart readiness و escalation. مکانیزم پلتفرمی عوض می‌شود؛ معیار Evidence عوض نمی‌شود.