# بهره‌برداری، پشتیبان‌گیری و بازیابی

چگونگی خواندن سلامت، نگهداری هویت شبکه و برنامه‌ریزی بازیابی بدون اشتباه‌گرفتن ابزار موجود با سرویس پشتیبان کامل.

وضعیت: نیازمند پیکربندی | مخاطب: مدیر زیرساخت و مسئول تداوم خدمت
بازبینی مستندات: ۲۰۲۶/۰۹/۲۴ · ۲ مهر ۱۴۰۵

## سلامت را چندبعدی بخوانید

پایش باید فرایند، RPC، ارتباط همتا، sync، هویت شبکه، مجموعه اعضا و مشارکت بلاک را جدا نشان دهد. پاسخ health مربوط به برنامه با سلامت اجماع یکسان نیست؛ همچنین زمان آخرین گزارش برای تفسیر هر وضعیت لازم است.

در Station، گزارش مرکزی قدیمی به وضعیت نامشخص یا محدودیت دید تبدیل می‌شود. نبود گزارش سایر ایستگاه‌ها به‌تنهایی به معنی قطع نود محلی نیست. در شبکه چندمنبعی، هش بلاک‌ها در ارتفاع مشترک مقایسه می‌شود تا تفاوت ارتفاع با تفاوت شاخه اشتباه نشود.

## قطع فرایند و پیگیری عملیات

Admin Main کارهای طولانی Validator را در فایل پایدار عملیات ثبت می‌کند. شناسه پردازه مالک، زمان به‌روزرسانی و وضعیت قطع‌شده کمک می‌کنند پس از restart یک کار یتیم به‌اشتباه فعال نمایش داده نشود.

برای ادامه، ابتدا نتیجه canonical و مرحله واقعی کار بررسی شود. درخواست تکراری نباید باعث نصب اعتبارسنج دوم، بازتولید کلید یا اجرای موازی رأی شود. این رفتار در محدوده قفل و idempotency کد پیاده شده است؛ جای برنامه بازیابی کل میزبان را نمی‌گیرد.

## چه داده‌ای باید حفاظت شود؟

دامنه پشتیبان شامل هویت شبکه و Genesis، داده زنجیره لازم برای نقش نود، کلیدها در محل مصوب، خزانه رمز‌شده و اطلاعات بازیابی آن، رجیستری‌ها، تنظیم سرویس و داده Station است. این موارد را نباید در یک آرشیو عمومی سورس قرار داد.

SQLite فعال ممکن است فایل‌های WAL داشته باشد؛ کپی ساده یک فایل در زمان نوشتن، تضمین نسخه سازگار نیست. روش snapshot یا توقف کنترل‌شده باید در برنامه پشتیبان همان محیط تعریف شود. نگهداری کلید و رمز بازیابی نیز باید از نسخه داده عادی تفکیک شود.

> این بخش برنامه عملیاتی پیشنهادی است: در بررسی سورس، سرویس جامع پشتیبان‌گیری زمان‌بندی‌شده با آزمون restore انتهابه‌انتها تأیید نشده است. نمایش اطلاعات خزانه پس از رمز یا حفظ فایل هنگام خطای start، معادل چنین سرویسی نیست.

## بازیابی با حفظ هویت

شاخه Linux New Network مانع بازتولید Genesis و کلید در یک نصب موجود می‌شود و فایل‌های آماده‌شده را پس از شکست start حفظ می‌کند. برای شبکه قبلی، بازیابی باید همان هویت تأییدشده را حفظ کند؛ ساخت شبکه تازه با نام مشابه، بازیابی شبکه قبلی نیست.

پس از restore، تطبیق Chain ID و Genesis، ارتفاع و هش بلاک، مجموعه Validator، مالکیت داده و اتصال امضاکننده باید بررسی شوند. نبود این کنترل‌ها می‌تواند یک سرویس ظاهراً روشن را به منبع داده اشتباه تبدیل کند.

## به‌روزرسانی و برگشت نسخه

در بسته تاریخی Station، updater مبتنی بر Git برای Linux وجود دارد که تغییرات checkout را نگه می‌دارد، نسخه جدید می‌گیرد و نصاب را اجرا می‌کند. این مسیر یک سامانه به‌روزرسانی امضاشده سراسری برای Windows، macOS و Linux نیست؛ حفظ تغییرات Git نیز پشتیبان دیتابیس و کلید محسوب نمی‌شود.

پیش از ارتقا، نسخه برنامه، ساختار داده، نسخه قرارداد و روش بازگشت باید ثبت شوند. بسته جدید نباید runtime قدیمی را بی‌بررسی جایگزین کند. انتشار Remote macOS هنوز امضای ناشر و notarization عمومی ندارد و نباید کانال به‌روزرسانی تأییدشده برای آن فرض کرد.

## معیار پایان تحویل عملیاتی

پذیرش باید نصب پاک، شروع و توقف کنترل‌شده، بازیابی نسخه پشتیبان، قطع منبع RPC، انقضای دسترسی، ورود سازمان و خطاهای امضاکننده را در محیط مجاز پوشش دهد. برای شبکه، پیشروی واقعی بلاک و هماهنگی منابع باید شاهد داشته باشد.

گزارش Linux New Network صریحاً آزمون بار، نفوذ و بازیابی را در کارهای باقی‌مانده آورده است. زمان بازیابی، میزان داده قابل ازدست‌رفتن و تعهد دسترس‌پذیری در این سورس‌ها به‌عنوان SLA عمومی تأیید نشده‌اند.

## مراجع پیاده‌سازی

- admin-main-new/backend/app/services/operation_store.py
- admin-main-new/backend/app/services/validator_diagnostics_service.py
- admin-main-new/backend/app/services/security_service.py
- admin-main-linux-newnet/backend/app/new_network.py
- admin-main-linux-newnet/VERIFICATION_LINUX_NEWNET_FA.md
- plank-station-new/agent/app.py
- Plank-Station-Linux-v1.0.0/deploy/update-ubuntu-24.04.sh