بررسی اشتباهات در پشتیبان گیری SQL Server

بکاپ گیری از پایگاه اطلاعاتی SQL Server یکی از مهمترین وظایف روزمره مدیران پایگاه اطلاعاتی در محیط SQL Server است. فرآیند بکاپ گیری بسیار مهم و مستلزم فرآیندهای خوب تعریف شده، چک لیست ها و چندین مدیر پایگاه اطلاعاتی جهت اجرا و مدیریت می باشد. خطاهای بکاپ گیری هنوز جزء متداول ترین خطاها هستند، خطاهای پرهزینه و زمانبر که مدیران دائما با آن ها روبرو می شوند. ما لیستی از برخی از رایج ترین اشتباهات را تهیه کرده ایم و پیشنهاداتی را در مورد نحوه اجتناب از آن ها ارائه نموده ایم.

برسی امنیت SQL Server Express

برنامه ریزی

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

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

طرح بکاپ گیری غلط و یا مدل بازیابی غلط
اغلب با کسانی برخورد می کنید که انتظار از دست رفتن هیچ داده ای را ندارند، پایگاه اطلاعاتی آن ها در یک مدل Simple Recovery است و فقط بکاپ گیری کامل را انجام می دهند. سناریوی دیگر این است که پایگاه اطلاعاتی در مدل Full Recovery باشد و تنها بکاپ گیری های کامل مورد توجه قرار بگیرند. ابتدا باید تفاوت بین مدل های بازیابی و گزینه های مختلف بکاپ گیری را بفهمید چون هر دو مکمل یکدیگرند.

من فقط نیاز به بازیابی پایگاه اطلاعاتی دارم
باید بدانید که غیر از پایگاه اطلاعاتی چیزهای دیگری هم برای بازیابی SQL Server وجود دارند. وقتی طرح بکاپ گیری پایگاه اطلاعاتی خود را تنظیم می کنید، باید بخاطر بسپارید که از Reporting Serviceها، Analysis Serviceها، Integration Serviceها و نیز آیتم هایی که خارج از SQL Server هستند از جمله ابزارهای شخص ثالث، فایل های sqlcmd، اسکریپت های دسته ای و غیر هم بکاپ گیری کنید.

محافظت

عدم محافظت از بکاپهای فیزیکی
از آنجائیکه بکاپ گیری کامل پایگاه اطلاعاتی شامل تمام داده های موجود در پایگاه اطلاعاتی می شود، باید به ارزش داده ها یا عواقب افتادن آن ها بدست افراد نا اهل بیاندیشید. اگر اطلاعات کارت های اعتباری یا شماره¬ها یا پسوردهای مهم را ذخیره می کنید، باید مطمئن شوید که این داده ها تا زمانی که وجود دارند و در نسخه های بکاپ شما هستند، همیشه محافظت می شوند. اگر کسی نسخه بکاپ را در اختیار داشته باشد، به راحتی میتواند با یک Restore یا بازگردانی به داده ها دسترسی پیدا کند. دلیل دیگر اینکه چرا میخواهید از فایل ها محافظت کنید این است که مطمئن شوید آن ها در زمانی که نیاز به Restore دارید، وجود دارند. فایل ها میتوانند به راحتی بصورت عمدی و یا تصادفی حذف شوند و دیگر برای بازگرداندن یا Restore وجود نداشته باشند. همچنین باید دسترسی به مکان هایی که بکاپ ها ذخیره می شوند را محدود کنید و همچنین به آن ها اجازه ندهید در مکان های دیگر کپی شوند یا آن ها را در این خصوص محدود کنید.

