BorgBackup برای چه مسئله‌ای مناسب است؟
فرض کنید چند سرور لینوکسی دارید و می‌خواهید از تنظیمات، اسناد و خروجی پایگاه داده نسخه‌های روزانه نگه دارید. هر روز بیشتر فایل‌ها ثابت‌اند، ولی باید بتوان وضعیت یک روز مشخص را جداگانه بازیابی کرد. BorgBackup برای ساخت آرشیوهای نسخه‌دار با حذف داده تکراری، فشرده‌سازی و امکان رمزگذاری طراحی شده است. در این مقاله، هدف یادگیری چرخه کامل یک مخزن آزمایشی است: ساخت، ثبت دو آرشیو، دیدن تفاوت مصرف، استخراج در مسیر جدا و کنترل سلامت. نگهداری نسخه‌ها و دسترسی به کلید نیز بخشی از همین چرخه‌اند.
فرمان‌های این راهنما مطابق شاخه پایدار مستندات Borg با نحو نسل اول نوشته شده‌اند؛ در نسخه‌ای که نصب می‌کنید ابتدا خروجی نسخه و راهنمای همان نسخه را بررسی کنید. دستورهای شاخه‌های اصلی متفاوت را بدون تطبیق کنار هم قرار ندهید. این موضوع هنگام استفاده از بسته توزیع لینوکس مهم است، چون نسخه بسته الزاماً با تازه‌ترین مستند آنلاین یکسان نیست. هدف آزمایش این است که رفتار نصب خودتان را بشناسید و سپس آن را به عملیات واقعی تبدیل کنید.
تفاوت مخزن و آرشیو
مخزن، محل نگهداری ساختاریافته داده و فراداده Borg است. هر اجرای create یک آرشیو مشخص ایجاد می‌کند که فایل‌های انتخاب‌شده را توصیف می‌کند. چند آرشیو می‌توانند بخش‌های مشترک داده را در یک مخزن استفاده کنند؛ بنابراین اندازه ظاهری مجموع فایل‌ها با فضای یکتای ذخیره‌شده برابر نیست. این اشتراک به معنی وابستگی نسخه جدید به اجرای یک زنجیره بازیابی دستی نیست: کاربر آرشیو مورد نظر را انتخاب می‌کند و Borg بخش‌های لازم را از مخزن می‌خواند.
بااین‌حال، خراب شدن بخش مشترک می‌تواند بیش از یک آرشیو را تحت تأثیر قرار دهد. داشتن نام‌های متعدد در فهرست آرشیو، جای نسخه مستقل در محل دیگر را نمی‌گیرد. برای طراحی ظرفیت، اندازه اولیه داده، نرخ تغییر و قابلیت فشرده‌شدن را جدا در نظر بگیرید. آرشیو فایل‌های از قبل فشرده یا رمزگذاری‌شده ممکن است صرفه‌جویی کمتری از مجموعه متن و تنظیمات داشته باشد. بهتر است چند اجرای نماینده انجام دهید و رشد واقعی مخزن را مبنای برآورد قرار دهید.
انتخاب مسیر و حساب اجرا
برای شروع، یک پوشه ورودی کم‌حجم و غیرحساس و یک مسیر مقصد تازه انتخاب کنید. مقصد را داخل همان پوشه ورودی قرار ندهید. اجرای آزمایشی با حساب معمولی برای فایل‌های همان کاربر کافی است؛ برای خواندن فایل‌های متعلق به دیگران یا بخش‌های سیستم ممکن است مجوز بیشتری لازم باشد. مستندات Borg توصیه می‌کند مخزن و حافظه محلی آن با حساب یکسان مدیریت شوند تا مشکلات مالکیت ایجاد نشود. اجرای گاه‌به‌گاه با root و گاهی با کاربر عادی می‌تواند همین نظم را به هم بزند.
قبل از اجرای فرمان، بررسی کنید مقصد واقعاً روی دیسک مورد انتظار mount شده است. اگر مسیر دیسک پشتیبان وجود داشته باشد ولی mount انجام نشده باشد، نوشتن روی پوشه زیرین می‌تواند دیسک سیستم را پر کند. این کنترل را در اسکریپت عملیاتی هم حفظ کنید. برای آزمایش آموزشی، محل محلی ساده است، اما برای حفاظت از خرابی دیسک منبع باید نسخه‌ای در مقصد مستقل داشته باشید. انتخاب محل ذخیره را بر اساس نوع خرابی مورد انتظار انجام دهید، نه فقط آسان بودن دسترسی.
ساخت مخزن رمزگذاری‌شده و اولین آرشیو
در نمونه زیر همه مسیرها آموزشی‌اند. پیش از استفاده، آن‌ها را با پوشه‌های آزمایشی خود جایگزین کنید. اگر مقصد از قبل مخزن دارد، دوباره آن را به‌عنوان مخزن تازه مقداردهی نکنید؛ ابتدا وضعیت موجود را بررسی کنید. حالت repokey در این نحو، کلید رمزگذاری را به‌صورت محافظت‌شده در مخزن نگه می‌دارد و گذرواژه برای دسترسی لازم است. انتخاب حالت رمزگذاری باید از ابتدا آگاهانه انجام شود و به یک فرمان کپی‌شده محدود نماند.
borg --version
borg init --encryption=repokey /srv/borg-lab
borg create --stats /srv/borg-lab::day-one /srv/demo-data
borg list /srv/borg-lab
گذرواژه را در اعلان تعاملی وارد کنید و آن را داخل خط فرمان، تاریخچه پوسته یا گزارش عمومی قرار ندهید. نام آرشیو باید واضح و در مخزن قابل تشخیص باشد. برای محیط چندمیزبانه، ترکیب نام میزبان و زمان می‌تواند از برخورد نام‌ها و اشتباه در انتخاب جلوگیری کند. خروجی آماری را ذخیره کنید تا اندازه اولیه و مدت اجرا معلوم باشد. سپس یک فایل آزمایشی را تغییر دهید و آرشیو دوم بسازید؛ این آزمایش کوچک، تفاوت داده پردازش‌شده و داده یکتای افزوده‌شده را نشان می‌دهد.
خواندن آمار بدون برداشت اشتباه
آمار Borg اندازه اصلی، اندازه فشرده و اندازه حاصل از حذف داده تکراری را از هم جدا می‌کند. کاهش اندازه یکتا در اجرای دوم طبیعی است اگر بیشتر محتوا تغییر نکرده باشد. اما کوچک بودن خروجی همیشه موفقیت نیست؛ ممکن است ورودی اشتباه یا خالی انتخاب شده باشد. بنابراین تعداد فایل‌ها و مسیرهای موجود در آرشیو را نیز بررسی کنید. یک دیسک داده که mount نشده، می‌تواند تصویری بسیار کم‌حجم و ظاهراً موفق از یک پوشه خالی ایجاد کند.
borg create --stats /srv/borg-lab::day-two /srv/demo-data
borg list /srv/borg-lab::day-two
در گزارش عملیاتی، زمان شروع و پایان، نام آرشیو و نتیجه خروج را همراه آمار نگه دارید. اگر تعداد فایل‌ها ناگهان کم شد، آن را به‌عنوان تغییری نیازمند بررسی ببینید. افزایش شدید زمان نیز می‌تواند به تغییر حجم، فشار دیسک یا مسیر شبکه مربوط باشد. مقایسه چند روز متوالی، الگوی معمول را روشن می‌کند و کمک می‌کند برای هر نوسان کوچک هشدار بی‌فایده تولید نشود. معیار هشدار باید از رفتار واقعی همین مجموعه داده به دست آید.
استخراج امن در پوشه جدا
در نحو مستند این مقاله، extract فایل‌ها را نسبت به پوشه جاری استخراج می‌کند. بنابراین پیش از اجرا، وارد یک پوشه خالی مخصوص آزمایش شوید و محل فعلی را کنترل کنید. اجرای عجولانه در پوشه داده اصلی می‌تواند فایل‌های موجود را در معرض بازنویسی قرار دهد. ابتدا فهرست آرشیو را بخوانید تا ساختار مسیرهای ذخیره‌شده معلوم باشد. اگر ورودی مسیر مطلق داشته، ساختار ثبت‌شده و مسیر بازیابی را از خروجی واقعی بررسی کنید و بر اساس حدس عمل نکنید.
mkdir /srv/borg-restore-lab
cd /srv/borg-restore-lab
borg extract /srv/borg-lab::day-one
پس از استخراج، تنها وجود نام فایل را بررسی نکنید. فایل متنی را بخوانید، تصویر یا سند را با برنامه مربوط باز کنید و برای نمونه‌های ثابت هش را مقایسه کنید. مجوز و مالکیت نیز ممکن است برای اجرای سرویس اهمیت داشته باشند. اگر آزمون با کاربر معمولی انجام شده، توانایی او برای بازگرداندن مالکیت‌های متفاوت محدود است؛ این موضوع را از خرابی محتوای آرشیو تفکیک کنید. برای بازیابی کامل سرویس، محیط آزمایشی با دسترسی و ساختار مناسب لازم است.
فایل باز و پایگاه داده زنده
Borg تضمین نمی‌کند مجموعه فایل‌هایی که برنامه هم‌زمان تغییر می‌دهد یک وضعیت سازگار کاربردی بسازند. ابزار فایل را در زمان خواندن می‌بیند؛ ممکن است فایل اول پیش از یک تراکنش و فایل دوم پس از آن خوانده شود. برای پایگاه داده، روش رسمی خروجی یا پشتیبان همان موتور را اجرا کنید و سپس نتیجه آماده را آرشیو کنید. اگر از snapshot فایل‌سیستم استفاده می‌کنید، باید محدودیت سازگاری برنامه و هماهنگی لازم را نیز بشناسید.
در یک جریان عملی، آماده‌سازی خروجی پایگاه داده باید وضعیت مستقل داشته باشد. موفق بودن Borg نباید شکست تولید خروجی جدید را پنهان کند. برای مثال، اسکریپت نباید هر شب فایل قدیمی موجود را آرشیو کند و فقط به دلیل موفقیت create، پشتیبان روز جدید را سالم اعلام کند. زمان تولید، اندازه و نتیجه اعتبارسنجی خروجی را بررسی کنید. سپس در آزمون بازیابی، داده را در یک نمونه جدا وارد کنید و چند پرس‌وجوی مشخص انجام دهید. این کار قابلیت استفاده را می‌سنجد، نه صرفاً قابلیت کپی را.
کنترل سلامت و مرز تعمیر
فرمان check برای بررسی سازگاری مخزن و آرشیوهاست. بررسی مخزن و بررسی فراداده آرشیو دو بخش متفاوت‌اند و گزینه verify-data کنترل رمزنگاری‌شده داده محتوا را نیز اضافه می‌کند. این بررسی نیازمند خواندن داده است و برای مخزن بزرگ می‌تواند طولانی باشد. برنامه نگهداری باید هزینه زمانی و ورودی‌خروجی آن را در نظر بگیرد؛ حذف کامل بررسی به دلیل طولانی بودن، خرابی را تا روز بازیابی پنهان می‌کند.
borg check /srv/borg-lab
borg check --verify-data /srv/borg-lab
حالت repair را با check عادی اشتباه نگیرید. مستندات رسمی هشدار می‌دهد تعمیر می‌تواند موجب از دست رفتن داده شود و قرار نیست داده نابودشده را از هیچ بازسازی کند. اگر خطا مشاهده شد، ابتدا گزارش را حفظ کنید، وضعیت سخت‌افزار و ذخیره‌ساز را بررسی کنید و پیش از اقدام تغییردهنده نسخه‌ای از مخزن نگه دارید. همچنین مسیر نسخه مستقل را بررسی کنید. اجرای تعمیر به‌عنوان اولین واکنش خودکار، به‌خصوص روی سخت‌افزار ناپایدار، تصمیم مناسبی نیست.
کلید و گذرواژه در روز خرابی
برای بازیابی باید هم داده مخزن و هم اطلاعات لازم برای باز کردن آن در دسترس باشند. نگهداری کلید یا گذرواژه فقط روی دستگاه منبع، یک وابستگی خطرناک ایجاد می‌کند. مستندات Borg فرمان‌های export و import کلید را ارائه می‌کند؛ با راهنمای همان نسخه، خروجی کلید را در محل جدا و محافظت‌شده نگه دارید. این فایل را مانند یک سند عمومی یا پیوست گزارش عادی منتشر نکنید. مسئول دسترسی و روش تحویل اضطراری باید مشخص باشد.
تمرین بازیابی را از محیطی انجام دهید که به حافظه و تنظیمات شخصی مدیر قبلی وابسته نیست. همکار مسئول باید بتواند محل مخزن، حساب اتصال و اطلاعات کلید را پیدا کند. اگر این کار فقط با تماس با یک نفر ممکن باشد، مستند عملیات ناقص است. در عین حال دسترسی را بی‌دلیل گسترده نکنید؛ قابلیت بازیابی برای افراد مجاز و محدود بودن دسترسی به داده باید هم‌زمان طراحی شوند. رمزگذاری جای برنامه مدیریت مجوز و نسخه مستقل را نمی‌گیرد.
مخزن دوردست روی SSH
Borg می‌تواند به مخزن دوردست از طریق SSH دسترسی داشته باشد. در این سناریو، نسخه برنامه و محیط اجرای سمت دوردست، حساب اتصال و مسیر مخزن باید بررسی شوند. یک حساب اختصاصی برای نگهداری مخزن می‌تواند مدیریت مالکیت را روشن‌تر کند. ابتدا اتصال و هویت میزبان را به شکل تعاملی و کنترل‌شده بررسی کنید، سپس اجرای خودکار را با همان حسابی که زمان‌بند استفاده می‌کند آزمایش کنید. موفقیت اتصال از حساب شخصی شما، موفقیت حساب سرویس را ثابت نمی‌کند.
برای محدود کردن حساب سمت مقصد، از قابلیت‌ها و راهنمای رسمی استقرار Borg استفاده کنید؛ محدودیت را با آزمون عملی تأیید کنید. هدف این است که حساب پشتیبان فقط دامنه لازم را داشته باشد و رفتار مورد انتظار مانند ایجاد آرشیو واقعاً کار کند. پیش از محدودیت سخت‌گیرانه، مسیر بازیابی و عملیات نگهداری را نیز در نظر بگیرید. اگر دسترسی حذف از حساب روزمره گرفته شود، باید معلوم باشد prune یا compact در کدام فرایند مجاز و توسط کدام مسئولِ مجاز انجام می‌شود.
حذف آرشیو و آزاد کردن فضای دیسک
در نسخه مستند این راهنما، حذف آرشیو لزوماً همان لحظه فضای فیزیکی مخزن را آزاد نمی‌کند؛ compact برای جمع‌آوری فضای بخش‌های بدون استفاده مطرح است. اشتراک داده میان آرشیوها نیز باعث می‌شود حذف یک نسخه، به اندازه ظاهری آن فضا آزاد نکند. پیش از پاک‌سازی، سیاست نگهداری را روی نام‌ها و گروه‌های درست اعمال کنید و خروجی آزمایشی را بخوانید. نسخه قدیمی ممکن است تنها نسخه پیش از یک تغییر خراب باشد و صرف قدیمی بودن دلیل کافی برای حذف نیست.
فضای آزاد مقصد و حافظه محلی Borg را پایش کنید. مستندات تأکید می‌کند عملیات نگهداری نیز به فضای کاری نیاز دارد و پر شدن کامل دیسک می‌تواند حتی آزادسازی فضا را دشوار کند. بنابراین آستانه هشدار را پیش از پرشدن کامل تعیین کنید. اگر رشد مخزن از انتظار بیشتر شد، ابتدا داده یکتا و الگوی تغییر را بررسی کنید؛ اجرای مکرر پاک‌سازی بدون شناخت علت رشد راه‌حل پایدار نیست. ظرفیت، مدت نگهداری و فاصله اجرای نسخه‌ها باید با هم تنظیم شوند.
معیار تحویل یک سامانه قابل اتکا
برای پایان استقرار آزمایشی، دو آرشیو ساخته‌شده را مستقل استخراج کنید و تفاوت مورد انتظار فایل تغییرکرده را ببینید. سپس یک آزمون از محیط دیگر انجام دهید تا وابستگی به کلید یا حافظه محلی پنهان آشکار شود. زمان بازیابی را ثبت کنید و مطمئن شوید هدف عملیاتی سرویس را پاسخ می‌دهد. اگر بازیابی داده درست است ولی آماده‌سازی محیط ساعت‌ها طول می‌کشد، مستند راه‌اندازی سرویس نیز بخشی از کار باقی‌مانده است.
در پایش روزانه، سن آخرین آرشیو معتبر، نتیجه فرمان، تغییر تعداد فایل‌ها و آخرین آزمون بازیابی را کنار هم ببینید. نام آرشیو جدید به‌تنهایی اثبات کامل بودن ورودی نیست. Borg ابزار قدرتمندی برای کاهش داده تکراری و نگهداری نسخه‌هاست، اما کیفیت نتیجه به انتخاب ورودی سازگار، مدیریت کلید، ظرفیت کافی و تمرین بازیابی وابسته است. وقتی فرد دیگری بتواند از روی مستندات یک نسخه مشخص را به سرویس قابل استفاده تبدیل کند، چرخه پشتیبان از یک فرمان موفق به فرایندی قابل اتکا رسیده است.
