ُهمراهان گرامی سلام ، حالتون خوبه ؟ امیدوارم که شاد باشید. هر مدل ریکاوری اجازه بکاپ گرفتن از کل یا جزیی از دیتابیس SQL Server یا فایل های مستقل یا گروهی از فایل های دیتابیس را می دهد. ولی بکاپ های در سطح جدول (Table-level backups) را نمی توان ایجاد کرد.
نکته: backup و restore در SQL Server، در همه سیستم عامل های ساپورت شده، چه سیستم های ۶۴ بیت، چه ۳۲ بیت، کار می کنند.
بکاپ های داده ها (data backup)
اسکوپ بکاپ داده ها می تواند کل یک دیتابیس یا گروهی از filegroupها یا فایل ها باشد. برای هر یک از اینها، SQL Server، بکاپ های کامل و دیفرانسیلی را ساپورت می کند:
بکاپ کامل
بکاپ کامل حاوی همه داده ها در دیتابیسی معین یا گروهی از filegroupها یا فایل ها، و همچنین log کافی برای ریکاور کردن آن داده ها است.
بکاپ دیفرانسیلی
بکاپ دیفرانسیلی بر پایه آخرین بکاپ کامل داده ها است. این موضوع، اساس دیفرانسیل شناخته می شود. پایه دیفرانسیلی، بکاپ کاملی از خواندن/نوشتن دادها است. بکاپ دیفرانسیلی فقط شامل داده هایی است که از پایه دیفرانسیلی تغییر کرده اند. معمولاً، ایجاد کردن بکاپ های دیفرانسیلی که بعد از بکاپ پایه گرفته می شوند، سریعتر و کوچکتر از پایه بکاپ کامل است. بنابراین، استفاده از بکاپ های دیفرانسیلی می تواند سرعت فرآیند درست کردن بکاپ های دوره ای را، بمنظور کاهش خطر از دست دادن داده ها، افزایش دهد. معمولاً، پایه دیفرانسیلی توسط چندین بکاپ دیفرانسیلی متوالی مورد استفاده قرارمی گیرد. هنگام restore کردن، ابتدا بکاپ کامل restore می شود، و سپس آخرین بکاپ دیفرانسیلی.
در طول زمان، همین طور که دیتا بیس آپدیت می شود، مقدار داده موجود در بکاپ های دیفرانسیلی افزایش می یابد. این کار، ایجاد و restore کردن بکاپ را کندتر می کند. نهایتاً، باید بکاپ کامل دیگری ایجاد کرد تا بتوان پایه دیفرانسیلی جدیدی برای سری دیگری از بکاپ های دیفرانسیلی مهیا کرد.
نکته: معمولاً، بکاپ دیفرانسیلی همان فایل داده هایی را پوشش می دهد که در پایه دیفرانسیلی واحد پوشش داده می شوند. در مدل ریکاوری ساده، بکاپ دیفرانسیلی می تواند فقط یک پایه دیفرانسیلی داشته باشد. تلاش برای استفاده از چندین پایه باعث error می شود و عملیات بکاپ گیری fail می شود. در مدل ریکاوری کامل، پک آپ هاب فایل دیفرانسیلی می توانند از چندین پایه استفاده کنند، اما مدیریتش مشکل می شود.
هر بکاپ داده ای شامل قسمتی از transaction log است بطوریکه بکاپ را می توان به انتهای آن بکاپ ریکاور کرد.
در مدل ریکاوری کامل یا مدل ریکاوری bulk-logged، بعد از اولین بکاپ داده ها، بکاپ های منظم transaction log مورد نیاز هستند. هر log backup، بخشی از transaction log را تحت پوشش قرار می دهد که هنگام ایجاد بکاپ فعال بود، و log backup شامل همه رکوردهای log است که در log backup قبلی بکاپ نشدند.
بکاپ های دیتا بیس (database backup)
استفاده از بکاپ های دیتابیس آسان است و توصیه می شود هر وقت سایز دیتابیس اجازه می دهد، گرفته شوند. SQL Server، بکاپ های زیر را ساپورت می کند.
نوع بکاپ-شرح
بکاپ دیتابیس-بکاپ کاملی از کل دیتابیس. بکاپ های دیتابیس زمانی که بکاپ تمام می شود، کل دیتابیس را نمایش می دهند.
بکاپ های دیفرانسیلی دیتابیس-بکاپی از همه فایل های دیتابیس. این بکاپ فقط شامل data extendهایی است که از زمان آخرین بکاپ هر فایل دیتابیس دچار تغییر شده اند.
بکاپ های جزیی (partial backup)
بکاپ های جزیی و جزیی دیفرانسیلی در SQL Server معرفی شدند. این بکاپ ها جهت فراهم کردن انعطاف بیشتر برای گرفتن پشتیبان از دیتابیس هایی که شامل تعدادی فایل گروه های فقط خواندنی (read-only filegroups) در مدل ریکاوری ساده است، طراحی شده اند. اما، این بکاپ ها توسط مدل های ریکاوری ساپورت می شود.
SQL Server، بکاپ های زیر را ساپورت می کند.
SQL SERVER آموزش
نوع بکاپ-شرح
بکاپ دیتابیس-بکاپی از همه داده ها در filegroup, اولیه، هر filegroup خواندن/نوشتن، و هر فایل فقط خواندنی یا filegroupها.
بکاپ های دیفرانسیلی دیتابیس-بکاپی که فقط شامل data extendهایی است که از زمان آخرین بکاپ جزیی همام گروه filegroupها دچار تغییر شدند.
بکاپ های فایل (file backup)
فایل موجود در دیتابیس را می توان بطور جداگانه backup و restore کرد. استفاده از بکاپ های فایل می تواند سرعت ریکاوری را با restore کردن فایل های آسیب دیده و بدون restore کردن بقیه دیتابیس افزایش دهد. مثلاً اگر دیتابیسی از چندین فایل تشکیل شده است که روی دیسک های مختلف قرار دارند و یک دیسک fail شود، فقط باید فایلی را که روی آن دیسک بود restore کرد. اما، برنامه ریزی و restore کردن بکاپ های فایل می تواند پیچیده باشد؛ بنابراین، بکاپ های فایل فقط باید در جایی استفاده شوند که مقادیری را به برنامه restore شما اضافه می کنند.
SQL Server، بکاپ های زیر را ساپورت می کند.
بکاپ های Transaction Log
در مدل ریکاوری کامل یا مدل ریکاوری bulk-logged، بکاپ های منظم transaction log مورد نیاز هستند. هر log backup، بخشی از transaction log را تحت پوشش قرار می دهد که هنگام ایجاد بکاپ فعال بود، و log backup شامل همه رکوردهای log است که در log backup قبلی بکاپ نشدند. بکاپ های log قطع نشده شامل زنجیره log کاملی از دیتابیس است. در مدل ریکاوری کامل، و بعضی وقتها در مدل ریکاوری bulk-logged، زنجیره log آسیب ندیده به شما اجازه restore کردن دیتابیس تا هر مقطع زمانی را میدهد.
قبل ازاینکه اولین بکاپ log را ایجاد کنید، باید یک بکاپ کامل ایجاد کنید، مانند بکاپ دیتابیس. از آن به بعد، بکاپ گرفتن از transaction log منظم، لازم است؛ نه فقط برای کم کردن احتمال از دست دادن کارتان، بلکه برای کوتاه کردن transaction log.
مهم : برای محدود کردن تعداد بکاپ های log که باید restore شوند، بکاپ گرفتن از داده های تان بطور روتین واجب است. مثلاً می توانید یک بکاپ کامل از دیتابیس هفتگی یا بکاپ های دیفرانسلی روزانه برنامه ریزی کنید.
بکاپ های فقط کپی (copy-only backups)
بکاپ گرفتن از دیتابیس معمولاً آنرا و زمان restore شدن بکاپ ها را دچار تغییر می کند. اما، هرچند وقت یکبار، گرفتن بکاپی بمنظور خاصی، بدون اثر گذاشتن روی بکاپ کلی و فرایندهای restore، برای دیتابیس مفید است. بکاپ های فقط کپی در Server 2005 معرفی شدند. این بکاپ ها مستقل از بکاپ های منظم SQL Server هستند.
ابزارهای بکاپ (backup devices)
بکاپ های SQL Server روی ابزارهای بکاپ از قبیل فایل های دیسک یا tape media ایجاد می شوند. می توانید بکاپ های جدیدی به هر بکاپ موجود روی ابزار پیوست کنید، یا هر بکاپ موجود را overwrite کنید.
زمانبندی بکاپ ها
اجرای عملیات بکاپ گیری اثرات کمی روی transactionهایی دارد که در حال اجرا هستند؛ بنابراین، عملیات های بکاپ را می توان هنگام عملیات های منظم اجرا کرد. هنگام عملیات بکاپ گیری، SQL Server، داده ها را مستقیماً از فایل های دیتابیس به ابزارهای بکاپ کپی می کند. داده ها تغییر نمی کنند، و transactionهایی که هنگام بکاپ گیری در حال اجرا هستند، هرگز به تاخیر نمی افتند. بنابراین، می توانید بکاپ SQL Server را با کمترین تاثیر روی بارکاری production، اجرا کنید.
می توانید بکاپ ها را زمانبندی کنید تا بطور اتوماتیک نیز اجرا شوند.
فشرده سازی بکاپ
SQL Server 2008 Enterprise و نسخه های بعدی، فشرده سازی بکاپ ها را ساپورت می کند، و هر نسخه ای ازSQL Server 2008 و بعد می تواند بکاپ فشرده شده را restore کند.
محدودیت های عملیات های بکاپ گیری در SQL Server
در SQL Server 2005 و نسخه های بعدی، بکاپ می تواند هنگامی که دیتابیس آنلاین و در حال استفاده شدن است، انجام گیرد. اما، محدودیت های زیر وجود دارد.
از داده های آفلاین نمی توان بکاپ گرفت
هر عملیات بکاپ که بطور مستقیم یا غیرمستقیم داده های آفلاین را ریفرنس می کند، fail می شود. بعضی نمونه ها بشرح زیر هستند:
شما اقدام به گرفتن بکاپ کامل از دیتابیس می کنید، اما یکی از filegroupهای دیتابیس آفلاین است. از آنجاییکه همه filegroupها بطور مستقیم یا غیرمستقیم در بکاپ کامل دیتابیس درگیر هستند، این عملیات fail می شود.
برای بکاپ گیری از این دیتابیس، می توانید از بکاپ فایل استفاده کنید و فقط filegoupهای آنلاین را تعیین کنید.
شما اقدام به گرفتن بکاپ جزیی می کنید، اما filegroup خواندن/نوشتن آفلاین است. از آنجاییکه همه filegroupهای خواندن/نوشتن برای بکاپ جزیی لازم هستند، این عملیات fail می شود.
شما اقدام به بکاپ فایل از فایل های معینی می کنید، اما یکی از این فایل ها آفلاین است. عملیات fail می شود. برای بکاپ گرفتن از فایل های آنلاین، می توانید فایل آفلاین را از لیست فایل ها حذف کنید و عملیات را تکرار کنید.
معمولاً، log backup، حتی اگر یک یا چند فایل آفلاین باشند نیز با موفقیت انجام می شود. اما اگر فایلی حاوی تغییراتی باشد که در مدل ریکاوری bulk-logged ایجاد شده است، همه فایل ها باید آنلاین باشند تا بکاپ گیری با موفقیت انجام شود.
محدودیت های همزمان هنگام بکاپ
SQL Server از یک فرآیند بکاپ گیری آنلاین استفاده می کند تا اجازه بکاپ گیری را، هنگامی که دیتابیس در حال استفاده شدن است، بدهد. هنگام بکاپ گیری، اکثر عملیات ها قابل انجام هستند؛ مثلاً عبارت های INSERT، UPDATE، یا DELETE هنگام عملیات بکاپ گیری مجاز هستند. اما اگر سعی کنید هنگامی که فایل دیتابیس در حال ایجاد شدن یا حذف شدن است، عملیات بکاپ گیری را شروع کنید، عملیات تا وقتی که فرآیند ایجاد یا حذف فایل تمام شود، به تاخیر می افتد.
عملیات هایی که هنگام بکاپ دیتابیس یا log backup اجرا نمی شوند:
عملیات های مدیریت فایل از قبیل عبارت ALTER DATABASE با آپشن های ADD FILE یا REMOVE FILE.
عملیات های Shrink database یا shrink file، که شامل عملیاتهای auto-shrink نیز می شود.
اگر سعی کنید هنگامی که عملیات بکاپ گیری در حال اجرا است فایل دیتابیسی را ایجاد یا حذف کنید، عملیات ایجاد یا حذف فایل fail می شود.
اگر عملیات بکاپ گیری با عملیات مدیریت فایل یا عملیات shrink تداخل پیدا کند، یک تعارض (conflict) روی می دهد. بدون توجه به اینکه کدام عملیات اول شده است، عملیات دوم منتظرlock set می ماند تا time out شود. اگر قفل هنگام time out باز شود، عملیات دوم ادامه پیدا می کند. اگر قفل time out شود، عملیات دوم fail می شود.