عدم رمزگذاری بکاپ ها
موضوع دیگری که به محافظت فیزیکی محدود می شود رمزگذاری داده های مهم در پایگاه اطلاعاتی در رویدادی است که فرد به بکاپ های شما دسترسی دارد. به طور پیش فرض، داده ها در پایگاه اطلاعاتی رمزگذاری نمی شوند. بهرحال میتوانید داده های اصلی را با استفاده از کلیدهای رمزگذاری یا رمزگذاری داده ها به صورت شفاف (TDE) در پایگاه اطلاعاتی رمزگذاری نمائید همچنین باید بتوانید با برخی از ابزارهای شخص ثالث بکاپ گیری SQL Server، بکاپ های رمزگذاری شده بسازید. در این صورت یک سطح محافظتی دیگر به نسخه های بکاپ شما اضافه می گردد، مخصوص مواردی که این نسخه ها ممکن است بدست افراد نا اهل بیفتد.

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

نوشتن چندین بکاپ در فایل فیزیکی مشابه
مسئله دیگر زمانی است که چندین بکاپ در یک فایل فیزیکی مشابه نوشته می شوند. در صورتی که فایل خراب شود، این کار میتواند منجر به یک نقطه خرابی گردد. بعلاوه، تنها با نگاه کردن به نام و اندازه فایل نمی توان گفت که چه چیزی داخل فایل بکاپ است بنابراین اگر چندین بکاپ در یک فایل وجود دارند، تنها راه تشحیص اینکه چه چیزی در فایل است، استفاده از فرمان های Restore می باشد. روش بهتر، ساخت یک بکاپ بازای هر فایل و استفاده از یک قرارداد نامگذاری ثابت می باشد. در این روش میتوانید نگاهی به نام فایل بیاندازید و بگوئید چه نوع بکاپی است و برای چه پایگاه اطلاعاتی و چه زمانی ساخته شده است. اگر فایلی خراب شود، فقط روی بکاپ همان فایل تاثیر می گذارد.

امکان دسترسی اکانت های بیشتر به ساخت بکاپ ها
همانطور که پیشتر گفتیم، دسترسی افراد نااهل به بکاپ ها یک مشکل جدی و بزرگ است. نکته دیگر که باید توجه داشته باشید این است که آیا افراد زیادی هستند که امکان ساخت بک های پایگاه اطلاعاتی خود را دارند. اگر افراد دسترسی به محل ذخیره شدن بکاپ ها را ندارند و اگر میتوانند بکاپ های خود را بسازند، پس میتوانند به راحتی یک کپی از کل پایگاه اطلاعاتی بگیرند. برای اینکه چنین اتفاقی نیافتد، باید اجازه افراد را به ساخت بکاپ ها محدود کنید و نیز زمانیکه بکاپ ها ساخته می شوند، بر آن ها نظارت داشته باشید. این کار با استفاده از جدول های سیستم و نیز گزارش رویداد ویندوز و گزارش خطای SQL Server انجام می شود.

عدم بکاپ گیری از پایگاه اطلاعاتی سیستم
موضوع دیگری که اغلب نادیده گرفته می شود بکاپ گیری پایگاه های اطلاعاتی سیستم است. مشخص نیست که آیا این به خاطر عدم اطلاع از چیزهایست که در این پایگاه اطلاعاتی ذخیره شده اند یا به خاطر عدم آگاهی از نحوه استفاده از آن ها برای بازگردانی. دو پایگاه اطلاعاتی سیستم اصلی که باید بکاپ بگیرید master و msdb هستند. پایگاه اطلاعاتی master اطلاعات امنیتی و نیز فراداده های مربوط به پایگاه های اطلاعاتی دیگر را ذخیره می کند. msdb اطلاعات مربوط به برنامه ها(job)، اپراتورها و هشدارها و غیره را ذخیره می کند. این خیلی مهم نیست مگر آنکه تغییراتی را در پایگاه اطلاعاتی مدل انجام دهید. از آنجائیکه Tempdb هربار که SQL Server را restart می کنید، ساخته می شود نیازی به بکاپ گرفتن از tempdb نیست. پایگاه اطلاعاتی دیگری که میتوانید بکاپ بگیرید، پایگاه اطلاعاتی منبع است، اما این کار باید خارج از SQL Server انجام شود. بعلاوه، به عنوان روش دیگر برای بازیابی آبجکت¬های مهم، اطلاعات مهم مربوط به این پایگاه های اطلاعاتی را بنویسید، اما داده های مربوط به تاریخچه را نخواهید داشت.

