راهکارهای گرفتن Backup با توجه به کمبود منابع ذخیره سازی،عدم کاهش سرعت سرور اسکیوال و ...

[mahdy.asia]

حجم دیتابیس شرکت ما 20GB شده تا بحال چند سری بانک اطلاعات دچار مشکل شده و مجبور شدیم Backup ریستور کنیم با توجه به از بین رفتن اطلاعات بین Backup گیری تا تخریب شدن دیتابیس (Backup اطلاعات رو روی Tape نگهداری می دهیم) دنبال راهکارهایی هستیم که در صورت مخدوش شدن بانک اطلاعاتی بتوانیم آخرین اطلاعات را داشته باشیم بدون خرید منابع ذخیره سازی جدید
چه پیشنهاداتی دارید؟

[in_chand_nafar]

اگر دیتا برای شما ارزش حیاتی دارد سراغ HA بروید
این هم یک لینک (http://nikamooz.com/%D8%A7%D9%85%DA%A9%D8%A7%D9%86%D8%A7%D8%AA/radionikamooz/67-%DA%86%DA%AF%D9%88%D9%86%D9%87-%D8%A8%D8%A7%D9%86%DA%A9-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA%DB%8C-%D8%AE%D9%88%D8%AF-%D8%B1%D8%A7-%D9%87%D9%85%DB%8C%D8%B4%D9%87-%D9%BE%D8%A7%D8%A8%D8%B1%D8%AC%D8%A7-%D9%86%DA%AF%D9%87-%D8%AF%D8%A7%D8%B1%DB%8C%D9%85%D8%9F.html)مناس ب

[pashna]

سلام،

چه چیزی باعث تخریب اطلاعات می‌شه ؟

اگر اشتباهت کاربری باعث می‌شه، روش هایی که دوستمون گفتن به سختی می‌تونه کمکت کنه.

[in_chand_nafar]

یکی از وظایف یک ادمین خوب بررسی صحت بانک اطلاعات و... می باشد
از دستور DBCC CHECKDB برای بررسی صحت بانک اطلاعاتی (یکی از کارهای مربوط به این دستور) کمک بگیرید

[pashna]

سلام،

حق کاملا با شماست ، و دستور که فرموده بودید هم کاملا درسته، صحت بانکِ اطلاعات با صحت داده‌های ورودی فرق داره. منظور من اینکه که، اگر تخریب در اثر اشتباه کاربر، مثلا دیتا رو اشتباها پاک می‌کنه، اتفاق بیفته، حتا اگر شما از Mirroring استفاده بکنید، دیتا در Node Mirror هم خراب شده یا همینطور AlwaysOn. فقط در شرایطی میتونید دیتا رو از Replication بازیابی کنید.
اگر منظور دوستمون از تخریب اطلاعات ، تخریب توسط کربر باشه، به نظر من تنها راه نجات استفاده از Backup Plan مناسب هست. مثلا هفته آئ‌ یکبار Full Backup بگیرن و ساعتی یکبار هم TransactionLog Bakup.

[mahdy.asia]

تا بحال اخیرآ یکبار Damage Database داشتیم یکبار هارد سوخته !

[in_chand_nafar]

شما سناريوهاي زير را بايد رعايت كنيد
1- براي سخت افزار (هارد) استفاده از RAID
2- در مورد حذف كنترل دسترسي و... و مهمتر از همه تهيه بكاپ به شكل Full,Differential,Log
متاسفانه خيلي جاها از لاگ بكاپ غافل مي مانند ارزش زيادي داره هر چند دقيقه يكبار مي توانيد لاگ بكاپ بگيرين و اگر مشكلي داشتيد مي توانيد Restore را به ساعت قبل از مشكل برگردونيد (point In time)
اين هم يك لينك (http://msdn.microsoft.com/en-us/library/ms179451.aspx)

[esteghamat]

سلام
راهنمايي دوستان بسيار عالي بود. من هم چند تا نكته به نظرم با توجه به تجربياتم موثر بوده و بعضا دوستان هم اشاره كردند را مي آورم :
1- واقعا Backup گيري هنوز بصورت يك الگوي ناقص استفاده مي شود. همونطور كه گفته شد حتما يك plan براي اون نياز است. مثلا هر شب يك Full Backup و در طول روز با توجه به نياز شما مثلا هر 20 يا 40 دقيقه يك Transaction Backup.
و اگر با كمبود فضاي زيادي مواجه هستيد، هر هفته يك يا دو بار Full بگيريد ولي حتما Dif back. و نيز Log back. را هم انجام دهيد.
دقت كنيد كه فايل هاي trn نبايد از بين برود تا زنجيره شما حفظ شود.
اگر وسط كار مجبور شديد يك Full بگيريد و براي جايي ارسال كنيد و يا ... و بعد آنرا پاك كنيد. حتما دو باره در همان مسير شبكه اي يك full بگيريد و اولين trn را براي آن بگذاريد.
2- ذخيره Backup ها روي همان سرور بزرگترين اشتباهي است كه در Backup گيري مي توانيد انجام دهيد. حتما به يك آدرس شبكه اي و روي يك سرور ديگر ارسال كنيد.
3- حتما حداقل هر ماه يكبار يك restore ازمايشي از Backup هاي Full و Trn تهيه شده Restore كنيد.
4- در پايان يك دوره مثلا پايان يك ماه Backup هاي آخرين روز ماه را از روي سرور Backup هم خارج نماييد و به يك صندوق امانات مطمئن در جاي ديگري منتقل نماييد.
موفق باشيد