فیلم گفتگو: پایش بانک اطلاعات اتوماسیون کسب و کار فراگستر

زمان تقریبی مطالعه: 27 دقیقه

معمولا یکی از دغدغه‌های اصلی سازمانها بخصوص راهبران سیستم‌ها، تهیه بکاپ یا پشتیبان‌گیری از اطلاعات است. فرآیند مربوط به تهیه بکاپ اطلاعات در پایگاه‌های داده حیاتی سازمان، نظیر سیستمهای اتوماسیون کسب و کار، از اهمیت ویژه‌ای برخوردار است. این اهمیت حفظ و نگهداری داده برای سازمان، به اندازه‌ای است که در صورت از دست رفتن اطلاعاتشان به صورت موقت یا دائمی هزینه‌های بس گزاف و بعضا غیر قابل جبرانی به سازمان تحمیل کرده و می‌تواند باعث اختلال یا حتی توقف فعالیت‌های سازمان گردد. در همین راستا سازمان‌ها سالانه با صرف هزینه‌های بسیار سعی در حفظ و نگهداری داده‌های سازمان به صورت امن و همیشه در دسترس دارند.

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

فیلم کامل گفتگو

محتوای متن کامل این گفتگو را از اینجا بخوانید :

– سلام خدمت آقای دکتر تجویدی هستیم از اساتید حوزه پایگاه داده یا دیتابیس مخصوصا در حوزه ادمستریشن و راهبری ایشون از اساتید به نام هستند من در واقع از ایشون خواهش کردم که توی این فیلم خدمتشون باشیم یک سری سوالات خودم دارم یک سری سوالات از واحدهای خدمات پس از فروش در واقع یادداشت شده که باید ازشون بپرسم و همچنین در واقع از سازمان های بهره بردار میخوام خواهش بکنم قبل از اینکه ما کار رو شروع بکنیم اگر سلام علیکی در واقع با دوستان دارید بفرمایید که شروع کنیم

+  من هم سلام عرض میکنم خدمت شما من در خدمتتون هستم

بکاپ (backup) و لزوم تهیه نسخه پشتیبان از نرم افزار

(از زمان 00:59 تا 04:14 )

– آقای دکتر ما توی حوزه ی همانطور که عنایت دارید در زمینه حوزه سیستم های اطلاعاتی علی الخصوص سیستم های اتوماسیون کسب و کار، Business automationفعال هستیم فراگستر رو شما میشناسید عرضم به حضور شما که یک دغدغه وجود داره در زمینه نگهداشت داده ها سیستم های مختلف سیستم های در واقع اتوماسیون اداری سیستم های اتوماسیون مالی سیستم های تولید و تمامی در واقع نرم افزارها منتج میشه به تولید داده و اطلاعات اینها در واقع ثروت سازمان هستش این یه فکتی که بالاخره باید بذاریمش گوشه از یک سمت دیگه هم داریم میشنویم اخبار رو که در زمینه در واقع از دست رفتن اطلاعات یا در واقع نفوذ هایی که اتفاق میفته این ثروت در واقع در یک کسری از ثانیه در واقع دود میشه و به هوا میره این فکت دوم از کجا شروع بکنیم صحبت کردن رو ما در واقع عرضم به حضور شما که توی حوزه پیاده سازی سیستم ها خیلی در واقع سازمان ها اصرار به تنظیم بک آپ دارند خوب خیلی چیز واضح و درستی هم هستش ولی همیشه اعتقاد من این بوده که تنظیم بکاپ یک چیزی هستش که در واقع کارفرما و پیمانکار باید بشینند با همدیگه این کارو انجام بدن یک نسخه ای نیستش که یک شرکت ۱۰۰ نفره با یک شرکت هزار نفره با شرکت چند هزار نفره ما بیایم بگیم خیلی خوب ما نسخه را می خواهیم در واقع تنظیمات بک آپ رو روی سیستم انجام بدیم اینها رفتارهای مختلفی داره آیا با این در واقع عرض بنده شما موافق هستید که این یک در واقع اشتراک و اجتماع میخواد که بخواد این کار درست در واقع برنامه ریزی بشه

+ بله دقیقا ببینید مسئله بکاپ تقریبا میشه گفت مهمترین مسئله تو بحث نگهداشت دیتا هست اینکه به چه شکل بکاپ گرفته بشه زمان بندیش چه جوری باشد آیا روزانه بکاپ گرفته بشه ساعتی یا دقیقه ای بکاپ گرفته بشه اینکه خود این بکاپ یا پشتیبان کجا نگهداری بشه و اینکه آیا این بکاپ واقعا سالمه اگه روزی اتفاقی افتاد قابل برگشت هست خیلی بحث مفصلیه که میشه در موردش صحبت کرد بک آپ به چه شکلی است انواع بک اپ چه جوری است چه جوری زمان بندی کنیم یا همونطور که شما فرمودید مشتری با حجم دیتای متفاوت و شاید مدل کسب و کارشان هم با اینکه همه اونها دارن از اتوماسیون استفاده میکنن ولی مدل کسب و کاری شان فرق داشته باشد تحمل اینکه سیستم قطع باشه ممکنه برای سازمان a و سازمان b متفاوت باشد خب باید یک رویکرد جدیدی برایش در نظر گرفت خب به نظر من چون خیلی بحث مفصله از یک نقطه ای شروع کنیم تفکیکش کنیم

زمانبندی بک آپ و آشنایی با مفاهیم RTO و RPO

(از زمان 04:14 تا 05:26)

– بسیار عالی آقای دکتر من دوتا مفهوم میشناسم به نام آرپیو و آرتیو یعنی میزان زمانی که من سازمانم تحمل داره برای از دست دادن داده و میزان زمانی هم که در واقع سازمان هم صبر داره که زمانی که یک در واقع رخداد ناگواری اتفاق میفته برگردونم به محلی که در واقع بودم من میدونم در سازمان های بزرگ صحبت از ثانیه است شاید هم صحبت ثانیه هم نباشه یعنی بانک ها علی القاعده در زمینه نگه داشتن دیتاشون حتی شاید ثانیه براشون عدد بزرگی باشد ولی سازمان هایی هستند که در واقع عرضم به حضور شما که این عدده برایشان میتواند بزرگتر باشد ولی هر دو تا سازمان فارغ از این قضیه میان بهترین را برای خودشون در نظر میگیرند من روی این قضیه یک ذره در واقع عرضم به حضور شما که مسئله دارم اگر در واقع تو حوزه نگهداشت اطلاعات و بکاپ ها اگر صحبت ثانیه هستش آیا ما در زمینه اون که اون هزینه ای که بابت اون زیرساخت لازم هستش آیا توجیه هستیم

تهیه نسخ پشتیبان، بنا به حجم اطلاعات و منابع سخت افزاری

(از زمان05:26 تا 09:20)

– این قسمت رو می‌خوام در واقع توضیح در واقع بفرمایید که من چطور میتونم در واقع بکاپم را به نحوی تنظیم بکنم که اون دوتا مفهومی که عرض کردم خیلی به هم نزدیک باشه کوچیک باشه یا اگر در واقع یک سازمان یا یک شرکتی هستم که در واقع نمیخوام اون هزینه های چند صد میلیونی یا میلیاردی در واقع انجام بدم چه شکلی میتونم در واقع اندازه گیری بکنم که  trade off اتفاق بیفتد با اون هزینه ای که میخوام در ارتباط با زیرساخت داشته باشم بتونم در واقع گارانتی خوبی هم در حوزه دیتا داشته باشم

