سیاست نگهداری یا Retention مشخص می‌کند کدام نقطه‌های بکاپ برای چه مدت باقی بمانند؛ با فاصلهٔ تهیهٔ بکاپ یکسان نیست. چند نسخهٔ روزانه برای خطای همان روز مفیدند، اما آلودگی یا حذف اشتباهیِ دیرکشف‌شده ممکن است نسخهٔ قدیمی‌تری بخواهد. سیاست باید با زمان کشف مشکل، ظرفیت ذخیره و وابستگی نسخه‌ها سازگار باشد.
۱. فاصلهٔ تهیه و عمر نگهداری را جدا کنید
| تصمیم | پاسخ به کدام سؤال؟ |
|---|---|
Frequency |
هر چند وقت نقطهٔ تازه ساخته می‌شود؟ |
Retention |
هر نقطه تا چه زمانی در دسترس است؟ |
Recovery window |
برای چه بازه‌ای واقعاً نسخهٔ سالم قابل‌بازیابی داریم؟ |
ممکن است هر ساعت بکاپ بگیرید اما فقط یک روز نگه دارید. چنین برنامه‌ای مشکلِ کشف‌شده پس از یک هفته را پوشش نمی‌دهد. در مقابل، داشتن چند نسخهٔ ماهانه فاصلهٔ تغییرات امروز را جبران نمی‌کند. این دو نیاز باید جدا بررسی شوند.
۲. یک الگوی آموزشی، نه نسخهٔ همگانی
برای طراحی می‌توان سه لایهٔ روزانه، هفتگی و ماهانه را بررسی کرد؛ تعدادها تابع نرخ تغییر، ارزش داده و محدودیت نگهداری‌اند. جدول زیر فقط یک سناریوی قابل‌بحث است، نه سیاست جاری رایکت یا توصیهٔ اجباری برای همهٔ سایت‌ها:
| لایهٔ فرضی | هدف | سؤال کنترل |
|---|---|---|
| روزانه برای ۱۴ روز | خطای نزدیک و تغییرات اخیر | آیا RPO به بکاپ پرتکرارتر نیاز دارد؟ |
| هفتگی برای ۸ هفته | مشکل دیرکشف‌شده | نسخهٔ سالم را چطور شناسایی می‌کنیم؟ |
| ماهانه برای ۶ ماه | بازگشت دورتر متناسب با نیاز | دلیل نگهداری و دسترسی مجاز روشن است؟ |
نگهداری طولانی‌تر هزینه و مسئولیت حفاظت اطلاعات مشتری را افزایش می‌دهد؛ این مقاله مشاورهٔ حقوقی یا تعیین مدت قانونی نگهداری نیست. نیاز قراردادی را از مسئول مربوط بگیرید.
۳. ظرفیت را با روش ذخیره برآورد کنید
اگر اندازهٔ کاملِ آموزشی ۵ گیگابایت و ۱۴ نسخه مستقل باشد، برآورد سادهٔ همان لایه ۷۰ گیگابایت است، پیش از سربار، رشد و نسخه‌های هفتگی. اما وقتی incremental یا deduplication دارید، جمع سادهٔ اندازهٔ ظاهری فایل‌ها لزوماً مصرف واقعی نیست.
- حجم واقعیِ اندازه‌گیری‌شده را مبنا بگذارید.
- برای رشد داده و ساخت نسخهٔ بعدی حاشیهٔ ظرفیت در نظر بگیرید.
- ظرفیت مخزن و محل موقت اجرای بکاپ را جدا بررسی کنید.
- رمز یا کلید بازیابی باید در مسیر مجاز و مستقل قابل‌دسترس بماند.
فشرده‌سازی و رمزگذاری هم بسته به نوع داده مصرف و زمان متفاوتی دارند؛ یک نسبت ثابت برای همهٔ فایل‌ها فرض نکنید.
۴. نسخهٔ قدیمی را بدون بررسی زنجیره حذف نکنید
در روش‌های وابسته، نسخهٔ جدید ممکن است به نسخهٔ پایه یا دادهٔ مشترک قدیمی احتیاج داشته باشد. حذف دستیِ فایل بر اساس تاریخ می‌تواند نقطه‌های ظاهراً جدید را خراب کند. قواعد retention باید از طریق ابزارِ آگاه به وابستگی و با بررسی نتیجه اعمال شوند.
نکته: این راهنما هیچ دستور حذف، Cron یا تنظیم retention روی هاست اجرا نمی‌کند. قبل از هر پاک‌سازی واقعی، نسخهٔ مستقل سالم، دامنهٔ حذف و روش بازیابی را با مسئول بکاپ بررسی کنید.
قواعد lifecycle در یک سرویس مانند AWS Backup، نمونهٔ پیاده‌سازی همان سرویس است؛ نام و محدودیت‌هایش را به سی‌پنل یا پلن دیگر تعمیم ندهید.
۵. دفتر نگهداریِ قابل استفاده بسازید
- برای هر مجموعه، تاریخ، اجزا، محل مستقل و تاریخ انقضای برنامه‌ریزی‌شده را بنویسید.
- موفقیت ساخت را از موفقیت انتقال و آزمون بازیابی جدا ثبت کنید.
- قدیمی‌ترین نسخهٔ سالم و جدیدترین نقطهٔ قابل‌بازیابی را مشخص کنید.
- بعد از تغییر بزرگ سایت، کافی‌بودن پنجرهٔ نگهداری را دوباره ارزیابی کنید.
وجود بکاپ در همان حساب، فقط بخشی از نیاز را پوشش می‌دهد. راهنماهای برنامهٔ بکاپ وردپرس و نگهداری مستقل، مکمل‌اند؛ این مقاله صرفاً تصمیم دربارهٔ عمر و ترکیب نسخه‌ها را دقیق‌تر می‌کند.
مدت نگهداری نسخه‌ها را با هدف بازیابی اشتباه نگیرید؛ برای تعیین میزان دادهٔ قابل‌از‌دست‌رفتن و زمان قابل‌قبول توقف، راهنمای RPO و RTO را مطالعه کنید.
۶. مسیر مطالعهٔ مرتبط
۷. منابع و روش بررسی
منابع رسمی در ۲۴ اکتبر ۲۰۲۶ بررسی شدند. این متن راهنمای تشخیص و برنامه‌ریزی است؛ بازیابی بکاپ، تغییر حفاظت و تست روی سایت زنده انجام نشده است.
