restic و هدف نسخهٔ پشتیبان قابل بازیابی
restic برنامهٔ خط فرمان برای تهیه و بازگردانی نسخهٔ پشتیبان است. جریان پایهٔ کار شامل ساخت repository، ثبت snapshot از داده و بازیابی snapshot انتخابی است. repository مجموعه‌ای از داده، فراداده و اطلاعات کلید را نگه می‌دارد و می‌تواند در محل محلی یا یکی از مقصدهای پشتیبانی‌شده قرار بگیرد. مزیت عملی این شیوه زمانی دیده می‌شود که کاربر بخواهد فرایند پشتیبان را قابل تکرار و قابل بررسی کند. با این حال، نصب ابزار و اجرای یک backup هنوز برنامهٔ کامل بازیابی از حادثه نیست.
پیش از انتخاب مقصد یا زمان‌بندی، دو سؤال عملی مطرح است: چه مقدار تغییر داده را می‌توانید از دست بدهید و چه مدت می‌توانید منتظر بازگشت سرویس بمانید؟ پاسخ این سؤال‌ها فاصلهٔ اجرای پشتیبان و طراحی بازیابی را شکل می‌دهد. برای یک پوشهٔ شخصی، بازیابی چند فایل ممکن است کافی باشد؛ برای یک خدمت آنلاین، داده، تنظیمات و وابستگی‌های برنامه باید با هم قابل استفاده شوند. ارزیابی restic باید از این نیاز واقعی آغاز شود، نه از تعداد فرمان‌هایی که ابزار دارد.
repository، snapshot و جداسازی مقصد
در مستند رسمی، repository محل نگهداری نسخه‌هاست و دسترسی به آن به گذرواژه یا کلید معتبر نیاز دارد. هر snapshot نمایی از مجموعهٔ انتخاب‌شده در یک اجرای پشتیبان ارائه می‌کند. بهتر است از ابتدا نام‌گذاری میزبان، مسیرهای مبنا و برچسب‌ها را منظم انتخاب کنید تا بعدها بتوانید snapshot مورد نظر را تشخیص دهید. چندین نسخه با نام‌های مبهم، در لحظهٔ بحران ارزش کمتری از مجموعه‌ای دارند که زمان، منبع و هدف آن روشن است.
مقصد پشتیبان را در برابر همان حادثه‌ای که منبع را تهدید می‌کند بسنجید. یک repository روی همان دیسک، ممکن است برای بازگرداندن حذف اشتباه مفید باشد، اما خرابی همان دیسک هر دو را از دسترس خارج می‌کند. مقصد شبکه‌ای نیز اگر با همان اعتبارنامهٔ گسترده قابل حذف باشد، ممکن است در تسخیر حساب آسیب ببیند. این‌ها ویژگی مختص restic نیستند؛ مسائل طراحی پشتیبان‌اند. جداسازی محل، حساب و اختیار حذف باید بر اساس تهدید و توان عملیاتی شما انتخاب شود.
محدودهٔ داده را پیش از اجرا تعریف کنید
فهرست ورودی باید از نیاز بازیابی ساخته شود. پوشهٔ برنامه ممکن است همهٔ داده را در خود نداشته باشد؛ پایگاه داده، فایل‌های بارگذاری‌شده، تنظیمات خارج از مسیر نصب و کلیدهای لازم برای راه‌اندازی می‌توانند جای دیگری باشند. برای هر قلم بنویسید چرا لازم است و چه کسی مالک آن است. سپس فایل‌های موقت و داده‌های قابل تولید دوباره را با احتیاط از دادهٔ ضروری جدا کنید. هدف حذف بیشترین حجم نیست، بلکه داشتن مجموعه‌ای کامل و قابل فهم برای بازسازی است.
قواعد exclude را مانند کد حساس بازبینی کنید. یک الگوی بیش از حد گسترده ممکن است پوشه‌ای مهم را بدون جلب توجه کنار بگذارد. برای آزمون، فایل‌های نماینده از مسیرهای مهم انتخاب کنید و بعد از اجرا، حضورشان را در snapshot بررسی کنید. تغییر ساختار برنامه یا نام پوشه‌ها باید بازبینی همین قواعد را هم فعال کند. اگر سامانهٔ تولید داده تغییر کند ولی برنامهٔ پشتیبان ثابت بماند، ممکن است موفقیت فنی اجرا با ناقص بودن پوشش همراه شود.
دادهٔ در حال تغییر و سازگاری برنامه
کپی فایل‌ها همیشه معادل نسخهٔ سازگار یک برنامهٔ فعال نیست. به‌ویژه برای پایگاه داده یا مجموعه‌ای از فایل‌های وابسته، باید از روش پشتیبان مورد تأیید همان برنامه استفاده کنید. پیشنهاد عملی این است که ابتدا خروجی سازگار یا snapshot مناسب در لایهٔ برنامه و فایل‌سیستم ایجاد شود و سپس restic دادهٔ آماده را حفظ کند. روش دقیق به نرم‌افزار وابسته است و نباید یک دستور عمومی برای همهٔ پایگاه‌های داده پیشنهاد کرد.
راهنمای restic امکان گرفتن خروجی یک فرمان را توضیح می‌دهد و دربارهٔ خطر پنهان شدن خطای تولیدکنندهٔ داده در pipeline هشدار می‌دهد. اگر فرمان استخراج داده شکست بخورد ولی مرحلهٔ ذخیره خروجی خالی را بپذیرد، ظاهر موفق کار می‌تواند گمراه‌کننده باشد. طراحی اتوماسیون باید خطای همهٔ مراحل را بررسی کند. علاوه بر کد خروج، حجم غیرعادی کم یا نبود اقلام مورد انتظار را نیز به عنوان نشانهٔ نیازمند بررسی ثبت کنید؛ هر کدام به تنهایی حکم قطعی نیستند.
رمزگذاری و دو دسته اعتبارنامه
گذرواژهٔ repository و اعتبارنامهٔ دسترسی به مقصد ذخیره‌سازی دو موضوع جدا هستند. اولی برای باز کردن دادهٔ پشتیبان و دومی برای ارتباط با محل نگهداری استفاده می‌شود. ممکن است یکی سالم باشد و دیگری از دست رفته باشد، در حالی که بازیابی به هر دو نیاز دارد. مستندات restic روش‌هایی برای فراهم کردن گذرواژه در اجرای خودکار و مدیریت چند کلید دسترسی به repository دارند. انتخاب روش باید با سامانهٔ مدیریت راز و سطح دسترسی محیط هماهنگ باشد.
گذرواژه را در فرمان قابل مشاهده، گزارش عمومی یا مخزن کد قرار ندهید. اگر برای اجرای خودکار از فایل یا سامانهٔ راز استفاده می‌شود، مالکیت و مجوز خواندن آن را محدود کنید و نسخهٔ بازیابی امن داشته باشید. تنها نسخهٔ اطلاعات لازم برای باز کردن پشتیبان نباید داخل همان پشتیبان قفل شود. همچنین داشتن رمزگذاری به معنی جلوگیری از حذف repository نیست؛ شخص دارای اختیار حذف مقصد ممکن است دادهٔ رمزگذاری‌شده را نابود کند، حتی اگر نتواند محتوای آن را بخواند.
زمان‌بندی و تشخیص اجرای ناقص
restic خودش daemon زمان‌بندی نیست و مستندات برای اجرای دوره‌ای به ابزارهای سیستم‌عامل یا ابزارهای همراه اشاره می‌کنند. زمان‌بندی باید علاوه بر ساعت اجرا، وضعیت اجرای قبلی، احتمال هم‌پوشانی و زمان مجاز تأخیر را در نظر بگیرد. اگر پشتیبان یک روز بیش از معمول طول بکشد، شروع اجرای بعدی بدون کنترل می‌تواند بار و ابهام ایجاد کند. برای لپ‌تاپ، خاموش بودن دستگاه یا نبود شبکه نیز باید در طراحی لحاظ شود؛ ساعت ثبت‌شده در تقویم تضمین اجرای واقعی نیست.
وجود snapshot تازه تنها معیار موفقیت نیست. مستندات کد خروجی متمایز برای موفقیت، خطای جدی و خوانده نشدن بخشی از فایل‌ها دارند؛ در حالت آخر ممکن است snapshot ناقص ساخته شود. پایش باید تفاوت این وضعیت‌ها را حفظ کند. پیامی مانند «کار تمام شد» اگر خطاهای خواندن را پنهان کند به کاربر اطمینان کاذب می‌دهد. گزارش مفید باید آخرین اجرای کامل، خطاهای حل‌نشده و فاصلهٔ زمانی از آخرین نقطهٔ قابل اتکا را نشان دهد.
بررسی سلامت با آزمون بازیابی متفاوت است
فرمان check در حالت معمول سازگاری ساختاری repository را می‌سنجد. مستندات برای خواندن و بررسی دادهٔ واقعی، گزینهٔ read-data و برای بخشی از داده گزینه‌های مربوط را توضیح می‌دهند. بررسی کامل می‌تواند زمان و ترافیک بیشتری مصرف کند، بنابراین باید در برنامهٔ نگهداری دیده شود. موفقیت بررسی ساختار را به معنی خوانده شدن تمام محتوای ذخیره‌شده اعلام نکنید. نوع آزمون، تاریخ و دامنهٔ آن باید در گزارش سلامت نوشته شود تا معنای نتیجه روشن بماند.
حتی بررسی کامل داده نیز آزمون کاربردی بازیابی سرویس نیست. ممکن است فایل‌ها صحیح باشند ولی نسخهٔ برنامه، مجوزها یا تنظیمات لازم برای استفاده از آن‌ها در دسترس نباشد. به همین دلیل، یک چرخهٔ مستقل برای بازگردانی نمونه‌ها لازم است. برای اسناد، باز شدن و محتوای صحیح را بررسی کنید؛ برای سرویس، راه‌اندازی در محیط جدا و اجرای چند عملیات واقعی با دادهٔ آزمایشی را بسنجید. این کار فاصلهٔ میان سلامت ذخیره و قابلیت ادامهٔ کار را آشکار می‌کند.
بازیابی مرحله‌ای و جلوگیری از بازنویسی ناخواسته
در مستند بازیابی، انتخاب snapshot و مقصد بازگردانی بخش اصلی فرایند است. پیشنهاد عملی این است که در تمرین و در بسیاری از رخدادها، ابتدا به مسیر جدا بازیابی کنید و محتوا را بررسی کنید. بازگردانی مستقیم روی مسیر زنده بدون شناخت وضعیت فعلی می‌تواند تغییرات تازه را بازنویسی یا با دادهٔ قبلی مخلوط کند. نام میزبان، مسیر و زمان snapshot را دوباره تطبیق دهید؛ انتخاب آخرین نسخه همیشه درست نیست، به‌خصوص اگر خرابی یا حذف مدتی پیش آغاز شده باشد.
برای بازیابی یک سرویس، ترتیب کار را از پیش بنویسید: آماده کردن محیط، دسترسی به repository، بازگرداندن داده، تنظیم مجوزها و آزمون برنامه. زمان هر مرحله را در تمرین اندازه بگیرید. سرعت دانلود خام تنها بخشی از زمان بازگشت است؛ یافتن رمز، آماده کردن میزبان و تأیید صحت داده می‌تواند سهم بزرگی داشته باشد. اگر فقط یک نفر روش را بلد است، غیبت او یک وابستگی عملیاتی مهم است. راهنمای قابل اجرا برای فرد جایگزین بخشی از دارایی پشتیبان محسوب می‌شود.
سیاست نگهداری و تفاوت forget با prune
restic حذف اشاره به snapshot را با forget و پاک‌سازی دادهٔ دیگر استفاده‌نشده را با prune از هم جدا می‌کند. مستندات امکان پیش‌نمایش سیاست حذف با dry-run را نیز بیان می‌کنند. این تفکیک مهم است، چون حذف snapshot لزوماً بلافاصله فضای متناظر را آزاد نمی‌کند. از طرف دیگر، اجرای پاک‌سازی را نباید اقدام بی‌اثر فرض کرد. سیاست نگهداری باید قبل از اتوماسیون روی فهرست واقعی snapshotها بررسی و با نیاز بازیابی تطبیق داده شود.
برای تعیین مدت نگهداری، فاصلهٔ کشف خطا را در نظر بگیرید. اگر حذف اشتباه معمولاً هفته‌ها بعد دیده می‌شود، نگه‌داشتن فقط چند نسخهٔ نزدیک کافی نیست. دادهٔ فصلی یا پروژه‌ای ممکن است به نقاط زمانی خاص نیاز داشته باشد. در repository مشترک، گروه‌بندی و فیلتر سیاست باید دقیق بررسی شود تا یک قاعده ناخواسته روی میزبان یا مسیر دیگری اعمال نشود. پیش‌نمایش را ذخیره کنید و برای تغییر مهم سیاست، بازبینی شخص دوم داشته باشید؛ این یک کنترل عملیاتی پیشنهادی است.
ظرفیت، هزینه و رفتار در خطا
علاوه بر حجم فعلی داده، رشد، نرخ تغییر، فضای موقت عملیات و هزینهٔ انتقال را بسنجید. در مقصد ابری ممکن است هزینهٔ خواندن یا خروج داده هنگام بررسی و بازیابی اهمیت پیدا کند. برآورد فقط بر اساس حجم اولیه می‌تواند ناکافی باشد. یک دورهٔ آزمایشی با دادهٔ نماینده اجرا کنید و زمان backup، check و restore را جدا اندازه بگیرید. نتیجهٔ این آزمایش برای انتخاب مقصد و زمان‌بندی از عددهای عمومی سرعت مفیدتر است.
اگر repository خطا گزارش کرد، ابتدا وضعیت و پیام را حفظ کنید و راهنمای عیب‌یابی رسمی را دنبال کنید. دستکاری فایل‌های داخلی یا حذف فایل قفل بدون بررسی اجرای فعال می‌تواند خطر تازه بسازد. عملیات تعمیر باید با شناخت دامنه و در صورت امکان روی نسخهٔ محافظت‌شده انجام شود. همچنین پر شدن مقصد یا قطع شبکه باید به اعلان قابل پیگیری منجر شود، نه سکوت. مسئول رسیدگی و مهلت واکنش باید پیش از نخستین خطا تعیین شده باشد.
معیار پذیرش یک استقرار واقعی
restic برای کاربری مناسب است که ابزار خط فرمان و اتوماسیون را می‌پذیرد و می‌خواهد نسخه‌های پشتیبان را در مقصدهای مختلف مدیریت کند. اگر نیاز به گردش کار کاملاً گرافیکی یا مدیریت متمرکز خاص دارید، رابط‌ها و ابزارهای همراه را جدا ارزیابی کنید و قابلیت آن‌ها را به هستهٔ restic نسبت ندهید. ابزار خوب تنها یکی از اجزای سامانهٔ پشتیبان است؛ انتخاب داده، مجوز مقصد، پایش و آزمون بازگردانی در اختیار تیم باقی می‌مانند.
تحویل قابل قبول باید نشان دهد چه چیزی پشتیبان می‌شود، چه چیزی نمی‌شود، آخرین اجرای کامل کدام است و چگونه یک فایل یا سرویس برمی‌گردد. حداقل یک آزمون بازیابی توسط فردی غیر از نویسندهٔ اسکریپت انجام دهید و ابهام‌های راهنما را اصلاح کنید. هیچ فرمان موفقی به تنهایی تضمین نمی‌کند که سازمان در حادثه آماده است. توصیه‌های عملی این مقاله تحلیل تحریریه‌اند؛ رفتار گزینه‌ها و سازگاری مقصد باید از مستندات نسخهٔ نصب‌شده بررسی شود.
