در این روش تمام فایل ها و فولدر های انتخابی 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 استفاده کنید .

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