انواع روش های Backup گیری از SQL Server

تصور کنید به عنوان یک DBA ( Database Administrator ) از Database های SQL Server های نرم افزار مالی ، نرم افزار اتوماسیون اداری ، نرم افزار نیروی انسانی ، نرم افزار شیرپوینت و مدیریت مستندات و … به درستی Backup نگرفته اید ، خدای ناکرده بر اثر یک تصادف اطلاعات موجود در این Database ها دچار اختلال می شود و شما مجبور می شوید اطلاعات را بازگردانی کنید ، اما متوجه می شوید که Backup ها به درستی گرفته نشده اند ، تست نشده اند و قابل بازگردانی نیستند و این یعنی شروع یک فاجعه بزرگ.

دقت کنید اگر بصورت منظم از دیتابیس های خود Backup میگیریید ولی هیچ plan ای برای بازگرداندن یا Restore دیتابیس ندارید کارشما کاملا بیهوده است.

انواع Backup در SQL Server

SQL Server Full Backup

معمولترین روش Backup گیری از SQL سرور روش Full یا Complete می باشد به این روش Database Backup هم گفته می شود. در این نوع Backup گیری از کلیه Database های موجود بر روی Instance شما به همراه همگی Transaction Log های موجود در آن Backup گرفته می شود و با این روش شما براحتی می توانید اطلاعات خود را Recover یا بازیابی کنید. این روش ساده ترین روش بازیابی اطلاعات می باشد زیرا تمامی اطلاعات به یکباره بازیابی می شوند.

 SQL Server Differential Backup

یکی دیگر از روش های معمول Backup گیری از SQL Server به روش Differential معروف است.اگر کمی با مفاهیم Backup در ویندوز آشنایی داشته باشید این نوع روش برای شما بسیار راحت می باشد ، در این روش فقط از تغییراتی که در Database های شما از آخرین Backup گرفته شده انجام شده است Backup گرفته می شود ، طبیعی است که اگر از Database های شما تاکنون Backup گرفته نشده باشد در اولین باری که بصورت Differential بکاپ بگیرید تمامی اطلاعات Database ها Backup گرفته می شوند. در فایل های ویندوز یک بیت به نام Archive Bit وجود دارد که تغییر کردن یک فایل را به شما نشان می دهد ، همین مفهوم در SQL Server به عنوان extent شناخته می شود ، یک extent شامل هشت قسمت ۸ کیلوبایتی می شود که مجموعه ۶۴ کیلوبایت داده را تشکیل می دهد.هر بار که اطلاعاتی در SQL سرور وارد می شود و یا تغییری انجام می شود یک Flag ایجاد می شود که به SQL سرور می گوید یک Differential Backup ایجاد شده است و باید اطلاعات موجود در extent ها در آن موجود باشد ، زمانیکه شما یک Full Backup می گیرید این Flag ها خاموش می شوند.

پس همانطور که عنوان هم کردیم اگر شما یک Full Backup بگیرید و سپس یک Differential Backup بگیرید محتویات موجود در Differential Backup شما فقط شامل اطلاعات تغییر کرده بعد از Full Backup می باشد که در واقع همان اطلاعات Extent ها هستند. توجه کنید که برخلاف ساختار Backup گیری ویندوز شما اگر چندین بار هم از اطلاعات موجود در SQL سرور بصورت Differential بکاپ بگیرید در نهایت همه تغییراتی که از ابتدای آخرین Full Backup بر روی Database انجام شده اند Backup گرفته خواهند شد.زمانیکه می خواهید Backup ای از SQL سرور خود را بازیابی کنید کافیست ضمن بازگردانی آخرین Full Backup فقط اطلاعات موجود در آخرین Differential Backup را نیز بازیابی کنید تا اطلاعات کامل بازیابی شود. در این حالت سایر Differential Backup های موجود نادیده گرفته می شوند. توجه کنید که اگر Database شما در مدل ریکاوری Simple یا Simple Recovery Model قرار دارد ، شما همچنان قابلیت استفاده از Full Backup و Differential Backup را دارید .

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

 SQL Server Log Backup

اگر 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 ها همینطور اضافه خواهد شد و رشد خواهد کرد.

SQL Server File Backup