+دقیقا همانطور که شما فرمودید ممکنه که قطعاً هزینه خیلی بالایی برای سازمان داشته باشد به طور مثال ممکنه شما یه سیستم مالی توی شرکتتون وجود داره که اونقدرها بحث آرتیو شاید توش مهم نباشه چون شما این دو مورد رو دقیق توضیح فرمودید من دیگه اشاره نمیکنم ولی شما میفرمایین سیستم مالی من ممکنه یک ساعت قطع باشه اوکی به سازمان لطمه نمیزنه حالا یا سیستم کارت ساعت ورودی که بچه ها میان سیستم قطع شده اوکی دستی ثبت میکنم تا سیستم وصل بشه خب چون اون زمان ریکاوریش اونقدرها اهمیت نداره پس توجیه هم نداره که هزینه خیلی زیادی بکنید که ما سر ثانیه هم سیستم قطع نشود ولی از طرفی خیلی از سیستم هایی هست توی کشور ما که به ازای قطعی چند دقیقه ای باید جریمه پرداخت کنم به هر حال یک slaبسته شده و بر مبنای اون اگر قطعی رخ بده باید اون سازمان هزینه اش را پرداخت کنه خوب اون حساسیت دارد حالا اینکه صرفا ما آرتیو آر پی او را با مکانیزم بکاپ و زمان بندی بک آپ میتونیم هندلش کنیم که قطعاً به این شکل نیست من فکر میکنم باید توی جلسه دیگه در مورد HA صحبت کنیم  HA کمک میکنه

– یعنی شما می‌فرمایید که اگر بخواهیم به اون صفر برسیم سازمان اینترپرایز قطعا باید یک بک اپ Always on  یا HA  راه اندازی کنند

+ قطعا باید یک HA  راه اندازی کنند که حالا روی Sql server بحث Always on  هست که بتونه دیتا رو توی یه فضایی حتی خارج از اون دیتا سنترش یعنی نگهداری کنه که بگیم به غیر از  HA  بحث DR   هم مطرح میشه که اگر اتفاق بدی برای دیتا سنتر هم افتاد هر تعداد سروری هم که بود دچار مشکل شد ما میدانیم دیتا جای دیگه هست در واقع RTO مون خیلی کمه یعنی حتی میتونیم اون فضا را به صورت اتوماتیک FAIL OVER بزنیم یعنی سیستم به سرعت سوییچ کنه و اون دیتابیسی که خارج از اون دیتا سنتر اولی ما بود نقش دیتابیس اصلی را بازی کند خب اینجا در واقع سازمان خیلیش راحته که RTO رو تونسته نزدیک به صفر ببره از طرفی خوب دیتایی هم این وسط از بین نرفته پس علاوه بر اینکه خود بک آپ خیلی مهم هست چون  HA که من خدمت شما عرض کردم به هیچ عنوان جایگزین بکاپ نیست چون حالا عمدی یا سهوی اگر اتفاقی برای دیتا بیفته خب روی نودهای دیگه  HAیا اون کلستر ما هم تاثیر میذارد  و اون دیتا از بین میرد تو این زمانه که بک آپ ما میرسه بخاطر اینکه توی کلاستر معمولا دیتا سینک هستند دیتایی پاک بشه روی همه ی نود ها پاک میشود و اگر ما بخواهیم دیتای پاک شده را برگردانیم اون موقع است که تنها گزینه برای ما میشه بک اپ پس در وقع HA  کمک میکنه در کنار بکاپ ما بتونیم RTO  و RPO را نزدیک به صفر داشته باشیم

– بسیار عالی تشکر میکنم.

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

چطور از دیتاها در اتوماسیون اداری فراگستر نسخه پشتیبان (بک آپ) تهیه کنیم؟

شرح انواع بکاپ گیری از اطلاعات

(از زمان 09:20 تا 17:26)

– تعداد سازمان‌هایی که در واقع میخوان این دوتا عدد به صفر برسه کمه علی القاعده در واقع سازمان اینترپرایز باشد باشن مثلا بانک باید باشه وزارتخونه باید باشه یا در این SCALE باشد ولی در واقع حجم خیلی زیادی از بهره بردار های این نوع سیستم ها توی این رنج نمی گنجند شرکت هایی هستند که مثلا فرض بفرمایید که شرکت های تولیدی هستند شرکت های در واقع توزیع و پخش هستند اینها در واقع عرضم به حضور شما که شاید هم اصلا هیچ وقت اون هزینه نگهداشتشون اینقدر نخواد بالا بره که بخوام به سمت در واقع راه حل ها برن و میپذیرند و در واقع تمام هدف من این هستش که این یک مبحث در واقع دو تا کفه ترازو هستش که اگر در واقع ما بخواهیم هزینه رو کنترل بکنیم یک مقدار باید در واقع اون انتظارات رو همون RPO  و RTO  را در واقع اون انتظار رو بیاریم پایین تر بگیم که آقا ما میپذیریم که مثلا از زمانی که بخواد دیتا از دست بده و برگرده مثلا من نیم ساعت را میپذیرم پس در واقع میریم سمت در واقع راه حل های به نوعی آفلاینی مثل بک آپ که شما فرمودید که این جایگاه شون هیچ وقت در واقع راه حل های HA جایگزین این ها نمیشن خوب پس حجم خیلی زیادی از سازمان ها به نظر من توی این رنج قرار میگیره که باید یک در واقع تنظیم صحیحی برای در واقع بکاپ شون در حوزه اطلاعات داشته باشد من دو تا در واقع خواهش دارم یکی اینکه انواع بکاپ رو برای در واقع من شرح بدید ما چه نوع بکاپ هایی داریم یک در واقع اطلاعاتی از شما بگیرم و یک Best Practice  را در واقع خیلی دوست دارم برای من روی میز بگذارید فرض بفرمایید من مدیر عامل یک شرکت Medium Scale  هستم مثلا فرض بفرمایید که ۵۰۰ تا در واقع کاربر دارم حجم دیتای چند صد گیگی دارم من چند نوع در واقع میتونم که بک آپ تنظیم بکنم و Best Practice  که برای Scale  من که یک تعداد زیادی از سازمان های کشور توی این رنج میگنجه را اگر مطرح بفرمایید ممنون میشم ازتون

