لودر سایت
مشاوره راه کارهای ذخیره سازی

استراتژی Backup 

در این روش تمام فایل ها و فولدر های انتخابی Backupگیری می شوند و archive attribute آنها پاک می شود.

Normal Backups(یا Backup ساده) از archive attribute برای تصمیم گیری در مورد اینکه چه فایل ها و فولدرهایی Backupگیری شوند استفاده نمی کند،تمام آیتم های انتخابی Backup گرفته می شوند و archive attribute آنها پاک می شود . هر استراتژی Backup گیری با این روش شروع می شود زیرا ما باید در ابتدا تمام فایل ها را داشته باشیم.

اگر چه Normal backup به خاطر تولید Backupکامل از تمام داده ها ، کارامدترین نوع Backupگیری به حساب می آید، اما بیشترین فضا و زمان را در بین انواع دیگر Backupمصرف می کند. فراموش نکنید که نرمال Backup صفت بایگانی(A) کلیه فایلها را پاک می کند .

انتخاب فایل هایی که archive attribute آنها ست شده است و archive attribute پاک می شود. اگر شما incremental backup (یا Backup افزایشی) را یک روز بعد از Backup نرمال بگیرید،فقط فایلهایی که طی روز قبل تغییر داده شده یا جدید ساخته شده اند شامل Backup گیری افزایشی می شوند.مشابه همین اگر شما incremental backup را یک روز بعد از یک incremental backup دیگر بگیرید ، job شما فقط شامل فایلهای که در طول روز تغییر داده شده یا جدید ساخته شده اند می شود.
Incremental backup سریع ترین و کم حجم ترین نوع Backupگیری می باشد ، اگر چه این نوع ،بهره وری کمی در restore کردن دارد زیرا شما باید اول Backup نرمال را restore کنید و بعد Backup افزایشی را restoreکنید (به ترتیب ساخته شدن )

فایل هایی که archive attribute آنها ست شده است انتخاب می شوند . archive attribue پاک نمی شود .differential backup (یاBackup تفاضلی) از صفت تغییر استفاده می کند و فقط فایلهایی را شامل می شود که از آخرین Backup نرمال یا Incremental ساخته شده یا تغییر داده شده اند. differential backup صفت تغییر را پاک نمی کند .بنابریاین اگر شما ۲ روز پشت سر هم Backup تفاضلی بگیرید ، Backup دوم شامل تمام فایل هایی که در Backup اول differential گرفته شده است می شود بعلاوه ی هر فایلی که جدید تغییر داده شده یا ساخته شده است در روز دوم .

نتیجه این می شود که differential backup در مقایسه با incremental backup به فضا و زمان بیشتر نیاز دارد ، اما به نسبت نرمال بک آپ، خیلی کوچک تر است.

Differential backup به مقدار قابل توجهی از incremental backup در هنگام restore کارامد تر است.اگر چه برای restoreکردن کامل سیستم ، ما باید اول نرمال Backup و بعد آخرین Backup differential را برگردانیم.

اگر Recovery Model پایگاه داده‌های شما در حالت Full یا Bulk-Logged قرار داشته باشد بنابراین شما میتوانید از Transaction Log های خود نیز Backup بگیرید. اگر شما در ساختار خود Transaction Log Backup را دیده باشید و به همراه آن Full Backup نیز داشته باشید قادر خواهید بود چیزی شبیه به Restore Point ویندوز را برای SQL سرور ایجاد کنید بدین معنا که اگر شخصی بصورت تصادفی کلیه اطلاعات موجود در Database های شما را حذف کند، شما میتوانید با استفاده از اینBackup ها اطلاعات را بحالت عملیاتی قبل از حذف اطلاعات بازیابی کنید. نکته منفی که در خصوص Log Backup ها وجود دارد این است که اگر Recovery Model شما به حالت Bulk-Logged قرار گرفته باشد شما برای بازیابی مجبور هستید کل Transaction Log های موجود را بازیابی کنیدLog Backup ها در واقع همان Transaction Log Backup ها هم هستند، این نوع Backup به شما اجازه میدهد که بتوانید از بخش فعال Transaction Log ها Backup بگیرید. در اینصورت زمانیکه شما از اطلاعات خود یک Full یا Differential Backup می گیرید، Transaction Log Backup تمامی اطلاعاتی که بعد از گرفتن این Backup ها ایجاد شده اند را نیز Backup میگیرد. زمانیکه دستور گرفتن Transaction Log Backup صادر شد فضایی که توسط Transaction Log ها اشغال شده بود آزاد و میتوان از آن برای سایر فرآیندهای سیستم استفاده کرد اما اگر شما Transaction Log Backup نگیرید حجم این Log ها همینطور اضافه خواهد شد و رشد خواهد کرد.

از این نوع روش Backup گیری بعنوان Database Mirroring نیز یاد میشود، در این روش همانطور که از نامش پیداست بمعنی بکاپ‌گیری آینه‌ای است، بدین صورت که از این نوع روش Backup گیری بیشتر برای بالابردن دسترسی‌پذیری یا Availability  پایگاه‌های داده استفاده می‌شود، شما در این روش نیازمند حداقل دو سرور مجزا هستید که بتوانند Database های خود را با همدیگر Synchronize کنند. روش Backup گیری Mirroring بر اساس هر Database انجام میشود و در اصطلاح فنی به آن Per Database Basis گفته میشود ، توجه کنید که این روش صرفا با Full Recovery Model کار میکند. در این روش Backup گیری، بعد از راه‌اندازی سرویس اگر هر اطلاعاتی در Database ها ثبت شود بلافاصله با Database دیگر که بر روی سرور دیگری قرار دارد Replicate  و یکپارچه‌سازی می‌شود.

