החדשות הטובות הן שהתוכנית הזאת לא דורשת צוות טכני גדול. היא דורשת כמה החלטות שמקבלים מראש, כשהאתר עדיין עובד והלחץ עדיין לא כאן. המדריך הזה מתאים לבעלי אתרים קטנים ובינוניים, בלי קשר לפלטפורמה, והוא מתמקד במה שכדאי להבין ולבדוק, ולא בהוראות לכלי מסוים.
מה בעצם צריך לגבות
אתר הוא לא קובץ אחד. באתר שבנוי על מערכת ניהול תוכן, כמו וורדפרס, יש בדרך כלל שני חלקים שונים: קבצים, כמו תבנית, תוספים ותמונות, ובסיס נתונים שמחזיק את הפוסטים, העמודים, ההגדרות והתגובות. גיבוי של רק אחד מהם הוא חצי גיבוי. קבצים בלי בסיס נתונים מחזירים אתר ריק, ובסיס נתונים בלי התמונות מחזיר טקסט בלי תמונות.
יש גם דברים שלא נמצאים בתוך האתר בכלל, ובכל זאת בלעדיהם אי אפשר להחזיר אותו: פרטי הגישה לחשבון האחסון, פרטי רשם הדומיין, הגדרות ה-DNS, חשבון הדואר שאליו נשלחים חידושים וחשבוניות, והגדרות של שירותים חיצוניים כמו טפסים או תשלומים. מומלץ לרכז את כל אלה ברשימה מסודרת, ולשמור את הסיסמאות במנהל סיסמאות ולא בקובץ פתוח.
מי שמנהל כמה אתרים, או רוצה לעקוב אחרי שינויים בפלטפורמות ובכלים, ימצא חדשות ומדריכים לבעלי אתרים בעברית, בנושאים כמו חיפוש ותנועה, הכנסות ופלטפורמות. אבל את הרשימה של האתר שלכם רק אתם יכולים להכין.
כלל 3-2-1, והתוספת שהופכת אותו לאמיתי
כלל אצבע מוכר בתחום הגיבויים הוא 3-2-1: לפחות שלושה עותקים של המידע, על שני התקנים או אמצעי אחסון שונים, ואחד מהם מחוץ למקום הרגיל. המרכז הלאומי לאבטחת סייבר של בריטניה (NCSC) מזכיר את הכלל הזה בפוסט שלו על גיבויים לא מקוונים מאוגוסט 2019, ומוסיף אזהרה חשובה: הכלל מגן מפני תקלה מקומית, אבל הוא לא מחייב שאף עותק יהיה מנותק.
למה זה משנה? לפי אותו פוסט, ה-NCSC נתקל במקרים שבהם תוכנת כופר הצפינה לא רק את המידע המקורי, אלא גם כוננים חיצוניים ואחסון רשת שהיו מחוברים, ואף גיבויים בענן שהיו מחוברים לאותה מערכת. גיבוי שנגיש באותה סיסמה ומאותו מקום כמו האתר עלול ליפול יחד איתו. לכן ההמלצה היא להחזיק לפחות עותק אחד מנותק או מבודד, כזה שתקלה אחת לא יכולה להגיע אליו.
בפועל, לבעל אתר קטן זה יכול להיראות כך, לדוגמה בלבד: גיבוי אוטומטי יומי אצל חברת האחסון, עותק שבועי שנשמר בשירות אחסון נפרד עם סיסמה אחרת, ועותק חודשי שמורד למחשב או לכונן שמנותק רוב הזמן. שלושה עותקים, בשני מקומות לפחות, ואחד מהם לא זמין לתוקף שהשתלט על חשבון האחסון.
הגיבוי של חברת האחסון: נוח, אבל לא מספיק
רוב חברות האחסון מציעות גיבוי, ולפעמים הוא כלול במחיר. זה שימושי מאוד ליום יום, למשל כשעדכון של תוסף שבר את האתר ורוצים לחזור לגרסה הקודמת של האתר. אבל כדאי לברר כמה דברים לפני שסומכים עליו לבד: כמה זמן נשמרים הגיבויים, האם הם נשמרים על אותו שרת או במקום אחר, האם השחזור דורש פנייה לתמיכה, והאם יש עלות לשחזור.
השאלה החשובה ביותר היא מה קורה אם החשבון עצמו נעלם. אם האחסון הושעה, אם החברה נסגרה או אם מישהו השתלט על החשבון, גיבוי שנמצא רק בתוך אותו חשבון לא יעזור. זו בדיוק הסיבה לעותק הנפרד.
יש גם עניין של זמן. גיבוי שנשמר שבעה ימים לא יעזור אם הפריצה התרחשה לפני שלושה שבועות והתגלתה רק עכשיו. לכן כדאי לשמור גם עותקים ישנים יותר, ולא רק את האחרון. ה-NCSC ממליץ להשתמש בגרסאות ובשחזור של מידע שנמחק, כשהספק מאפשר זאת, כדי לחזור למצב האחרון שבו הכול היה תקין.
שתי שאלות שקובעות כל כמה זמן לגבות
אין תדירות גיבוי אחת שמתאימה לכל אתר. במקום לנחש, כדאי לענות על שתי שאלות. הראשונה: כמה עבודה אתם מוכנים לאבד? אתר תדמית שמתעדכן פעם בחודש יכול להסתפק בגיבוי שבועי, אבל חנות שמקבלת הזמנות כל יום, או בלוג שמתפרסמים בו כמה פוסטים בשבוע, יאבדו הרבה יותר אם הגיבוי האחרון ישן.
השאלה השנייה: כמה זמן האתר יכול להיות למטה? לאתר שהוא כרטיס ביקור, יומיים בלי אתר הם אי נוחות. לאתר שהוא מקור ההכנסה, גם כמה שעות הן הפסד. התשובה הזאת קובעת אם מספיק גיבוי שמחזירים לבד בסוף שבוע, או שצריך גם מישהו זמין שיודע לעשות את זה מהר.
כשהתשובות כתובות, קל יותר לבחור כלי ולבדוק אם הגיבוי הקיים בכלל עונה עליהן. ומי שכבר איבד קבצים יודע שהשאלה היא לא רק טכנית. בכתבה על מה באמת קורה כשקבצים נעלמים יש רקע על הצד של שחזור מידע מהתקנים.
תרגול שחזור: השעה הכי חשובה בשנה
כאן נמצא ההבדל בין גיבוי לתוכנית. ה-NCSC מדגיש שגיבויים צריך ליצור לעיתים קרובות, ולבדוק באופן קבוע שהם עובדים כמצופה. גיבוי שמעולם לא שוחזר הוא הנחה, לא עובדה.
תרגול פשוט לא חייב לגעת באתר החי. אפשר לשחזר את הגיבוי לסביבת בדיקה, לדומיין משנה זמני או למחשב מקומי, ולבדוק שלוש שאלות: האם האתר עולה? האם התוכן, התמונות והקישורים הפנימיים במקום? וכמה זמן לקח כל התהליך? את התשובה לשאלה האחרונה כדאי לרשום, כי היא מה שתגידו ללקוחות או לקוראים ביום אמת.
תוך כדי התרגול כדאי לכתוב מסמך שחזור קצר. לא מסמך טכני ארוך, אלא רשימת צעדים בסדר הנכון: איפה הגיבויים, איך נכנסים לכל חשבון, באיזה סדר משחזרים, ומה בודקים בסוף. ביום של תקלה, גם בעל אתר מנוסה חושב פחות טוב. רשימה שנכתבה מראש עושה חלק מהחשיבה במקומו.
אחרי פריצה: לא לשחזר לפני שמבינים
כשאתר נפרץ, הדחף הטבעי הוא להחזיר מיד את הגיבוי האחרון. לפעמים זו טעות. אם הפורץ נכנס דרך תוסף פגיע או סיסמה חלשה, שחזור מהיר מחזיר את האתר יחד עם אותה פרצה, ולעיתים גם עם קוד זדוני שהושתל לפני שהגיבוי נלקח.
סדר עדיף הוא להחליף קודם סיסמאות לכל החשבונות הרלוונטיים, לזהות ככל האפשר איך התרחשה הפריצה ומתי, לבחור גיבוי מלפני המועד הזה, ולעדכן את כל הרכיבים לפני שהאתר חוזר לאוויר. בעלי עסקים יכולים להרחיב על הצד הארגוני של ההתגוננות בכתבה על איומי הסייבר על עסקים בישראל. כשמדובר באתר שמחזיק מידע של לקוחות, כדאי לפנות גם לאיש מקצוע, כי ייתכן שיש חובות נוספות מעבר להחזרת האתר.
תוכנית של עמוד אחד
אם צריך לסכם את כל זה במקום אחד, זה יכול להיות עמוד בודד שמודפס או שמור מחוץ לאתר:
- מה מגבים: קבצים, בסיס נתונים, ורשימת חשבונות וגישות.
- איפה: לפחות שלושה עותקים, בשני מקומות, ואחד מנותק או מבודד.
- כמה זמן: עותקים יומיים לטווח קצר, ועותקים ישנים יותר לטווח ארוך.
- מתי בודקים: תרגול שחזור קבוע, לפחות פעם ברבעון או אחרי כל שינוי גדול באתר.
- מה עושים ביום תקלה: רשימת הצעדים, בסדר, עם מי שאחראי על כל אחד מהם.
אף תוכנית לא מבטיחה שלא יקרה כלום. אבל אתר עם גיבוי שנבדק וצעדים שנכתבו מראש הופך משבר לעבודה של כמה שעות, במקום ימים של ניחושים. ההשקעה היא כמה שעות בשנה, והיא מחזירה את עצמה בפעם הראשונה שמשהו משתבש.
לכתבות נוספות במדור אינטרנט.
