Borg یا Restic؛ بازیابی ۲۳ برابر سریع‌تر، مقصد ابری محدودتر

برای بازیابی کامل از دیسک محلی، Borg ارزش بررسی بیشتری دارد؛ برای ذخیرهٔ مستقیم نسخه‌ها در فضای شیءمحور، Restic انتخاب سرراست‌تری است. در آزمون محلی ComputingForGeeks، بازیابی مجموعه‌ای حدود ۳۷۰ مگابایتی با Borg برابر ۰٫۱۶ ثانیه و با Restic برابر ۳٫۶۷ ثانیه بود؛ یعنی Borg در همان آزمون نزدیک به ۲۳ برابر سریع‌تر بازیابی کرد. ساخت نخستین نسخه به‌ترتیب ۷٫۸۱ و ۸٫۱۰ ثانیه طول کشید و اوج حافظهٔ ثبت‌شده در این مرحله ۷۵ و ۱۱۱ مگابایت بود.

این نتیجه دربارهٔ بازیابی کامل از مخزن محلی است و سرعت بازیابی از شبکه یا فضای ابری را تعیین نمی‌کند. راهنمای مقصدهای Restic ایجاد مخزن محلی، اتصال SFTP و استفادهٔ مستقیم از S3، فضای سازگار با S3، Azure Blob و Google Cloud Storage را شرح می‌دهد. پس انتخاب میان این دو ابزار به محل نگهداری نسخه‌ها، نوع بازیابی موردنیاز و محدودیت حافظهٔ میزبان بستگی دارد.

اختلاف زمان بازیابی از کجا آمده است؟

آزمون یادشده روی یک ماشین مجازی اوبونتو با مخزن‌های تازه در فایل‌سیستم محلی انجام شد. مجموعهٔ آزمایشی فایل‌های کوچک و بزرگ و بخشی از ساختار سیستمی را در بر می‌گرفت؛ هر ابزار نیز با تنظیم رمزگذاری پیش‌فرض خود اجرا شد. برای بازیابی، کل نسخه در یک مسیر موقت استخراج و زمان واقعی اجرای فرمان اندازه‌گیری شد. این شرایط برای مقایسهٔ همان عملیات مشخص‌اند، اما نمایندهٔ مخزن قدیمی، دادهٔ بسیار بزرگ یا مقصدی پشت شبکه نیستند.

نزدیک بودن زمان نخستین پشتیبان‌گیری در کنار فاصلهٔ زیاد زمان استخراج نشان می‌دهد که سرعت ساخت نسخه به‌تنهایی معیار مناسبی برای بازگشت سرویس نیست. اگر کار عملیاتی به بازگرداندن یک درخت کامل فایل وابسته است، نتیجهٔ بازیابی کامل اهمیت زیادی پیدا می‌کند. اگر هنگام خرابی معمولاً چند فایل یا یک پوشه لازم می‌شود، باید زمان بازیابی انتخابی همان فایل‌ها را جدا سنجید؛ آزمون منتشرشده ترتیب عملکرد دو ابزار را برای این حالت مشخص نکرده است.

بخش بزرگی از دادهٔ آزمایش از محتوای تصادفی ساخته شده بود. چنین داده‌ای معمولاً فرصت کمی برای فشرده‌سازی می‌دهد و رفتار آن با فایل‌های متنی، گزارش‌های در حال تغییر یا مجموعه‌ای از نسخه‌های پایگاه داده یکسان نیست. همچنین آزمون روی دیسک محلی انجام شده بود؛ هنگام بازیابی از راه دور، انتقال داده و پاسخ‌گویی مقصد نیز وارد زمان کل می‌شوند. بنابراین نسبت سرعت مشاهده‌شده برای اولویت‌بندی یک آزمایش محلی مفید است، نه برای پیش‌بینی زمان رفع خرابی در هر زیرساخت.

حافظه و حذف دادهٔ تکراری چه اثری دارند؟

