اسنپشات نمایشی از یک نقطه در زمان است که حفاظت آن با پیادهسازیاش تعیین میشود. یک راهبرد پشتیبانگیری، نگهداری عامدانه، جداسازی دسترسی و بازیابی آزمایششده را اضافه میکند. برخی اسنپشاتها پشتیبان هستند؛ برخی دیگر به ذخیرهسازی اصلی وابستهاند. بپرسید چه چیزی از حذف، نفوذ یا از دست رفتن محیط اصلی جان سالم به در میبرد.
پیش از نامگذاری، نسخه را توصیف کنید
واژه اسنپشات به شما میگوید که یک نقطه در زمان نمایش داده شده است، اما نه اینکه داده قابل بازیابی کجا نگهداری میشود یا چه کسی میتواند آن را حذف کند. اسنپشات فایلسیستم روی ذخیرهسازی اصلی و اسنپشات بلوکی مدیریتشده توسط ارائهدهنده میتوانند مرزهای خرابی متفاوتی داشته باشند. با پیادهسازی شروع کنید، نه اینکه برچسب را بهعنوان وعدهای جهانی در نظر بگیرید.
AWS اسنپشاتهای EBS را بهعنوان پشتیبانهای افزایشی نقطهای از حجمهای خود مستند میکند. این یک پیادهسازی مشخص است، نه اثبات اینکه هر گزینه اسنپشات به یک شکل رفتار میکند. برای هر سرویس بپرسید که آیا بازیابی به حجم اصلی وابسته است، آیا نسخهها دامنه خرابی اصلی را ترک میکنند و وقتی منبع حذف شود چه اتفاقی میافتد.
خرابیهایی را که انتظار دارید از آنها جان سالم به در ببرید مقایسه کنید
بازگردانی سریع پس از یک بهروزرسانی و بازیابی پس از از دست دادن یک حساب، مسائل متفاوتی هستند. یک اسنپشات محلی ممکن است برای اولی راحت باشد، در حالی که برای دومی جداسازی کمی ارائه میدهد. نسخههای مستقل میتوانند حفاظت را افزایش دهند، اما تنها در صورتی که مسیرهای ذخیرهسازی، دسترسی و حذف آنها بهقدر کافی از حادثهای که برای آن آماده میشوید جدا باشد.
خرابی و نتیجه مورد نیاز را بنویسید. این مقایسه نمونه یک کمک تصمیمگیری است، نه فهرست ویژگیهای SwissOctet. این مقایسه پرسشهایی درباره نسخهها و کنترل تشویق میکند، نه ادعای اینکه یک فناوری همیشه برتر است. نتیجه واقعی به پیکربندی و فرایند بازیابی مستندشده اپراتور بستگی دارد.
| سناریو | پرسش برای یک اسنپشات | پرسش برای یک پشتیبان |
|---|---|---|
| بهروزرسانی ناموفق برنامه | آیا میتوانم به نقطه مورد نظر بازگردم؟ | بازیابی قابل استفاده چقدر طول میکشد؟ |
| از دست رفتن دیسک اصلی | آیا نسخه به آن دیسک وابسته است؟ | آیا میتوانم روی ذخیرهسازی تازه بازیابی کنم؟ |
| به خطر افتادن حساب مدیریتی | آیا این حساب میتواند همه نسخهها را حذف کند؟ | آیا حقوق حذف جدا شدهاند؟ |
| خطایی که هفتهها بعد کشف میشود | آیا آن نقطه هنوز نگهداری میشود؟ | آیا نگهداری تأخیر کشف را پوشش میدهد؟ |
سازگاری برنامه را بررسی کنید
یک دیسک میتواند فایلها را در حالی ثبت کند که برنامه هنوز آنها را تغییر میدهد. بسته به نرمافزار و فرایند اسنپشات، نتیجه ممکن است وضعیت سازگار با خرابی را نشان دهد، نه وضعیت هماهنگ برنامه. فرض نکنید که فایلهای قابل خواندن به معنای توافق پایگاه داده و بارگذاریهای مرتبط با آن است. از روش پشتیبانگیری مستندشده توسط برنامه یا پایگاه داده استفاده کنید.
طراحی بایگانی پیوسته PostgreSQL تفاوت را نشان میدهد: بازیابی به یک پشتیبان پایه مناسب و یک توالی پیوسته از فایلهای log پیشنوشت مورد نیاز نیاز دارد. کپی کردن سرسری یک پوشه در حالی که پایگاه داده در حال اجراست، رویه معادلی نیست. اگر برنامه فایلها را خارج از پایگاه داده نیز ذخیره میکند، برنامهریزی کنید که این دو مجموعهداده با هم بازیابی شوند.
نگهداری را بهعنوان پنجره بازیابی در نظر بگیرید
نگهداری باید در نظر بگیرد که یک خطا چه مدت میتواند ناشناخته بماند. پنجره دهروزه به حذف تصادفیای که پس از یک ماه کشف میشود کمکی نمیکند. نگه داشتن هر نسخه بهطور نامحدود مشکل متفاوتی ایجاد میکند: هزینه، افزایش مواجهه با دادههای حساس و سیاست حذف نامشخص. نگهداری را بر اساس الزامات عملیاتی و مدیریت داده مشخص انتخاب کنید.
نقاط بازیابی را با زمینه مفید، مانند نسخه برنامه و زمان کار تکمیلشده، برچسبگذاری کنید، بدون درج اسرار. تاریخچه کافی نگه دارید تا وضعیت خوب را از وضعیت آسیبدیده تشخیص دهید. پیش از هرس کردن، تأیید کنید که سیستم انتخابی چگونه دادههای اشتراکی یا افزایشی را مدیریت میکند؛ حذف یک نقطه برچسبخورده ممکن است معادل حذف یک فایل مستقل ساده نباشد.
کارهای موفق را از دادههای تأییدشده جدا کنید
گزارش موفقیت یک ابزار پشتیبانگیری ثابت میکند که فرایند آن تحت قواعدش کامل شده است. این بهطور خودکار اثبات نمیکند که همه دادههای مهم برنامه انتخاب شدهاند، هر بایت ذخیرهشده سالم مانده است یا یک سرور جدید میتواند از نتیجه استفاده کند. اینها بررسیهای متفاوتی هستند. سلامت مخزن، بازبینی انتخاب و بازیابی نمونه را در برنامه عملیاتی بگنجانید.
Restic تفاوتی بین بررسی پیشفرض مخزن و تأییدی که دادههای pack ذخیرهشده را میخواند مستند میکند. بررسی کامل خواندن داده میتواند زمان و پهنای باند بیشتری مصرف کند. این مثال نکته برنامهریزی را عینی میکند: تصمیم بگیرید که تأیید واقعاً چه چیزی را میخواند و برای آن کار بودجه تعیین کنید. از مستندات ابزار استفاده کنید، نه اینکه فرض کنید هر دستوری با نام check پوشش یکسانی دارد.
یک بازیابی کوچک و کامل را آزمایش کنید
یک نشریه با پایگاه داده، تصاویر بارگذاریشده و پیکربندی را در نظر بگیرید. هر سه را در یک محیط آزمایشی خصوصی بازیابی کنید، سپس یک مقاله را باز کنید و پیوستهای آن را بررسی کنید. در طول این تمرین، یکپارچهسازیهای زمانبندیشده ایمیل، پرداخت و انتشار را غیرفعال نگه دارید. آزمایش تنها یک فایل متنی تصادفی، روابطی را که برنامه را مفید میکنند نادیده میگیرد.
زمان لازم را اندازهگیری کنید و ثبت کنید که کدام اعتبارنامهها، نسخههای بسته یا وابستگیهای خارجی وجود نداشتند. مجوزهای فایلهای بازیابیشده را بررسی کنید، نه فقط محتوای آنها را. یک تمرین بازیابی اغلب کشف میکند که داده وجود دارد، اما دستورالعملها یا دسترسی لازم برای استفاده از آن هرگز در کنار برنامه عملیاتی حفظ نشده است.
پشتیبانهای اختیاری را بهعنوان یک سرویس مشخص بخوانید
هنگام پیکربندی SwissOctet، به گزینه دقیق پشتیبانگیری و دوره نگهداری برای آن خانواده نگاه کنید. بپرسید کدام حجمها و دادههای برنامه را پوشش میدهد، آیا بازیابی خودخدمت است و وقتی پیکربندی اصلی تغییر میکند چه اتفاقی میافتد. برچسب گزینه بهتنهایی یک نسخه مستقل، مخزن تغییرناپذیر یا نقطه بازیابی سازگار با پایگاه داده را اثبات نمیکند.
از اسنپشاتها در جایی که با بار کاری تناسب دارند استفاده کنید و یک راهبرد پشتیبانگیری گستردهتر برای خرابیهایی که پوشش نمیدهند نگه دارید. یک مسیر بازیابی مستقل برای دادههای مهم ثبت کنید، اعتبارنامههایی را که میتوانند نسخهها را پاک کنند محافظت کنید و رویه را آزمایش کنید. قویترین انتخاب آن است که از سناریوی تعریفشده شما جان سالم به در میبرد، نه آن که نام اطمینانبخشتری دارد.
چکلیست عملی شما.
- مشخص کنید داده قابل بازیابی کجا قرار دارد.
- خرابیهایی را که نسخه باید از آنها جان سالم به در ببرد فهرست کنید.
- از یک روش سازگاری مورد پشتیبانی برنامه استفاده کنید.
- نگهداری را برای پنجره کشف انتخاب کنید.
- حقوق حذف را جداگانه محافظت کنید.
- یک برنامه کامل را بهصورت جداگانه بازیابی کنید.
جزئیاتی که اهمیت دارند.
آیا اسنپشات هرگز پشتیبان نیست؟+
برخی پیادهسازیهای اسنپشات پشتیبان هستند. تمایز مفید، وابستگی ذخیرهسازی، نگهداری، مدل دسترسی و بازیابی آزمایششده آنهاست، نه فقط برچسب.
آیا یک بررسی موفقیتآمیز یکپارچگی اثبات میکند که برنامه کار خواهد کرد؟+
این فقط آنچه را که آن بررسی پوشش میدهد اثبات میکند. بازیابی برنامه، پیکربندی، مجوزها و روابط داده را جداگانه آزمایش کنید.
آیا باید پشتیبان را روی همان سرور نگه دارم؟+
یک نسخه روی همان سرور ممکن است برای اشتباهات محدود کمک کند، اما در خرابیهای مهم شریک است. دادههای مهم به یک مسیر بازیابی خارج از مرز خرابیای که قصد دارید از آن جان سالم به در ببرید نیاز دارند.
به منبع بروید.
این منابع از مفاهیم فنی این راهنما پشتیبانی میکنند. پیش از تغییر یک سیستم تولیدی، مستندات جاری را دنبال کنید.
- Amazon EBS: اسنپشاتها docs.aws.amazon.com
- PostgreSQL: بایگانی پیوسته و بازیابی نقطهای www.postgresql.org
- Restic: کار با مخازن و بررسیهای یکپارچگی restic.readthedocs.io
راهنمایی تحریریه توسط SwissOctet. مثالها نمایشی هستند. مشخصات خدمات، گزینههای موجود و شرایط قراردادی باید جداگانه تأیید شوند.