بازیابی

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

برگرداندن (restore) از نوار
باید آخرین مجموعه ی کامل بک ها را در یک دیسک نگه دارید تا از بازیابی سریع پایگاه اطلاعاتی خود اطمینان حاصل کنید. برگرداندن از دیسک در اکثر موارد همیشه سریع تر از برگرداندن از نوار است. طبق یک قاعده کلی، برای بازیابی، از دیسک و برای ذخیره سازی طولانی مدت از نوار استفاده کنید.

نداشتن بکاپ های جدید در دیسک
مسئله دیگر زمانی به وجود می آید که بکاپ های جدید در دیسک وجود ندارند و بنابراین باید بدنبال بکاپ ها در نوار بگردید. همچنین، باید مجموعه کامل بکاپ ها را نگه دارید که شامل بکاپ گزارش تراکنش، بکاپ تفاضلی و بکاپ کامل در دیسک است. گرچه ایده خوبی است که هر دو مجموعه را در صورت امکان در دیسک نگه دارید. هر چیزی فراتر از این در دیسک، معنی پیدا نمی کند چرا که شما در کل میخواهید جدیدترین داده ها را بازگردانید.

نداشتن اولویت بندی برای بازیابی
ما در مورد داشتن یک طرح تمرینی برای بازیابی پایگاه های اطلاعاتی شما صحبت کردیم. بعلاوه، باید یک اولویت بندی برای روند برگرداندن(Restore) تنظیم کنید. اولویت بندی به شما امکان می دهد از پس مهمترین پایگاه های اطلاعاتی بر بیایید. همچنین اگر پایگاه های اطلاعاتی وجود دارند که وابسته به پایگاه اطلاعاتی دیگر هستند، الویت بندی هابه ترتیبی عمل می کنند که اپلیکیشن ها بتوانند به درستی عمل کنند. انجام بی درنگ همه کارها غیر ممکن است. بنابراین ایده خوبی است که به فکر روشی باشید که در رویداد خرابی های چندگانه بتوانید از پس کارها بربیایید.

عدم اطلاع از نحوه بازیابی اپلیکیشن هایی که از چندین پایگاه اطلاعاتی استفاده می کنند
بسیاری از شما اپلیکیشن هایی دارید که برای عمل کردن وابسته به بیش از یک پایگاه اطلاعاتی هستند. به همین دلیل است که واقعا باید به فکر فرآیند بازیابی برای این نوع بازیابی ها باشید. آیا لازم است تمام پایگاه های اطلاعاتی در لحظه به یک نقطه بازیابی شوند؟ اگر پایگاه های اطلاعاتی دارید که تکثیر شده اند، چگونه فرآیند بازیابی بر این تکثیر تاثیر می گذارد؟ اگر از اپلیکیشن های شخص ثالثی استفاده می کنید که از SQL server استفاده می کنند پس به چه اقدامات خاصی برای برگرداندن پایگاه های اطلاعاتی و کار کردن دوباره اپلیکیشن ها، نیاز دارید؟ باید به فکر بازیابی کامل باشید نه فقط یک پایگاه اطلاعاتی.

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

نظارت

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

لاگ برداری از تمام بکاپ های موفق
بخش غیرآشنای خرابی های لاگ برداری و نظارت، مسئله لاگ های خطای پرشده با بکاپ های موفق است. اگر پایگاه های اطلاعاتی متعددی دارید و از لاگ تراکنش بکاپ گیری می کنید، این مسئله برای شما مشکل ساز خواهد شد. شما میتوانید برای غیرفعال کردن لاگ برداری های موفق از Trace Flag 3226 استفاده کنید تا لاگ های خطای شما کوچک بماند.

عدم نظارت بر اندازه فایل و زمان بکاپ گیری
همچنین باید بر مدت زمانی که بکاپ گیری ها انجام می شوند و نیز اندازه های فایل، نظارت داشته باشید. به این ترتیب احتمال روی هم افتادگی این فرآیند با فرآیندهای دیگر به صفر می رسد و دیگر برای ساخت نسخه های بکاپ فضا کم نمی آورید. شما باید فهرستی از آنچه رخ می دهد را نگه دارید، این فهرست را می توان با استفاده از جدول های سیستم بکاپ در msdb خودکار سازی کرد، به این ترتیب می توانید در گیر اینگونه مسائل نشوید.