+ ما چون در واقع داریم رو بحث پلتفرم مایکروسافت  و در واقع  Sql بحث رو جلو میبریم هرچند که بقیهRdbms ها هم تقریبا همین قاعده هست به هر حال هم full-backup  هست هم differential-backup  و هم backup- transactional حالا سعی  هم بر اینه خیلی بحث ها فنی نباشه و توضیحات به صورت کلی باشد full-backup از اسمش مشخصه اینجوری تصور کنیم که کل دیتابیس و آبجکت هایی که داخلش هست را داره بک اپ میگیره و یکجا برای ما نگهداری میکنه خوب خیلی جاها همین یه دونه بک آپ دارند و ممکن هم هست به ذهن برسه همین بک اپ کفایت میکنه دیگه شما همه چیز را بک آپ میگیری یه جا داری چه لزومی داره نوع های دیگه بک اپ اینجا مطرح بشه بله ولی این فرایند یکی اینکه زمان بره مثلا حتی سازمانی که دیتای زیادی هم نداره ممکنه فرایند بک آپش نیم ساعت طول بکشه و اینکه به هر حال بکاپ منابع بره سی پی یو را درگیر میکنه آی او را درگیر میکنه تا حدودی  ram را درگیر میکنه نمیشه به این پشت سر هم تداوم بخشید و همینطور این بک اپ را پشت سرهم گرفت اگر هم بگیم  شبانه ما روزی یک بار بکاپ میگیریم خوب اینجا RPO خیلی عدد بدی میشه به فرض اینکه من ۱۲ شب حالا بگیم بامداد بک آپ گرفتیم ساعت پنج عصر یه اتفاقی افتاد و سیستم از بین رفت خب من فاصله اون روز تا پنج عصر دیتا را از دست میدم خوب پس full-backup خوبه اما به تنهایی کافی نیست یه جورایی انگار شرط لازمه ولی شرط کافی نیست اینجا تایپ های دیگری از بکاپ مطرح میشه.  differential-backup  بکاپ میاد به Full قبلش نگاه میکند هر چقدر تغییرات توی دیتا رخ داد این تغییرات  را بک اپ میگیرد حالا اگر بخواهیم به لحاظ فنیش بگیم به اندازه یک اکستند که هشت تا پیج هشت کیلوبایتیه به ازای هر تغییری اون میزان در واقع دیتا رو یه جایی برای ما نگهداری میکند خوب طبیعیه که یه بانکی که حتی چند ترابایت دیتا داشته باشه ممکنه در طول یک روز تغییراتش به چند بیت بیشتر نرسد خب پس میتونه یه بار full بک آپ بگیره روزانه شروع کند به differential-backup گرفتن اگر روزی هم نیاز پیدا کرد به اینکه این بک اپو برگردونه Full رو که برگردونه میتونه آخرین  differential رو هم برگردونه و به اون لحظه از زمان که differential-backup گرفته سیستم رو به اون نقطه برسونه اما کنار این دو نوع بکاپ، بکاپ سومی وجود داره که خیلی مهمه اینقدر مهمه که ما حتی میتونیم differential-backup رو حذف کنیم و اون هم backup- transactional است. transactional-backup چند تا کار خوب برای ما انجام میده اسمش رو خود بکاپه هست یعنی میاد تا اون آخرین تراکنشی که انجام شده اون پشتیبان میگیره از بانک اطلاعات و خوبی ای که transactional-backup داره اینه که اون در واقع Chain یا زنجیرش حفظ میشه یعنی چی ؟ من مثال بزنم ساعت پنج عصر Full-backup گرفتم.   شروع میکنم  یک ربع یه بار transactional-backup گرفتن. شد ساعت ده شب. ده شب گفتن یه اتفاقی افتاد و یه دیتایی از بین رفت. ده شب اعلام کردن بررسی  میکنم میبینم نه اون اتفاقه ساعت 9 شب اتفاق افتاده آیا ما میتونیم روی زمان حرکت کنیم؟ بله با داشتن transactional-backup و full-backup ما میتونیم بانک رو به نقطه ساعت ۸ شب ببریم به غیر از این یه چیزی که قطعاً شما و همکاران شما باهاش مواجه بودین اینه که لاگ دیتابیس خیلی رشد کرده خوب لاگ دیتابیس چیز مهمی است و اگر شما از اون بکاپ نگیرین sql server میگه تا زمانی که شما transactional-backup نگرفتید من اون لاگو حفظ میکنم خیلی وقتا اون لاگ ممکنه حتی حجمش بیشتر از دیتا باشه چرا؟ تصور کنین ما یه بانک یه گیگی داریم میایم delete و insert میکنیم یعنی حذف میکنیم و اضافه میکنیم همون فضا به لحاظ دیتا برایش کفایت میکرد ولی چون داره توی زمان اتفاقاتی میفته خوب اون رخ داد رو sql server میخواد ثبت کنه پس لاگ داره رشد میکنه تا کجا؟ اگر ما transactional-backup نگیریم میشه گفت تا ابد تا جایی که درایو فایل لاگ روش هست بله پر میشه و مشکل ایجاد میکنه پس transactional-backup میگیریم که دیتا رو داشته باشیم آخرین ترانزکشن ها را داشته باشیم و اصطلاحا log recognition رخ بده یعنی اینکه rdbms ما متوجه بشه که ما این بک آپ را از این لایه بکاپ گرفتیم و یه جا نگهداری کردیم که بتونه دوباره رواون باز نویسی انجام بده و البته بد نیست که اشاره کنم دیتابیس حتما باید روی ریکاوری مدلش full باشه اگر این کار مدل به صورت سیمپل باشه دیگه transactional-backup نمیتونیم بگیریم خوب قطعا توصیه ما اینه که همه مشتری ها ریکاوری مدلشون همون full باشد

روش‌های زمانبندی بکاپ و معرفی یک Best Practice برای سازمانهای متوسط

(از زمان 17:26 تا 19:39)

+ خوب یک جمع بندی سریع داشته باشیم ما full-backupو differential-backup و transactional-backup داریم چجوری زمان بندی کنیم؟ یه چیزی که شاید بشه گفت best practice هست و من فکر میکنم خودم سالها پیش تو خود سایت مایکروسافت هم دیدم میگن هفته یکبار full-backup روزی یک بار differential-backup و یک ربع یه بار transactional-backup بک آپ بگیریم خب تا اینجا میشه گفت که ما بدون HA به RPO خوبی هم رسیدیم یعنی در بدترین حالت ما یک ربع دیتارو از دست میدیم
– درسته
+ یعنی اینکه transactional-backup رو گرفته نزدیک شده به گرفتن بعدی و سیستم یه جوری منهدم میشه هیچ چیزی ما نداریم به غیر از بک آپ که البته باید در مورد این صحبت کنیم که بک آپ حتما باید یه جای امنی گرفته بشه باید مفصل همین امروز باید در موردش صحبت کنیم خب پس باز به RPO خوبی میرسیم و به قول فرمایش شما وقتی سازمان دیتای زیادی نداره برگشت این بک آپ هم آنچنان زمانی نمیبره یعنی از لحظه‌ای که ما متوجه بشیم تا بخواهیم سیستم رو برگردیم به نظر من یه نیم ساعت طول میکشه تا سیستم دوباره UP بشه خوب آیا ما نیاز هزینه بیشتر بکنیم؟ نه اگر واقعا سازمان این اعداد ارقام براش مطلوبه خوب میتونه هزینه بیشتر نکنه اما اگر همین یک ربع ها هم خیلی مهمه براش یا اون زمانی که سیستم میخواد برگرده خیلی مهمه اوکی باید هزینه راه‌اندازی HA رو پرداخت کنه ولی مثل بقیه چیزهایی که تو دنیا هست شما وقتی یه چیزی به دست میاری کلی سختی کنارش وجود داره به هر حال وقتی میاد به سمت Always on یه سری مخاطرات داره بحث نگهداری اون کلاستره مطرح میشه حساسیت های شبکه مطرح میشه باید همه موارد در نظر بگیریم
– درسته درسته

با حجم بالای نسخه‌های پشتیبان چه کنیم؟

(از زمان 19:39 تا 22:36)

