پوریا رضاتبار بالانقیبی

»»——☠——«   قسمت בوم »——☠——««

اندازه سازمان و تعداد سرورها و کلاینت ها

چرا اندازه سازمان «تعداد» نیست و «الگو» است

در طراحی بکاپ، بزرگ یا کوچک بودن سازمان فقط با شمارش سرورها تعیین نمی شود، بلکه با الگوی تولید داده و الگوی عملیات تعیین می شود. دو سازمان با ۲۰ سرور می توانند نیاز کاملا متفاوتی داشته باشند اگر یکی روزانه چند ترابایت تغییر داده داشته باشد و دیگری چند گیگابایت. بنابراین اندازه سازمان را باید به چند محور تبدیل کرد که مستقیما روی معماری اثر می گذارند

تعداد دارایی ها: سرورهای فیزیکی، ماشین های مجازی، کانتینرها، سرویس های ابری، کلاینت های کاربر

حجم داده تحت حفاظت و مهمتر از آن نرخ تغییر روزانه

تعداد سایت ها و شعب و فاصله شبکه ای آن ها

محدودیت های عملیاتی: پنجره بکاپ، ساعت های کاری، محدودیت خاموشی، تیم نگهداری

الزامات امنیتی و انطباق: نگهداری بلندمدت، جداسازی، ثبت وقایع، محدودیت دسترسی

 مدل سازمانی طبقه بندی دارایی ها برای بکاپ

برای اینکه بکاپ از «لیست فایل ها» به «سامانه قابل مدیریت» تبدیل شود، دارایی ها را سازمانی طبقه بندی می کنند. یک طبقه بندی کارآمد معمولا چند لایه دارد

دامنه سرویس: زیرساخت پایه، سرویس های تجاری، سرویس های پشتیبان

حساسیت داده: عمومی، داخلی، محرمانه، بسیار محرمانه

حیاتی بودن: حیاتی، مهم، معمولی، کم اهمیت

نوع بارکاری: فایل محور، دیتابیس، پیام رسانی، مجازی سازی، برنامه های وب، تحلیلی

این طبقه بندی مستقیم به سیاست زمان بندی، نگهداری، رمزنگاری، و مقصد بکاپ تبدیل می شود.

موجودی گیری سازمانی به سبک قابل اتکا

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

 نقشه دارایی ها: چه چیزی وجود دارد، کجاست، مالک آن کیست

نقشه وابستگی: هر سرویس به چه چیزهایی وابسته است مثل نام و گواهی و دیتابیس و صف پیام

نقشه داده: داده اصلی کجاست، کپی ها کجاست، «منبع حقیقت» کدام است

نقشه دسترسی: چه حساب هایی به کجا دسترسی دارند، مخصوصا به مخزن بکاپ

 نقشه تغییر: چه بخش هایی بیشترین تغییر را دارند تا سیاست افزایشی و نگهداری درست تعیین شود

در سازمان های متوسط و بزرگ، نتیجه مهم این مرحله این است که «واحد» تعریف کنید. واحد یعنی چیزی که بکاپ و بازیابی آن معنی دارد، مثلا «سرویس حقوق و دستمزد» یا «پرتال مشتریان»، نه صرفا یک ماشین.

برآورد ظرفیت به زبان مدیریتی و به زبان مهندسی

ظرفیت بکاپ دو نوع هزینه دارد: هزینه ذخیره سازی و هزینه زمان و شبکه.

برای اینکه ظرفیت قابل دفاع باشد، معمولا این محورها را عددی می کنند

حجم اولیه داده قابل بکاپ

نرخ رشد ماهانه

نرخ تغییر روزانه

نسبت فشرده سازی و رفع تکرار واقعی در داده های شما

همزمانی کارها و اوج بار

نرخ بازیابی مورد انتظار

به شکل سازمانی، شما باید دو ظرفیت جدا ببینید

ظرفیت مخزن عملیاتی برای بازیابی سریع کوتاه مدت

ظرفیت آرشیوی یا خارج از سایت برای تاب آوری و نگهداری بلندمدت

