چگونگی فرآیند Backup (قسمت آخر)

Transaction Log Backup

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

Partial Backup

بکاپ‌گیری جزئی روش دیگری از Backup است که از نسخه SQL Server 2005 معرفی شده است. این بکاپ به شما این امکان را می‌دهد تا از Primary FileGroupها، تمامی FileGroup های (Read-Write) و تمامی File های تعریف شده به صورت اختیاری بکاپ تهیه کنید. این نوع بکاپ‌گیری یک مزیت به شمار می‌رود، در صورتی که شما FileGroup های (Read-Only) در دیتابیس داشته باشید و نخواهید همواره از تمامی دیتابیس های خود بکاپ تهیه کنید.

File Group Backup

شما می‌توانید برای فایلهای موجود در Database خود File group تهیه کرده و از این File group ها نیز Backup بگیرید. بصورت پیش فرض در یک Database یک عدد File group اصلی (PRIMARY file group) وجود دارد که به فایل Data ای که ایجاد شده است گره می‌خورد. بزرگترین مزیتی که File Group Backup ها نسبت بهFile Group ها دارند این است که شما می‌توانید از File Group های خود بصورت فقط خواندنی (Read Only) بکاپ بگیرید. این بدین معناست که با ایجاد این نوع بکاپ نمی‌توان اطلاعات را دستکاری کرد و صرفا می‌توان آنها را خواند.

Copy-Only Backup

زمانیکه از روش Copy Only Backup برای Backup گیری از Database ها استفاده می‌کنید، تقریبا Backup مشابه Full Backup گرفته‌اید که در آن تمامی اطلاعات موجود در Database ها و Log ها و سایر موارد مرتبط وجود دارند، اما تفاوت در این است که در صورتیکه شما از Database های خود FullBackup بگیرید، Plan بکاپ‌گیری Differential و تغییراتی که در Database ها انجام شده است تغییر می‌کند، اما در حالت Copy Only هیچ گونه تغییری در Backup Plan شما پیش نمی‌آید و تنها یک کپی با تمام مشخصات از اطلاعات موجود برداشته می‌شوند. معمولا اینگونه backup ها بصورت دستی و برای بررسی و تحلیل استفاده می‌شوند. تمام فایل ها و فولدرهای انتخابی بک آپ گیری می شود. کپی بک آپ از archive attribute هیچ استفاده ای نمی کند، یعنی نه تغییر میدهد نه فایل ها را براساس آن انتخاب می کند .Copy backup برای بک آپ گیری زمان بندی شده (scheduled backups) مورد استفاده قرار گرفته نمی شود. این نوع بک آپ گیری برای انتقال داده بین سیستم ها یا ساختن یک بایگانی copy شده از تمام داده ها بسیار مفید می باشند .

Mirror backup

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

Mirror backup، فرآیند ایجاد کپی مستقیمی از فایل ها و فولدرهای انتخاب شده، در زمانی معین است. از آنجایی که فایل ها و فولدرها بدون هیچ گونه فشرده سازی در مقصد کپی می شوند، سریع ترین روشِ بکاپ گیریست. با وجود سرعت افزایش یافته در آن، نقاط ضعفی را نیز به همراه دارد: به فضای ذخیره سازی وسیعتری نیاز دارد و نمی تواند از طریق پسورد محافظت شود.

در این نوع از بکاپ گیری، هنگامی که فایل های بی کاربرد حذف می شوند، از روی بکاپ mirror نیز حذف می شوند. بسیاری از خدمات بکاپ، بکاپmirror را با حداقل 30 روز فرصت برای حذف پیشنهاد می کنند. این امر به این معناست که به هنگام حذف یک فایل از منبع، آن فایل حداقل 30 روز بر روی storage server نگهداری می شود.