– آقای دکتر پس best practice برای مدیوم اسکیل که فرض بفرمایید همانطور که عرض کردم یک سازمان 500 نفره من اینارو عرض میکنم که یه پیش فرضی در واقع دارم میچینم دیتابیس با یک حجم دیتابیس چند ترابایتی مثلا دو یا چهار ترابایتی متوجه شدم که در واقع شما فرمودید که full رو  هفته یک بار و differential را هر روز وtransactional هر یک ربع.  من اون دوتای دوم و سوم رو فهمیدم و میذارم کنار ولی حسب تجربه در زمینه همون full هفته یک بار یکی دو تا من نکته دیده بودم که اتفاق افتاده بود میخواستم مطرح بکنم به عنوان در واقع یه چیزی که ممکنه که اتفاق بیفتد حجم دیتا روی در واقع ساعت تنظیم دیتابیس full خیلی اثر گذاره این نمیتونه در واقع به نظر من یک عدد فیکسی باشه بگیم ۱۲ یا 10 شب این در واقع اگر دیتابیس 2 ترابایت باشدیا دیتابیس 20 ترابایت باید باشه یا دیتابیس 40 ترابایت باشد و بر اساس در واقع عرضم به حضور شما که براساس اون infrastructure سخت افزاری هم که در واقع اینها رو داره هندل میکنه ممکنه که زمان بکاپ برسه به در واقع ابتدای روز کاری بعدی پس اگر در واقع آیا این رو شما در واقع می پذیرید که در این زمینه باید دقت بشه و بیایم و اون حجم رو در نظر بگیریم بر اساس اون ساعت رو اونقدر عقب بکشیم یه چیزی هم نباشه که مثلا یک مرتبه ست بشه مثلا پنج سال بعد ۱۰ سال بعد همون اتفاق بیفته این مخاطره را من دیدم که اتفاق می افتد

+ دقیقا بله شما مشتری دارین که بکاپش بیش از یک روز طول میکشه هم الان ببینید خیلی میشه در مورد این صحبت کرد به نظرم بد نیست همینجا بگیم که به هر حال یه قابلیتی که الان فراگستر داره این است که میتونه دیتابیس آرشیو راه اندازی کند خوب شما مشتری هایی دارید که بالای ۳۰ ترابایت حجم دیتاشون هست خوب نگهداری این دیتابیس خیلی سخته خصوصا همین بحث بک آپ گیری تنها را اگر صرفا بخواهیم مثال بزنیم زمان خیلی زیادی میگیره و ممکنه با روز کاری تداخل ایجاد کند و خیلی مشکلاتی که هست

– full؟

+ بله دقیقا بحث مشکل اصلا فضایی که بخواد این بکاپ نگهداری بشه حالا ممکنه یه policy هم اون سازمان داشته باشد که من تا چندتا full بکاپ قبلی روهم می‌خوام این فضای نگهداری خیلی در واقع مشکل ایجاد میکنه خوب یه امکان خوبی که من واقعا لذت میبرم ازش و این امکان را فراگستر دارد دیتابیس آرشیوه

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

(از زمان 22:36 تا 24:40)

+ ببینید من مدل دیتابیس آرشیو دیدم حتی مدل هایی که نگیم دیتابیس آرشیو آن هم با مدل پارتشنینگ مکانیزمی که توی Sql server هست اینو پیاده کردم ولی مدلی که اینجا وجود داره شما میتونید بخش زیادی از این دیتا که large object هم محسوب میشه معمولا مشتری که 30 ترابایت دیتا داره 40 ترابایت دیتا داره باید بگیم از این 40 ترابایت بالای 30 ترابایتش large object است میتونیم در سرور های دیگری اینو برد وقتی میگم سرورهای دیگه یعنی حتی لزومی نداره یه سرور به عنوان آرشیو باشه میتونه چنتا سرور به عنوان آرشیو باشه دوتا خوبی خیلی بزرگ برای اون سازمان که داره دیتا رو نگهداری میکنه داره اولیش که Maintenance یا  نگهداری اون دیتابیس است میخواست ۴۰ ترابایت بک آپ بگیره حالا میره 5 ترابایت بک آپ می گیره ۳۵ ترابایتش رو برده رو آرشیو و چون اون دیگه تغییر پذیر نیست یه بار بک آپ میگیره میذاره کنار دیگه خیالش راحته درسته صاحب ۴۰ ترابایت دیتا است ولی نگهداری ۵ ترابایت رو داره انجام میده این یه امکان خیلی خوبیه که خوب میدونم که فراگستر مشتری زیادی داره که تو این اسکیل هستند و خوبه که این کار را انجام بدن اگر تا الان به فکر نبودند و موضوع بعدی اینکه وقتی شما دیتا رو روی سرورهای دیگه میبرید واقعا یه اتفاقی افتاده انگار دیتا توزیع شده ما غیر از اینکه Data centralization یا متمرکز میگیم Decentralize یا نا متمرکز یا Distributed یا توزیع شده اتفاقا اینجا همون نقطه توزیع شده اش است چون حتی یک table داره دیتاش روی سرورهای مختلف توزیع میشه و یه جوری از امکان پارلم ما داریم اینجا استفاده میکنیم که بخواد به صورت همزمان سرورها به ما پاسخگو باشند

– آقای دکتر خیلی تشکر میکنم از  اطلاعاتی که تا این لحظه در اختیار ما قرار دادید

چگونه صحت عملیات بکاپ را بررسی کنیم؟

(از زمان 24:40 تا 27:57)

– آقای دکتر من تقریبا تمام سوالاتم را در حوزه اخذ بک آپ پرسیدم از شما حالا یک دغدغه دیگری وجود داره در زمینه ی زمانی که از این backup ها میخواهیم استفاده بکنیم در واقع Restore میخواد اینها بشه دو تا من سوال برام مطرح هستش یکی از کجا در واقع مطمئن بشیم یا چجوری میتونیم مطمئن بشیم در خصوص صحت این بک آپ ها این یه بخش دیگه الان در واقع خیلی میشنویم توی در واقع دنیای نرم افزار امروز علی الخصوص در واقع کشور در خصوص این تهدیداتی که تو حوزه داده ها مطرح هستش یهو در واقع داده ها مثلا فرض بفرمایید رنسام گرفته میشه باج گیر میاد باج گیری میکنه و این دیتاها از دست میره یا اینکه حالا مباحث بعدی به وجود میاد یا اینکه در واقع توسط منابع انسانی داده ها خوب مدیریت نمیشه عمدا و سهوا یا سهوا از دست میره میتونم خواهش کنم روی این دو بعد هم در واقع از اطلاعات شما استفاده بکنم عرض کردم یکی در خصوص نحوه صحه سنجی در واقع استفاده از این بک آپ ها و اینکه چه policy های در واقع میتونیم بچینیم که این داده ها درست در واقع نگهداری بشه برای روز مبادا