تمام فایل ها و فولدرهای انتخابی Backup گیری می شوند .کپی Backup از archive attribue هیچ استفاده ای نمی کند ؛ یعنی نه تغییر میدهد نه فایل ها را براساس آن انتخاب می کند .Copy backup برای Backup گیری زمان بندی شده (scheduled backups) مورد استفاده قرار گرفته نمی شود . این نوع Backup گیری برای انتقال داده بین سیستم ها یا ساختن یک بایگانی copy شده از تمام داده ها بسیار مفید می باشد .

تمام فایل ها و فولدرهایی که در طول روز تغییر کرده اند براساس تاریخ تغییر فایل Backup گرفته می شوند.همچنین از archive attribue هیچ استفاده ای نمی شود .اگر شما می خواهید از تمام فایل ها و فولدرهایی که در طول روز تغییر کرده اند Backup بگیرید بدون تأثیر در schedule بک آپ گیری خود، از Daily Backup استفاده کنید .

در این روش امکان ادغام و ایجاد راهکارهای بک آپ گیری بر اساس موارد فوق وجود خواهد داشت.

چرا پشتیبان گیری و ذخیره سازی اطلاعات

امروزه اطلاعات و دیتای هر سازمان (شامل آرشیو اسناد اداری، اطلاعات شرکت و پروژه ها ،دیتای مربوط به نرم افزار های مالی و … ) از پر اهمیت ترین بخش ها می باشد. از این رو روش های حفاظت از اطلاعات بـه طور قابل توجهی تغییرکرده اند، و پشتیبان گیری از این اطلاعات پر ارزش از مهمترین فرایند های یک سازمان می باشد.

ذخیره سازی اطلاعات

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

از انواع تجهیزات ذخیره سازی اطلاعات میتوان به  DAS / SAN / NAS اشاره کرد. که هر کدام با توجه به نیازهای سازمان ها و شرکت های بزرگ و کوچک مورد استفاده قرار خواهد گرفت

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

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

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

  •  آیا نسخه پشتیبان از اطلاعات در جای مناسبی ذخیره می شوند؟
  •  از چه اطلاعاتی باید پشتیبان گیری شود؟
  •  آیا backup های ما در زمان نیاز به کار ما می آیند؟
  •  چگونه backup بگیریم؟
  •  چه زمان هایی پشتیبان گیری انجام دهیم؟
  •  و …

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

تیم متخصصین حامین فناوران نوین جهت استقرار دو شاخص مهم و اساسی  به موجوب استقرار و انتخاب تجهیزات ذخیر سازی اقدامات بایسته و ارائه راهکارها را خواهند داشت.

 

تعریفی بر شاخص RTO :

مدت زمان تحمل یک سازمان در صورت بروز خرابی و اشکال تا سرویس دهی مجدد را RTO  (recovery time objective )  می نامند .هر سازمان ملزم به تعین بازه زمانی طولانی ترین و کوتاهترین زمان تحمل سازمان در وقفه می باشد. . معیار و ملاک هر مجموعه برای تعین این پارامتر خسارت ریالی ، بار سیاسی و . . . خواهد بود .

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

بعد از تعریف آستانه تحمل  زمانی سازمان در بروز وقفه (RPO) متخصصین مرکز داده می بایست بر این پایه تجهیزاتی را انتخاب نمایند که با توجه به معیار های فرآیند نسخه دوم اطلاعات و آرشیو که در ابتدای این نوشتار ذکر شده ، پاسخگوی مدت زمان تعریف شده جهت وقفه در سیستم باشند .

 همخوانی تجهیزات انتخابی با RTO  بسیار مهم می باشد . در برخی از مجموعه ها Overdesign  شده و در برخی دیگر تجهیزات بسیار ناکارآمد تر از RTO  تعین شده می باشد .

تعریفی بر شاخص RPO :

میزان آستانه تحمل یک سازمان در از دست رفتن اطلاعات  را RPO   می نامیم . بعنوان مثال اگر آخرین نسخه Backup  تعین شده مربوط به ۴ بامداد بوده و سیستم در ساعت ۸ بامداد دچار وقفه گردد مجموعه بین ساعت ۴ تا ۸ بامداد هیچ Backup تهیه نکرده و ۴ ساعت از داده ها را از دست خواهد داد  .

نکته کلید مطلب آنجاست که هر مجموعه می بایست بر اساس زمان RTO  خود تجهیزاتی را انتخاب نمایند که در بازه زمانی تعین شده توانایی بازیابی و بازخوانی اطلاعات را داشته باشد .

ارتقا RPO و RTO بستگی به افزایش بودجه سازمانها در تأمین هزینه‌های تکنولوژی های Storage , Storage Networking و processes و Networking و پیاده‌سازی آن‌ها دارد. همچنین فاصله فیزیکی بین دیتا سنتر های شما و اینکه Application ها چقدر تحمل network latency را دارند تأثیر در اینکه شما چقدر می‌توانید به Zero RPO برسید دارد.

مجموع دو فاکتور RPO به علاوه RTO تعیین کننده میزان تحمل ریسک در یک مجموعه می‌باشد.
(RPO+RTO = Acceptable Business Risk)
error: دوست گرامی لطفا در باز انتشار محتوای سایت ذکر نام منبع را لحاظ فرمائید !!!!!