آزمایش

عدم استفاده از گزینه تائید restore
مشگل دیگری که ممکن است با آن مواجه شوید زمانی است که سعی می کنید بکاپ خود را بازگردانید و می فهمید که بکاپ شما خوب نیست. گرچه تائید یک restore یا بازگردانی، موفقیت انجام عمل بازگرداندن را تضمین نمی کند اما حداقل این ذهنیت را در شما ایجاد می کند که SQL Server توانسته محتوای بکاپ ها را بدون هیچ مشکلی بخواند.
زمانیکه از طرح¬های حفظ و نگهداری استفاده می کنید، اضافه کردن این مرحله کار ساده ای است. اما وقتی اسکریپت های مخصوص خودتان را می سازید باید این مرحله را نیز به فرآیند اضافه کنید. در آخر، باید به خروجی این فرمان نظارت داشته باشید تا مطمئن شوید که تائید restore بدون هیچ مشکلی صورت گرفته است.

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

زمانبندی

زمانبندی غلط بکاپ گیری
زمانبندی غلط بکاپ گیری یک مشکل متداول دیگر است. در اکثر موارد وقتی بکاپ گیری کامل را یکبار در هفته انجام می دهید، بکاپ گیری¬های تفاضلی (Differentials) باید در روز دیگری از هفته انجام بگیرد. اگر فضای خالی نداشته باشید، این گزینه ممکن است تنها گزینه شما باشد. اما فضای خالی دیگر نباید مسئله مهمی باشد. سناریوی دیگر، داشتن پایگاه اطلاعاتی در بازیابی کامل ، انجام بکاپ های کامل روزانه و سپس کوتاه کردن لاگ تراکنش است. اگر قصد دارید داده ها را دور بیاندازید باید از مدل Simple Recovery نیز استفاده کنید. شما باید ترکیبی از بکاپ های کامل، تفاضلی و لاگ های تراکنشی داشته باشید و سعی کنید از انجام فعالیت هایی که I/O بالایی دارند مثل بکاپ های کامل در زمانهای اوج مصرف اجتناب کنید. گرچه ممکن است مجبور به این کار باشید، اما باید بدانید که برای به حداقل رساندن اثرات احتمالی میتوانید از بکاپ های تفاضلی همراه با بکاپ های کامل استفاده کنید.

آگاهی

عدم درگ گزینه ها
مشکل بزرگ دیگری که افراد با آن مواجه هستند عدم آگاهی از گزینه های مختلفی است که با استفاده از فرمان¬های T-SQL و SQL Server Management Studio می توان به آنها دسترسی داشت.
باید زمانی از وقت خود را صرف خواندن کتاب های آنلاین SQL Server نمائید. در این صورت با تمام گزینه های مربوط به بکاپ گیری و بازیابی آشنا خواهید شد. منابع رایگان دیگری نیز در اینترنت وجود دارند که میتوانید از آن ها استفاده کنید.

عدم درک فرآیند Restore
قبلاً کمی در مورد بازیابی صحبت کردیم اما موضوع دیگری که باید راجع به آن بدانید، فرآیند Restore یا بازگردانی است. با توجه به اهمیت بکاپ گیری ، باید گفت که بازیابی نیز به همان اندازه حائز اهمیت است.

تکیه بر SSMS
مشکل دیگری که معمولا وجود دارد اتکا کردن به Management Studio است. Management Studio یک ابزار فوق العاده برای انجام اکثر کارهایی است که باید آنها را انجام دهید، اما گزینه های دیگری نیز وجود دارند که نمی توانید با SSMS استفاده کنید. باید مقداری از وقت خود را صرف آشنایی با فرمان های T-SQL نمائید. اگر لازم است Restore یا بکاپ گیری را از یک خط فرمان انجام دهید باید فرمان های T-SQL را بدانید.