+ چند تا بعد داره این یکی این که بک آپی که داریم از طریق نرم افزار Sql server میگیریم یا اصن بک آپی که ماکروسافت برامون مهیا کرده که از سیستم بگیریم قطعا باگی ندارد ولی خوب ممکنه ما اون بکاپی که میگیریم روی یه استوریج قرار بدیم مسئله دار باشه و ما خیالمون راحته که بک آپ داره گرفته میشه و به وقتش میشه ازش استفاده کرد البته من دیدم در مواردی که واقعا دیسک مشکل داره یه جورایی خود ابزار هم متوجه شده و اون پایان فرایند بکاپ یه اروری بهش داده انگار هر وقت داشته بک آپ میگرفته یه فیدبکی داره از اون ابزار میگیره به غیر از اون ما زمانی که داریم بکاپ میگیریم یه تیک وریفای وجود داره تو این فرایند که بعد از اینکه بکاپ گرفته شده یه بار انگار به شکل اینترنالی میاد Sql server مون رو Restore میکنه وقتی که Restore کرد همه چیز گفت اوکیه اون موقع به ما میگه که بکاپ سالم گرفته میتونیم اطمینان بکنیم این یه مرحله ولی بخاطر اینکه مطمئن تر باز کار بکنیم با اطمینان خاطر بگیم بکاپ به درد ما میخوره هر چند وقت یکبار بک آپ رو یکبار Restore کنیم یه فضایی آماده کنیم که بتونیم بک آپ رو Restore کنیم انگار که اون لحظه ای که اتفاقی نباید بیفته پیش خودمون اون فرایندرو شبیه سازی کردیم ببینیم ری استور میشه یا نه خوب قطعا بعد از این دیگه ما خیالمون راحته که اگر اتفاقی افتاد یا اصن اتفاقی هم نیوفتاد ما نیاز داریم دیتابیس رو توی محیط دیگری کنیم میدونیم که این اتفاق میوفتد

چگونه امنیت نسخه‌های بکاپ را حفظ کنیم؟

(از زمان 27:57 تا 32:02)

+ اما نکته خیلی مهمی که فرمودین بله خیلی اتفاق افتاده برای خیلی از سازمان ها که دیتاشون رمز شده رنسام گرفته رنسام هم به شکلی هست که میاد دیتارو رمز میکنه میگرده رو دیسک ما روی نتورک ما میگرده و بک آپ رو پیدا میکنه اون رو هم رمز میکنه شما نگاه میکنی چی داری؟ هیچی به غیر از اینکه یه پولی باید به حساب اون باجگیر بریزی که بتونی دیتا رو برگردونی

– این وسط در واقع HA هم خیلی نمیتونه اثرگذار باشه چون اون رو هم رمز میکنه

+ خوب این تجربه رو میشه گفت که خیلی ها دارند خیلی سازمان های بزرگی این اتفاق براشون افتاده چی کار باید بکنیم؟ اول اینکه این صحبت هایی که ما میکنیم قطعا هیچ وقت امنیت صد درصدی نیست من یاد اون مقاله میفتم که Sage گفت اگر امنیت صددرصد میخوای سیمچین رو گرفت سیم رو قطع کرد به هر حال شما وقتی که تو این دنیای مجازی قرار میگیری هیچ چیز صد درصدی نیست فقط سعی میکنیم مکانیزم امنیت را تا جایی که شده افزایش بدیم که خدایی نکرده این اتفاق نیفته خوب یه راهش اینه که ما بک آپ رو روی تیپ نگهداری کنیم چون این نوع ویروس‌ها یا حالا این نوع باج افزارها که میان معمولا Disc base دارن عمل میکنن و وقتی شما بک آپ را روی یک تیپ قرار میدی به نوعی انگار دیگه جدا کردی از این فرایندی که میاد سرویس sql server رو stop میکنه دیتا رمز میکنه میگرده تو نتورک بک آپ رو رمز میکنه شما وقتی روی تیپ داری خیالتون راحته برای اون روزی که انشالله برای سازمانی اتفاق نیفتد ولی اگر این اتفاق افتاد بشه از اونجا دیتا را برداشت و Restore کرد حالا اگر برای سازمان هزینه تیپ بالاست یا به هر حال نیروی متخصصش نداره  یا به هر شکلی میشه گفت که اون زیر ساخت این کارو را نداره به نظرم بد نیست که توی فاصله زمانی کوتاه بیاید بک آپ رو روی یه در واقع storage های پرتابلی کپی کنه و اونرو قطع کنه اصلا از شبکه توی فضای دیگه نگهداری کنه مثل اینکه من یه هارد اکسترنال دارم میزنم بک آپ رو توش نگهداری میکنم و اون رو جدا میکنم

– آقای دکتر ولی من بمب زمانی شنیدم میدونم که بعضی از باج گیر ها میاد مثلا ممکنه دو هفته بعد

+ دقیقا میخواستم همینو عرض کنم خدمت شما متاسفانه اینم تضمین صد درصدی نیست چون بعضی وقتا این ویروس ها میچسبن به این فایل ها و شما فکر میکنید همه چیز اوکیه رمز نشده اون  رو میبرین روی یه تیپی یا یه storage اکسترنالی نگهداری میکنی و موقع Restoreکردن می بینید که آلوده شده قطعا دیگه اگر شما دیتای آلوده را بردارید و اون ویروس پیشرفته رو بگیری خیلی موضوع سخت میشه حالا به هر حال شما میتونید از قبل نسخه های مختلفی از آن تهیه کنید و در storage های مختلف قرار بدهید ولی به هر حال عرض کردم صد در صد نیست منتها من تا به حال ندیدم تا این لحظه کسی این کارو کرده باشه و کماکان دچار مشکل شده باشه  همه اونهایی که رنسام گرفتن که سازمان های خیلی بزرگی هم بودند همین قواعد ساده را رعایت نکردند یعنی روی تیپ نداشتند روی یک در واقع هارد اکسترنالی هم کپی نکرده بودند

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

+ خواهش میکنم

پیش بینی و محاسبه رشد اطلاعات به چه صورت است؟

(از زمان  32:02 تا 39:23)

– آقای دکتر یک سوالی در واقع تو خیلی از پروژه ها از من یا ازدوستان در واقع سوال میکنن و میپرسند که من حالا به شوخی خیلی از وقت ها میگم هنوز به اون درجه از اجتهاد نرسیدم که بخوام پاسخ بدم و پیش بینی بکنم مبحث در واقع رشد اطلاعات هستش که سوال میکنن که آقا شما که مثلا فرض بفرمایید که نمونه های حالا خیلی هم در واقع نمونه مشابه ما مثلا به نظرتون ما چه چون همه چی به پول ختم میشه و من درک میکنم در واقع قراره که یک بودجه در واقع مصرف بشه بابت در واقع تهیه یک سری زیر ساخت سخت افزاری، نرم افزاری میخوان بدونن چه عددی هستش سوال میشه که آقا در واقع حجم رشد این اطلاعات به چه ترتیبی هستش؟ ما مثلا شش ماه بعد یک سال بعد دو سال بعد چقدر خواهیم داشتش و عرض کردم من واقعا نمیتونم این رو دقیق بگم به اون درجه از اجتهاد نرسیدم ولی معمولا دو تا مسئله را که به عنوان پاسخ مطرح میکنم که میخوام  در واقع در این خصوص از تجربه شما استفاده بکنم یکی در واقع اینکه یک فکته که ما در ابتدای پروژه معمولا در واقع حداقل من ناتوانم در خصوص اینکه بتونم پیش بینی بکنم یک سازمان دو سال بعد چه حجمی از دیتاهای grow up به چه ترتیبی خواهد بودش چرا؟ چراش هم الان عرض می کنم ولی میتونم در واقع حضور شما که بگم که اگر شما بیاید به قول معروف نمونه سازمان های مشابه را اگر از من بخواهم بپرسم حتی اگر در ذهن نداشته باشم میتونم سوال بکنم بیام و بگم. در زمینه رشد و اینکه پیش بینی رشد من در واقع عرضم به حضور شما که چیزی که در واقع تو ذهنم هستش اینه که سوالی نیستش که در ابتدا بشه پاسخش را داد ولی میشه در واقع در یک دونه برهه زمانی شبیه سازی کرد ضرب کردش در اون زمان و بگیم که دو سال بعد به کجا میرسیم من یادمه تو چند تا از پروژه های بزرگ رفتار کاربر با سامانه تاثیر گذار میتونه باشه حتی عرض اول بنده هم در واقع این یه نقیضی هست براش یعنی کاملا یک چیزی است که باید مرور زمان ما را به آن برسونه به عنوان مثال در یک پروژه‌ای بودش که اصن قرار نبودش رفتار سازمانی در واقع رفتار کاربر بدین ترتیب باشه که مثلا یک حجم عظیمی از دیتا مثلا فرض بفرمایید که نامه هایی از این دست که مثلا فلان طور باشه با فلان شرایط در سامانه به گردش دربیاد و خوب سامانه به اجرا درآمد دیدن که جواب داره میده و در واقع سازمان هی بار بیشتری عه جواب میده پس اینم بیاریم پس اینم بیاریم پس اینم بیاریم اینها آیتم هایی است که در همان ابتدای پروژه چون وجود تخمین اثرگذار هستش ما چطور میتونیم که در واقع یک تخمینی از میزان رشد اطلاعاتمون داشته باشیم که به واقعیت نزدیک باشد

