پشتیبان گیری SQL Server Differential

همانطور که می دانید Differential به معنای تفاضل می باشد. در این روش فقط از تغییراتی که در Database های شما بعد از آخرین Full Backup صورت گرفته شده، Backup گرفته می شود. طبیعی است که اگر از Database های شما تاکنون Backup گرفته نشده باشد در اولین باری که بصورت Differential بکاپ بگیرید تمامی اطلاعات Database ها Backup گرفته می شوند. در فایل های ویندوز یک بیت به نام Archive Bit وجود دارد که تغییر کردن یک فایل را به شما نشان می دهد ، همین مفهوم در SQL Server به عنوان Extent شناخته می شود ، یک extent شامل هشت قسمت (Page)، 8 کیلوبایتی می شود که مجموعه 64 کیلوبایت داده را تشکیل می دهد.

هر بار که اطلاعاتی در SQL سرور وارد می شود و یا تغییری انجام می شود یک Flag ایجاد می شود (در واقع یکی از خانه های DCM Page روشن می شود) که به SQL سرور می گوید یک Differential Backup ایجاد شده است و باید اطلاعات موجود در extent ها در آن موجود باشد، زمانی که شما یک Full Backup می گیرید این Flag ها خاموش می شوند(تمام خانه های DCM Page صفر می شوند).

گرفتن چندین بکاپ از SQL سرور به صورت Differential

پس همانطور که عنوان هم کردیم اگر شما یک 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 را دارید.

استفاده از مدل ریکاوری Full یا Bulk-Logged در دیتابیس

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

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

BACKUP DATABASE BOM

TO DISK=’E: \Databases\BOM_dif.bak’ WITH Differential

تذکر : در حقیقت DCM Page یکی از Page های سیستمی ما بوده که وقتی ما از دیتابیس خود فول بک آپ می گیرم ، تمام فلگ های DCM Page صفر می شوند. هر بار که شما تغییری در دیتابیس خود ایجاد می کنید در حقیقت فلگ مربوط به Extent آن در DCM Page یک می شود و اسکیوال سرور هر بار که می خواهد Differential Backup بگیرید از این فلگ هایی که یک شده اند می فهمد که کدام Extent ها تغییر یافته اند و از آنها بک آپ می گیرد.

SQL Server Log Backup

اگر Recovery Model پایگاه داده های شما در حالت Full یا Bulk-Logged قرار داشته باشد بنابراین شما می توانید از Transaction Log های خود نیز Backup بگیرید.

اگر شما در ساختار خود Transaction Log Backup را دیده باشید و به همراه آن Full Backup نیز داشته باشید قادر خواهید بود چیزی شبیه به Restore Point ویندوز را برای SQL سرور ایجاد کنید بدین معنا که اگر شخصی بصورت تصادفی کلیه اطلاعات موجود در Database های شما را حذف کند ، شما می توانید با استفاده از این Backup ها اطلاعات را به حالت عملیاتی قبل از حذف اطلاعات بازیابی کنید.

نکته منفی در خصوص SQL Server Log 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 Log Backup

هدف اصلی از گرفتن این نوع بک آپ انتقال اطلاعات از فایل لاگ به فایل بک آپ و خالی شدن VLF های فایل لاگ و آماده شدن برای استفاده مجدد می باشد و این که لاگ فایل ما دائم رشد نکند.

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

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

BACKUP LOG BOM

TO DISK=’E: \Databases\BOM_Log.bak’

تذکر : لازمه گرفتن Log Backup ، این است که Recovery Model ما حتما Full باشد . به شکل زیر توجه فرمایید. همچنین به این موضوع دقت کنید که Recovery Model نحوه رفتار Log File را تعیین می کند . یعنی اینکه تعیین می کند که در Log File اطلاعات چگونه ذخیره شود .

به طور مثال اگر Recovery Model را بر روی Bulk Logged تنظیم نماییم یعنی اینکه ، آقای SQL Server اگر Bulk Operationای به ازاء بانک اطلاعاتی من ایجاد شد ، در این صورت حداقل Log را برای من ثبت کن و صرفا آدرس Extentهایی که تغییر یافته اند را ثبت کن ولی جزئیات را ثبت نکن .