SQL Server disaster-recovery

שלום רב,

תוכנית DRP (ראשי תיבות של Disaster Recovery plan) הינה תוכנית "התאוששות מאסון" שצריכה להימצא בכל ארגון.

"אסון" לא חייב להיות משהו דרסטי כמו נפילת שרת database אלה גם יכול להיות להיות משהו שכיח יותר כמו מחיקת טבלה או רשומה בטבלה קריטית בטעות - תוכנית DRP צריכה לכלול התמודדות גם עם מקרים כאלה.

כידוע ישנם מספר פתרונות טכנולוגיים מובנים בחבילת SQL Server להעלאת השרידות השרת והמידע כגון: windowes cluster להעלאת שרידות מערכת ההפעלה והשרת עצמו, AlwaysOn גרסת SQL Server 2012 ועוד... וכמובן גיבויים קרים וחמים ברמת ה- SQL Server להעלאת זמינות המידע ומניעת איבוד המידע בזמן "אסון".

כמובן לשיטות הללו ישנם עוד פתרונות כגון: גיבויים ברמת מערך האחסון, הורדה לקלטות ועוד שיטות רבות ומגוונות.
הבעיה בכל השיטות והפתרונות הללו שלפעמים בזמן "אסון" אנחנו מנהלי בסיסי הנתונים לא יודעים על מה להסתמך וממה לגבות, האם לשחזר מהגיבוי הסטנדרטי? האם מקלטות וכו'... - וזה בעצם מטרת תוכנית ה- DRP - לעשות סדר במקרה של אסון ולחסוך בזמן ההשבתה.

בתוכנית אני מצפה שיהיה בין השאר טבלה עם פרטי הסיטואציה והפתרון.
לדוגמא: במקרה של מחיקת טבלה יש לשחזר גיבוי SQL Server עם גלגול גיבויים חמים בשם אחר ושחזור הטבלה שנמחקה או שימוש בכלי צד שלישי שיודעים לשחזר טבלה בודדת וכו'...

לאחרונה פורסם באתר http://www.sqlmag.com פוסטר מצויין בנושא: SQL Server Disaster Recovery Step by Step אשר יכול לעשות לנו סדר בזמן "אסון".
לשימושכם : http://www.sqlmag.com/whitepaper/sql-server/sql-server-disaster-recovery-step-step-145134

טיפ לסיום, למזלנו "אסונות" לא מתרחשים כל הזמן, ולכן אני ממליץ לכם על מנת לשמור על "כשירות מבצעית" מידי פעם לעשות ניסויי שחזור על מנת לבדוק שכל מערכות הגיבוי עובדות ותקינות.

שיהיה בהצלחה,

http://blogs.microsoft.co.il/blogs/itaib/archive/2013/02/03/sql-server-disaster-recovery.aspx

SQL SERVER 2008

שלום רב,

ב – SQL server 2008 ישנם שיפורים רבים בנושאים שונים כגון: כלי הניהול, אבטחה, שיפור ביצועים, אחסון המידע, ניטור ו- audit .

להלן דוגמאות לחלק מהשיפורים חדשים :

1. Policy – מנגנון ליישום ה- policy של הארגון בשרתי בסיס הנתונים.
ניתן להגדיר policy ברמת שרת בסיס הנתונים, לדוגמא: שמות אובייקטים, רמות אבטחה וכו'.
אחרי שקובעים את ה- policy השונים ניתן לבצע מספר פעולות:
a. ניתן למנוע פעולות הסותרות את ה- policy
b. ניתן לקבל התראות במייל כאשר אחד האובייקטים לא עומד ב- policy שהגדרנו (בשרת שלנו, ובשאר השרתים בארגון)
c. JOB מתוזמן אשר בודק את ה- policy בבת אחת לכמה שרתים
d. הפצת ה- policy בקלות ובמהירות לשרתים שונים בארגון
e. בדיקות יזומות לשרתים שהם עומדים ב- policy – ניתן לבצע גם בדיקות מול גרסאות שונות של MSSQL.