+ اگر واقعا نشه پیش بینی کرد عملکرد سیستمو خوب واقعا نمیتونیم به عدد درستی برسیم اما اگر روال سامانه همینی هست که داره اجرا میشه همین تعداد کاربر همین تعداد لاگی که داره تولید میشه خب یه ساده ترین راهش اینه که من نگاه میکنم بانکم بر فرض الان ۱۰۰ گیگه فردا نگاه میکنم 102 گیگیه پس فردا 104 گیگیه میگم خیلی خوب روزی دو گیگ داره اضافه میشه این یه مدل خیلی ساده است که با اون this pc اون مای کامپیوترمون نگاه کردن به دیسک میتونیم تخمین بزنیم خیلی ساده  بغیر از این خوب ما یه سری اسکریپت داریم که میتونیم حجم دیتا فایلو حالا تا بایتشو جزئیاتش ببینیم و اون هم میتونیم تو یک فاصله زمانی منظمی باز بگذاریم فاصله زمانی منظم

– نمونه گیری کنیم

+ بله روزانه بگذاریم حتی در یک جایی نگهداری کنیم بگذاریم یک ماه، هر روز اونرو ثبت کنیم ببینیم در واقع نمودار رشد دیتارو ببینیم پس میتونیم همونو تخمین بزنیم بگیم شش ماه بعد یک سال بعد یا دو سال بعد دیتا به کجا میرسد از اون بیشتر بخواهیم وقت بگذاریم به هر حال میتونیم جداولمونو، فیلدامونو به ازای هر رکورد چقدر بایت داره فضا اشغال میکنه حالا چه تعداد داره insert انجام میشه ضرب کنیم جمع کنیم تا به اون حجم مورد نظر برسیم ولی درسته اون محاسباتی داره و میشه گفت خیلی دقیقه ولی به نظر من گزینه اول و دوم بله واقعی تره تهش هر اتفاقی داره میفته عددی که داره به ما اونجا نشون میده و ما میتونیم رشد دیتارو ببینیم.

– منم موافقم با این گزینه دوم.

+ معمولا خیلی از سازمان ها یکی TPS یکی رشد دیتا یه چیزی که میخواهند حالا رشد دیتا منطقیه میگه من میخوام پیش بینی کنم بهش storage تخصیص بدم دیگه شیش ماه بعد ببینم من فضا دارم خوب خوبه اینکه این حساسیت دارند ولی هم من هم شما میدونیم سازمان های خیلی بزرگ یه دفعه به میگن ما فضا برای سه هفته دیگه بیشتر نداریم از اون طرف خیلی تاکید دارند که پیش بینی کنند دو سال آیندشون رو از اون طرف دو ماه بعد که فضا کم میارن خودشون سوپرایز میشن یا خیلی وقت ها تی پی اسی میخوان ok من میگم پنجاه هزار تا چیکار میخوای بکنی آیا واقعا میدونی اون عددی که من بدم چه منابعی بهش تخصیص بدی همچین فرمولی داری در صورتی که خوب میتونه منابع اگر بخواهید چه سروری بخواد تهیه کنه میتونه از شرکت بپرسه شرکت هم با توجه به این تعداد زیاد مشتری تو ابعاد مختلف داره میتونه در واقع بهترین solution رو بهش ارائه بده ولی بله همین که خدمتتون عرض کردم اینجوری ما میتونیم رشد دیتارو محاسبه کنیم

– پس اگر من جمع بندی بکنم نظر شما این است که در واقع در قاچ های زمانی مختلف نمونه برداری کنیم به عنوان معیار قرار بدیم ولی اگر خیلی اصرار در واقع بر این باشه که حتما در ابتدای قاچ اول ما بتونیم پیش بینی بکنیم در واقع اون جداول اصلی و  طول رکوردها رو ضرب بکنیم به رفتار سازمانی یعنی اون متغیر این سمت میشه خوب جداول و طول رکوردهایی که ذخیره میشه ولی چه تعداد نامه چه تعداد فایل چه تعداد سند چه تعداد داکیومنت بارگذاری میشه چه تعداد در واقع گردش اطلاعات. اون اطلاعات را از سازمان بگیرید و اون ضربه ساده را انجام بدید اگر بخواهید در ابتدا بدونید.

+ چون خیلی از دیتابیس شما ممکنه هزار تا تیبل داشته باشد ولی واقعا دیتاهای تغییرپذیر دیتایی که حجم زیاد دارند اگر بخواهیم بشماریم شاید به ۱۰ تا دونه نرسه

– دو تا جدول

+ بله ما همون ده تا جدول و حساب کتابش را انجام بدهیم به رکورداش چه تعداد رکورد داره insert میشه بایتی هر رکوردمون در واقع چند بایته میتونیم باز با یه تخمین خوبی برسیم

– بله دقیقا

شرح وظایف روزانه یک DBA (مدیر پایگاه داده) در سازمان برای تهیه بکاپ چیست؟

(از زمان 39:23 تا 46:46)

– خیلی از DBA های سازمان ها دیگه الان دیگه منظور از سازمان ها، سازمان های بهره برداری از رفقای ما هستند و در واقع دوست شدیم با همدیگر و در واقع تو پروژه ها با همدیگر کار میکنیم و جلو میریم سازمان های بزرگ متوسط اسکیل های مختلف در واقع کار میکنند من برای در واقع عرضم به حضور شما سازمان های جدید و اون در واقع مجموعه که میخواهند به فراگستر join شوند و با ما کار بکنند این سوال در واقع اون دسته از دوستان هستش شما به عنوان یک متخصص و expert تو این حوزه میتونم خواهش بکنم فهرستی از فعالیت هایی که یک DBA باید در واقع داشته باشه روی همچین سیستم هایی که سیستم های اثربخش و مهمی هستند داده های سازمان توش هستش در واقع دارن کار میکنن چه کارهایی من به عنوان یک DBA در واقع ابتدا و انتهای روزم به چه ترتیبی هستش