ترکیب این دو تعیین می کند بکاپ به چه شکل لایه بندی شود.

پنجره بکاپ و واقعیت بهره برداری

در سازمان های واقعی، بزرگترین دشمن بکاپ «کمبود زمان شبانه» است. اگر پنجره بکاپ کوتاه باشد، معماری باید به سمت این گزینه ها برود

 افزایشی دائمی با فول های دوره ای

 استفاده از تغییر بلوکی در مجازی سازی

 توزیع بار با پروکسی ها یا چند مسیر انتقال

 اولویت بندی کارها بر اساس حیاتی بودن

 بکاپ های نزدیک به منبع در شعب و سپس تجمیع خارج از ساعت شلوغی

و یک نکته سازمانی مهم: اگر پنجره بکاپ را بر اساس تصور ایده آل طراحی کنید نه بر اساس ترافیک واقعی، پروژه در ماه اول دچار شکست های زنجیره ای می شود.

کلاینت های کاربر و چالش پراکندگی

در بسیاری از سازمان ها، «داده حیاتی» ناخواسته روی لپ تاپ هاست: فایل های قرارداد، خروجی تحلیل، اسناد. اگر این کلاینت ها خارج از دفتر کار می کنند، بکاپشان باید این ویژگی ها را داشته باشد

تحمل قطع و وصل اینترنت و ادامه انتقال

رمزنگاری سرتاسری

کنترل پهنای باند و زمان بندی

سیاست نگهداری کوتاه برای کاهش هزینه

قابلیت بازیابی خودکار یا سلف سرویس برای کاهش فشار به تیم IT

در سازمان بالغ، سیاست این است که یا داده را از کلاینت به مخازن سازمانی منتقل کنید یا بکاپ کلاینت را یک سرویس رسمی با مالکیت و گزارش گیری کنید، نه یک اقدام سلیقه ای.

مجازی سازی دارید یا نه

تفاوت بنیادی در نقطه کنترل

اگر مجازی سازی ندارید، نقطه کنترل شما سیستم عامل و اپلیکیشن روی هر سرور است و بکاپ غالبا ایجنت محور می شود.

اگر مجازی سازی دارید، نقطه کنترل شما هایپروایزر و لایه ذخیره سازی است و بکاپ می تواند ماشین محور باشد.

این تفاوت روی همه چیز اثر می گذارد: سرعت، سازگاری، پیچیدگی، و حتی مدل امنیت.

معماری بکاپ در محیط غیرمجازی

در محیط فیزیکی یا پراکنده، معمولا این الگوها رایج است

ایجنت روی هر سرور برای بکاپ فایل و سیستم و اپلیکیشن

بکاپ برنامه محور جداگانه برای دیتابیس ها

ذخیره سازی متمرکز یا نیمه متمرکز برای مخزن

چالش ها

نگهداری نسخه ایجنت ها و ناسازگاری ها

مصرف منابع روی سرورهای تولید

پیچیدگی در بازگردانی کامل سرویس به سخت افزار جدید

راه حل سازمانی

استاندارد کردن سیستم عامل ها و پچ ها تا ایجنت ها پایدار باشند

تعریف «پروفایل بکاپ» برای نقش ها مثل فایل سرور، وب سرور، دیتابیس

مستندسازی بازیابی bare metal یا معادل آن

معماری بکاپ در محیط مجازی

در مجازی سازی، هدف این است که بدون فشار مستقیم روی هر ماشین، بکاپ قابل اتکا گرفته شود و بازیابی سریع باشد. معمولا چند قابلیت تعیین کننده هستند

اسنپ شات هماهنگ با فایل سیستم و اپلیکیشن

انتقال داده از مسیر بهینه با پروکسی

تغییر بلوکی برای کاهش حجم افزایشی

امکان بازیابی سریع ماشین و سپس انتقال به ذخیره سازی اصلی

اما ریسک های خاص هم وجود دارد

انفجار همبستگی: یک خطای ذخیره سازی یا یک پیکربندی بد، صدها ماشین را یکجا تحت تاثیر می گذارد

