חברת שיבר

האם ADSL הוא אכן "אינטנרט מהיר"

לא אחת אנו מקבלים תלונות מלקוחותינו המחוברים ב ADSL – על אינטרנט (גלישה) איטי ו/או על השהיות בקבלת ושליחת מיילים. מעבר לסיבות (שהיום – אני מקווה – כבר מקובל על כולם שהן נפוצות) כגון: תקלות ספק אינטרנט, עומס אינטרנט "כלל ארצי", מתקפת וירוסים, מתקפת האקרים, התקנות קאזה וכו' – יש סיבה מאוד מהותית והיא נמצאת בבסיס טכנולוגיית ה ADSL והיא: האסימטריות של הקוו (וזה – אגב – ה A של ראשי התיבות ADSL).
מצ"ב כמה מילים שכתב סמנכ'ל הטכנולוגיות שלנו (זאב שניידר) המסבירות נושא זה:

"הבעיה מתעוררת במיוחד כאשר המשתמשים שולחים מהארגון דוא"ל בתפוצה ואז ה uplink חוסם את ב downlink.
ניתוח תרחיש דוגמא: קובץ word של 500K (שזה גודל של מסמך בן מספר דפים מלאים ועם לוגו החברה על כל דף) שנשלח ל 20 אנשים , זה 10MB שיעברו ב uplink של 96Kbit/sec (זה רוחב הפס היוצא) שזה בערך 720KByte/min כלומר במשך יותר מ 14 דקות הקו עסוק רק ב upload וה download מנוטרל (לא נכנס דואר ואין גלישה !) בגלל האסימטריות של הקו.
ברוב המקרים הבעיות ב ADSL נובעות כתוצאה מה "פיקים" כאלה ב uplink , דמיינו עכשיו 10 משתמשים שבמשך יום עבודה שולחים הודעה אחת בלבד מסוג זה (דהינו: בתפוצה כנ'ל), כבר 140 דקות (כשעתיים וחצי שהארגון סובל מאיטיות בגלישה) ועם יש יותר מ 10 כאלה … או אחד ששולח 10 פעמים אותו סירטון של 2MB …
צריך להבין שבמקרה של רשימת תפוצה ההודעה מוכפלת בכמות הנמענים החיצוניים מכיוון שהשרת יוצר session עם כל שרת של הנמען בנפרד ובכל פעם שהמייל לא עובר במלואו (מכל סיבה שהיא) הוא חוזר לתור ונשלח שוב !"

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

אם נתיחס לדוגמא של זאב שבה לקח 140 דקות לדואר לצאת, הרי שבפתרון משולב ISDN יקח לאותו דואר כ 100 דקות (כשעה וחצי) !

ועוד כמה מילים ל"טכנולוגיים" שבינכם:

יש עוד פתרון וזה ע"י הפעלת smart host , דהינו: העברת המיילים לשרת הדואר של הספק יחד עם רשימת התפוצה, אבל…. בפועל נוצרת תלות בשרת הדואר של הספק ולמרות שאף ספק לא יודה בכך – במציאות השרתים הללו לא עובדים ברמת שרות אחידה, רציפה וגבוהה והתוצאה היא שמיילים – לפעמים – לא מגיעים ללקוחות או מגיעים באיחור רב וכל זה ללא יכולת שליטה שלנו (או של הלקוח) על התעבורה הזאת, שכן היא – כאמור – מתנהלת בשרת הדואר של הספק.

האומנם הכול מגובה?

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

להלן כמה תרחישים בהם מתקיים הכשל הזה:

1.בשרת אין תוכנת דואר (כגון exchange) והמשתמשים עובדים מול התיבות שלהם אצל ספק האינטרנט ומורידים (למשל ל outlook) את הדואר.
במצב זה כל הנתונים שב outlook אינם מגובים (מיילים, יומני פגישות, ספר טלפונים..) והם נשמרים בתחנה אצל כל אחד.
אז מה הפתרון?, אז זהו… שאין פתרון..
אפשר – תיאורטית – להגדיר ב outlook שקבציו ישמרו בשרת ולא בתחנה, אלא שבפועל זה לא עובד טוב ויציב.
אפשר "ללמד" את המשתמש להעתיק/לגבות את קבצי ה outlook לשרת לצורך גיבוי כל יום, אבל גם זה לא ממש עובד, הן בגלל שהעובד "מחפף" והן בגלל שלעיתים הקבצים "פתוחים" ולא ניתן לגבותם.
אפשר להשתמש בתוכנות גיבוי שיגבו מהתחנות לשרת, אבל מעבר לעלויות הרכישה והתחזוקה – גם כאן יהיו בעיות של קבצים פתוחים.
ישנם עוד רעיונות "יצירתיים" לפתרון, אבל בשורה התחתונה – אין פתרון אמין, יציב ולא תלוי אדם.

2.בשרת יש תוכנת דואר ויש תהליך גיבוי מסודר, אבל למשתמש הוגדר גם personal folder.
הגדרה כזאת אינה "טבעית" ואנו מוצאים אותה במקומות בהם המשתמש לא רוצה שמידע מסוים ישב בשרת, חשוב להבין ולהבהיר למשתמש כי חומר זה אינו מגובה (ולא ניתן לגיבוי אמין ומוסדר – ראה סעיף קודם) שכן הוא נשמר בתחנה.

3.טעויות הגדרה, כגון :
יש exchange אבל המשתמשים מוגדרים מולו ב pop3 (ולכן החומר נשמר בתחנה ולא בשרת).
יש exchange ותוכנת גיבוי, אבל אין לתוכנת הגיבוי agent for exchange.
יש exchange ותוכנת גיבוי עם agent for exchange , אבל לא הוגדר לגבות גם ברמת break level.
יום א' לא מגובה אף פעם – זה "קוריוז" שנובע מכך שתוכנות הגיבוי נוצרו אצל הגויים ושם לא עובדים בימי א'…., כמובן שניתן לתקן את ההגדרה.
ואלו רק חלק מהדוגמאות.

4.תוכנות "לווין" בארגון – תוכנות המותקנות בתחנה ולא בשרת ומשמשות את המשתמש בלבד (למשל "מכפל" להכנת משכורות), בד"כ הארגון מסתמך על נהלי הגיבוי שהגיעו עם התוכנה (בד"כ גיבוי לדיסקטים – למי שעוד זוכר מה זה דיסקטים…) ועל המשתמש – וזה רע….
הפתרון הוא פשוט: העברת הקבצים להיות ע"ג השרת (תוך הטמעת נהלי אבטחת נתונים – במידת הצורך), הגדרת התוכנה בהתאם והפעלת agent for open file בגיבוי.
כל פתרון אחר (גיבוי ל flash, צריבה וכו') שבד"כ מציעים אותו על רקע של אבטחת נתונים (חשש לשמור חומר רגיש בשרת) – הוא חד משמעית פחות טוב, שכן הוא נסמך על המשתמש – ויותר גרוע מזה לא יכול להיות …

5.מידע "רגיש" – נתונים שנוצרו בתוכנות "רגילות" (word, excel וכו') אבל יש רגישות לשמירתם על השרת (חשש לשמור חומר רגיש בשרת):
אני אצטט מה שכתבתי בסעיף למעלה:
כל פתרון אחר (גיבוי ל flash, צריבה וכו') שבד"כ מציעים אותו על רקע של אבטחת נתונים (חשש לשמור חומר רגיש בשרת) – הוא חד משמעית פחות טוב, שכן הוא נסמך על המשתמש – ויותר גרוע מזה לא יכול להיות …

6.תוכנות בסיסי נתונים כגון SQL – גם כאן דרוש לתוכנת הגיבוי agent for SQL (למשל) ובלעדיו בלתי אפשרי לשחזר את הנתונים.
(ניתן "לעקוף" את הצורך ב agent וזאת ע"י הפעלת האפשרות ב SQL לגבות את הנתונים לקובץ "בצד").

7.תוכנות עם נתונים בשרת שנשארות "פתוחות": בין עם מדובר בתוכנות המותקנות בשרת (למשל חשבשבת DOS) ובין עם בתוכנות המותקנות בתחנה אך שומרות את המידע בשרת (word, excel וכו') – במידה והמשתמשים לא סוגרים את הקובץ ואת התוכנה עצמה , הקובץ "פתוח" ולא יגובה.
כשזה קורה "פה ושם" אין מה להתייחס, אבל כשזה ע"ב קבוע ואותו משתמש תמיד שוכח לסגור את הקובץ, אני מציע לא לנסות "לחנך" את המשתמש ופשוט לקנות לתוכנת הגיבוי את מודול ה agent for open file.

8.גיבוי סלקטיבי – לא מגבים את כל השרת, אלא מגדירים מחיצות וקבצים מסוימים, אנו נתקלים בזה בד"כ במקומות בהם הטייפ קטן מלהכיל את כל הנתונים וללקוח יש מגבלה תקציבית להחליף את הטיפ לגדול יותר.
תצורת גיבוי זאת רעה וזה ברור, כל פתרון "יצירתי" (כגון: יצירת "מחיצת על" שרק תחתיה יפתחו המחיצות הדורשות גיבוי) סופו להיכשל כי הוא תלוי אדם.

ולסיום ובפעם האלף – לגבות לקלטות ולשים את הקלטות במגרה, מעיד עליכם שאתם אופטימיים חסרי תקנה ומאמינים ששרפות וגניבות קורים לאחרים ולא לכם…

תוכנות שיתוף קבצים

לכל משתמשי קזה, מסנג'ר ושאר התוכנות השיתופיות

לא אחת עובדינו נתקלים בהתקנות של תוכנות אלו אצל לקוחותינו השונים, בהתאם להנחייתנו עובדינו מנסים "בעדינות" לשכנע את הלקוח להסיר את התוכנות אבל לצערי

לא תמיד מקבלים אישור לכך.
מעבר לעומס המזעזע (!) שהתוכנות הללו יוצרות ברשת הפנימית וביציאה לאינטרנט (עומס שקשה מאוד לעמוד על סיבתו – בבואנו לבדוק רשת שהתקבלה תלונה לגביה שהיא "איטית")

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

ואחרון חביב: הם כר פורה לוירוסים המיוחדים להם והפורצים מהם לכל שאר המערכות.

חבילת אבטחת הנתונים ה"נכונה" ללקוחות הקטנים/בינוניים

עם שוך (יותר נכון: כנראה הפוגה בלבד) מתקפת הוירוסים האחרונה – שהוגדרה בעולם כמתקפה ההקשה ביותר אי פעם אני מתפנה להיענות לבקשת חלק ממכם ולהגדיר את חבילת האבטחה האופטימאלית ללקוחותינו, ההדגש במכתב לעיל הוא על נושא האנטי וירוס ועל מגזר הלקוחות הקטן/בינוני בלבד:

1. חברות ה ISP (ספקיות אינטרנט) משווקות שרות אנטי וירוס המפשיט את הוירוסים כבר אצלם ולפני הגעתם לארגון, שרות זה מאפשר להרחיק את קוו החזית הראשון מהלקוח ואני ממליץ בחום רב לרכוש אותו, העלות היא כ 1.5$ לתיבה לחודש, הוא יועד מלכתחילה ללקוחות ללא שרתי דואר בתוך הארגון, אך הוא ניתן היום גם ללקוחות עם שרתים כנ'ל ולעיתים בתמחור שונה.

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

3. החזית הבאה תטפל בנושא האנטי וירוס ואנטי ספאם, עד למתקפה האחרונה לא הייתה מניעה להתקין את המוצרים המתאימים על אחד משרתי הארגון ה"רגילים" ובד"כ ההתקנה הייתה מתבצעת על שרת הדואר. המתקפה האחרונה טופלה בד"כ היטב ע"י מוצרי האבטחה המותקנים בכל ארגון, אך יצרה עומס גדול מאוד על השרת שעליו הותקנו מוצרי האבטחה – עד למצב שבו השרת לא "התפנה" לבצע את המטלות ה"רגילות" (דואר וכו') ולמעשה פעולות מסוימות בארגון שותקו. כפתרון לכך אנו ממליצים להתקין שרת ייעודי לנושא זה, אין צורך בחומרה יקרה כבשרת "רגיל", אך בוודאי שרצוי חומרה יציבה ואיכותית, מערכת הפעלה לשרת וחבילת מוצרים מתאימה (נורטון, מקאפי ואלדין).
מהחבילות הנ'ל יש להתקין את המודולים שמטפלים ב:
3.1 וירוסים של דואר וספאם – ע"י הפנית הדואר הנכנס אליהם ומהם לשרת הדואר הארגוני SMTP gateway
3.2 וירוסים של אתרי אינטרנט – ע"י הפניית הגלישה אליהם ומהם החוצה web security
3.3 אנטי וירוס לשרת עצמו
3.4 מודול התעדכנות מול אתר חברת התוכנה ודחיפת עדכונים לתחנות ולשרתים האחרים בארגון

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

5. החזית האחרונה (הטכנולוגית..) נמצאת בשרתים ובתחנות שם יש להתקין את מודול האנטי וירוס ולהגדיר התעדכנות מול השרת.

6. ולבסוף: הגורם האנושי, יש לרענן במעגל אין סופי את הנהלים שאוסרים לבצע פעילות שאינה לצרכי העבודה, לא להתקין ולהשתמש בתוכנות שיתופיות כ ICQ, קזה ודומיהם, לא להיכנס לאתרים מפוקפקים, לא לפתוח דואר שנושאו ותוכנו לא צפויים ולא "רגילים" וכו'.

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

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

זהירות – אחיזת עיניים!

אני מבקש לידע אתכם ב"עליית מדרגה" בתחכום מעשי הרמאות הנעשים בכלי האינטרנט.
המדובר בדבר דואר המתחזה בצורה מושלמת להיות דואר של חברת פיננסים/ממשלתית/ביטוחית וכו' – ידועה.
כתובת השולח נראית אותנטית, מבנה הדואר שמתקבל הוא בפורמט הרגיל המתקבל מאותו גוף, לעיתים הדואר הוא בפורמט של HTML וזהה מבחינה העיצוב והגרפיקה לדפי האתר האמיתיים.

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

הישמרו…

האם אתם מוציאים דואר שעלול להראות כדואר זבל

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

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

שיחזור מגיבויים – שווה את הטרחה?

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

1. בעת התקנת הטייפ ו/או התוכנה לראשונה המתקין מבצע גיבוי ושיחזור ניסיוני.

2. אנו מגדירים ביצוע אוטומתי – בסוף כל גיבוי – של פעולת verify, דהינו: בסוף כל (!) גיבוי, התוכנה מסובבת את סרט הגיבוי לאחור ומבצעת קריאה של כל תוכן הסרט עם הגיבוי ומשווה "on line" תוכן זה לעומת המצוי על דיסק המחשב.

3. בסוף כל (!) פעולת גיבוי, נשלח מייל למנהל הרשת ו/או לנו עם לוג הגיבוי ועם הכותרת הצליח/נכשל.

יש להבין כי פעולת השיחזור עושה למעשה פעולה כמעט זהה לפעולת ה verify קריאת הקלטת וכתיבה על הדיסק (במקום להשוות לדיסק), דהינו השיחזור המדגמי מיותר.
ועוד נקודה: באופו טבעי שיחזור מדגמי נעשה מתוך קלטת אחת בלבד ומשחזר כמות קטנה ומדגמית בלבד, אז מה תלמד אותנו הצלחת שיחזור כזה?:
שהקלטת מהתאריך XX/XX/XX אכן מכילה את החומר של המחיצות YYY ולא יותר מזה…., דהינו: עדיין יתכן שחלק מהחומר לא גובה, עדיין יתכן שכל שאר הקלטות לא תקינות, עדיין יתכן שגם אם הכל בסדר מחר תתקלקל קלטת, או לא יגובה חלק מהחומר והרי אף אחד לא מעלה על דעתו לבצע כל יום שיחזור בדיקה של כל החומר….
ולכן לטעמי ובלי לפגוע באף אחד שיחזור מדגמי יש לו ערך אחד בלבד: "כיסויי תחת" לחברות המתחרות לנו והמתהדרות בביצוע פעולה זאת .
למותר לציין שהלקוח תמיד צודק ולקוח שמתעקש לקבל את הבדיקה, יקבל …..

הגיבוי עובד, אבל השחזור?

שלום לכולם,
בהמשך למאמר קודם שכתבתי על חשיבות הגיבויים ועל ההכרח לבדוק שאכן כל החומר החשוב מגובה, אני הפעם מבקש למקד את תשומת הלב בפן השני של הגיבוי השחזור.
אנו נדרשים לשחזור חומר מגיבוי בתרחישים שונים, אבל המטרה העיקרית של הגיבוי זה להיות מסוגלים לשחזר את השרת במהירות ובאמינות – למצבו קודם לאסון.
את המילה "אסון" מגדיר כל עסק לפי רמת ה"היסטריה" שלו, אבל כמדומני שהתרחיש בו השרת כולו "אובד" (נשרף, נגנב, נפגע מברק וכו') הוא התרחיש שכולם יגדירו כ"אסון".

ורבותי, צר לי להיות זה שצריך לבשר לכם – זה אכן אסון….:
תוכנות הגיבוי יודעות לשחזר את השרת למצבו הקודם במהירות ובאמינות רק (!!!!) עם השחזור נעשה לאותו שרת בדיוק !
אני אסביר:

למערכת ההפעלה של מיקרוסופט יש מה שנקרא system state שזה אוסף נתונים של "לב" המערכת שמכיל את המידע על המשתמשים, הרשאות, התוכנות המותקנות וכו', אבל גם את המידע על חומרת השרת (בקרי דיסק, בקרי רשת וכו').
מערכות מידע אלו "קשורות" בינם ללא יכולת "התרה", דהינו : לא ניתן לשחזר את הנתונים של המשתמשים, התוכנות וכו' ללא שיחזור המידע של החומרה.

במילים פשוטות, זה מה שיקרה בעת אסון כנ"ל:
אתם תמהרו ותרכשו או "תגייסו" שרת אחר, עליו תותקן מערכת ההפעלה עם הדריברים לשרת החדש.
כעת תותקן תוכנת הגיבוי ויתחיל תהליך שחזור, אבל……..: אם תשחזרו את ה system state של השרת ה"ישן", בתום השחזור השרת החדש לא "יעלה", שכן שחזרתם גם את הדריברים של השרת הישן ואלו לא מתאימים לחדש.
אם תשחזרו ללא ה system state אין לכם את המידע על המשתמשים, התוכנות, הרשאות וכו' …..
מלכוד 22 …

אז מה עושים ?

חברות גדולות ועם "כיסים עמוקים" משקיעות בפתרונות יקרים להחריד שכוללים למשל – שרת נוסף (ראי) באתר אחר.
חברות בינוניות רוכשות פתרונות ייעודיים לנושא זה שהגדרתו המקצועית היא: bare metal restore , כמו למשל (ויש עוד פתרונות כנ'ל) תוכנת Symantec livestate recovery with restore anywhere option (עלות הפתרון המבוסס על תוכנה זאת + דיסקים לשמירה + עבודה, כ 2500$ + מע"מ).
עוד אפשרות, זה לקבל החלטה של רכש "כפול", דהינו רוכשים שני שרתים זהים לחלוטין, אחד מהם מאוחסן (כבוי) באתר אחר – למקרה אסון (עלות: לפי סוג השרת).
חברות יותר קטנות או "רזות", "מזיקות אצבעות" ומקוות לטוב.
עד כאן "עשיתי לכם שחור", בפועל המצב קצת יותר טוב, בעבודה מאומצת – לעיתים של ימים – ובעזרת תוכנות צד שלישי, אפשר בסופו של דבר לחזור למצב של שרת בתפקוד מלא, אבל בפרוש לא ניתן חד משמעית להבטיח 100% חזרה לתפקוד מלא לחלוטין וללא בעיות עתידיות ובפרוש יתכן שמדובר בזמן רב של עבודה מאומצת (שמעבר לעלותה לכם אתם מושבתים מעבודה כל עוד היא לא הסתימה…).

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

כל הפתרונות הללו לא יכולים להבטיח 100% חזרה לתפקוד מלא ואמין.
ולשאלה שבוודאי ימצא מי שישאל: אם צריך את ה Symantec livestate recovery (או דומים לו), אז בשביל מה צריך גם טייפ גיבוי על כך במייל הבא שכותרתו תהיה:
Multi layer backup