فقط دانلود کنید و اسکریپت ها را بدون آنکه بفهمید، اجرا نمایید
باید از دانلود کردن و اجرای اسکریپت ها بدون آنکه بفهمید واقعاً چکاری انجام می دهند، اجتناب کنید. باید زمانی از وقت خود را صرف خواندن اسکریپت و هر سند دیگر مربوط به اسکریپت نمایید. باید مطمئن شوید که آنچه را که انتظار دارید بدست می آورید. بدون صرف وقت در مورد فهمیدن اسکریپت، از کجا می دانید که به درستی کار می کند؟

عدم صرف وقت جهت یادگرفتن ویژگی های جدید
اشتباه رایج دیگر عدم صرف وقت برای یادگیری ویژگی های جدید است. ممکن است فکر کنید که بکاپ گیری، بکاپ گیری است، اما همیشه با هر بار انتشار SQL Server، ویژگی های جدیدی برای بکاپ گیری اضافه می شوند. بهتر است که پابه پای هر نسخه منتشر شده SQL Server پیش بروید و وقتی از سرویس پک ها استفاده می کنید، از همه تغییرات مطلع شوید.

عملکرد

نوشتن مستقیم روی نوار
اکثر ابزارهای بکاپ گیری شخص ثالث عامل هایی دارند که به شما امکان نوشتن مستقیم روی نوار را می دهند. تا چند وقت پیش که فضای دیسک محدود و گرانقیمت بود، این ویژگی فوق العاده به نظر می رسید، اما حالا اینطور نیست. شما میتوانید ابتدا روی دیسک بنویسید و سپس آن را روی نوار آرشیو نمائید، چون بکاپ های دیسک معمولا همیشه سریع تر هستند.

به حداکثر نرساندن I/O دیسک
مشکل دیگری که رخ می دهد به حداکثر نرساندن I/O دیسک است. بکاپ ها و Restoreها بسیار متمرکز بر I/O هستند چرا که باید پایگاه اطلاعاتی را کامل بخوانند و سپس پایگاه اطلاعاتی را کامل بنویسند.
با ساخت بکاپ ها در دیسک های فیزیکی مختلف میتوانید از مزیت خواندن از یک مجموعه دیسک و نوشتن در مجموعه دیگر دیسک ها بهره مند شوید. برای کاهش I/O دیسک میتوانید نسخه های بکاپ خود را فشرده کنید، بنابراین داده های بسیار کمتری را می نویسید. همچنین می توانید داده های خود را در چندین فایل در چندین دیسک بنویسید تا توان عملیاتی I/O افزایش یابد.

بکاپ گیری از پایگاه اطلاعاتی بی مصرف
آیا پایگاه های اطلاعاتی غیر تولید اضافی در سرور خود دارید که هر شب از آن ها بکاپ می گیرید؟ اگر این پایگاه های اطلاعاتی پایگاه اطلاعاتی موقت یا آزمایشی هستند، نباید چرخه ها را با بکاپ گیری آن ها تلف کنید. اگر فرآیندی دارید که از تمام پایگاه های اطلاعاتی پشتیبانی می گیرد، در واقع شما با بکاپ گیری از این پایگاه های اطلاعاتی غیر ضروری، وقت خود را تلف می کنید. باید نگاهی به رویتن های بکاپ گیری خود بیاندازید و وقت خود را با بکاپ گیری پایگاه های اطلاعاتی که نمیخواهید هدر ندهید.

بکاپ گیری از پایگاه اطلاعاتی Read Only
مشکل دیگری که وجود دارد، بکاپ گیری دوباره و دوباره از پایگاه های اطلاعاتی Read-Only است. اگر این پایگاه های اطلاعاتی هر روز تغییر نمی کند، نباید خودتان را هر روز به خاطر بکاپ گیری از آن ها به زحمت بیاندازید.