2. Performance data collection – הינו מנגנון חדש אשר כולל בסיס נתונים אשר אוגר ומנהל את כל נושא הביצועים של השרת המקומי ושרתים אחרים.
המנגנון שומר מידע בנוגע לשאילתות שרצו מאז ומתמיד, מדדי CPU ו- IO, דיסקים, זמני תגובה ועוד...
המנגנון כולל סט של דוחות דינמיים ומעמיקים מאוד , אשר בעזרתם ניתן לתחקר את ההיסטוריה של השרת.
המנגנון גם כולל – כלי לניהול – הגדרת זמני ניטור, הגדרת שמירת מידע ישן וכו'...

3. New activity monitor – מנגנון המציג נתוני שרת ב- real time – ייצא הסבר ב- veracitip הבא.

4. Resource governor – מנגנון לניהול משאבים בבסיס הנתונים.
בעזרת המנגנון ניתן להגדיר לכל משתמש (רק ברמת משתמש בשונה מה- more) בבסיס הנתונים את כמות המשאבים שהוא יקבל.
המנגנון עובד ב- real time – כלומר: ניתן להגדיר ולשנות את הפרמטרים בזמן אמת לטרנזקציה.

5. גיבוי עם כיווץ – בשונה מ- hyperbac לא ניתן לבצע שחזור של אובייקט בודד.

6. Change tracking – מנגנון מובנה לניטור שינויים בטבלאות בסיסי הנתונים.
כל שינויי בסכמה וב- DATA נרשם לטבלת LOG אשר ניתן בסופו של דבר לקבל דוח המציג:
מי שינה, מתי, באיזו עמודה (לא ניתן לראות את הנתון שהשתנה).
המנגנון כולל כלי לניהול – ניקוי אוטומטי של טבלאות ה- LOG וכו'...

7. Change data tracking – מנגנון המאפשר שמירת מידע של גרסאות.
כלומר: כל שינוי ב- DATA בטבלאות, המנגנון שומר את הנתון הישן והחדש + מי שינה ומתי וכו'...

8. תמיכה ב- data type מסוג blob .

9. שיפורים בנושאי אבטחה:
a. שיפור בניהול המפתחות לבסיסי נתונים מוצפנים.
b. הצפנה ברמת בסיס הנתונים כולו – ניתן לבצע שחזור לבסיס נתונים או ביצוע attach רק עם מפתח.
c. הפרדת המפתחות מה- DATA (בשונה מ- 2005)

10. Enhanced auditing – מנגנון מובנה לניטור כל הפעילויות בבסיס הנתונים.
כל שליפה (מי שלף, מה, מתי , מאיפה) , עדכון, מחיקה נשמרת הפעולה בטבלת LOG.

11. Mirroring :
a. שיפור התעבורה ברשת ב- 250%
b. תיקון page דפוקים מהשרת המשני – אוטומטי – פתרון מעולה ל- corruption .

12. יכולת עבודה מול בסיסי נתונים גדולים:
דחיסת מידע ברמת ה- page ב- 60% ויותר.
Data type מקומפרסים (vardecimal)

13. Filtered indexes – יצירת אינדקס עם where !! יחזיק מידע מוגבל – משפר ביצועים, מקטין אינדקסים.

בהצלחה !

הגנת קבצי גיבוי

שאלה:
אחת הבעיות של מנהלי בסיסי נתונים ומנהלי אבטחת המידע בארגון הינו שמירת קבצי הגיבויי של בסיסי הנתונים.
אנו מנהלי בסיסי הנתונים מגנים על השרת , הרשת ובסיסי הנתונים ע"י סיסמאות fire wall וכו'... אך ידוע שכאשר מגבים את בסיס הנתונים לקובץ גיבוי , אין בעיה לשחזר את קובץ הגיבוי לשרתים אחרים (כמובן לפי מגבלות הגרסאות).
יתר על זאת, ישנם מוצרי צד שלישי אשר מאפשרים גיבוי עם כיווץ של בסיסי הנתונים כך שאפילו בסיסי נתונים גדולים , ניתן להעתיק בקלות את קובץ הגיבוי שלהם \ לצרוב לדיסק ולשחזר במקום אחר בקלות ובמהירות.
כיצד ניתן להתמודד עם בעיית האבטחה החמורה הזו?

