پشتیبان‌گیری از کانتینر یا فایل‌های آن؟ بر اساس شکل بازیابی تصمیم بگیرید
پشتیبان‌گیری ایمیج و فایل‌سطح چیزهای متفاوتی را بازیابی می‌کنند و به کلیدهای متفاوتی وابسته‌اند. شیء ذخیره‌شده را با بازیابی‌ای که واقعاً لازم دارید هماهنگ کنید.
می‌توانید از یک کانتینر رمزگذاری‌شده به‌عنوان یک شیء واحد پشتیبان بگیرید، یا آن را مانت کنید و از فایل‌های داخلش پشتیبان بگیرید. هر دو به‌راحتی از VPN عبور می‌کنند و شباهت همین‌جا تمام می‌شود. آن‌ها چیزهای متفاوتی را بازیابی می‌کنند، به کلیدهای متفاوتی وابسته‌اند، فضای متفاوتی مصرف می‌کنند و وقتی کسی داده‌ها را برمی‌گرداند به شکل‌های متفاوتی شکست می‌خورند. اول شیء بازیابی را انتخاب کنید، سپس انتقال، سپس رمزگذاری نسخه ذخیره‌شده. فهرست زیر همین ترتیب را دنبال می‌کند، چون تقریباً هر اختلاف بر سر پشتیبان‌گیری در واقع اختلاف بر سر این است که کدام یک از این سه اول تعیین شده است.
دو شیء، دو شکل بازیابی
پشتیبان ایمیج یک کانتینر را بازیابی می‌کند: حجم رمزگذاری‌شده را پس می‌گیرید و هنوز به مواد بازیابی آن برای بازکردنش نیاز دارید. پشتیبان فایل‌سطح فایل‌ها و درخت‌های پوشه را بازیابی می‌کند، و هر رمزگذاری‌ای که از آن‌ها محافظت می‌کند ویژگی مخزن پشتیبان است نه کانتینر اصلی. کپی ساده در یک پوشه راه دور حالت سومی است و هر محافظتی را که آن پوشه تصادفاً دارد به ارث می‌برد.
| Object | What a restore gives you | Where the encryption question lands |
|---|---|---|
| Encrypted container image | The volume, still locked | The container format and its recovery key material |
| Mounted files into a backup tool | Selected files and metadata | The backup repositorys own keys and design |
| Plain copy to a remote folder | Whatever the copy process kept | Whatever protects that storage afterwards |
ردیف میانی همان است که مردم اشتباه می‌خوانند. می‌تواند طرحی کاملاً خوب باشد: برنامه پشتیبان‌گیری متن آشکار را به‌صورت محلی می‌خواند و مخزنی رمزگذاری‌شده و احراز هویت‌شده می‌نویسد. آن‌گاه امنیت بر آن برنامه و اعتبارنامه‌هایش استوار است، نه بر گذرواژه کانتینر اصلی، و این دو را نباید طوری توصیف کرد که گویی یک کنترل واحد هستند.
بررسی 1: بازیابی باید چه چیزی را بازسازی کند؟
پرسش را به شکل بازیابی بپرسید، نه پشتیبان‌گیری. اگر نیاز این است که «این سرویس را روی میزبان دیگری برگردان»، ایمیج به‌همراه مواد بازیابی‌اش پاسخ منسجمی است. اگر نیاز این است که «صفحه‌گسترده مالی مارس را برگردان»، بازیابی ایمیجی چند گیگابایتی فقط برای بیرون‌کشیدن یک فایل روش گرانی برای پاسخ است. هر دو بازیابی مشروعی هستند و بودجه‌های قابل‌تعویض نیستند. طرحی که فقط یکی را نام ببرد، دیر یا زود با دیگری آزموده می‌شود.
هدف بازیابی را در طرح بنویسید: کل حجم، یک درخت پوشه، یا فایل‌های جداگانه. سپس یادداشت کنید چه فراداده‌هایی باید همراهشان سفر کنند، چون مالکیت، مجوزها، ویژگی‌های گسترده و برچسب‌های زمانی بخشی از بازیابی فایل‌سطح هستند و در جریان‌های کاری مبتنی بر کپی که هنگام آزمایش کافی به نظر می‌رسیدند اغلب از دست می‌روند.
همچنین تعیین کنید چه کسی بازیابی را انجام می‌دهد. مخزن فایل‌سطح که هر اپراتوری می‌تواند مانت کند مدل دسترسی متفاوتی از ایمیجی است که حضور دارنده کلید را لازم دارد، و هیچ‌کدام خودبه‌خود بهتر نیست. مهم این است که انتخاب آگاهانه و مکتوب باشد.
بررسی 2: چه چیزی از نسخه ذخیره‌شده محافظت می‌کند؟
VPN از یک بخش انتقال محافظت می‌کند. پس از پایان انتقال هیچ چیزی درباره نسخه ذخیره‌شده نمی‌گوید، و «از تونل گذشت» جمله‌ای درباره توانایی اپراتور پشتیبان در خواندن داده‌های شما نیست. اگر طرف دور را کس دیگری اداره می‌کند، پرسش این است که آن‌ها چه می‌توانند بخوانند، نه اینکه پیوند رمزگذاری شده بود یا نه.
برای یک ایمیج این یعنی محافظت از مواد کلید کانتینر جدا از خود ایمیج. از دست دادن سرصفحه یعنی از دست دادن حجم، پس از سرصفحه جایی پشتیبان بگیرید که ایمیج آن‌جا نیست:
cryptsetup luksHeaderBackup /dev/vg0/data --header-backup-file data-header.img
cryptsetup luksDump /dev/vg0/data | head -20برای مخزن فایل‌سطح بررسی کنید که ابزار محتوا و فراداده را پیش از خروج از میزبان رمزگذاری و احراز هویت می‌کند، و بفهمید کلیدها دست چه کسی است. مستندات طراحی Restic صریح می‌گوید که میزبان مبدأ مورد اعتماد را فرض می‌کند و رمزگذاری مانع کسی که دسترسی به فضای ذخیره‌سازی دارد از حذف پشتیبان‌ها نمی‌شود. هر دو هشدار مهم‌اند: مخزن می‌تواند محرمانه باشد و باز هم نابود شود.
بررسی 3: آیا نسخه سازگار است؟
پشتیبانی که از یک سیستم فایل در حال تغییر گرفته می‌شود یک کپی است، نه نقطه بازیابی. برای ایمیج از روش پشتیبانی‌شده ابزار حجم برای یک اسنپ‌شات پایدار استفاده کنید، که معمولاً یعنی عملیات اسنپ‌شات یا جداکردن، نه خواندن یک فایل بزرگ در حین تغییر:
lvcreate -L 5G -s -n data-snap /dev/vg0/data
cryptsetup open /dev/vg0/data-snap data-snap --readonlyبرای فایل‌های مانت‌شده از رویه سازگاری پشتیبانی‌شده برنامه برای پایگاه‌های داده فعال و سایر داده‌های هماهنگ‌شده استفاده کنید. کپی در سطح سیستم فایل و نقطه بازیابی سازگار با برنامه دو توصیف متفاوت‌اند، و تفاوت فقط وقتی دیده می‌شود که بخواهید برنامه را از نسخه بازیابی‌شده اجرا کنید.
مواد بازیابی را روی مسیری مستقل و محافظت‌شده نگه دارید. از دست دادن ماشین اصلی هرگز نباید تنها اعتبارنامه‌ای را هم از بین ببرد که پشتیبانش را باز می‌کند، و دقیقاً همین اتفاق می‌افتد وقتی فایل کلید روی همان حجمی است که پشتیبان می‌شود. این جداسازی را آگاهانه بیازمایید: روی میزبانی بازیابی کنید که هرگز اصل را ندیده است، فقط با استفاده از آنچه طرح می‌گوید در دسترس است.
بررسی 4: آیا تشخیص تغییر برای این شیء برقرار است؟
کانتینر رمزگذاری‌شده برای بیشتر ابزارهای انتقال مثل یک فایل بزرگ و مبهم به نظر می‌رسد، بنابراین یک ویرایش کوچک در متن آشکار بسته به ابزار و قالب می‌تواند خواندن دوباره بزرگ یا بارگذاری کامل دوباره را به دنبال داشته باشد. تکه‌بندی با اندازه متغیر و حذف تکراری، همان‌طور که restic مستند می‌کند، می‌تواند آن را کم کند، اما این ویژگی آن ابزار است نه کانتینرهای رمزگذاری‌شده به‌طور کلی.
اندازه بگیرید نه اینکه فرض کنید. اجرای اول را با اجرای دوم پس از یک تغییر کوچک و بی‌خطر مقایسه کنید و بایت‌های منتقل‌شده و همچنین زمان سپری‌شده را ثبت کنید. هنگام آزمایش یک پشتیبان شناخته‌شده سالم را نگه دارید تا یک آزمون تنها نقطه بازیابی شما را مصرف نکند.
سپس فهرست را با تنها آزمونی تمام کنید که اهمیت دارد: بازیابی بدون ماشین اصلی. یک کانتینر بازیابی‌شده را باز کنید، یا فایل‌های انتخابی را با فراداده‌هایشان بازیابی کنید، و تأیید کنید که برنامه یا کاربر می‌تواند از نتیجه استفاده کند. انتقالی سریع و خوب رمزگذاری‌شده که نمی‌تواند به این آزمون پاسخ دهد کپی داده‌های شماست، نه پشتیبان آن.