بررسی اجمالی روش های پشتیبان گیری در SQL SERVER
درس “Overview of Backups in SQL Server” به بررسی تخصصی و جامع اهمیت بکاپ‌گیری در مدیریت پایگاه داده می‌پردازد و هدف آن آموزش طراحی استراتژی مؤثر برای حفاظت از داده‌ها در برابر خرابی‌های سخت‌افزاری، خطاهای انسانی و حملات سایبری است. در این محتوا، انواع بکاپ‌ها شامل Full Backup، Differential Backup و Transaction Log Backup با کاربردها و مزایای خاص خود معرفی شده‌اند. همچنین، استراتژی‌های بکاپ‌گیری نظیر برنامه‌ریزی منظم، ترکیب این انواع و ذخیره‌سازی امن بکاپ‌ها مورد بحث قرار گرفته و ابزارهایی مانند SQL Server Management Studio (SSMS) و دستورات T-SQL برای اجرای بکاپ‌ها توضیح داده شده‌اند. این درس به شما مهارت لازم برای استفاده از این ابزارها و تدوین یک پلن بکاپ‌گیری حرفه‌ای را ارائه می‌دهد تا با تماشای ویدیو، بتوانید داده‌های خود را به‌طور کامل محافظت کنید.
اجازه بدین که در مورد برخی از option های مختلفbackup گیری در sql server 2016 صحبت کنیم. Sql server ، سه نوع مختلف از روش های backup گیری رو ساپورت و پشتیبانی میکنه. نام های این 3 روش یکی Full، روش دوم Differential، و آخرین یا سومین روش Log هستش. اجازه بدین که در مورد هر کدوم از این ها به صورت جداگانه صحبت کنیم.
یک Full Backup، همان طور که از نامش پیداست، از هر چیزی back up گیری میکنه. اون از همه داده ها، هر نوع فایل، هر نوع فایل گروه یا باصطلاح file group، هر جدول و کلا از هر چیزی که وجود داره،back up میگیره . در ابتدا قبل از اینکه backup گیری دیگه ای داشته باشیم یا اینطوری بگم قبل از اینکه بخایم از روش های دیگه ی موجود برای بک آپ گیری استفاده کنیم، اول از هر چیزی یک full back upباید انجام بدیم.
در یک پایگاه داده کوچیک ممکن هست که بسته به حساسیت کارتون همیشه نیاز باشه گاه به گاه یک back up full رو داشته باشیم.
خب در مورد روش دوم بک آپ گیری یاDifferential Backup ، اینو بگم که این روش یک بک اپ گیری از داده هایی هست که دقیقا بعد از زمانی که اخرین نسخه full backup رو گرفته ایم بوجود اومدن و یا اون سری از داده هایی که بعد از آخرین نسخه full backup تغییر کرده اند و آپدیت شدند. بنابراین اگه یک full backup در روز دوشنبه انجام داده باشم، پس روز سه شنبه من میتونیم differential back upرو انجام بدم و بدونید بک آپی که سه شنبه گرفته ام تنها از هر چیزی back up میگیره که فقط اون داده ها بین دوشنبه و سه شنبه تغییر کرده اند.
خب اینم بگم برای کار خیلی از افراد این نوع بک آپ گیری خیلی می تونه مفید باشه چون هر بار که یکسری اطلاعات کوچیک ولی در عین حال حساسشون تغییر میکنه، می تونن خیلی سریع فقط از همون داده های تغییر کرده، بک آپ بگیرن و اینطوری مجبور نمیشن از تمام اطلاعات و پایگاه داده شون بخاطر تغییر اون اطلاعات جزئی بخان مجدد یک full backup بگیرن. این نوع از بک آپ گیری یعنی differential back up معمولا یک back up گیری سریعتر رو منجر میشه و دلیلش هم این هست که چون داده و اطلاعات کمتری رو back up گیری میکنیم، این کارمون منجر به back up گیری سریعتر میشه، اما این میتونه روند کندتره بازگرداندن اطلاعات یا همون restore رو منجر بشه، چون در ابتدا ما بازگردانی اطلاعات رو با full backup داریم و بعد از اون باز گردانی با differential back up.
بنابراین در اینجا یک گام اضافی در restore اطلاعات با یک بک آپ از نوع differential back up رو داریم که ممکنه مدت زمان بیشتری طول بکشه و همچنین در هنگام بازیابی یا restoring نسخه full back up، ممکنه داده هایی که تغییر کرده اند، در هنگامی بازیابی بک آپ از نوع differential backup ویرایش و رونویسی بشن و نهایتا وقتی که ما یک بک آپ از نوع full back up و یک بک آپ از نوع differential backup داریم در هنگام بازیابی اطلاعات اول بک آپ از نوع full back up جایگزین میشه و نهایتا تغییراتی که از آخرین زمانی که ما بک آپ از نوع full back up رو گرفتیم توسط بک آپ های از نوع differential backup بازیابی میشن. بنابراین این روند بازیابی اطلاعات برای افرادی که پایگاه های داده بزرگ دارن ناکارامد هست. چون اونا اطلاعاتشون دقیقه ای تغییر میکنه و اگه بخان بیان و یک بک آپ از نوع full back up بگیرن و بعدش بقیه بک آپ هاشون رو از نوعdifferential backup تنظیم کنن اونوقت مجبورن روزانه حداقل یک بار بدلیل حساسیت اطلاعاتشون بک آپ از نوع differential backup رو بگیرن حالا اگر فرضا بعد از یک مدت یکماه یکدفعه بانک اطلاعاتیشون با مشکل برخورد کرد اونوقت یک بک آپ از نوع full back up دارن و حدود 30 تا بک آپ از نوع differential backup، و اونوقت بازیابی یا restore اطلاعات در یک همچین حجمی ممکنه یکمی گیج کننده هم باشه.
بک آپ گیری از نوع differential backup میتونه برای اون دسته از افرادی کارآمد باشه که سایز و اندازه پایگاه داده شون از medium یا یک سایز متوسط به سمت سایز های پایین تر و دیتابیس های کوچکتر هستش. یک راه حل مناسب برای این نوع از دیتابیس ها این هست که بک آپ از نوع backup full رو در اول هر هفته تهیه کنند ولی در طول هفته بیان و بک آپ های از نوع differential backup رو هر روز انجام بدن و هر هفته همین کار رو تا زمانی که یک دیتابیس سالم دارن رو انجام بدن و بک آپ های جدید رو هر هفته جایگزین بک آپ های قدیمی بکنن.
سومین گزینه و آخرین روش از بک آپ گیری نوع Log Backup هست که تنها بک اپ گیری بر اساس پردازش اطلاعات ورودی یا log هست یعنی یک بک آپی داشته باشیم که بر اساس اطلاعاتی تعریف میشه که وارد پایگاه داده تون به عنوان یک log میشه. بعدا خواهید دید که ما مُد ریکاوری و بک آپ گیریمون دارای گزینه های مختلفی هست از جمله مُد full. اگر ما این مُد رو انتخاب کرده باشیم بک آپ گیری به روش Log Backup برامون در دسترس هست. اینو بگم در حالت های ریکاوری دیگه، به سادگی داده کافی در ورود به سیستم پردازش برای توجیهback up گیری از نوع Log Backup وجود نداره، و نهایتا مُد های دیگه نمیتونن شرایط مناسب برای شروع بک آپ گیری از نوع Log Backup رو برآورده کنن. اما زمانی که در حالت یا مُد ریکاوری از نوع full هستیم، همه جزئیات تمام اطلاعات پردازش شده ورودی در log خواهد بود و بالطبع می تونیم در این مُد از روش بک آپ گیری Log Backup استفاده کنیم. اگه بیایم و برای بک آپ گیری نوع log back up رو انتخاب کنیم بعد زمانی که قصد دارین یک log یا همون یک log back up رو بازیابی کنین، میتونین دقیقا یک بازیابی اطلاعات یا یک restoreتا زمانی که اون log رو تعریف کرده اید، بدست بیارید. دقیقا مثل ریستور ویندوز که وقتی میخایم عملیات restore رو انجام بدیم می بینید که بازگشت به اطلاعات سیستمی یک زمان و یک تاریخ درست از آخرین نرم افزاری که بعنوان یک ورودی یا log روی سیستم عاملتون نصب کردید رو بعنوان بک آپ، بهتون پیشنهاد میده.
بنابراین زمانی که شما بازیابی رو انجام میدین، لزوما بازیابی رو برای همه داده ها ندارین، بلکه بازیابی دقیقا از زمانی که یکسری داده های مشخص با عنوان یک log به نرم افزار معرفی شده بودن، شروع میشه. یجورایی ما رو برمی گردونه به قبل از زمانی که log تعریف شده و این میتونه خیلی مفید باشه چرا که بعد از تعریف log ممکنه داده های مخربی وارد دیتابیسمون شده باشن و الان میخایم برگردیم درست قبل از log.
بنابراین بازیابی رو درست قبل و بعد از هر تغییرات داده ای شخصی میتونین انجام بدین. مطابق با این گفته ها، اگه اتفاق بدی برای دیتا بیسمون در یک زمان خاص بعد از اعمال یکسری از همین تغییرات و پردازش های اطلاعات بیفته و ما بعنوان مثال هر دو بک اپ گیری از نوع full back up و نوع logbackup رو داشته باشیم، در ابتدا full back up رو بازیابی میکنیم و بعد از اون در حالی که logbackup رو بازیابی میکنیم، میتونیم بگیم تا یک زمان خاصی عملیات بازیابی یا restore رو برامون اعمال کنه و حتی میتونیم بگیم که عملیات restore اون پایگاه داده رو بگیم در حالت خاصی ترک کنه که این حالت خاص، قبل از ایجاد مشکلی هست که برامون رخ داده.
Log backup خیلی رایج بخصوص در پایگاه های داده خیلی بزرگ و خیلی مهم این نوع بک آپ گیری خیلی زیاد مشاهده میشه در ادامه چیزی که در زمان صحبت پیرامون امر بک آپ گیری در موردش شنیدید و من در موردش دوست دارم یکسری نکاتی رو بهتون بگم اینه که چطور حالا که ما یک بک آپ گرفتیم می تونیم اون رو بازیابی یا Restore کنیم. پس الان اگه یک بک آپ دارید که میخاید اون رو بازیابی یا Restore کنید بهتون پیشنهاد میدم قبلش اون رو یکبار با Restore کردن یا بازیابی کردن امتحان کنید. ممکن هست شما الان در موقعیت شغلیتون مجبور باشین که هر روز از اطلاعات پایگاه داده تون بک آپ بگیرین و اگه بعدا یک زمانی پیش بیاد که مجبور بشین که برای بازیابی اطلاعاتی که چون فکر می کردید خیلی با ارزش هستن، مکرر بک آپ می گرفتید، اقدام کنید، شاید متوجه این بشید که یا ابزارهای مورد نیاز بازیابی اطلاعاتتون رو ندارید یا اینکه شناخت از این که، چجور بازیابی یا Restore کنین رو ندارین و بنابراین بک اپ هاتون بی فایده و بلااستفاده باقی می مونن و الان که از کاری که هر روز انجام میدادین و میومدین و از اطلاعات ارزشمندتون بک آپ می گرفتین متنفر میشید. شما میتونین در زمانهای مختلف با تست کردن فرایند بازیابی یا Restore یکم از این نوع مشکلاتی که ممکن هست بعدا براتون پیش بیاد کم کنید، و با این کار مشکلاتتون رو تسکین بدین. پس پیشنهاد میدم اگه شما یک همچین شخصی هستید که دائما از اطلاعات ارزشمند شرکتتون بک آپ می گیرین بیاید و یکی از این بک آپ هاتون رو انتخاب کنید و در یک سرور دیگه مثلا یک سروری که برای تست کردن، اومدین و sql server 2016 رو روی اون نصب کردین یا سرور دیگه ای که مثلا نسخه development نرم افزار sql server رو روش نصب کردین انتخاب کنید و پیش برین و یک بازیابی یا Restore رو انجام بدین و ببینین که چه اتفاقی میفته.
بازیابی از یک پایگاه داده بزرگ میتونه چندین ساعت طول بکشه و این چیزی هست که هر کسی در سازمان خودش که در حال کار با دیتابیس ها هست باید از اون اگاهی داشته باشه. اگه به طور منظم در حال بک اپ گیری باشین میتونین مطمئن باشین که توانایی بازیابی یا Restore اطلاعات ارزشمند اداره تون رو بدون از دست دادن حتی یک بیت از اطلاعات رو خواهین داشت.
این رو بدونید اگه اطلاعات بخان در چندین ساعت بازیابی بشن می تونه برای ما یک مشکل بزرگ رو یادآوری کنه ولی اگه شما اطلاعات کافی از انواع روش های بک آپ گیری داشته باشید می تونید این مشکلات رو براحتی حتی در کار با دیتابیس های بزرگ هم برطرف کنید. بنابراین شما میخواهید هر کسی رو از انچه در یک چارچوب زمانی اتفاق میفته، وقتی عمل بازیابی رو انجام میدین اگاه کنین. حتی اگه یک همچین اتفاقی براتون رخ بده و در هنگام بازیابی یک پایگاه داده بزرگ ببینید که زمان زیادی طول میکشه اگه اطلاعات کافی در مورد انواع بک آپ ها داشته باشین می تونین خیلی راحت بقیه رو در ادراه تون مجاب کنید که چرا اینقدر زمان بازیابی اطلاعات در مورد این دیتابیس خاص طول کشیده و نگرانی همکارانتون رو برطرف کنید و شما اگر اطلاعات کافی رو داشته باشین هر کسی رو می تونید مجاب کنید که چرا اینقدر زمان، برای عملیات بازیابی یا Restore صرف شده.