یکی دیگر از گزینه هایی که برای Backup گیری از SQL سرور وجود دارد به File Backup معروف است. این روش به شما امکان این را می دهد که بتوانید به جای اینکه کل Database را Backup بگیرید هر فایل را بصورت مستقل Backup بگیرید. البته این روش زمانی صادق است که شما چندین فایل Data در Database خود ساخته باشید. یکی از دلایل مهم استفاده از این روش Backup گیری زمانی است که شما یک Database دارید که دارای چندین فایل با حجم های زیاد است و می خواهید هر کدام از این فایل ها را بصورت جداگانه و مستقل Backup بگیرید. توجه کنید که در بیشتر موارد شما فقط یک فایل در Database خود دارید و این روش معمولا به کار شما نمی آید ، اگر فرض کنید که ما در Database همین وب سایت سازمان دارای چندین فایل در هر Database بودیم و نیاز به Backup گیری از هر کدام بصورت مجزا را داشتیم از این روش استفاده می کردیم. این نوع Backup معمولا در محیط های Enterprise ای انجام می شود که واقعا حجم عظیمی از اطلاعات در آن وجود دارد.

 SQL Server Filegroup Backup

شما می توانید برای فایل های موجود در Database خود filegroup درست کنید ، علاوه بر اینکه شما می توانید با استفاده از روش قبلی که File Backup بود از فایل های مجزای موجود در Database خود Backup بگیرید می توانید از این filegroup ها که به تعریف فارسی گروه فایل ها می باشند نیز Backup بگیرید. بصورت پیشفرض در یک Database یک عدد filegroup اصلی یا PRIMARY filegroup وجود دارد که به فایل Data ای که ایجاد شده است گره می خورد.همانطور که اشاره کردیم شما می توانید برای خود filegroup های جدید ایجاد کنید و فایل های data ی خود را در این filegroup ها دسته بندی کنید.در بسیاری از موارد شما فقط همین PRIMARY filegroup را در ساختار خود دارید بنابراین همانند بحث filegroup قبلی این مورد نیز کاربرد چندانی در database های شما ندارد. تاکید کردیم که شما می توانید از هر filegroup ها بصورت جداگانه و مستقل Backup بگیرید ، بزرگترین مزیتی که filegroup Backup ها نسبت به file Backup ها دارند این است که شما می توانید filegroup های خود را بصورت فقط خواندنی یا Read Only بکاپ بگیرید این بدین معناست که نمی توان این اطلاعات را دستکاری کرد و صرفا می توان آن را خواند. شما می توانید به جای اینکه از همه Database های خود Backup بگیرید تنها در وهله های زمانی معین از نسخه های خواندنی و نوشتنی یا Read Write مربوط به filegroup ها Backup بگیرید.

 SQL Server Copy Only Backup

زمانیکه شما از روش Copy Only Backup برای Backup گیری Database ها استفاده می کنید تقریبا Backup ای شبیه به Full Backup گرفته اید که در آن تمامی اطلاعات موجود در Database ها و Log ها و سایر موارد مرتبط وجود دارد ، اما این سئوال پیش می آید که واقعا تفاوت Full و Copy در چه چیزی است ؟ تفاوت در این است که در صورتیکه شما از Database های خود Full Backup بگیرید Plan بکاپ گیری Differential و تغییراتی که در Database ها انجام شده است تغییر می کند اما در حالت Copy Only هیج تغییری در Backup Plan شما پیش نمی آید و صرفا یک کپی با تمام مشخصات از اطلاعات برداشت می شود ، در اصطلاح فنی Copy Only Backup ها Log Chain یا ذنجیره Log های شما را که برای برنامه ریزی Backup های دیگر استفاده می شود را تغییر نمی دهند. معمولا اینگونه backup ها بصورت دستی و برای موراد بررسی و تحلیلی استفاده می شود اما به هر حال بد نیست هر چند وقت یکبار بصورت دستی اینکار را انجام دهید. هرگاه از Copy Backup یاد کردید به فکر Snapshot های VMware بیوفتید که دقیقا چنین روش Backup گیری هستند.

SQL Server Mirror Backup

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

Print Friendly, PDF & Email
تعداد بازدید: 3,426