در نخستین پشتیبان‌گیری آزمون، اوج مصرف حافظهٔ Borg کمتر بود. این عدد، سقف مصرف ابزار در همهٔ مخزن‌ها نیست: اندازه و شمار فایل‌ها، تعداد نسخه‌ها و تغییرات داده می‌توانند بار کاری را عوض کنند. روی میزبان کم‌حافظه، اوج مصرف را هنگام ساخت نسخهٔ نخست، نسخهٔ بعدی و بازیابی آزمایشی ثبت کنید. اجرای بعدیِ بدون تغییر فایل‌ها فشار یک اجرای واقعی با تغییرات روزانه را نشان نمی‌دهد.

مستندات BorgBackup توضیح می‌دهد که Borg فایل‌ها را به قطعه‌های وابسته به محتوا تقسیم می‌کند، قطعهٔ تکراری را دوباره به مخزن نمی‌افزاید و داده را سمت کاربر رمزگذاری می‌کند. این سازوکار می‌تواند در نسخه‌های پیاپی از ذخیرهٔ دوبارهٔ محتوای یکسان جلوگیری کند. میزان صرفه‌جویی، بااین‌حال، به محتوای واقعی و مقدار تغییر میان نسخه‌ها وابسته است؛ صرف داشتن قابلیت حذف دادهٔ تکراری، برندهٔ مقایسهٔ حجم مخزن را تعیین نمی‌کند.

برای Restic، راهنمای رسمی فرمان stats تفاوت دو سنجه را روشن می‌کند: restore-size اندازهٔ فایل‌هایی را می‌شمارد که می‌توان بازیابی کرد و raw-data اندازهٔ قطعه‌های یکتای ذخیره‌شده را. مقایسهٔ این دو برای نسخه‌ها و مجموعه‌فایل‌های مشخص، اثر حذف دادهٔ تکراری را بهتر از حجم ظاهری یک نسخه نشان می‌دهد. اندازهٔ فیزیکی مخزن را هم جدا ثبت کنید، زیرا سربار نگهداری و فشرده‌سازی در آن اثر می‌گذارد.

برای دیسک محلی کدام انتخاب منطقی‌تر است؟

اگر مخزن روی دیسک متصل به میزبان یا مسیر فایل محلی قرار دارد و بازیابی کامل محدودیت اصلی است، Borg نقطهٔ شروع منطقی‌تری برای ارزیابی است. دلیل این ترجیح همان نتیجهٔ محدودِ استخراج محلی است، نه ادعای برتری همیشگی. هر دو ابزار در آزمون نخستین نسخه را با زمانی نزدیک به هم ساختند؛ مزیت عملی Borg در آن شرایط هنگام برگرداندن کل مجموعه دیده شد.

برای تصمیم روی دادهٔ خود، چند نسخه با تغییرات معمول بسازید و آن‌ها را در مسیری جدا از دادهٔ اصلی بازیابی کنید. زمان ساخت نسخه، زمان رسیدن فایل‌های حیاتی، بازیابی کامل، اوج حافظه و اندازهٔ مخزن را کنار هم بگذارید. بررسی درست بودن فایل‌های بازیابی‌شده نیز بخشی از همین سنجش است: استخراج سریع، اگر دادهٔ لازم را در وضعیت موردنیاز برنگرداند، به هدف بازیابی خدمت نمی‌کند.

نوع فایل در تفسیر حجم مخزن اهمیت ویژه‌ای دارد. مجموعه‌ای که بخش عمده‌اش میان نسخه‌ها ثابت می‌ماند، فرصت متفاوتی برای حذف دادهٔ تکراری نسبت به مجموعه‌ای با تغییرات گسترده دارد. برای همین، یک نسخهٔ نخست و یک اجرای کاملاً بدون تغییر تصویر کافی نمی‌دهند؛ نسخه‌ای پس از تغییر معمول داده‌ها، هزینهٔ واقعی‌تر نگهداری را نشان می‌دهد.

روی میزبان SSH چه تفاوتی ایجاد می‌شود؟

