آموزش Backup در SQL Server
یکی از مهم ترین اقدامات هر ادمین دیتابیسی ایجاد مکانیزم بکاپ گیری و Restoring می باشد ، بکاپ فایل دیتابیس ها مانند خود دیتابیس از اهمیت بالایی برخوردار بوده و می بایست توجه زیادی به آن داشت ، در این پست قصد داریم صفر تا صد بکاپ گیری و انواع بکاپ های موجود در دیتابیس SQL Server را بررسی کنیم ، با ما همراه باشید .
بعد از استارت پروژه و ایجاد دیتابیس اولین اقدامی که باید صورت پذیرد ایجاد پلن بکاپ می باشد ، تعیین بهترین پلن نیز بستگی به بیزینس کاری آن دیتابیس دارد ، بعضی از دیتابیس ها تراکنشی بوده و حجم داده های زیادی به آن وارد می شود ، خب قطعا برای این دیتابیس باید انواع پلن های بکاپ گیری را ایجاد کرد تا در هنگام بوجود آمدن شرایط خاص کمترین ایجاد اختلال در سرویس دهی سامانه ایجاد شود . پس حتما برای این کار می بایست ریکاوری مدل این دیتابیس را به حالت Full تغییر دهید . قبل از شروع صحبت در مورد بکاپ گیری ها بهتر است انواع ریکاوری مدل های دیتابیس را بررسی کنیم .
- Full
- Simple
- Bulk Logged
سه نوع ریکاوری مدل دیتابیس داریم . بسته به شرایط کاری دیتابیس می توان تنها یک مورد از این سه مورد را انتخاب کرد ، در بالا مثالی در این زمینه زدیم ، تنها دیتابیسی که از این قائده مستثنی می شود دیتابیس TempDB می باشد که همیشه باید در حال Simple باشد . برای تغییر ریکاوری مدل دیتابیس می توان از منوی Properties دیتابیس در تب General گزینه Recovery Model را تغییر دهید و یا از اسکریپت زیر استفاده کنید .
ALTER DATABASE MYDB SET RECOVERY FULL
FULL Recovery Model
این مدل ریکاوری کامل ترین مدل بوده و در زمان لازم در صورتی که دیتابیس ما با مشکل مواجه شده باشد می توان به تاریخ و ساعت مورد نظر خود رسیده و بازگردانی کنیم ، قابلیت Point in time recovery این امکان را بما می دهد تا به نقطه مذکور برسیم ، تا زمانی که بکاپ Transaction Log ها گرفته نشود SQL اقدام به حذف لاگ ها نمی کند و برای حذف لاگ ها حتما باید یک بکاپ DIFF یا FULL و یا بکاپ Transactional LOG گرفته شود . برای اطمینان خاطر از حفظ تمامی اطلاعات شما در صورت بروز مشکل می توانید همیشه نوع مدل بازیابی دیتابیس خود را به این حالت تغییر دهید .
Bulk-Logged Recovery Model
این مدل ریکاوری بسیار شبیه به ریکاوری مدل فول می باشد با این تفاوت که این روش در هنگام ثبت اطلاعات از قابلیتی به نام Minimal logging استفاده کرده که به نسبت ریکاوری مدل فول سرعت بالاتری دارد ولی باز به نسبت فول Transaction Log ها از حجم کمتری برخوردار بوده و زمان پردازش اطلاعات نیز کمتر می شود ، مشکل این روش نداشتن امکان Point in time recovery بودهو حتما می بایست از پلن بکاپ گیری منظم و زمانبندی شده استفاده کرد تا کمترین میزان از دست رفتن اطلاعات پیش بیاید ، مجموعا از این مدل بهتر است استفاده نشده و یا به صورت موقت استفادهشود زیرا برای دیتابیس های تراکنشی در زمان Disaster میزان لاگ بازگشتی به صورت مقطعی می باشد.
Simple Recovery Model
این روش ریکاوری مدل SQL حداقل اندازه اطلاعات را در Transaction Log خود نگهداری می کند و در زمان مشخصی (Transaction Checkpoint) اقدام به Truncate کردن لاگ ها می کند ، مشخص است که در این روش قابلیت Point in time recovery وجود نداشته و تنها راه بازگشت اطلاعات در زمان Distaster استفاده از فول و یا لاگ بکاپ های اخذ شده می باشد ، قطعا در این مدل فضای نگهداری دیتابیس کمتر مورد استفاده قرار می گیرد و عملا لاگ چندانی ثبت نمی شود .
پیشنهاد ما و پیش فرض خود SQL سرور استفاده از ریکاوری مدل Full می باشد . برای تغییر ریکاوری مدل دیتابیس ها از اسکریپت بالا و یا مسیر Properties هر دیتابیس در تب Option می توانید اقدام کنید .
قطعا تمامی شرکت هایی که نرم افزار های خدماتی و یا هر نوع نرم افزار دیگری که حجم دیتای زیادی دارند مجاب به این هستند که از دیتای خود بکاپ گیری کرده و محافظت کنند ، برای صحت و سلامت سرویس دهی خدمات شما باید پلن های بکاپ گیری مختلفی بر اساس بیزینس برنامه ها پیاده سازی کرد ، با ما همراه باشید.
انواع روش های بکاپ گیری در SqlServer
Full Backup
ساده ترین روش بکاپ گیری با کاملترین دیتا و لاگ موجود در زمان زندگی عادی دیتابیس در این فایل قرار گرفته است و در زمان Disaster راحت ترین روش بازیابی اطلاعات را خواهید داشت زیرا تمامی Transaction Log های موجود در این فایل بکاپ موجود است ولی مشکلی زمانی خودش را نشان می دهد که حجم دیتابیس شما زیاد باشد مثلا 22 ترا بایت ، بکاپ گیری از این دیتابیس چقدر زمان می برد ؟ چند وقت یک بار می توان بکاپ فول از این دیتا بیس گرفت ؟ اگر آخرین فول بکاپ ما برای 1-2 ماه پیش باشد حجم Diff بکاپ ما چقدر می شود؟ و چقدر طول میکشد اخذ شود؟ در اینجور مواقع باید همیشه در کنار پلن فول بکاپ پلن های دیگر را نیز مد نظر داشت .
اگر ریکاوری مدل دیتابیس شما بر روی حالت Simple باشد، بعد اخذ فول بکاپ تا اخذ فول بکاپ دیگر سیستم شما تحت ریسک بالایی از بابت از دست رفتن اطلاعات داشته و فقط می توان به زمان بکاپ فول قبلی بازگشت .
بکاپ گیری فول از دیتابیس با ریکاوری مدل فول یا bulk-logged فقط بکاپ فول دیتابیس کافی نبوده و می بایست از دیتابیس بکاپ Transaction Logged نیز اخذ شود تا همانطور که گفته شد بتوان به زمان دلخواه بازگردانی کرد .
نمونه اسکریپت اخذ بکاپ و تغییر ریکاوری مدل به فول و گرفتن بکاپ لاگ
USE master;
ALTER DATABASE AdventureWorks2012 SET RECOVERY FULL;
GO
-- Back up the AdventureWorks2012 database to new media set (backup set 1).
--SQLDBA.IR
BACKUP DATABASE AdventureWorks2012
TO DISK = 'Z:\SQLServerBackups\AdventureWorks2012FullRM.bak'
WITH FORMAT;
GO
--Create a routine log backup (backup set 2).
--SQLDBA.IR
BACKUP LOG AdventureWorks2012 TO DISK = 'Z:\SQLServerBackups\AdventureWorks2012FullRM.bak';
GO
Differential Backup
این نوع بکاپ تفاوت دیتای حال حاضر با آخرین بکاپ اخذ شده می باشد ، اگر برای بار اول بکاپ Diff گرفته می شود SQL به صورت خودکار از تمامی اطلاعات دیتابیس یک بکاپ کامل گرفته و در بکاپ Diff بعدی تفاوت دیتای الان و اخرین بکاپ فول را بکاپ گیری می کند ، در هنگام بازیابی نیز آخرین Full backup موجود را ریستور کرده و آخرین Diff بکاپ را بر روی آن بازیابی می کنیم ، دقت کنید اخرین Diff بکاپ چرا که شامل دیتای تمامی Diff بکاپ های قبلی نیز می باشد . همانطور که در عکس زیر مشاهده می کنید 24 عدد extend داریم که دیتای 6 عدد از آنها نسبت به بکاپ فول ما تغییر کرده که این تعداد بکاپ Differential ما را تشکیل می دهد ، sql آدرس این مقادیر را در Differential bitmap page ها نوشته و در زمان ایجاد بکاپ Diff آنها را جمع آوری کرده و فلگ می زند .
برای اینکه سایز Diff بکاپ های شما بزرگ نشود و اخذ و بازگردانی این بکاپ ها سریع تر انجام شود بهتر است پلن هفتگی بکاپ فول و اخذ روزانه یا دو یا چند بار در هفته بکاپ Diff داشته باشید .
Transaction Log Backup
این مدل بکاپ تنها در صورتی قابل اخذ می باشد که Recovery model دیتابیس شما بر روی Full یا Bulk-Logged باشد . با در اختیار داشتن Transaction Log بکاپ ها می توانید از قابلیت Point in time recovery استفاده کرده و کمترین میزان از دست رفتن اطلاعات و صفر شدن DataLoss را داشته باشید ، بعد از اخذ فول بکاپ و یا Transactional backup کل فضای اشغال شده توسط این فایل ها آزاد شده و لاگ ها Truncate می شوند .
برای نگهداری مطمعن تر و بهتر از دیتای کسب و کار شما بهتر است به صورت مکرر بکاپ گیری کنید تا کمترین میزان ریسک را متحمل شوید . پیشنهاد مایکروسافت اخذ بکاپ لاگ در هر 15 الی 30 دقیقه می باشد و اگر کسب و کار شما حساس است می توانید فواصل را کمتر هم بکنید ولی از طرفی باید به میزان فضای ذخیره سازی فایل ها نیز توجه داشته باشید تا زنجیره بکاپ گیری قطع نشود .
File Backup
این روش بکاپ گیری مشابه روش Full می باشد با این تفاوت که این بار از دیتای موجود بکاپ گیری نمی کنید بلکه از فایل های مختلف دیتابیس بکاپ میگیرید ، در محیط های عملیاتی بزرگ با حجم دیتای بالا معمولا دیتابیس را بین فایل های مختلف تقسیم میکنند و با این روش می توانید از فایل خاصی بکاپ گیری کنید .
Copy Only backup
در صورتی که شما قصد داشته باشید فول بکاپی از دیتابیس بدون تغییر در زنجیره بکاپ های Diff ایجاد شود داشته باشید می توانید از این روش استفاده کنید . این بکاپ مشابه فول بکاپ بوده و تمامی دیتا و لاگ ها در آن موجود است . این بکاپ را می توان با نرم افزار های backup exec و مشابه آن و یا حتی به صورت دستی با اسکریپت تهیه کرد .
Partial Backup
این نوع بکاپ گیری مخصوص دیتابیس های با حجم بسیار بالا می باشد که دیتابیس در File Group های مختلف تقسیم شده است ، نحوه بکاپ گیری این تایپ نیز برای دیتابیس های با ریکاوری مدل ساده طراحی شده است . این نوع بکاپ گیری نیز مشابه با بکاپ گیری فول بوده با این تفاوت که می توانید تک تک فایل گروه ها و فایل گروه اصلی را بکاپ گیری کنید .
در SQL Server، فرآیند پشتیبانگیری (Backup) برای ایجاد نسخه پشتیبان از دیتابیس و فایل لاگ استفاده میشود. این فرآیند امکان بازیابی دادهها در صورت بروز مشکلات یا از دست رفتن اطلاعات را فراهم میکند. در ادامه، نحوه انجام فرآیند پشتیبانگیری در SQL Server را بررسی میکنیم:
1. پشتیبان گیری کامل (Full Backup):
– پشتیبانگیری کامل، شامل ایجاد یک نسخه کامل از تمام دادهها و ساختار دیتابیس است.
– برای انجام پشتیبان گیری کامل، میتوانید از دستور BACKUP DATABASE در SQL Server استفاده کنید.
– مثال:
BACKUP DATABASE نام_دیتابیس TO DISK = ‘مسیر_فایل_پشتیبان\نام_فایل_پشتیبان.bak’
2. پشتیبان گیری لاگ تراکنش (Transaction Log Backup):
– پشتیبانگیری لاگ تراکنش، شامل ایجاد نسخه از فایل لاگ برای بازیابی تراکنشهای بعدی است.
– برای انجام پشتیبان گیری لاگ تراکنش، میتوانید از دستور BACKUP LOG در SQL Server استفاده کنید.
– قبل از انجام پشتیبان گیری لاگ تراکنش، باید حالت دیتابیس را به حالت بازیابی تراکنشی (Full Recovery Mode) تنظیم کنید.
– مثال:
BACKUP LOG نام_دیتابیس TO DISK = ‘مسیر_فایل_پشتیبان\نام_فایل_پشتیبان.trn’
3. پشتیبان گیری با نام گذاری و استناد به تاریخ (Named and Dated Backups):
– برای مدیریت بهتر پشتیبانها، میتوانید از نامگذاری خاص و استناد به تاریخ استفاده کنید.
– با استفاده از نامگذاری و استناد به تاریخ
Certainly! Here are a few more tips and considerations for performing backups in SQL Server:
4. استفاده از برنامهریزی منظم برای پشتیبانگیری: تنظیم یک برنامهریزی منظم برای انجام پشتیبانگیری در SQL Server بسیار مهم است. برنامهریزی به صورت مکرر و منظم اجرای عملیات پشتیبانگیری را فراهم میکند و از اطلاعات با ارزش دیتابیس شما محافظت میکند. میتوانید از ابزارهای داخلی SQL Server مانند SQL Server Agent یا ابزارهای خارجی مانند نرمافزارهای مدیریت پشتیبانگیری استفاده کنید.
5. ذخیره پشتیبانها در مکانهای مختلف: برای اطمینان از حفاظت کامل از دادهها، پیشنهاد میشود پشتیبانها را در مکانهای مختلف ذخیره کنید. میتوانید از روشهای متفاوتی مانند درایوهای خارجی، سرویسهای ذخیرهسازی ابری (Cloud Storage) یا سرورهای پشتیبان اضافی استفاده کنید. این اقدام میتواند در صورتی که یک منبع پشتیبانی خراب شود، از از دست رفتن کامل دادهها جلوگیری کند.
6. بررسی و تست مداوم پشتیبانها: برای اطمینان از صحت و قابلیت بازیابی پشتیبانها، میتوانید به صورت مداوم آنها را بررسی و تست کنید. این شامل اجرای بازیابی آزمایشی (Test Restore) در محیطی مجزا از دیتابیس اصلی است. با انجام این تستها، میتوانید مطمئن شوید که پشتیبانها قابلیت بازیابی دارند و در صورت نیاز، میتوانید به سرعت دادههای خود را بازیابی کنید.
Certainly! Here are a few more tips and considerations for performing backups in SQL Server:
7. ثبت و نگهداری گزارشات پشتیبانگیری: هنگامی که پشتیبانگیری انجام میشود، مهم است گزارشات مربوط به آن ثبت و نگهداری شوند. این گزارشات شامل جزئیاتی مانند تاریخ و زمان پشتیبانگیری، نام فایل پشتیبان، نام دیتابیس و سایر اطلاعات مرتبط است. این اطلاعات میتوانند در صورت بروز مشکلات در بازیابی، ردیابی و تعیین دقیق مشکلات مفید باشند.
8. استفاده از پشتیبانی تراکنشی (Transaction Log Backups) برای حفظ نقطههای بازیابی: با استفاده از پشتیبانی تراکنشی، میتوانید نقاط بازیابی مختلف در زمانهای مختلف را داشته باشید. این به شما اجازه میدهد تا در صورت نیاز، دیتابیس را به یک نقطه قبلی در زمان بازیابی کنید و از دست رفتن تراکنشهای اخیر جلوگیری کنید.
9. استفاده از فشردهسازی برای کاهش حجم فایلهای پشتیبان: برای صرفهجویی در فضای ذخیرهسازی و کاهش زمان انتقال و بازیابی، میتوانید از فشردهسازی در فایلهای پشتیبان استفاده کنید. SQL Server قابلیت فشردهسازی دادههای پشتیبان را ارائه میدهد که میتواند حجم فایلهای پشتیبان را به طور قابل توجهی کاهش دهد.
10. پیادهسازی راهاندازی مکرر: برای اطمینان حاصل کردن از پشتیبانگیری صحیح و موثر، پیادهسازی راهاندازی مکرر را در نظر بگیرید. این بدان
معنی است که باید روند پشتیبانگیری را بررسی کنید، از صحت و قابلیت بازیابی پشتیبانها اطمینان حاصل کنید و در صورت نیاز تغییرات لازم را اعمال کنید.
11. آموزش و آشنایی با روشهای بازیابی: همانطور که پشتیبانگیری مهم است، همینطور آموزش و آشنایی با روشهای بازیابی نیز بسیار ضروری است. باید آموزش دیده و تمرین کافی برای بازیابی دادهها از پشتیبانها داشته باشید تا در صورت بروز مشکلات، بتوانید به سرعت و با دقت دادههای خود را بازیابی کنید.
12. تنظیمات حفاظت از دیتابیس: در SQL Server، میتوانید تنظیمات حفاظت از دیتابیس را تعیین کنید تا از دسترسی غیرمجاز به پشتیبانها جلوگیری کنید. از جمله این تنظیمات میتوان به رمزنگاری پشتیبانها، محدود کردن دسترسی به فایلهای پشتیبان، و استفاده از ابزارهای مدیریت دسترسی به پشتیبانها اشاره کرد.
13. آزمون بازیابی: برای اطمینان حاصل کردن از صحت و قابلیت بازیابی پشتیبانها، میتوانید آزمون بازیابی را انجام دهید. در این آزمون، فایل پشتیبان را بازیابی کرده و صحت دادهها را بررسی کنید. این آزمون میتواند به شما اطمینان دهد که در صورت بروز مشکلات، میتوانید به سرعت و با دقت دادههای خود را بازیابی کنید.
14. نگهداری پشتیبانها: باید استراتژی مناسبی برای نگهداری پشتیبانها در نظر بگیرید. این شامل مدت زمان نگهداری، ذخیرهسازی در مکانهای مناسب و استفاده از چرخههای نگهداری (retention cycles) است. باید تعیین کنید چقدر از پشتیبانها را نگهداری کنید و کدامها را حذف کنید تا فضای ذخیرهسازی بهینهتر شود.
15. مانیتورینگ و زمانبندی: برای اطمینان حاصل کردن از صحیح بودن فرآیند پشتیبانگیری، باید مانیتورینگ منظم و کنترل زمانبندی داشته باشید. باید مشخص کنید که آیا پشتیبانگیری به طور منظم ان
جام میشود و در صورت بروز مشکلات، به شما اطلاع داده میشود.
16. به روزرسانی استراتژی پشتیبانگیری: استراتژی پشتیبانگیری خود را به طور دورهای بررسی و به روزرسانی کنید. با توجه به تغییرات ساختار دیتابیس و نیازهای سازمان، ممکن است نیاز به تغییر در روشها و تنظیمات پشتیبانگیری داشته باشید.
در نهایت، مهمترین نکته این است که استراتژی پشتیبانگیری را براساس نیازهای سازمان خود شخصی سازی کنید و به روز نگهدارید تا از امنیت و قابلیت بازیابی دادههای خود اطمینان حاصل کنید.
همچنین، بهتر است با توجه به نیازهای خاص سازمان خود و محیط تولیدی خود، استراتژی پشتیبانگیری مناسبی را تعیین کنید و از دستورات و ابزارهای مناسب در SQL Server استفاده کنید. این به شما کمک خواهد کرد تا از امنیت و قابلیت بازیابی دادههای خود اطمینان حاصل کنید.
دیدگاه ها 2