قفل شدن روی یک نقطه کنترل: اگر کاتالوگ یا سرویس مدیریت بکاپ آسیب ببیند، بازیابی گسترده سخت می شود

رشد اسنپ شات ها و پر شدن datastore در اثر بکاپ های ناقص

برای سازمان های بزرگ، بلوغ یعنی اینها را رسمی می کنند

سیاست محدودیت مدت اسنپ شات و پایش اجباری

جداسازی شبکه بکاپ از شبکه تولید

طراحی ظرفیت با در نظر گرفتن بازیابی انبوه نه فقط بکاپ گیری روزانه

کانتینر و بارهای مدرن

حتی اگر «مجازی سازی» دارید، ممکن است بار کاری شما کانتینری باشد. بکاپ کانتینر به معنی بکاپ گرفتن از خود کانتینر نیست، بلکه بکاپ از اینهاست

داده پایدار و حجم ها

پیکربندی ها و رازها و سیاست ها

رجیستری و نسخه تصاویر

تعریف سرویس و شبکه

در سازمان های نوین، هدف این است که بازتولید محیط سریع باشد و بکاپ بیشتر روی داده های پایدار متمرکز شود.

نوع دیتابیس ها و برنامه های حیاتی

چرا «نوع دیتابیس» تعیین کننده RPO است

برای دیتابیس، بکاپ با کپی فایل فرق دارد. شما با مفهومی به نام سازگاری تراکنشی سروکار دارید. بنابراین نوع دیتابیس و مدل ثبت لاگ و روش بازیابی آن تعیین می کند که آیا می توانید RPO چند دقیقه ای داشته باشید یا نه.

به زبان سازمانی، سه کلاس نیاز دارید

دیتابیس هایی که باید نقطه به نقطه بازیابی شوند و لاگ بکاپ می خواهند

دیتابیس هایی که بکاپ روزانه کافی است

دیتاست هایی که بیشتر آرشیوی اند و می توانند با RPO بزرگتر کار کنند

برنامه های حیاتی و دامنه واقعی بکاپ

برای یک برنامه حیاتی، معمولا چند جزء باید همزمان دیده شوند

داده اصلی مثل دیتابیس

فایل های بارگذاری شده و دارایی های رسانه ای

پیکربندی برنامه و پارامترها

گواهی های دیجیتال و کلیدها

وابستگی ها مثل صف پیام، کش، سرویس جستجو، سرویس گزارش

اگر فقط از دیتابیس بکاپ بگیرید ولی گواهی ها یا پیکربندی اتصال ها از بین برود، RTO واقعی شما بالا می رود. سازمان های بالغ برای هر برنامه حیاتی یک «بسته بازیابی» تعریف می کنند که شامل همه این اجزا و ترتیب بازگردانی است.

دسته بندی برنامه ها برای سیاست بکاپ

یک روش کارآمد سازمانی این است که برنامه ها را به چند تیپ استاندارد تبدیل کنید و برای هر تیپ، سیاست آماده داشته باشید

برنامه های تراکنشی با دیتابیس مرکزی

برنامه های فایل محور و همکاری

سرویس های وب استاتیک یا کم تغییر

سرویس های تحلیلی و انبار داده

سرویس های یکپارچه سازی و تبادل پیام

هر تیپ، الگوی بکاپ، نگهداری، و آزمون بازیابی مخصوص دارد.

بکاپ از پیکربندی و زیرساخت به اندازه دیتا مهم است

برای سیستم های حیاتی، این موارد معمولا در حادثه فراموش می شوند اما زمان بازیابی را تعیین می کنند

تنظیمات شبکه و نام ها و رکوردها

تنظیمات دیوارآتش و دسترسی ها

تنظیمات بالانسر و معکوس کننده ها

حساب های سرویس و مجوزها

کلیدهای رمزنگاری و مدیریت کلید

نسخه ها و وابستگی های نرم افزاری

راهکار نوین سازمانی این است که پیکربندی را تا حد امکان استاندارد، نسخه بندی شده، و قابل بازتولید نگه دارید تا بکاپ فقط «داده» باشد نه «همه چیز».

داده های غیرساخت یافته و چالش انفجار فایل های کوچک

