معرفی
این راهنما بر پایه مستندات رسمی پروژه نوشته شده و هدف آن ساختن یک مدل ذهنی دقیق برای طراحی، عملیات و عیب‌یابی است.
نکته 1
Snapshot محلی در همان filesystem در برابر خرابی کامل storage محافظت نمی‌کند.
نکته 2
btrfs send می‌تواند stream کامل یا incremental بر پایه parent snapshot بسازد.
نکته 3
برای disaster recovery باید مقصد مستقل، verification و retention policy طراحی شود.
برداشت عملیاتی IROSG
قبل از هر تغییر Production، نسخه، وابستگی، سطح دسترسی، rollback و observability را بررسی کنید. منبع رسمی همین صفحه مرجع اصلی جزئیات است.
snapshot چه چیزی را نگه می‌دارد؟
در Btrfs، snapshot نمایی از یک subvolume در یک لحظه ایجاد می‌کند و به کمک copy-on-write می‌تواند بخش‌های تغییرنکرده داده را با مبدأ شریک باشد. نتیجه این است که ساخت snapshot معمولاً نیاز به کپی فوری همه بایت‌ها ندارد. اما این سرعت نباید با استقلال فیزیکی اشتباه شود. اگر snapshot و مبدأ روی همان سامانه ذخیره‌سازی باشند، خرابی آن سامانه می‌تواند هر دو را از بین ببرد. snapshot برای برگشت سریع مفید است، ولی به تنهایی طرح کامل پشتیبان نیست.
Subvolume را نیز با directory معمولی یکسان ندانید. مرز subvolume بر رفتار snapshot اثر دارد. اگر داخل درخت شما subvolumeهای دیگری وجود دارند، نباید فرض کنید snapshot والد همه محتوای آن‌ها را مانند یک پوشه عادی به شکل بازگشتی در بر می‌گیرد. پیش از طراحی پشتیبان، نقشه subvolumeها را تهیه کنید و مشخص کنید کدام داده در کدام مرز قرار دارد. این بررسی جلوی غافلگیری مهمی را می‌گیرد: ممکن است snapshot ظاهراً موجود باشد ولی داده مورد انتظار اصلاً در دامنه آن نباشد.
سازگاری فایل‌سیستم با سازگاری برنامه فرق دارد
Snapshot در یک لحظه وضعیت فایل‌سیستم را ثبت می‌کند، ولی برنامه ممکن است چند فایل یا چند مرحله نوشتن مرتبط داشته باشد. برای پایگاه داده، داشتن تصویر فایل‌ها در یک لحظه لزوماً معادل پشتیبان کاربردی کامل نیست. باید روش توصیه‌شده خود برنامه برای quiesce، checkpoint یا backup را بررسی کنید. بعضی برنامه‌ها می‌توانند از وضعیت شبیه قطع ناگهانی برق بازیابی شوند، ولی این فرض باید آزموده شود و نباید برای همه نرم‌افزارها تعمیم داده شود.
برای آزمایش، یک برنامه کوچک با داده قابل بررسی داشته باشید. هنگام فعالیت snapshot بگیرید و سپس آن را در محیط جدا بازیابی کنید. فقط باز شدن پوشه را نسنجید؛ پرسش واقعی برنامه و یکپارچگی داده را بررسی کنید. اگر برنامه journal یا log تراکنش دارد، وجود و هماهنگی آن با داده اصلی مهم است. نتیجه آزمون باید نشان دهد کدام روش snapshot برای همان برنامه قابل قبول است و چه محدودیتی باقی می‌ماند.
حالت فقط خواندنی و جریان send
فرایند send از subvolume فقط خواندنی استفاده می‌کند تا ورودی ثابت باشد. اگر داده در حین تولید جریان تغییر کند، معنای تصویر مورد انتقال مبهم می‌شود؛ به همین دلیل نظم ایجاد snapshot و ثابت نگه داشتن آن اهمیت دارد. در حالت کامل، جریان اطلاعات لازم برای بازسازی snapshot را حمل می‌کند. در حالت افزایشی، تغییر نسبت به یک مبنای شناخته‌شده منتقل می‌شود. این مبنا باید در دو طرف به شکل مناسب وجود داشته باشد و نباید با یک پوشه شبیه به آن جایگزین فرض شود.
Receive جریان را به عملیات بازسازی فایل‌ها و metadata تبدیل می‌کند. نتیجه از نظر محتوای مورد انتظار معادل است، ولی همه شناسه‌های داخلی الزاماً یکسان نیستند. بنابراین برای سنجش صحت، صرف مقایسه inode کافی نیست. نام فایل، اندازه، محتوای انتخابی یا hash، مجوز و ویژگی‌های لازم برنامه را بررسی کنید. اگر کاربرد به ویژگی خاصی مثل extended attribute وابسته است، آن را در آزمون پذیرش بگنجانید و فقط تعداد فایل‌ها را گزارش نکنید.
زنجیره افزایشی را مانند یک وابستگی مدیریت کنید
فرض کنید snapshot روز نخست کامل ارسال شده و روز دوم فقط اختلاف نسبت به آن منتقل می‌شود. مقصد برای بازسازی افزایشی به مبنای درست نیاز دارد. اگر مبنا زودتر حذف یا تغییر کند، انتقال بعدی ممکن است شکست بخورد. بنابراین سیاست حذف باید وابستگی send را در نظر بگیرد. زمان نگهداری مبدأ و مقصد می‌تواند متفاوت باشد، اما باید حداقل مبنای مشترک لازم باقی بماند. یک جدول ساده از snapshot، زمان و والد انتخاب‌شده به مدیریت کمک می‌کند.
Snapshot دریافت‌شده را برای کار روزمره مستقیماً قابل نوشتن نکنید اگر قرار است پایه دریافت‌های بعدی باشد. برای آزمایش یا بازیابی، از آن نسخه مناسب جدا بسازید تا مبنای replication تغییر نکند. این تفکیک جلوی خطایی را می‌گیرد که در آن کاربر برای اصلاح یک فایل، پایه زنجیره را دستکاری می‌کند. نام‌گذاری روشن مانند نسخه نگهداری و نسخه بازیابی، همراه با مجوز مناسب، احتمال اشتباه را کم می‌کند.
انتقال شبکه و مدیریت خطا
جریان send را می‌توان از مسیر شبکه یا فایل میانی منتقل کرد. مسیر انتقال باید حفاظت و احراز هویت متناسب داشته باشد، زیرا داده پشتیبان ممکن است حساس باشد. فشرده‌سازی انتقال، پهنای باند و مصرف CPU را با بار واقعی بسنجید. یک گزینه سریع‌تر در شبکه محلی لزوماً برای مسیر دور یا میزبان کم‌توان مناسب نیست. همچنین خروجی همه مراحل pipeline را بررسی کنید؛ موفقیت آخرین فرمان به تنهایی همیشه نشان نمی‌دهد تولید جریان بدون خطا تمام شده است.
قطع ارتباط می‌تواند مقصد ناقص یا عملیات نیمه‌تمام باقی بگذارد. نباید فقط وجود نام snapshot را نشانه موفقیت دانست. وضعیت دریافت، کد خروج و نتیجه اعتبارسنجی را ثبت کنید و پیش از تلاش دوباره، روش پاک‌سازی یا ادامه مورد پشتیبانی را بررسی کنید. حذف بی‌دقت مسیر مقصد ممکن است نسخه سالم قبلی را هم از بین ببرد. برای خودکارسازی، نام موقت و مرحله پذیرش نهایی را طوری طراحی کنید که نسخه ناقص با پشتیبان تأییدشده اشتباه نشود.
مقصد مستقل چه معنایی دارد؟
مقصد روی دیسک دیگر همان دستگاه، در برابر خرابی یک دیسک کمک می‌کند ولی در برابر سرقت دستگاه یا خطای مدیریتی گسترده لزوماً مستقل نیست. مقصد شبکه‌ای با همان اعتبارنامه حذف کامل نیز ممکن است در برابر نفوذ به مبدأ آسیب‌پذیر باشد. استقلال را از نظر سخت‌افزار، محل، دسترسی و دوره نگهداری بررسی کنید. برای داده مهم، محدود کردن توان حذف نسخه‌های قبلی از حساب ارسال‌کننده می‌تواند بخشی از طرح حفاظت باشد، مشروط به اینکه گردش کار آن پشتیبانی شود.
Replication خطای منطقی را نیز می‌تواند منتقل کند. اگر فایل اشتباه حذف شود و snapshot جدید همان حذف را ثبت کند، مقصد جدید هم آن وضعیت را خواهد داشت. ارزش retention در این است که نسخه پیش از اشتباه باقی بماند. فقط نگه داشتن آخرین snapshot حفاظت کافی در برابر کشف دیرهنگام خطا نیست. فاصله و تعداد نسخه‌ها را بر اساس زمان معمول تشخیص مشکل و محدودیت ظرفیت انتخاب کنید. سیاست باید برای رشد داده و نرخ تغییر واقعی قابل اجرا باشد.
مصرف فضا را با دقت تفسیر کنید
به دلیل اشتراک extentها، جمع اندازه ظاهری snapshotها با فضای واقعی اشغال‌شده یکسان نیست. حذف یک snapshot نیز الزاماً همان مقدار فضای ظاهری را آزاد نمی‌کند، چون داده ممکن است هنوز توسط snapshot یا subvolume دیگری استفاده شود. ابزارهای گزارش مصرف باید با درک اشتراک داده تفسیر شوند. اگر پس از حذف نسخه قدیمی فضای کمی آزاد شد، فوراً نتیجه نگیرید حذف شکست خورده است؛ بررسی کنید چه نسخه‌هایی هنوز به داده اشاره دارند.
در عین حال، snapshot رایگان نیست. تغییر زیاد داده، metadata و تعداد زیاد نسخه‌ها می‌توانند ظرفیت و هزینه نگهداری را افزایش دهند. پایش فضای آزاد و وضعیت فایل‌سیستم لازم است. پر شدن فضا می‌تواند هم کار برنامه و هم تهیه snapshot بعدی را مختل کند. سیاست نگهداری باید پیش از رسیدن به وضعیت اضطراری عمل کند. حذف دستی عجولانه در زمان کمبود فضا خطر از بین بردن مبنای انتقال یا آخرین نسخه سالم را دارد.
سلامت رسانه و صحت پشتیبان
بررسی سلامت فایل‌سیستم و scrub می‌تواند در کشف برخی خطاهای ذخیره‌سازی کمک کند، ولی جای آزمون restore را نمی‌گیرد. ممکن است فایل‌ها از نظر خواندن سالم باشند اما برنامه با آن وضعیت بالا نیاید، یا بخش مهمی از داده از دامنه پشتیبان جا افتاده باشد. آزمون بازیابی باید روی مقصد مستقل و با داده واقعی نمونه انجام شود. زمان انتقال، بازسازی و آماده شدن برنامه را جدا اندازه بگیرید تا زمان واقعی بازگشت خدمت معلوم شود.
یک فایل نشانه با تاریخ و شناسه دوره پشتیبان می‌تواند برای تشخیص نسخه کمک‌کننده باشد، اما به تنهایی صحت همه داده را ثابت نمی‌کند. نمونه‌برداری از فایل‌های مهم، بررسی مجوزها و اجرای آزمون کاربردی را ترکیب کنید. گزارش باید بگوید کدام بخش‌ها بررسی شده‌اند. اگر رمزنگاری یا کلید خارجی برای خواندن داده لازم است، بازیابی کلید را هم تمرین کنید؛ پشتیبان رمز‌شده بدون راه دسترسی به کلید ممکن است در حادثه عملاً غیرقابل استفاده باشد.
بازگرداندن فایل یا کل سرویس
برای حذف اتفاقی یک فایل، کپی انتخابی از snapshot ممکن است کم‌ریسک‌تر از برگشت کل subvolume باشد. پیش از کپی، نسخه فعلی و وابستگی برنامه را بررسی کنید تا تغییرهای سالم دیگر از بین نروند. برای بازگرداندن کل سرویس، برنامه را طبق روش مناسب متوقف یا هماهنگ کنید و مقصد بازیابی را جدا آماده کنید. تعویض مسیر فعال باید با امکان بازگشت و بررسی مالکیت همراه باشد. داشتن snapshot اجازه نمی‌دهد هماهنگی با برنامه نادیده گرفته شود.
طرح قابل اتکا در پایان باید پاسخ دهد چه داده‌ای پوشش داده می‌شود، هر نسخه از چه مبنایی ساخته شده، تا چه زمانی باقی می‌ماند و چگونه صحت آن ثابت شده است. Btrfs ابزارهای مؤثری برای snapshot و انتقال اختلاف فراهم می‌کند، اما تصمیم درباره سازگاری برنامه، استقلال مقصد و retention همچنان مسئولیت طراحی است. وقتی این قراردادها روشن باشند، سرعت snapshot و send به مزیت عملی تبدیل می‌شود و در حادثه موجب برداشت اشتباه از میزان حفاظت نخواهد شد.
در خودکارسازی، نام snapshot را از زمان و شناسه یکتا بسازید و موفقیت را در فهرست جدا ثبت کنید. وجود نام به تنهایی معیار پذیرش نیست. پیش از حذف نسخه قدیمی، بررسی کنید دست‌کم یک نسخه تأییدشده و مبنای لازم برای انتقال بعدی باقی می‌ماند. این کنترل کوچک از تبدیل یک خطای زمان‌بندی به حذف زنجیره سالم جلوگیری می‌کند.