+ بله ببینید ما یه سری Job های روزانه حالا یا شاید بشه گفت هفتگی بهتره یا حالا بهتره بگم باید داشته باشیم سیستم اولیش که در موردش مفصل صحبت کردیم بک آپ ما باید روزانه یا حتی بهتر دقیقه‌ای بک آپ بگیریم و این باید چک بشه حالا یا DBA صحت بک آپ رو چک میکنه یا اینکه یه سیستم های مانیتورینگ دارند راه اندازی میکنن که اگر بکاپ گرفته نشه هشدار بده به هر حال یه سیستم Alert راه اندازی میشه که بتونه خبر بده که بک آپ گرفته شده یا نه

–  چه سیستم هایی میتونم اسم از شما بگیرم 

+ بله مثلا اومدن Redgate راه اندازی کردند یا آمدن IDERA راه اندازی کردن این ها ابزارهای مانیتورینگ است که سیستم Alert هم داره و میتونه اگر بک آپ گرفته نشد هشدار بده حالا به هر شکلی پنلی راه انداختن که اس ام اس میده یا ایمیل میزنه که به هر حال خبر میده به DBA که به فکر باشه چون خصوصا transactional-backup نگرفتن علاوه بر اینکه به هر حال پشتیبان تو داری از دست میدی یه هشدار دیگر است که لاگت ممکنه اونقدر رشد کنه که اگه دو سه روز سیستم سر بزنی قبل از اون سیستم شما از کار بیفته خوب از بک آپ که بگذریم در موردش هم مفصل صحبت کردیم البته اینها را معمولا سازمان ها میدونن ولی ما هم به عنوان فراگستر میایم این Job های ضروری رو که الان خدمت شما عرض کنم برای مشتری راه اندازی میکنیم ولی خوب اینجاست که دیگه مشتری از اینجا به بعدشو باید مواظب باشه چک بکنه که این Job ها به طور منظم اجرا بشه اگه بخوام نام ببرم حالا خیلی هم اولویت بندی نکنیم همین جوری بگم که یکیش Rebuild و Reorganize ایندکسه که بخاطر اینکه Fragmentation رو  کاهش بدیم یا حالا تهش بگیم که بخاطر اینکه Performance بهتری داشته باشیم اینجا خوبه که به صورت روزانه حالا بگیم شبانه اجرا بشه و اون DBA  اونی که مانیتوری داره روی دیتابیس چک بکنه اینو و مطمئن بشه که این داره به درستی کار میکنه به غیر از اون بحث Update statistics هست به روز رسانی آمار هست خوب این هم خیلی تاثیر دارد ما سازمان خیلی بزرگی داشتیم که DBAهای خوبی هم تو اون سازمان مشغول بودند Update state را به صورت کامل انجام نمیدادند یعنی حالا یا بهتره بگم به جای اینکه full اسکن انجام بدن بر اساس درصدی از دیتا آمارشون به روز می کردند و سیستم دچار مشکل شده بود وقتی ما رفتیم مانیتور کردیم Query که باید زیر یک ثانیه انجام میشد نزدیک به مثلا ۴۰،۵۰ ثانیه طول میکشید و با یه آپدیت کردن اون state این مشکل حل شد و به هر حال اون سازمان هم پذیرفت که اون object های خاص را به صورت full در واقع آمارش رو به روز رسانی کند پس تا اینجا بگم بک آپ هست Rebuild و Reorganize ایندکس هست و بروز رسانی آمار یا Update statistics هست و یه Job دیگه هم خیلی مهمه اونم integrity check است یعنی اینکه اون دیتا پیج هایی که دیتا داخلشون قرار گرفتند ما خیالمون راحت باشه  سالم است کی ناسالمه؟ ممکنه نوسان برق رخ بده ممکنه ضربه ای بخوره به اونها یا ممکنه ویروس یا هر عامل دیگری باعث میشه بلاک هایی از اون دیسک آسیب ببینند و این خیلی خطرناکه خطرناکیش هم بخاطر اینه که همون لحظه خودش را نشون نمیده رفته توی یه نقطه ای از دیتا قرار گرفته که ممکنه تا یه هفته دیگه یا حتی یک ماه دیگه هم کسی به اون قسمت بلاک سر نزنه وقتی ما داریم بک آپ میگیریم از دیتابیس اون خرابی هم همراه بک آپ است وقتی سیستم میره سراغ بلاک خراب یه رفتار بدی از خودش نشان میدهد یعنی من توی سازمانی دیدم که مثلا اپلیکیشن همینجور متوقف مانده یه ارور های انگار ناشناخته ای پشت صحنه رخ داده وقتی رفتیم دیتابیس را چک کردیم دیدیم بله بلاک خراب داشته خب بلاک خراب رو چه جوری دیتاش رو بازیابی کنیم؟ میریم سراغ بکاپ قبلی. بکاپ قبلی رو برمیگردونیم  میبینیم تو اون هم بلاک خراب داریم میریم قبل تر تا جایی که میریم میبینم چند ماه پیش این اتفاق افتاده و ما دیگه بک آپ خیلی قدیمی رو نداریم که .خوب اگر نگیم هر روز خوبه هفته ای یک بار integrity check انجام بشه که اگر به بلاک خراب رسیدیم بتونیم با اون بک آپ سالمی که قبلش گرفته شده اون بلاک یا بلاک های خرابو بازیابی کنیم در غیر این صورت دیتای اون بلاک ما از دست دادیم دادیم و یه نکته مهم دیگه ای که خیلی سازمان ها رعایت نمیکنند وقتی یه HA Always on راه اندازی میشه معمولا همه job هاداره رو پرایمری انجام میشه چون نودهای دیگه حالت Read only دارن ولی integrity check باید روی همه نودها انجام بشه چون پشت صحنه سخت افزارهای متفاوتی دارند و بلاک های متفاوتی دارند توصیه شده integrity check علاوه بر پرایمری انجام میشه بر روی secondary یا secondary ها هم انجام میشه پس بخوام جمع بندی کنم بک آپ، بازسازی شاخص ها به روز رسانی آمار و integrity check یا صحت سنجی صفحات داده اگر درست گفته باشم این job ها باید به صورت روزانه حالا یا بعضیش به صورت هفتگی باید چک بشه

– بله بسیار عالی

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

(از زمان  46:46 تا 53:50)

– آقای دکتر سوال آخرم اگر بخواهم از شما بپرسم در واقع یاد یه خاطره ای افتادم در واقع سوالم این هستش که فرض کنیم DR در واقع اون disaster اتفاق افتاده و ما می خواهیم که دنبال DR ایم میخواهیم که در واقع ریکاوری بشیم یه در واقع فیلمی من چند وقت پیش دیدم که میگفت خلبان بمرده یعنی دیگه خلبان مرد  اتفاق بده در واقع اتفاق افتادش و حالا میخوایم چه کنیم من یاد یه خاطره افتادم این رو خواستم عرض بکنم تو یکی ازخودروسازها اومدن و گفتن که آقا میخواید بیاید و در واقع این شبیه سازی این در واقع رخدادها را ببینید گفتیم آره که من دیدم که اینها آمدند و توی تایمی حالا از خارج از زمان کاری هم بود با لگد میزدند و سرورهارو مینداختند و کابل هارو میکشیدند و کاملا به روش حمله کردند و زیرساخترو  به هم زدند حالا از این تایم شروع کردند و کورنومترو زدند که این قضایا برگرده و همون دوستان ما هم حتی میگفتند که ما اجازه نداریم که محل سکونتمون رو بیش از یک ربع از محل در واقع حالا اون مکان در واقع اون کارخانه در واقع دور ببریم و اینقدر حساب شده هستش در واقع disastریکاوری که حتی فاصله مهمونی رفتن چک میکردند یا خانه را اجازه نمیدادند بیش از فاصله یک ربع فاصله بگیریم حالا به قول معروف این اتفاق بده افتاده بنا به هر دلیلی اقداماتی که در واقع یک سازمان مجهول باید انجام بده که بتونه به اون نقطه ی در واقع stable برسه از منظر شما چی هستش؟