اشتراک های فایل، ایمیل های آرشیوی، و خروجی های تیم ها معمولا میلیون ها فایل کوچک دارند. این داده ها از نظر تعداد فایل، نه حجم، بکاپ را کند می کنند. راهبردهای سازمانی شامل

نسخه بندی نزدیک به منبع برای بازگشت سریع

سیاست پاکسازی و چرخه عمر داده برای جلوگیری از انباشت بی پایان

جداسازی داده های آرشیوی از داده های عملیاتی

زمان بندی هوشمند برای کاهش قفل فایل و تداخل با کاربران

هدف های RPO و RTO تقریبی

تبدیل خواسته کسب و کار به عدد قابل طراحی

RPO و RTO اگر از کسب و کار استخراج نشوند، تبدیل به اعداد خیالی می شوند. روش سازمانی این است که برای هر سرویس بپرسید

اگر داده از دست برود، هزینه آن چیست و در چه بازه ای غیرقابل تحمل می شود

اگر سرویس قطع شود، چه فرآیندهایی متوقف می شوند و چه مدت تحمل دارند

چه جایگزین دستی وجود دارد و تا چه مدت

بعد اینها را به یک طبقه عملیاتی تبدیل می کنند، مثلا

حیاتی با RTO بسیار پایین و RPO پایین

مهم با RTO متوسط و RPO متوسط

معمولی با RTO و RPO بالاتر

نکته پیشرفته این است که RPO و RTO را فقط برای «سرویس» تعریف نکنید، برای «جزء» هم تعریف کنید. مثلا وب سایت ممکن است RTO پایین بخواهد اما گزارش گیری داخلی نه.

پیامدهای مستقیم RPO و RTO روی معماری

RPO پایین یعنی دفعات بکاپ بیشتر، لاگ بکاپ، یا مکانیزم های نزدیک به لحظه. این باعث افزایش بار شبکه، افزایش IOPS ذخیره سازی، و افزایش نیاز به اتوماسیون مانیتورینگ می شود.

RTO پایین یعنی بازیابی باید سریع باشد. این معمولا نیازمند

بکاپ تصویر محور برای بازگردانی کامل

مخزن سریع نزدیک به محل اجرا

فرآیندهای استاندارد و تست شده

آماده بودن زیرساخت مقصد برای بالا آوردن سرویس

اگر RPO پایین دارید ولی RTO بالا، می توانید بیشتر روی ذخیره سازی و ثبت تغییر تمرکز کنید. اگر RTO پایین دارید ولی RPO بالا، می توانید روی قابلیت بالا آوردن سریع نسخه آخر تمرکز کنید. خیلی از سازمان ها این دو را قاطی می کنند و هزینه بی دلیل بالا می رود.

خطای رایج: RTO را فقط برای سرور دیدن

کسب و کار RTO را برای «سرویس قابل استفاده» می خواهد، نه برای روشن شدن یک ماشین. ممکن است ماشین بالا بیاید ولی اینها آماده نباشند

دیتابیس در حالت سازگار

نام و گواهی ها درست

دسترسی کاربران برقرار

وابستگی ها مثل پیام رسانی و کش و ذخیره فایل

بنابراین RTO باید با سناریوی بازیابی انتها به انتها سنجیده شود.

آزمون پذیری RPO و RTO

اگر نتوانید RPO و RTO را با آزمون نشان دهید، آن ها هدف عملیاتی نیستند. سازمان های پیشرفته برای هر سرویس حیاتی اینها را تعریف می کنند

سناریوی آزمون: حذف فایل، خرابی دیتابیس، رمزگذاری، خرابی سایت

معیار زمان: از لحظه اعلام حادثه تا لحظه ارائه سرویس

معیار داده: چه مقدار داده از دست رفت و آیا قابل قبول بود

معیار کیفیت: آیا سرویس سالم است یا فقط بالا آمده

ثبت نتیجه و اقدام اصلاحی

این موضوع را باید به چرخه مدیریت تغییر وصل کنید. هر تغییر بزرگ در برنامه یا زیرساخت می تواند RTO را بدتر کند اگر آزمون دوباره انجام نشود.

