این یادداشت چرخه مربوط به پشتیبان گیری را کامل می کند. در مورد سازماندهی منطقی یک سرور اختصاصی (یا VPS) که برای پشتیبان‌گیری مناسب است، بحث می‌کند، و همچنین گزینه‌ای برای بازیابی سریع سرور از پشتیبان‌گیری بدون خرابی زیاد در صورت بروز فاجعه ارائه می‌دهد.
داده های خام
یک سرور اختصاصی اغلب دارای حداقل دو هارد دیسک است که برای سازماندهی یک آرایه RAID سطح اول (آینه) خدمت می کنند. این برای ادامه کار سرور در صورت خرابی یک دیسک ضروری است. اگر این یک سرور اختصاصی معمولی است، ممکن است یک کنترلر RAID سخت افزاری جداگانه با فناوری کش فعال بر روی SSD وجود داشته باشد تا علاوه بر هارد دیسک های معمولی، یک یا چند SSD به آن متصل شود. گاهی اوقات سرورهای اختصاصی ارائه می شوند که در آنها تنها دیسک های محلی SATADOM (دیسک های کوچک، از لحاظ ساختاری یک فلش درایو متصل به پورت SATA) یا حتی یک فلش مموری کوچک معمولی (8-16 گیگابایت) متصل به یک پورت داخلی خاص است. داده ها از سیستم ذخیره سازی گرفته می شود، از طریق یک شبکه ذخیره سازی اختصاصی (Ethernet 10G، FC، و غیره) متصل می شود، و سرورهای اختصاصی وجود دارد که مستقیماً از سیستم ذخیره سازی بارگیری می شوند. من چنین گزینه هایی را در نظر نخواهم گرفت، زیرا در چنین مواردی وظیفه تهیه نسخه پشتیبان از سرور به راحتی به متخصصی که سیستم ذخیره سازی را نگهداری می کند، منتقل می شود؛ معمولاً فناوری های اختصاصی مختلفی برای ایجاد عکس های فوری، کپی برداری داخلی و سایر شادی های مدیر سیستم وجود دارد. ، در قسمت های قبلی این مجموعه مورد بحث قرار گرفت. حجم آرایه دیسک سرور اختصاصی بسته به تعداد و اندازه دیسک های متصل به سرور می تواند به چندین ده ترابایت برسد. در مورد VPS، حجم کمتر است: معمولاً بیش از 100 گیگابایت نیست (اما تعداد بیشتری نیز وجود دارد) و تعرفه های چنین VPS می تواند به راحتی از ارزان ترین سرورهای اختصاصی یک میزبان گران تر باشد. یک VPS اغلب دارای یک دیسک است، زیرا یک سیستم ذخیره سازی (یا چیزی بیش همگرا) در زیر آن وجود دارد. گاهی اوقات یک VPS دارای چندین دیسک با ویژگی های مختلف برای اهداف مختلف است:
- سیستم کوچک - برای نصب سیستم عامل؛
- بزرگ - ذخیره سازی داده های کاربر
هنگامی که سیستم را با استفاده از کنترل پنل مجدداً نصب می کنید، دیسک حاوی اطلاعات کاربر رونویسی نمی شود، اما دیسک سیستم کاملاً پر می شود. همچنین، در مورد VPS، میزبان ممکن است دکمه‌ای ارائه دهد که یک عکس فوری از وضعیت VPS (یا دیسک) می‌گیرد، اما اگر سیستم عامل خود را نصب کنید یا فراموش کنید سرویس مورد نظر را در داخل VPS فعال کنید، برخی ممکن است داده ها همچنان از بین بروند. علاوه بر دکمه، یک سرویس ذخیره سازی داده معمولاً ارائه می شود که اغلب بسیار محدود است. معمولاً این یک حساب کاربری با دسترسی از طریق FTP یا SFTP، گاهی همراه با SSH، با پوسته‌ای حذف‌شده (به عنوان مثال، rbash)، یا محدودیتی در اجرای دستورات از طریق کلیدهای autorized (از طریق ForcedCommand) است.
یک سرور اختصاصی توسط دو پورت با سرعت 1 گیگابیت بر ثانیه به شبکه متصل می شود، گاهی اوقات اینها می توانند کارت هایی با سرعت 10 گیگابیت بر ثانیه باشند. VPS اغلب دارای یک رابط شبکه است. اغلب، مراکز داده سرعت شبکه را در مرکز داده محدود نمی کنند، اما سرعت دسترسی به اینترنت را محدود می کنند.
بار معمولی چنین سرور اختصاصی یا VPS یک وب سرور، یک پایگاه داده و یک سرور برنامه است. گاهی اوقات ممکن است خدمات کمکی مختلفی نصب شود، از جمله برای یک وب سرور یا پایگاه داده: موتور جستجو، سیستم پست و غیره.
یک سرور مخصوص آماده شده به عنوان فضایی برای ذخیره نسخه های پشتیبان عمل می کند؛ بعداً در مورد آن با جزئیات بیشتر خواهیم نوشت.
سازماندهی منطقی سیستم دیسک
اگر یک کنترلر RAID یا یک VPS با یک دیسک دارید و هیچ اولویت خاصی برای عملکرد زیرسیستم دیسک ندارید (به عنوان مثال، یک دیسک سریع جداگانه برای پایگاه داده)، تمام فضای آزاد به شرح زیر تقسیم می شود: یک پارتیشن ایجاد می شود، و یک گروه حجمی LVM در بالای آن ایجاد می شود، چندین جلد در آن ایجاد می شود: 2 جلد کوچک با همان اندازه، که به عنوان سیستم فایل ریشه استفاده می شود (تغییر یکی یکی در طول به روز رسانی برای امکان بازگشت سریع، ایده از توزیع محاسبه لینوکس گرفته شد)، یکی دیگر برای پارتیشن swap است، بقیه فضای آزاد به حجم های کوچک تقسیم می شود، به عنوان سیستم فایل ریشه برای کانتینرهای کامل، دیسک برای ماشین های مجازی، فایل استفاده می شود. سیستم‌های حساب‌ها در /home (هر حساب دارای سیستم فایل خاص خود است)، سیستم‌های فایل برای کانتینرهای برنامه.
نکته مهم: جلدها باید کاملاً مستقل باشند، یعنی. نباید به یکدیگر یا به سیستم فایل ریشه وابسته باشند. در مورد ماشین های مجازی یا کانتینرها این نکته به صورت خودکار رعایت می شود. اگر اینها کانتینرهای برنامه یا دایرکتوری های خانگی هستند، باید به فکر جداسازی فایل های پیکربندی وب سرور و سایر سرویس ها به گونه ای باشید که تا حد امکان وابستگی بین حجم ها را از بین ببرید. به عنوان مثال، هر سایت از کاربر خود اجرا می شود، فایل های پیکربندی سایت در فهرست اصلی کاربر هستند، در تنظیمات وب سرور، فایل های پیکربندی سایت از طریق /etc/nginx/conf.d/ گنجانده نشده است..conf و برای مثال /home//configs/nginx/*.conf
اگر چندین دیسک وجود دارد، می توانید یک آرایه RAID نرم افزاری ایجاد کنید (و در صورت نیاز و فرصت، ذخیره آن را روی یک SSD پیکربندی کنید)، که در بالای آن می توانید LVM را طبق قوانین پیشنهادی در بالا بسازید. همچنین در این مورد، می توانید از ZFS یا BtrFS استفاده کنید، اما باید دو بار در مورد آن فکر کنید: هر دو نیاز به رویکرد بسیار جدی تری به منابع دارند، و علاوه بر این، ZFS با هسته لینوکس گنجانده نشده است.
صرف نظر از طرح مورد استفاده، همیشه ارزش دارد که از قبل سرعت تقریبی نوشتن تغییرات روی دیسک ها را تخمین زده و سپس مقدار فضای خالی را که برای ایجاد عکس های فوری اختصاص داده می شود، محاسبه کنید. به عنوان مثال، اگر سرور ما داده ها را با سرعت 10 مگابایت در ثانیه می نویسد، و اندازه کل آرایه داده 10 ترابایت است - زمان همگام سازی می تواند به یک روز برسد (22 ساعت - این میزان حجمی است که منتقل می شود. از طریق شبکه 1 گیگابیت در ثانیه) - ارزش رزرو حدود 800 گیگابایت را دارد. در واقعیت، این رقم کوچکتر خواهد بود؛ می توانید با خیال راحت آن را بر تعداد حجم های منطقی تقسیم کنید.
دستگاه سرور ذخیره سازی پشتیبان
تفاوت اصلی بین سرور برای ذخیره نسخه های پشتیبان، دیسک های بزرگ، ارزان و نسبتا کند آن است. از آنجایی که هارد دیسک‌های مدرن قبلاً از نوار 10 ترابایت در یک دیسک عبور کرده‌اند، لازم است از سیستم‌های فایل یا RAID با چک‌سام‌ها استفاده شود، زیرا در طول بازسازی آرایه یا بازیابی سیستم فایل (چند روز!) ممکن است دیسک دوم به دلیل خرابی انجام شود. برای افزایش بار در دیسک‌هایی با ظرفیت تا 1 ترابایت، این امر چندان حساس نبود. برای سادگی توضیح، فرض می‌کنم فضای دیسک به دو قسمت تقریباً مساوی تقسیم می‌شود (دوباره، برای مثال، با استفاده از LVM):
- حجم های مربوط به سرورهای مورد استفاده برای ذخیره داده های کاربر (آخرین نسخه پشتیبان تهیه شده برای تأیید روی آنها مستقر می شود).
- حجم های مورد استفاده به عنوان مخازن BorgBackup (داده های پشتیبان گیری مستقیماً در اینجا قرار می گیرند).
اصل کار این است که برای هر سرور حجم های جداگانه ای برای مخازن BorgBackup ایجاد می شود، جایی که داده های سرورهای رزمی می روند. مخازن در حالت فقط ضمیمه کار می کنند که امکان حذف عمدی داده ها را از بین می برد و به دلیل حذف مجدد و پاکسازی دوره ای مخازن از پشتیبان های قدیمی (نسخه های سالانه باقی می ماند، ماهانه برای سال گذشته، هفتگی برای ماه آخر، روزانه برای هفته گذشته، احتمالاً در موارد خاص - ساعتی برای روز آخر: مجموعا 24 + 7 + 4 + 12 + سالانه - تقریباً 50 نسخه برای هر سرور).
مخازن BorgBackup حالت فقط الحاقی را فعال نمی‌کنند، در عوض، از یک دستور اجباری در .ssh/authorized_keys استفاده می‌شود چیزی شبیه به این:
from="адрес сервера",command="/usr/local/bin/borg serve --append-only --restrict-to-path /home/servername/borgbackup/",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding,no-user-rc AAAAA.......مسیر مشخص شده حاوی یک اسکریپت wrapper در بالای borg است که علاوه بر راه اندازی باینری با پارامترها، علاوه بر این فرآیند بازیابی نسخه پشتیبان را پس از حذف داده ها آغاز می کند. برای انجام این کار، اسکریپت wrapper یک فایل برچسب در کنار مخزن مربوطه ایجاد می کند. آخرین نسخه پشتیبان تهیه شده به طور خودکار پس از تکمیل فرآیند پر کردن داده ها به حجم منطقی مربوطه بازیابی می شود.
این طراحی به شما این امکان را می دهد که به صورت دوره ای بک آپ های غیر ضروری را پاکسازی کنید و همچنین از حذف هر چیزی در سرور ذخیره سازی پشتیبان توسط سرورهای رزمی جلوگیری می کند.
فرآیند پشتیبان گیری
آغازگر پشتیبان‌گیری، خود سرور اختصاصی یا VPS است، زیرا این طرح کنترل بیشتری بر فرآیند پشتیبان‌گیری از سوی این سرور می‌دهد. ابتدا یک عکس فوری از وضعیت سیستم فایل ریشه فعال گرفته می شود که با استفاده از BorgBackup در سرور ذخیره سازی پشتیبان نصب و آپلود می شود. پس از اتمام ضبط داده ها، عکس فوری از حالت نصب خارج و حذف می شود.
در صورت وجود یک پایگاه داده کوچک (حداکثر 1 گیگابایت برای هر سایت)، یک دامپ پایگاه داده ساخته می شود که در حجم منطقی مناسب ذخیره می شود، جایی که بقیه داده های همان سایت در آن قرار دارد، اما به طوری که Dump از طریق وب سرور قابل دسترسی نیست. اگر پایگاه‌های داده بزرگ هستند، باید حذف داده‌های داغ را پیکربندی کنید، به عنوان مثال، با استفاده از xtrabackup برای MySQL، یا با WAL با archive_command در PostgreSQL کار کنید. در این صورت پایگاه داده جدا از داده های سایت بازیابی می شود.
اگر از کانتینرها یا ماشین های مجازی استفاده می شود، باید qemu-guest-agent، CRIU یا سایر فناوری های لازم را پیکربندی کنید. در موارد دیگر، تنظیمات اضافی اغلب مورد نیاز نیست - ما به سادگی عکس های فوری از حجم های منطقی ایجاد می کنیم، که سپس به همان روشی که یک عکس فوری از وضعیت سیستم فایل ریشه پردازش می شود. پس از گرفتن اطلاعات، تصاویر حذف می شوند.
کارهای بیشتر روی سرور ذخیره سازی پشتیبان انجام می شود:
- آخرین نسخه پشتیبان تهیه شده در هر مخزن بررسی می شود،
- وجود یک فایل علامت بررسی می شود، که نشان می دهد فرآیند جمع آوری داده ها تکمیل شده است،
- داده ها به حجم محلی مربوطه گسترش می یابد،
- فایل تگ حذف می شود
فرآیند بازیابی سرور
اگر سرور اصلی بمیرد، سرور اختصاصی مشابهی راه اندازی می شود که از یک تصویر استاندارد بوت می شود. به احتمال زیاد دانلود از طریق شبکه انجام می شود، اما تکنسین مرکز داده که سرور را راه اندازی می کند می تواند بلافاصله این تصویر استاندارد را در یکی از دیسک ها کپی کند. دانلود در RAM انجام می شود و پس از آن فرآیند بازیابی شروع می شود:
- درخواستی برای پیوست کردن یک دستگاه بلوک از طریق iscsinbd یا پروتکل مشابه دیگری به یک حجم منطقی حاوی سیستم فایل ریشه سرور متوفی انجام می شود. از آنجایی که فایل سیستم ریشه باید کوچک باشد، این مرحله باید در چند دقیقه تکمیل شود. بوت لودر نیز بازیابی شده است.
- ساختار حجم‌های منطقی محلی دوباره ایجاد می‌شود، حجم‌های منطقی از سرور پشتیبان با استفاده از ماژول هسته dm_clone متصل می‌شوند: بازیابی داده‌ها شروع می‌شود و تغییرات بلافاصله در دیسک‌های محلی نوشته می‌شوند.
- یک کانتینر با تمام دیسک های فیزیکی موجود راه اندازی می شود - عملکرد سرور به طور کامل بازیابی شده است، اما با عملکرد کاهش یافته.
- پس از تکمیل همگام سازی داده ها، حجم های منطقی از سرور پشتیبان قطع می شود، ظرف خاموش می شود و سرور راه اندازی مجدد می شود.
پس از راه‌اندازی مجدد، سرور تمام داده‌هایی را که در زمان ایجاد پشتیبان وجود داشته است، خواهد داشت، و همچنین شامل تمام تغییراتی است که در طول فرآیند بازیابی ایجاد شده‌اند.
سایر مقالات این مجموعه
پشتیبان گیری قسمت 7: نتیجه گیری
از شما دعوت می کنم در نظرات درباره گزینه پیشنهادی صحبت کنید، از توجه شما متشکرم!
منبع: www.habr.com