+ ببینید ما وقتی داریم تو حوزه‌ی بانک اطلاعاتی و sql server در موردش صحبت میکنیم خوب وقتی کارمون رسید به disast ریکاوری یعنی اینکه منهدم شد سرورمون به نوعی ما باید بریم بک اپ رو بگیریم Restore کنیم و اتفاقا تو بحث RTO میگن از زمانی که بک آپو Restore میکنیم RTO نیستا از زمانی که سیستم منهدم شد یعنی اینکه اگر قراره ما DBI رو بریخونه سراغش دسترسی ریموت نداره پاشه بیاد اینجا تا بعد بک آپو بتونه کپی کنه حالا از یه فضایی به فضای دیگه و بعد Restore کنه تایمش تایمیه که سیستم Down آست دیگه  در واقع پس  ما چاره‌ای نداریم جز اینکه وایسیم صبر کنیم تا اون بک آپ Restore بشه متاسفانه خیلی وقت ها دیدیم طرف بک آپ هم نداره یا تو اون فرایندی که سیستم منهدم شده بک آپ هم منهدم شده این چون خیلی بدیهی بود من نگفتم ولی بد نیست بهش اشاره کنیم ما بک آپ رو نباید رو همون سرور نگهداری کنیم چون ممکنه ااون سرور کلا دیسکش بسوزه خب دیتا سوخته بک آپ هم سوخته قطها بک آپ باید در فضای خارج از نودها یا  نود فعالمون باشه که اگر اتفاقی براش بیفته ما بکاپ سالم را داشته باشیم

– با شبیه سازی موافق هستید با همون نمونه که من مثال زدم؟

+ والا من دلم نمیاد با هزینه های امروزی لگد تو هارد و سرورو اینا..

لگد به هارد نزدیم ولی یه مرتبه بیایم شبیه سازی بکنیم بگیم که فرض کنید این اتفاق افتاده اصلا تخمینی از زمان داشته باشیم ببینیم این کار 10 ساعت طول میکشه به اون نقطه مطلوب ۱۲ ساعت طول میکشه یک روز طول میکشه اینها در واقع اعداد با مدیران صحبت میکنند به قول معروف

+ ببینید اگر مهمه این موضوع که حتی میخواهید شبیه سازی بشه پس قطعا اون سازمان باید HA اندازی کنه و نه دو نود، حداقل سه نود داشته باشد یک نود نقش HA داشته باشد و تو همون data center  باشد

چرا HA? من منظورم همون بک آپ افلاین بودا بگیم که در واقع فرص کنید disaster اتفاق افتاده که اتفاق نیفتاده بخوایم در واقع از مسیر بک آپ برگردیم به مکانی که بوده این زمان را در واقع یک مرتبه مانور انجام بدیم

+ حالا من اجازه بدین اینو خدمت شما عرض کنم چون اینم در واقع  بحث DR است ما صرفا نمیگیم  Always on برای HA  یه هدفش HA است شما توی data center یه سرور یک داری یه سرور دو هم داری سرور بنا به هر دلیلی Down شد سرور دو جاش جایگزین میشه پس شما HA  رو داری  یا اصن هم Down نشه شما میخواهید ویندوزش رو ارتقا بدی شما میخوای یک patch نصب کنی این خیلی طبیعیه برای دوستان زیر ساخت یا اینکه میخواهید sql server ارتقا بدهید خوب نیاز به یه ریست داره ریست یعنی قطعی یعنی down time  از اون طرف سازمان ها معمولا این کار را انجام میدن و برای سازمان هایی که براشون مهمه میتونن برن توی فضای خارج از اون data center یه نود دیگه هم بیارن جز این شبکه کلاستر قرار بدهند اون نود نقش  DR را داشته باشد حالا اگر اون دیتا سنتر شما هر بلایی سرش آوردی آتیشش هم زدی به شرطی که network این وسط قطع نباشه network با client ها خوب شما میتونی بری یا حتی اون نود DR رو اتوماتیک fail over  رو روش فعال کنید یا حتی اگر دیتاشرو  سینک نکردی به صورت a sink به صورت آسنکترون نگهداری کردی میتونی بری اون نود DR رو force fail over بزنی همه این فرایند چند ثانیه است پس وقتی با راه اندازی Always on شما تو بحث DR هم تو چند ثانیه  میتونی دیتاتو برگردونی پس دیگه توجیه نداره به اون سازمان که بگی بک آپ رو برگردونه بیاد Restore کنه ما همه این بکاپ  Restore  راه ننداختن HA رو برای سازمانی گفتیم که اونقدر براش این RTO اهمیت نداشته خوب پس اون دیگه هیچ وقت نمیاد فاز تست این کارم  انجام بده ولی به هر حال اگر بخواهیم اینو تست بکنیم ما یه تایم Restore   داریم که یه بار میتونه سازمان انجام بده

– یه تایم انتقال داده رو هم را من دوس دارم بهش اضافه بکنم چون دیدم که اینها چند ساعت یا چند روز بابت انتقال و کپی کردنش طول بکشه

+ حالا  شما میخوای یه دیتابیس یا یه فایل چند ترابایتی کپی کنی باید صبر کنی   حالا  تو چه بستری با چه سرعتی داره این انتقال داده میشه خوب اون خیلی زمان بره پس برای سازمانی که اینها براش مهم باشه و اگه داریم حرف چند ترابایت برای سازمان میگیم به نظرم سازمانی که چند ترابایت دیتا داره دیگه باید HA و DR را راه اندازی کند نمیتونیم بگیم اون سازمان خیلی RPO و RTO براش مهم نیست درسته که شاید تایم ریکاوری خیلی مهم نباشه ولی وقتی داریم بحث چند ترابایت میگیم ممکنه یکی دو روز سیستم قطع باشد آیا این هم قابل تحمله؟ اگر قابل تحمله OK نره به سمت HR

– قابل تحمل نیست

+  بله قطعا نیست

– آقای دکتر میتونم از شما یه قول بگیریم یه جلسه ای رو در خصوص HA صحبت بکنیم حالا به قول معروف با اون رویکردی که سازمان ها اگر بخواهند به اینسمت بروند مسیر به چه ترتیبی است و چه کارهایی باید انجام بشه

+ بله حتما

– آقای دکتر خیلی تشکر میکنم خیلی اطلاعات خوبی دادین خیلی اثر بخش و به قول معروف جرقه هایی تو ذهن من زدش تشکر میکنم ازتون امیدوارم که در واقع مفید فایده برای تمام عزیزان بیننده هم باشد خیلی تشکر میکنم خداحافظی میکنم آقای دکتر تشکر میکنم سلامت

+ قربان شما سلامت باشید