آیا نیاز به بکاپ خارج از سایت یا ابر دارید و سرعت اینترنت چقدر است

بکاپ خارج از سایت: شرط تاب آوری واقعی

بکاپ داخل همان ساختمان در برابر سناریوهای بزرگ شکست می خورد: آتش سوزی، سرقت، خطای گسترده برق، یا رخداد امنیتی که به کل شبکه دسترسی پیدا کند. خارج از سایت یعنی یک نسخه که با حادثه اصلی هم سرنوشت نباشد. این خارج از سایت می تواند

سایت دوم سازمانی

ارائه دهنده ابر

رسانه جدا و آفلاین در چرخه مشخص

در طراحی نوین، هدف فقط «دور بودن» نیست، هدف «جداسازی دسترسی و تغییرناپذیری» است.

انتخاب بین سایت دوم و ابر بر اساس کنترل، هزینه و عملیات

سایت دوم کنترل بیشتر می دهد و برای بازیابی حجیم سریع تر است اگر لینک خوب باشد، اما هزینه سرمایه ای و نگهداری و امنیت فیزیکی دارد.

ابر هزینه اولیه کمتر و انعطاف بیشتر می دهد، اما

هزینه خروجی و بازیابی حجیم می تواند بالا باشد

وابستگی به اینترنت و محدودیت های زمان بحران وجود دارد

نیاز جدی به مدیریت هویت و کلید و قفل زمانی دارد

سازمان های بالغ معمولا «ترکیبی» می روند: بازیابی سریع محلی، نسخه خارج از سایت در ابر یا سایت دوم.

اینترنت و واقعیت سرعت موثر

سرعت اسمی لینک با سرعت موثر انتقال بکاپ فرق دارد. عوامل تعیین کننده

نوسان و از دست رفتن بسته ها

محدودیت های مسیر و ازدحام

همزمانی ترافیک کاربران

سربار رمزنگاری و فشرده سازی

محدودیت های سمت مقصد

برای طراحی، باید به جای تکیه بر عدد تبلیغاتی، یک معیار عملیاتی بسازید: حجم داده ای که در بازه مشخص واقعا منتقل می شود.

راهبردهای کاهش وابستگی به پهنای باند

اگر اینترنت محدود است، چند راهبرد مدرن به کار می آید

لایه بندی مقصد: نگهداری کوتاه مدت محلی، ارسال گزینشی به خارج از سایت

ارسال افزایشی و رفع تکرار در سطح بلوک یا شی

زمان بندی انتقال خارج از ساعت کاری

تعیین اولویت: سرویس های حیاتی اول

Seed اولیه: انتقال اولیه داده با روش های غیرشبکه ای و سپس فقط تغییرات

هدف این است که خارج از سایت همیشه به روز بماند، نه اینکه هر بار یک انتقال عظیم شکست بخورد.

امنیت خارج از سایت و ابر: هویت، کلید، و قفل

وقتی مقصد بیرون از سازمان است، سه لایه باید سازمانی و رسمی شوند

هویت و دسترسی: حساب های جدا، کمترین دسترسی، ثبت رویداد، احراز هویت قوی

مدیریت کلید: کلیدها جدا از مقصد نگهداری شوند و دسترسی به آن ها کنترل شده باشد

تغییرناپذیری: سیاست قفل زمانی و جلوگیری از حذف یا دستکاری

اگر این سه لایه نباشد، مقصد خارج از سایت می تواند با همان حمله ای که داخل را گرفت، نابود یا غیرقابل اعتماد شود.

تعریف سناریوی «بازیابی از بیرون» قبل از حادثه

بکاپ خارج از سایت زمانی ارزشمند است که بازیابی از آن تمرین شده باشد. باید روشن باشد

در بحران، چه کسی و از چه مسیر شبکه ای به مقصد دسترسی دارد

اگر اینترنت قطع باشد چه می شود

چه مقدار داده را می توان در چه مدت برگرداند

آیا امکان بالا آوردن سرویس در محل دیگر وجود دارد یا فقط بازگردانی داده مد نظر است