عدم ساخت بکاپ های فشرده شده
وقتی یک بکاپSQL Server ساخته می شود، بطور پیش فرض بازای هر صفحه ای که در پایگاه اطلاعاتی استفاده می شود، یک صفحه اضافه خواهد شد. ازآنجائیکه برخی از این صفحه ها ممکن است داده های کمی داشته باشند، هنگامیکه بکاپ ساخته می شود، فضای بی مصرف زیادی به وجود می آید. ابزارهای زیادی وجود دارند که به شما امکان ساخت نسخه های پشتیبان فشرده شده را می دهند و این ابزار در SQL 2008 هم موجود است. شما میتوانید نسخه های بکاپ خود را تا ۹۵% فشرده کنید و بکاپ خود را بسیار سریع تر اجرا نمایید و در مصرف فضای دیسک صرفه جویی کنید. همچنین اگر نیاز به انتقال بکاپ ها به سرورهای دیگر داشته باشید به شما کمک می کند، چرا که فایل بسیار کوچکتر است.

بکاپ گیری از طریق شبکه
با توجه به اینکه می توانید با استفاده از مسیرهای UNC، در هرجایی از شبکه خود یک بکاپ بسازید اما ایرادی که وجود دارد این است که نمی توانید پهنای باند شبکه را کنترل کنید و بنابراین زمان بکاپ گیری هر روز متغییر خواهد بود. بکاپ گیری در درایوهای محلی و سپس کپی کردن فایل ها ایده خوبی است. به همین دلیل است که فشرده سازی بکاپ ها اینقدر فایده دارد. در برخی موارد ممکن است یک VLAN جداگانه برای ترافیک بکاپ خود داشته باشید جایی که میتوانید پهنای باند را کنترل کنید و تاثیرات احتمالی را کمتر نمائید.

اجرای تمام بکاپ ها بطور همزمان
تنظیم زمانبندی های بکاپ گیری با استفاده از SQL Agent آسان است اما باید سعی کنید بکاپ گیری ها را سریعاً انجام دهید. در اکثر موارد در یک نمونه، شما این کار را به صورت سریالی انجام می دهید اما اگر از چندین سرور و در یک محل بکاپ گیری متمرکز می نویسید، راحت تر است که از تایم زمانبندی شده یکسان استفاده کنید. باید از این موضوع مطلع باشید و طبق آن زمانبندی خود را تنظیم نمائید. در این جا میتوانید بر بکاپ گیری های خود نظارت کنید تا ببینید آیا هر روز بیشتر از دیروز طول می کشند و سپس در صورت نیاز، زمانبندی خود را تنظیم نمائید.

مدیریت

طرح های بکاپ گیری ناسازگار
مدیریت SQL Server به خودی خود دشوار هست، با این وجود طرح های بکاپ گیری ناسازگار از سروری به سرور دیگر این دشواری را چندبرابر می کند. در عوض، باید سعی کنید پایگاه های اطلاعاتی خود را در چند گروه طبقه بندی کنید و سپس از یک طرح بکاپ گیری مشابه در همه این گروه های متفاوت پایگاه اطلاعاتی استفاده نمائید.

اضافه نکردن پایگاه های اطلاعاتی جدید در طرح بکاپ گیری
وقتی طرح های بکاپ گیری را تنظیم می کنید میتوانید با هارد کد کردن (Hard Code) مشخص کنید کدام پایگاه های اطلاعاتی باید بکاپ گرفته شوند. باید مطمئن شوید که این طرح آنقدر انعطاف پذیر هست که بتوانید پایگاه های اطلاعاتی جدید را بیافزائید و همچنین بربکاپ گیری ها نظارت داشته باشید تا اطمینان حاصل کنید که پایگاه های اطلاعاتی جدید از دست نمی روند.

پردازش بکاپ گیری غیر متمرکز
اگر سرورهای زیادی برای مدیریت دارید باید نگاهی به تنظیم فرآیند بکاپ گیری متمرکز بیاندازید. بنابراین میتوانید همه چیز را از یک نقطه مدیریت کنید. این کار با ساختن پردازش مخصوص خودتان یا استفاده از ابزارهای شخص ثالث که به شما امکان انجام این کار را می دهند، عملی است.