תשובה:
ישנם מספר פתרונות על-מנת להגן על קבצי הגיבוי של בסיס הנתונים:

1. גיבוי עם סיסמה: היכולת הבסיסית הינה ביצוע גיבוי עם סיסמה. כך שניתן לבצע שחזור לקובץ הגיבוי רק עם הזנת סיסמה.

2. הצפנה – לצערנו במידה ונשתמש ביכולת של גיבוי עם סיסמה גורמים הרוצים לפצח את הסיסמה של הקבצים ימצאו דרך לעשות זאת, על-כן מומלץ להגן על הגיבויים בדרכים נוספות – כגון: הצפנה !
ישנם מוצרי צד שלישי לדוגמא ה- HyperBac אשר מאפשרים בין היתר ביצוע גיבוי והצפנת קבצי הגיבוי (128, 192 or 256 bit) .
הצפנת קבצי הגיבוי מגינה על קבצי הגיבוי, כך שביצוע השחזור ניתן רק בעזרת KEY , על-כן, גם במקרה וקובץ הגיבוי יגיע לידיים הלא נכונות לא יהיה ניתן לבצע שחזור.

לפרטים נוספים: http://www.veracity-group.com/content.asp?id=154


עצות נוספות להגנה על קבצי הגיבוי :
· גורמים הרוצים לפצח את הסיסמה של הקבצים ימצאו דרך לעשות זאת, על-כן מומלץ להגן על הגיבויים בדרכים נוספות – כגון: הצפנה !
· יש לשמור את קבצי הגיבוי במקום מאובטח ברשת .
· יש לוודא כי רק הגורמים המורשים מבצעים את הגיבויים.
· יש לשמור את סיסמאות הגיבויים במקום מאובטח. אין אפשרות לשחזר קבצים הנעולים עם סיסמה ללא סיסמה !
· סקר אבטחת מידע : ביצוע סקר אבטחת מידע לבסיסי הנתונים, הסקר יכלול בדיקות מקיפות במספר רמות ונושאים. בתחום בסיסי הנתונים.


לפרטים נוספים בנוגע לעצות בנושאי אבטחת בסיס הנתונים וסקר אבטחת המידע ניתן לפנות לצוות היועצים הבכירים של קבוצת וראסיטי : support@veracity-group.com.


בהצלחה !

בדיקת קבצי גיבוי

בעיה :
יש לי קובץ גיבוי, כיצד ניתן לבדוק האם הקובץ תקין מבלי לשחזר אותו ?


פתרון:
MS-SQL 2005 מציע למנהל בסיס הנתונים מספר פקודות לבדיקת קובץ הגיבוי, להלן חלקם:

· VERIFYONLY
בדיקה האם ניתן לשחזר את הקובץ כמו שהוא או שהוא חלק מ- media set (ועוד מספר בדיקות כגון Checksum ו- sufficient space).
לפרטים נוספים:
http://msdn2.microsoft.com/en-us/library/ms188902.aspx


· HEADERONLY
הצגת פירוט הגיבויים בתוך הקובץ.
לפרטים נוספים:
http://technet.microsoft.com/en-us/library/ms178536.aspx


· LABELONLY
בדיקת קבצי הגיבוי במידה ומדובר ב- media set.
לפרטים נוספים:
http://technet.microsoft.com/en-us/library/ms186268.aspx


· FILELISTONLY
הצגת תוכן הגיבוי (קבצי ה- mdf וה- ldf ) כפי שהם היו בשרת המקור .
לפרטים נוספים:
http://msdn2.microsoft.com/en-us/library/ms173778.aspx


בהצלחה !!