מעבר אחסון נשמע מפחיד יותר ממה שהוא באמת, אבל הרוב המכריע של זמני ההשבתה במעבר נובעים מאותה טעות אחת: מעבירים את התנועה לשרת החדש לפני שווידאו שהוא עובד. כשעושים את זה בסדר הנכון, האתר ממשיך לרוץ על השרת הישן בזמן שבונים ובודקים את החדש, והמעבר עצמו הוא רגע שקוף לחלוטין למבקרים. המאמר הזה מסביר את התהליך שלב אחר שלב.
למה בכלל מעבירים אתר
הסיבות הנפוצות למעבר אחסון חוזרות על עצמן:
- ביצועים - האתר איטי, השרת חלש או עמוס, וזמני הטעינה פוגעים בחוויה ובדירוג.
- יציבות וזמינות - נפילות חוזרות, תמיכה שלא עונה, או חבילה שכבר לא מתאימה לנפח התנועה.
- אבטחה ותחזוקה - מעבר מאחסון בסיסי לאחסון מנוהל, שכולל גיבויים, ניטור ועדכוני אבטחה כחלק מהשירות.
- עלות - שדרוג או הוזלה, או איחוד כמה אתרים תחת חשבון אחד.
לא משנה מה הסיבה, הכללים זהים. המטרה היא להעביר את האתר במלואו, לוודא שהוא זהה לחלוטין לפני המעבר, ורק אז להחליף את היעד שאליו פונה הדומיין.
העיקרון שמונע downtime: שני שרתים במקביל
הטעות הקלאסית היא לחשוב על מעבר כעל "כיבוי כאן, הדלקה שם". זו בדיוק הגישה שיוצרת השבתה. הגישה הנכונה היא לבנות את האתר במלואו על השרת החדש בזמן שהשרת הישן עדיין משרת את כל התנועה. רק כשהעותק החדש נבדק ועובד בצורה מושלמת, מפנים אליו את הדומיין.
המשמעות המעשית: בכל שלב של המעבר יש אתר חי שעובד. אם משהו משתבש בשרת החדש, פשוט לא ממשיכים, והמבקרים אפילו לא יודעים שהיה תהליך ברקע.
התהליך שלב אחר שלב
1. גיבוי מלא של המצב הקיים
לפני שנוגעים בכלום, לוקחים גיבוי מלא ועדכני של האתר הישן: כל הקבצים (ליבה, תוספים, ערכת עיצוב, ספריית המדיה) ובסיס הנתונים המלא. זו רשת הביטחון. אם משהו ישתבש בהמשך, אפשר תמיד לחזור לנקודה הזו. אם אין לכם עדיין מנגנון גיבוי אמין, זו ההזדמנות לסדר אותו, ולא רק לקראת המעבר. הסברנו את העקרונות במדריך גיבוי אוטומטי לוורדפרס.
2. הכנת השרת החדש
מקימים את סביבת האחסון החדשה: מסד נתונים ריק, משתמש וסיסמה, וגרסת PHP שתואמת לאתר. כדאי שגרסת ה-PHP בשרת החדש תהיה זהה או חדשה מזו שבשרת הישן, כדי למנוע הפתעות תאימות עם תוספים. בשלב הזה השרת החדש עדיין ריק, ואף אחד לא פונה אליו.
3. העברת הקבצים ובסיס הנתונים
מעבירים את הגיבוי לשרת החדש: מעלים את כל הקבצים, מייבאים את בסיס הנתונים, ומעדכנים את קובץ ההגדרות (wp-config.php) עם פרטי בסיס הנתונים החדש. אפשר לעשות את זה ידנית, או בעזרת תוסף העברה ייעודי כמו Duplicator, All-in-One WP Migration או WP Migrate, שמקל מאוד על התהליך עבור אתרים בגודל בינוני.
4. בדיקה על השרת החדש לפני שמפנים תנועה
זה השלב הקריטי, וזה מה שמבדיל מעבר מקצועי ממעבר חובבני. בודקים את העותק החדש בלי לגעת בדומיין הציבורי. שתי דרכים נפוצות:
- קובץ hosts מקומי - מפנים את הדומיין לכתובת ה-IP של השרת החדש במחשב שלכם בלבד. כך אתם רואים את האתר על השרת החדש בדיוק כפי שיראו אותו המבקרים, בעוד כל שאר העולם עדיין מקבל את השרת הישן.
- כתובת זמנית - חלק מספקי האחסון נותנים כתובת בדיקה זמנית או תת-דומיין לתצוגה מקדימה.
בבדיקה עוברים על העמודים המרכזיים, הטפסים, תהליך הרכישה (אם זו חנות), התחברות לניהול, והקישורים הפנימיים. מוודאים שאין שגיאות, שהתמונות נטענות, ושמסד הנתונים שלם.
5. הורדת ה-TTL והפניית ה-DNS
DNS הוא מערכת השמות שמתרגמת את הדומיין לכתובת השרת. לכל רשומת DNS יש ערך TTL (Time To Live) שקובע כמה זמן שרתים ברחבי העולם שומרים את הערך במטמון לפני שהם בודקים שוב. יום-יומיים לפני המעבר מורידים את ה-TTL לערך נמוך (למשל 300 שניות). כך, כשמשנים את הרשומה בפועל, השינוי מתפשט במהירות במקום להיתקע במטמון לשעות.
ביום המעבר מעדכנים את רשומת ה-A (או ה-CNAME) כך שתפנה לשרת החדש. מרגע זה התנועה החדשה מתחילה לזרום לשרת החדש.
6. תקופת חפיפה: השאירו את השרת הישן חי
כאן נכנס סוד שמרבים לפספס. עדכון DNS לא קורה בו-זמנית לכל העולם. ספקי אינטרנט ושרתי DNS שונים מתעדכנים בקצב שונה, וההתפשטות המלאה יכולה לקחת בין כמה דקות לכמה שעות, לעיתים עד 24 שעות. בתקופת הביניים הזו, חלק מהמבקרים עדיין יגיעו לשרת הישן וחלק כבר לשרת החדש.
לכן השרת הישן חייב להישאר חי ופעיל לפחות 24 עד 48 שעות אחרי המעבר. אם תכבו אותו מיד, מי שעדיין מצביע עליו יקבל אתר מת. כל עוד שני השרתים מציגים אותו תוכן, החפיפה שקופה לחלוטין.
נקודה חשובה לחנויות ולאתרים עם טפסים: בתקופת החפיפה ייתכן שהזמנות או פניות ייכתבו בשני השרתים בנפרד. בחנות פעילה כדאי לתזמן את המעבר לשעה שקטה, ואחרי שההתפשטות הושלמה לוודא שלא נשארו הזמנות שנכתבו רק על השרת הישן.
7. אימות סופי וניקיון
אחרי שההתפשטות הושלמה, מוודאים שכל התנועה מגיעה לשרת החדש, שתעודת ה-SSL פעילה (https עם מנעול תקין), ושאין שגיאות בלוגים. רק אחרי שהכל יציב במשך יום-יומיים אפשר לסגור את השרת הישן. כדאי גם להעלות את ה-TTL בחזרה לערך רגיל.
טעויות נפוצות שגורמות להשבתה
- כיבוי השרת הישן מוקדם מדי - הסיבה מספר אחת להשבתה במעבר. תמיד להשאיר חפיפה.
- דילוג על שלב הבדיקה - מפנים DNS ורק אז מגלים שהאתר שבור על השרת החדש. אז כבר כולם רואים אתר תקול.
- שכחת תעודת ה-SSL - מעבירים את האתר אבל לא מתקינים SSL בשרת החדש, והמבקרים מקבלים אזהרת אבטחה.
- TTL גבוה - אם לא הורידו אותו מראש, ההתפשטות נתקעת לשעות ארוכות ומאריכה את חוסר הוודאות.
- התעלמות מהבדלי גרסאות - גרסת PHP או מסד נתונים שונה בשרת החדש שוברת תוספים ותיקח לכם זמן לאתר את הסיבה.
למתי מעבר אחסון הוא חלק מתמונה רחבה יותר
לעיתים הצורך במעבר הוא תסמין ולא הבעיה עצמה. אם האתר איטי באופן כרוני, מעבר לשרת מהיר יותר יעזור, אבל רק אם גם מטפלים בגורמים שבתוך האתר. ואם המעבר נכפה עליכם כי חברת האחסון השביתה את האתר בגלל וירוס, חשוב לנקות את האתר לפני ההעברה, אחרת פשוט מעבירים את הקוד הזדוני לשרת החדש יחד עם השאר.
מעבר מסודר כחלק מאחריות 360
אצלנו ב-OCW, מעבר אחסון הוא חלק מהתחזוקה השוטפת בחבילת אחריות 360, לצד אבטחה, נגישות, פרטיות ותחזוקה טכנית. אנחנו בונים את העותק החדש במקביל, בודקים אותו מקצה לקצה לפני שנוגעים בדומיין, מנהלים את ההתפשטות עם חפיפה מבוקרת, ומוודאים SSL ויציבות לפני סגירת השרת הישן. אם אתם שוקלים מעבר אחסון, או שכבר נכפה עליכם מעבר ואתם רוצים שייעשה בלי השבתה, צרו קשר ונתכנן אותו יחד. הקשר בין מעבר לבין תחזוקה שוטפת מוסבר במדריך תחזוקת וורדפרס - מה כלול וכמה עולה.
שאלות נפוצות
כמה זמן לוקח מעבר אתר וורדפרס?
העבודה עצמה, גיבוי, העברה ובדיקה, לוקחת בדרך כלל בין כמה שעות ליום עבודה, תלוי בגודל האתר. התפשטות ה-DNS עצמה יכולה לקחת בין כמה דקות לעד 24 שעות, אך בזכות תקופת החפיפה היא אינה גורמת להשבתה.
האם המבקרים ירגישו במעבר?
לא, אם עושים אותו נכון. כל עוד השרת הישן נשאר פעיל בזמן ההתפשטות ושני השרתים מציגים אותו תוכן, המעבר שקוף לחלוטין למבקרים.
מה זה TTL ולמה צריך להוריד אותו?
TTL הוא משך הזמן ששרתים שומרים את רשומת ה-DNS במטמון לפני שהם בודקים שוב. הורדתו מראש לערך נמוך גורמת לשינוי הכתובת להתפשט מהר, ומקצרת את חלון אי-הוודאות של המעבר.
מה עושים אם האתר נפרץ לפני המעבר?
מנקים אותו לפני ההעברה. מעבר של אתר נגוע פשוט מעתיק את הקוד הזדוני לשרת החדש. כדאי גם להעביר רק גיבוי נקי ולא להעתיק עיוור את הקיים.