کنار گذاشتن مدیر پایگاه اطلاعاتی از فرآیند بکاپ گیری
ساخت بکاپ ها یک کار روتین و معمولی بنظر می رسد، ولی هر روز اشتباهات زیادی صورت می گیرد. مثلاً هنگام بازیابی پایگاه های اطلاعاتی در SQL Server، غیر از بازگرداندن فایل چیزهای بیشتر دیگری هم برای بازگرداندن وجود دارند. طرح های بکاپ گیری مربوط به سرورهای فایل احتمالاً برای سرورهای پایگاه اطلاعاتی شما کار نخواهند کرد، پس حواستان باشد که مدیر پایگاه اطلاعاتی را از فرآیند بکاپ گیری و Restore، کنار نگذارید.

قراردادهای نامگذاری نا سازگار
باید مطمئن شوید که از قراردادهای نامگذاری استاندارد در زمان ساخت بکاپ ها استفاده می کنید. SQL Server به طور پیش فرض از bak و trn استفاده می کند اما شما میتوانید از dif برای بکاپ گیری های تفاضلی و flg برای گروه های فایلی و غیر استفاده نمایید. همچنین باید نام سرور، نام نمونه، نام پایگاه اطلاعاتی و تاریخ بکاپ ساخته شده را بگنجانید. در این صورت میتوانید با نگاه کردن به نام فایل بفهمید که چیست.

نوشتن بکاپ ها در محل های ناسازگار
مسئله دیگر نوشتن بکاپ ها در محل های متفاوت است. مثلا بکاپ های کامل در درایو E و بکاپ های لاگ در درایو F و غیره نوشته می شوند. اگر فایل ها کنار هم نگه داری نشوند این کار میتواند گیج کننده باشد. برای کسانی که با سرور آشنایی ندارند، اینکار موجب سردرگمی بیشتر آن ها می شود. پس مطمئن شوید که مجموعه کامل بکاپ های فایل در کنار یگدیگر نگاه داشته می شوند.

عدم حذف فایل ها و داده های قدیمی
در اکثر فرآیند بکاپ گیری، می توانید بکاپ قدیمی تر را حذف کنید تا فضای دیسک را مدیریت نمائید. از پاک کردن فایل های لاگ قدیمی مطمئن شوید و داده های مربوط به تاریخچه قدیمی را از جدول های سیستم Restore و بکاپ پاکسازی نمائید.

ابزارها

عدم اطلاع از ابزارهای موجود
ابزارهای زیادی وجود دارند که همراه SQL Server می باشند و میتوانند برای فرآیند بکاپ گیری مورد استفاده قرار بگیرند مثل SMS ، System Tables، T-SQL، Windows Event Viewer، SQL Server Error Logs و Notification و غیره. باید زمانی را صرف آشنایی با این ابزارها کنید در این صورت تمام اطلاعات و ابزارها در چنگ شما خواهند بود.

ترسیدن از ابزارهای شخص ثالث
این ابزارها ویژگی های مدیریتی فوق العاده ای را عرضه می کنند و همچنین ویژگی هایی که حتی در SQL Server هم وجود ندارند. نباید از تحقیق کردن در مورد این ابزارها و اجرای آنها بترسید.

نتیجه گیری

vector_monsterیکی از تجربیات تلخ مدیران پایگاه اطلاعاتی این است که نسخه بکاپ به خوبی عمل نمی کند. اشتباهات بکاپ گیری اغلب گران تمام می شود، همیشه زمان بر هستند و حتی میتوانند به قیمت شغل مدیران پایگاه اطلاعاتی تمام شوند. امیدواریم لیست اشتباهات عنوان شده در این مقاله به شما کمک کند تا جلوی اینگونه اشتباهات در بکاپ گیری ها را بگیرید.smile icon

3 دیدگاه
  1. arsalan681 says

    سپاس

  2. Saeedi says

    Great Article, Thanks.

  3. mrd515 says

    عالی بود عالی عالی

دیدگاه

آدرس ایمیل شما منتشر نخواهد شد.