عملیات پشتیبان‌گیری هم یک منبع است
در معماری Velero، عملیات‌هایی مانند Backup و Restore با منابع سفارشی Kubernetes توصیف می‌شوند و کنترل‌گرها آن‌ها را پردازش می‌کنند. منابع انتخاب‌شده خوشه جمع‌آوری و اطلاعات پشتیبان در محل ذخیره‌سازی تنظیم‌شده نگهداری می‌شود. تهیه نسخه از داده حجم‌ها به روش و افزونه‌های ذخیره‌سازی انتخابی بستگی دارد.
راهنمای رسمی تصریح می‌کند که نسخه پشتیبان خوشه الزاماً یک تصویر کاملاً اتمی از همه منابع نیست. اگر هنگام تهیه پشتیبان، منابع تغییر کنند، باید احتمال ناسازگاری میان بخش‌ها را در نظر گرفت. Hookها می‌توانند برای هماهنگی با برنامه به کار روند، اما وجود یک hook به‌تنهایی سازگاری همه برنامه‌ها را تضمین نمی‌کند.
سه پرسش جداگانه
برای ارزیابی نتیجه، این سه پرسش را جدا پاسخ دهید: آیا تعریف منابع موردنیاز ثبت شده است؟ آیا داده پایدار مربوط به آن‌ها نیز قابل بازیابی است؟ آیا برنامه با داده بازگردانده‌شده به‌درستی کار می‌کند؟ پاسخ مثبت به پرسش اول، دو پاسخ بعدی را ثابت نمی‌کند.
در restore به خوشه دیگر، نسخه API، افزونه‌ها، کلاس ذخیره‌سازی و وابستگی‌های خارجی اهمیت دارند. تغییر namespace نیز به‌تنهایی همه نشانی‌های ثابت یا ارتباط‌های بیرونی برنامه را اصلاح نمی‌کند.
آزمایش فرضی یک برنامه سفارش
یک برنامه آزمایشی با پایگاه داده و فایل پیوست در نظر بگیرید. پیش از backup، یک سفارش با شناسه مشخص و یک فایل با محتوای معلوم ایجاد کنید. بعد از پایان کار، آن را در مقصدی جدا بازیابی کنید؛ نه روی همان نصب اصلی که ممکن است داده قدیمی آن خطا را پنهان کند.
معیار پذیرش را از پیش بنویسید: سفارش خوانده شود، فایل صحیح دریافت شود و برنامه بتواند یک عملیات تازه انجام دهد. صرف ایجاد شدن PVC یا Running شدن Pod، نتیجه کامل بازیابی نیست. زمان آماده‌شدن برنامه را نیز ثبت کنید تا هدف زمانی بازیابی بر حدس تکیه نکند.
خطا را عمداً قابل مشاهده کنید
در محیط غیرعملیاتی، یک مجوز لازم برای مقصد پشتیبان را موقتاً بردارید و بررسی کنید شکست چگونه گزارش می‌شود. سپس مجوز صحیح را برگردانید و مطمئن شوید مسئول عملیات از وضعیت ناموفق آگاه شده است. هشدار بدون گیرنده مشخص، عملاً بخشی ناقص از طراحی است.
پیشنهاد نگهداری
روش حذف نسخه‌های قدیمی، مسئول نگهداری اعتبارنامه مقصد و آزمون دوره‌ای restore را در یک دستورالعمل قرار دهید. پیش از ارتقای پلتفرم، از سازگاری APIهای ذخیره‌شده با مقصد مطمئن شوید. پشتیبان خوب، مجموعه‌ای از فایل‌ها نیست؛ روشی آزموده‌شده برای بازگشت یک خدمت قابل استفاده است.
بازیابی را از نیاز برنامه تعریف کنید
پیش از ساخت برنامه زمان‌بندی پشتیبان، دو عدد عملیاتی را تعیین کنید: چه مقدار داده از دست‌رفته قابل تحمل است و خدمت در چه مدت باید برگردد؟ عدد نخست به فاصله نسخه‌های قابل بازیابی مربوط است و عدد دوم به کل فرایند بازسازی وابستگی‌ها، داده و دسترسی کاربران. داشتن فایل پشتیبان تازه به تنهایی زمان بازیابی کوتاه را تضمین نمی‌کند. اگر دانلود حجم بزرگ، ساخت دیسک یا بازسازی شاخص پایگاه داده ساعت‌ها طول بکشد، این زمان باید در تمرین اندازه‌گیری شود. از مقدار تبلیغاتی یا زمان یک آزمایش بسیار کوچک برای محیط واقعی استفاده نکنید.
برای مثال، یک برنامه شامل استقرار وب، راز اتصال، تنظیمات، ادعای فضای ذخیره و پایگاه داده را در نظر بگیرید. فهرست منابع Kubernetes فقط بخشی از خدمت است. نام دامنه، گواهی بیرونی، مخزن تصویر، پایگاه داده مدیریت‌شده یا کلید رمزگشایی ممکن است خارج از دامنه پشتیبان باشند. یک نقشه وابستگی بسازید و برای هر مورد بنویسید چگونه بازسازی یا بازیابی می‌شود. این نقشه باید نشان دهد اگر خوشه کاملاً از بین برود، چه چیزهایی هنوز در دسترس هستند و چه چیزهایی نباید به همان خوشه وابسته باشند.
نسخه منابع با نسخه داده یکی نیست
ذخیره تعریف یک PersistentVolumeClaim به معنی ذخیره محتوای دیسک آن نیست. تعریف می‌گوید برنامه چه فضایی می‌خواهد؛ داده واقعی در سامانه ذخیره‌سازی قرار دارد. روش حفاظت داده ممکن است تصویر لحظه‌ای ارائه‌دهنده، انتقال داده از تصویر یا پشتیبان فایل باشد. هر روش محدودیت و وابستگی خود را دارد. پیش از انتخاب، بررسی کنید در محیط مقصد همان فراهم‌کننده و قابلیت در دسترس است یا نه. نسخه‌ای که فقط در حساب و منطقه مبدأ قابل استفاده است ممکن است برای خرابی کامل آن دامنه کافی نباشد.
برای روشن شدن تفاوت، در محیط آزمایشی یک فایل با محتوای مشخص روی حجم بنویسید و مقدار کنترل آن را ثبت کنید. پس از پشتیبان‌گیری، هم تعریف منابع و هم وجود داده در مقصد را بررسی کنید. سپس بازیابی را در فضای نام جدا انجام دهید و فایل را با مقدار ثبت‌شده مقایسه کنید. اگر پاد بالا آمده ولی داده اولیه را ندارد، بازیابی خدمت موفق نیست. وضعیت ظاهری منابع نباید جای آزمون محتوای کاربردی را بگیرد. برای پایگاه داده نیز اجرای یک پرس‌وجوی معنادار بهتر از صرف اتصال موفق است.
سازگاری برنامه هنگام ثبت نسخه
یک تصویر لحظه‌ای از دیسک ممکن است از نظر ذخیره‌سازی معتبر باشد، اما برنامه در میانه نوشتن چند فایل مرتبط بوده باشد. پایگاه داده‌ها روش‌های خاصی برای بازیابی پس از قطع ناگهانی یا گرفتن نسخه سازگار دارند. باید مشخص کنید روش انتخابی چه تضمینی می‌دهد و آیا برای برنامه شما کافی است. قلاب‌های پیش و پس از پشتیبان می‌توانند برای هماهنگی مفید باشند، ولی هر فرمان توقف یا تخلیه باید رفتار شکست و مهلت انتظار مشخص داشته باشد. توقفی که پس از خطا آزاد نشود می‌تواند خود باعث اختلال شود.
برای داده حساس، روش بومی پشتیبان پایگاه داده ممکن است مکمل ضروری نسخه زیرساخت باشد. مثلاً نیاز به بازیابی نقطه زمانی با یک تصویر دوره‌ای یکسان نیست. نسخه منابع خوشه، نسخه داده و گزارش تراکنش‌ها باید از نظر زمان و سازگاری با هم بررسی شوند. در تمرین، یک رکورد پیش از نسخه و یک رکورد پس از آن ایجاد کنید و ببینید مقصد دقیقاً کدام را دارد. این آزمایش ساده مرز واقعی بازیابی را آشکار می‌کند و از عبارت مبهم «همه‌چیز برگشت» جلوگیری می‌کند.
انتخاب دامنه بدون جا انداختن وابستگی‌ها
فیلتر فضای نام، نوع منبع یا برچسب برای محدود کردن دامنه مفید است، اما می‌تواند وابستگی مهم را کنار بگذارد. برنامه‌ای که به یک منبع مشترک در سطح خوشه وابسته است با ذخیره فقط فضای نام خودش کامل نمی‌شود. در مقابل، بازیابی همه منابع سطح خوشه روی محیط زنده می‌تواند با تنظیمات موجود تعارض ایجاد کند. پیش از اجرا، فهرست انتخاب‌شده و موارد حذف‌شده را بازبینی کنید. هر حذف باید دلیل روشن داشته باشد، نه اینکه صرفاً از یک نمونه تنظیم اینترنتی کپی شده باشد.
در خوشه مقصد، تعریف انواع منابع سفارشی و کنترل‌گرهای مربوط باید آماده باشند. وجود شیء سفارشی بدون کنترل‌گر ممکن است هیچ اثر اجرایی ایجاد نکند. همچنین نام کلاس ذخیره‌سازی، نشانی سامانه بیرونی و سیاست شبکه ممکن است با مبدأ فرق داشته باشد. تغییر نام یا نگاشت مورد نیاز را در یک دستورالعمل تکرارپذیر ثبت کنید. ویرایش دستی پس از هر بازیابی باعث می‌شود زمان و نتیجه به حافظه اپراتور وابسته شود. تمرین در محیط تازه بهترین راه کشف این وابستگی‌های پنهان است.
حفاظت از مقصد پشتیبان
مخزن پشتیبان معمولاً اطلاعات حساس فراوانی دارد، از تنظیمات تا رازهای برنامه. دسترسی خواندن آن را مانند دسترسی به داده اصلی جدی بگیرید. حسابی که برای نوشتن نسخه استفاده می‌شود لزوماً نباید امکان حذف همه تاریخچه را داشته باشد. جداسازی اختیار حذف، نگهداری نسخه و دسترسی بازیابی می‌تواند اثر اشتباه یا نفوذ را محدود کند. روش دقیق به سامانه ذخیره‌سازی و قابلیت‌های آن بستگی دارد، بنابراین مجوزها را با عملیات واقعی آزمایش کنید و صرف نام نقش را کافی ندانید.
کلید رمزگشایی نیز باید بیرون از تنها محیطی که ممکن است از دست برود قابل بازیابی باشد. نسخه رمز‌شده بدون کلید، در روز حادثه قابل استفاده نیست. از سوی دیگر، گذاشتن کلید کنار همان نسخه با دسترسی یکسان، جداسازی مطلوب را تضعیف می‌کند. یک تمرین با حساب بازیابی مستقل انجام دهید: آیا اپراتور مجاز می‌تواند بدون تکیه به رازهای خوشه خراب، نسخه را بخواند و خدمت را بالا بیاورد؟ این پرسش هم امنیت و هم دسترس‌پذیری را به صورت عملی می‌سنجد.
خطاهای جزئی را در موفقیت کلی گم نکنید
یک عملیات ممکن است کامل شود اما هشدار یا خطای مربوط به بعضی منابع داشته باشد. وضعیت خلاصه را همراه جزئیات عملیات بخوانید. اگر حجم خاصی کنار گذاشته شده، باید بدانید آن حجم چه داده‌ای داشته است. شمار منابع انتخاب‌شده، منابع ذخیره‌شده و خطاهای هر افزونه را مقایسه کنید. افزایش ناگهانی زمان عملیات نیز می‌تواند نشانه فشار ذخیره‌سازی، کندی شبکه یا رشد داده باشد. زمان پشتیبان را فقط برای زمان‌بندی استفاده نکنید؛ روند آن سرنخ ظرفیت آینده است.
در زمان بازیابی، روی محیط جدا کار کنید تا اجرای همزمان دو نمونه برنامه به سامانه بیرونی آسیب نزند. یک برنامه بازیابی‌شده ممکن است فوراً ایمیل بفرستد، کار زمان‌بندی‌شده اجرا کند یا داده‌ای در سامانه اصلی بنویسد. پیش از باز کردن دسترسی، ارتباط‌های خروجی و کارهای پس‌زمینه را کنترل کنید. پس از تأیید داده و سلامت، تغییر مسیر کاربران باید مرحله‌ای و قابل بازگشت باشد. بازیابی فنی منابع و اعلام آمادگی خدمت دو نقطه جدا در فرایند هستند.
تمرین دوره‌ای با نتیجه قابل سنجش
تمرین خوب از حذف تصادفی یک فایل فراتر می‌رود. یک سناریو مانند از دست رفتن فضای نام یا خرابی کامل خوشه انتخاب کنید و از فرد دیگری بخواهید تنها با دستورالعمل موجود بازیابی کند. زمان یافتن نسخه، آماده کردن مقصد، انتقال داده و تأیید برنامه را جدا ثبت کنید. اگر مرحله‌ای نیاز به تماس با نویسنده دارد، آن وابستگی را اصلاح کنید. نتیجه باید شامل نسخه واقعاً استفاده‌شده، داده قابل بازیابی و زمان بازگشت خدمت باشد. این شواهد تعیین می‌کنند برنامه پشتیبان با نیاز سازمان سازگار است یا فقط مجموعه‌ای از عملیات سبزرنگ در داشبورد تولید می‌کند.
نگهداری نسخه و آزمون حذف
سیاست نگهداری را با نیاز بازیابی و هزینه ذخیره‌سازی هماهنگ کنید. حذف یک نسخه قدیمی نباید نسخه دیگری را که به آن وابسته است غیرقابل استفاده کند؛ رفتار روش ذخیره‌سازی انتخابی را بررسی کنید. همچنین زمان پایان اعتبار یک عملیات را با زمان حذف واقعی داده در مقصد یکسان فرض نکنید. یک نسخه آزمایشی کوتاه‌عمر بسازید و مسیر پاک‌سازی آن را تا مقصد دنبال کنید. اگر نسخه‌های قدیمی باقی می‌مانند، علت می‌تواند مجوز حذف، قفل نگهداری یا اختلال کنترل‌گر باشد. این وضعیت هم هزینه دارد و هم ممکن است برخلاف انتظار تیم درباره حذف داده باشد. گزارش ظرفیت باید رشد نسخه‌ها، خطاهای پاک‌سازی و نزدیک شدن به محدودیت مخزن را پوشش دهد تا روز بازیابی با مقصد پر یا تاریخچه ناقص مواجه نشوید.
