از دست رفتن داده قابل قبول و زمان بازیابی را تعریف کنید، یک نسخه مستقل سازگار نگه دارید و بازیابی برنامه واقعی را در انزوا آزمایش کنید. یک کار پشتیبان‌گیری تکمیل‌شده یا بررسی یکپارچگی به‌تنهایی اثبات نمی‌کند که هر وابستگی لازم برای بازیابی موجود است.
با بازیابی مورد نیاز خود شروع کنید
یک برنامه پشتیبان‌گیری با دو پرسش عملی شروع می‌شود: چقدر از کار اخیر را می‌توانید از دست بدهید و سرویس چقدر می‌تواند غیرقابل دسترس بماند؟ آن پاسخ‌ها زمان‌بندی، داده‌های شامل‌شده و روش بازیابی را تعیین می‌کنند. یک نسخه روزانه ممکن است برای یک وب‌سایت کم‌تغییر مناسب باشد در حالی که برای یک برنامه پرترافیک شکاف بیش از حد بزرگی باقی می‌گذارد.
فهرست کنید چه چیزی سرویس را کار می‌اندازد، نه فقط بزرگ‌ترین پوشه‌اش. داده برنامه، محتوای پایگاه داده، پیکربندی، فایل‌های بارگذاری‌شده و اطلاعات لازم برای بازسازی محیط ممکن است همه مهم باشند. یک فهرست خصوصی از وابستگی‌ها و کلیدهای بازیابی نگه دارید. پشتیبان‌گیری باید از یک سیستم کارآمد پشتیبانی کند، نه فقط آرشیوی تولید کند که هدفش فراموش شده است.
یک نسخه خارج از مرز خرابی نگه دارید
یک پوشه دوم روی همان ماشین می‌تواند به بازیابی یک ویرایش اشتباه کمک کند، اما همچنان در معرض از دست رفتن آن ماشین است. عکس‌های لحظه‌ای محلی می‌توانند برای بازگردانی سریع ارزشمند باشند و همچنان به یک نسخه مستقل برای حوادث گسترده‌تر نیاز دارند. یک مقصد بازیابی جداگانه انتخاب کنید و تصمیم بگیرید کدام دسترسی باید بتواند پشتیبان را بخواند، بنویسد یا حذف کند.
اگر اعتبارنامه‌های تولیدی بتوانند هر نسخه بازیابی را حذف کنند، یک حساب برنامه به‌خطر افتاده ممکن است کل استراتژی را شکست دهد. در صورت امکان دسترسی را جدا کنید و اعتبارنامه‌های ذخیره‌سازی را محافظت کنید. رمزگذاری به محافظت از محتوای ذخیره‌شده کمک می‌کند، اما فرآیند بازیابی همچنین به نگه داشتن کلیدش به‌صورت ایمن خارج از محیط آسیب‌دیده بستگی دارد.
یک وضعیت برنامه سازگار ثبت کنید
کپی کردن فایل‌های باز پایگاه داده بدون روش مناسب می‌تواند یک وضعیت غیرقابل استفاده ثبت کند. از یک رویکرد پشتیبان‌گیری که برنامه یا پایگاه داده پشتیبانی می‌کند استفاده کنید و بفهمید آیا به یک عکس لحظه‌ای سازگار، یک خروجی منطقی یا یک توقف کوتاه در نوشتن نیاز دارد. داده‌های مرتبط را هماهنگ کنید تا یک پوشه بارگذاری و ارجاعات پایگاه داده‌اش همان نقطه در گردش کار را توصیف کنند.
استثناها را عامدانه مستند کنید. کش‌ها و فایل‌های ساخت موقت ممکن است قابل بازتولید باشند؛ بارگذاری‌های مشتری معمولاً نیستند. فهرست را پس از افزودن یک ویژگی یا جابه‌جا کردن یک پوشه بازبینی کنید. یک کار پشتیبان‌گیری موفق نمی‌تواند مسیری را که هرگز شامل نشده حفظ کند.
بازیابی را در یک محیط جداگانه آزمایش کنید
داده‌های نماینده را در یک مکان جداگانه بازیابی کنید و تأیید کنید که درست باز می‌شوند. برای یک برنامه، سرویس بازیابی‌شده را همراه با فایل‌ها آزمایش کنید. ایمیل خروجی، کارهای زمان‌بندی‌شده و یکپارچه‌سازی‌های خارجی را در محیط آزمایش غیرفعال کنید تا تمرین روی کاربران واقعی عمل نکند یا کارهای تولیدی را تکرار نکند.
بررسی‌های یکپارچگی مخزن و یک آزمایش بازیابی به پرسش‌های متفاوتی پاسخ می‌دهند. یک ابزار می‌تواند ساختارها و داده‌های ذخیره‌شده را بررسی کند در حالی که برنامه همچنان به پیکربندی گم‌شده یا یک کلید فراموش‌شده نیاز دارد. ثبت کنید بازیابی چقدر طول می‌کشد، چه گام‌های دستی لازم است و کجا رویه نیاز به بهبود دارد. تمرین را پس از تغییرات قابل توجه تکرار کنید.
یک سناریوی عملی: تمرین بازیابی پیش از راه‌اندازی
برنامه‌ای را با یک پایگاه داده، بارگذاری‌های کاربر و مجموعه کوچکی از فایل‌های پیکربندی خصوصی در نظر بگیرید. مالک یک فهرست بازیابی می‌سازد و یک روش سازگاری پشتیبانی‌شده توسط پایگاه داده انتخاب می‌کند. یک مقصد پشتیبان‌گیری جداگانه نسخه‌های لازم را ذخیره می‌کند، در حالی که کلید بازیابی خارج از ماشین تولیدی نگه داشته می‌شود. اولین آزمایش با یک محیط جداگانه خالی شروع می‌شود، بنابراین وابستگی‌های پنهان نمی‌توانند از سرور کارآمد قرض گرفته شوند.
مالک داده و پیکربندی را بازیابی می‌کند، سپس ورود، یک رکورد نماینده و یک فایل بارگذاری‌شده را بررسی می‌کند. ایمیل خروجی، کارهای زمان‌بندی‌شده و اقدامات خارجی در طول تمرین غیرفعال می‌مانند. اگر پایگاه داده شروع شود اما یک مسیر بارگذاری یا یک راز گم شده باشد، آزمایش شکافی را یافته است که یک کار آرشیو موفق آشکار نمی‌کرد. مالک فهرست را اصلاح می‌کند و بررسی بازیابی متأثر را تکرار می‌کند.
در نهایت، مالک زمان بازیابی و گام‌های دستی را ثبت می‌کند. زمان‌بندی و سیاست نگهداری با این پرسش مقایسه می‌شوند که چقدر از کار اخیر می‌تواند از دست برود و سرویس چقدر می‌تواند غیرقابل دسترس بماند. این‌ها تصمیم‌های خاص پروژه هستند نه تضمین‌هایی که یک برچسب ذخیره‌سازی ارائه می‌دهد. یک رویه آزمایش‌شده یک پشتیبان‌گیری اختیاری یا یک محصول ذخیره‌سازی را به‌عنوان بخشی از یک استراتژی بازیابی گسترده‌تر مفید می‌کند.
| شواهد بازیابی | چه چیزی را بررسی می‌کند | پرسش باقی‌مانده |
|---|---|---|
| کار پشتیبان‌گیری تکمیل شد | کار موفقیت را گزارش کرد | آیا همه مسیرهای لازم شامل شده بودند؟ |
| بررسی یکپارچگی مخزن | بررسی ساختارها یا داده‌های ذخیره‌شده | آیا برنامه هر وابستگی را دارد؟ |
| بازیابی برنامه در انزوا | یک بازیابی نماینده کار می‌کند | آیا زمان مشاهده‌شده هدف شما را برآورده می‌کند؟ |
خرابی را قابل مشاهده و نگهداری را عامدانه کنید
پشتیبان‌گیری‌ای که بی‌صدا متوقف می‌شود یک شگفتی آینده است. تکمیل کار، ظرفیت موجود و سن آخرین نقطه بازیابی قابل استفاده را پایش کنید. تاریخچه کافی نگه دارید تا از مشکلی که بعداً کشف می‌شود بازیابی کنید و بفهمید هرس کردن چگونه بر آن تاریخچه تأثیر می‌گذارد. عملیات حذف را با دقت بازبینی کنید زیرا اشتباهات نگهداری می‌توانند تنها نسخه مفید را حذف کنند.
محدوده هر گزینه پشتیبان‌گیری را در سرویس SwissOctet انتخابی خود بخوانید و فرآیند بازیابی را تأیید کنید. Vault Storage می‌تواند به‌عنوان یک مؤلفه ظرفیت در نظر گرفته شود، اما یک محصول ذخیره‌سازی به‌تنهایی یک سیاست بازیابی کامل نیست. تصمیم بگیرید چه چیزی را باید بازیابی کنید، نسخه را مستقل نگه دارید و پیش از حیاتی شدن سرویس، رویه را اثبات کنید.
چک‌لیست عملی شما.
- از دست رفتن داده قابل قبول و زمان بازیابی را تعیین کنید.
- پایگاه‌های داده، فایل‌های بارگذاری‌شده و اطلاعات بازسازی را شامل شوید.
- یک نسخه مستقل و کلیدهای بازیابی جداگانه نگه دارید.
- در محیط ایزوله بازیابی کنید و برنامه را آزمایش کنید.
- قدمت پشتیبان، ظرفیت و مدت نگهداری را پایش کنید.
جزئیاتی که اهمیت دارند.
آیا یک پوشه دوم روی همان سرور، پشتیبان مستقل است؟+
خیر. همچنان در معرض از دست رفتن آن سرور است، هرچند ممکن است به بازیابی یک اشتباه محلی کمک کند.
آیا بررسی یکپارچگی جایگزین تمرین بازیابی می‌شود؟+
خیر. یک مخزن معتبر ممکن است همچنان فاقد پیکربندی، کلیدها یا داده‌های مورد نیاز برنامه باشد.
چرا هنگام آزمایش بازیابی باید یکپارچه‌سازی‌ها را غیرفعال کرد؟+
تا محیط آزمایش برای کاربران واقعی ایمیل نفرستد، کارها را تکرار نکند یا اقدامات تولیدی را فعال نکند.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی می‌کنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- restic: بازیابی از پشتیبان restic.readthedocs.io
- restic: کار با مخزن‌ها restic.readthedocs.io
- PostgreSQL: پشتیبان‌گیری و بازیابی www.postgresql.org
راهنمایی تحریریه توسط SwissOctet. مثال‌ها نمایشی هستند. مشخصات خدمات، گزینه‌های موجود و شرایط قراردادی باید جداگانه تأیید شوند.