هر دو ابزار می‌توانند مخزن را روی میزبان راه‌دور نگه دارند، اما مسیر عملیاتی آن‌ها فرق دارد. راهنمای مخزن راه‌دور Borg نصب Borg روی میزبان مقصد را سریع‌ترین و ساده‌ترین روش معرفی می‌کند؛ اگر نصب آن ممکن نباشد، استفاده از فایل‌سیستم راه‌دورِ سوارشده، مانند sshfs، را هم توضیح می‌دهد. در مقابل، Restic با SFTP به مسیر مخزن روی میزبان SSH وصل می‌شود.

اگر تیم اجازهٔ نصب Borg روی مقصد پشتیبان را دارد، روش معمول آن می‌تواند مناسب باشد. اگر مقصد فقط دسترسی SFTP می‌دهد، Restic وابستگی کمتری به نرم‌افزار سمت مقصد دارد؛ روش جایگزین Borg با فایل‌سیستم سوارشده نیز خودش نیازمند راه‌اندازی و نگهداری است. این تفاوت برای میزبانی که مدیریت آن در اختیار تیم دیگری است، ممکن است از چند ثانیه اختلاف در آزمون دیسک محلی مهم‌تر باشد.

بازیابی آزمایشی در این حالت باید از همان اتصال راه‌دوری انجام شود که هنگام خرابی در دسترس خواهد بود. پهنای باند، تأخیر و توان میزبان مقصد می‌توانند زمان بازیابی را تغییر دهند. دسترسی به گذرواژه یا کلید مخزن را هم در همان شرایط بررسی کنید؛ وجود فایل‌های نسخهٔ پشتیبان به‌تنهایی برای بازگرداندن دادهٔ رمزگذاری‌شده کافی نیست.

برای فضای شیءمحور چرا Restic دست بالاتر را دارد؟

اگر مقصد اصلی S3 یا یک سرویس شیءمحور پشتیبانی‌شده است، Restic مخزن را مستقیم در آن سرویس ایجاد و استفاده می‌کند. مسیر معمول و مستند Borg بر مخزن محلی یا میزبان SSH تکیه دارد؛ برای رساندن نسخه‌های Borg به فضای شیءمحور باید لایه یا گردش‌کار دیگری به طرح اضافه شود. چنین لایه‌ای هنگام بازیابی هم باید در دسترس و درست پیکربندی شده باشد. مزیت Restic در این سناریو سادگی مسیر رسیدن به مقصد است، نه سرعت اثبات‌شدهٔ بازیابی ابری.

پشتیبانی مستقیم نیز هزینهٔ خواندن، شمار درخواست‌ها یا زمان دریافت داده را حذف نمی‌کند. برای بار کاری شیءمحور، بازیابی کامل و بازیابی فایل‌های ضروری را از همان سرویس و با همان نوع اتصال موردنظر اجرا کنید. اندازهٔ مخزن، اوج حافظه و مدت ساخت نسخه را همراه با زمان بازیابی نگه دارید تا روشن شود صرفه‌جویی در راه‌اندازی مقصد با عملکرد موردنیاز تیم همراه است یا نه.

انتخاب نهایی به محل واقعی مخزن برمی‌گردد: روی دیسک محلی، نتیجهٔ بازیابی کامل دلیل محکمی برای آزمودن Borg است؛ روی میزبان SSH، اختیار نصب نرم‌افزار در مقصد تعیین‌کننده می‌شود؛ و در فضای شیءمحور، پشتیبانی مستقیم Restic مسیر ساده‌تری فراهم می‌کند. در هر سه حالت، زمان بازیابیِ همان فایل‌هایی که بازگشت سرویس به آن‌ها وابسته است، از سرعت ساخت یک نسخهٔ آزمایشی گویاتر خواهد بود.

بیشتر بخوانید:

• RAG را درست ارزیابی کنید؛ یک امتیاز خوب می‌تواند خطای بازیابی را پنهان کند
• CapCut یا Descript؛ کلیپ سریع در برابر تدوین با متن
• Google ADK یا OpenAI Agents SDK؛ اکوسیستم ابری انتخاب را عوض می‌کند