איך להעביר את האתר ל‑Devoster: מדריך שלב אחר שלב

העברת אתר משתבשת באחד משלושה מקומות, ואף אחד מהם אינו העתקת הקבצים. היא משתבשת ב‑DNS, כי רשומה שנשמרה במטמון שולחת גולשים לשרת שכבר רוקנתם. היא משתבשת באימייל, כי דואר הולך אחרי רשומת MX ואף אחד לא בדק אותה. והיא משתבשת בפרטי החיבור למסד הנתונים, כי האתר עלה נראה מושלם ומת ברגע שמישהו ניסה להתחבר.

עשו את זה בסדר הזה ושום דבר מכל אלה לא יקרה: הורידו את ערך ה‑TTL יום מראש, העתיקו הכל בזמן שהאתר הישן ממשיך לרוץ, בדקו את העותק בכתובת זמנית, החליטו מה קורה עם האימייל, ורק אז החליפו DNS. זו כל השיטה. בהמשך כל שלב בפירוט, הפקודות למי שעושה זאת לבד, ופרק כן על המקרים שבהם מעבר אלינו הוא לא ההחלטה הנכונה.

עיקרי הדברים

• הורידו את ה‑TTL ל‑300 שניות לפחות 24 שעות לפני המעבר. הצעד היחיד הזה הוא ההבדל בין החלפה של חמש דקות לבין זנב של יומיים שבהם גולשים עדיין מגיעים לשרת הישן.
• שום דבר לא נמחק מהספק הישן עד שרצתם על החדש שבועיים. המשיכו לשלם עליו, זה הביטוח הזול ביותר בתהליך.
• ההעברה ב‑Devoster חינם, אז אם שורת הפקודה לא נוחה לכם, פתחו פנייה ומסרו את זה במקום לאלתר בחצות.
• אימייל הוא הגירה נפרדת מהאתר. החליטו מראש אם הדואר עובר, נשאר, או עובר לספק ייעודי, כי MX, SPF, DKIM ו‑DMARC כולם דורשים טיפול.
• בדקו בכתובת זמנית או דרך קובץ ה‑hosts לפני שה‑DNS זז. בדיקה שעוברת אחרי המעבר היא לא בדיקה, היא גילוי.
• יש מקרים שבהם אנחנו היעד הלא נכון, בעיקר מידע תחת רגולציה, צורך במיקום באירופה או באסיה, או צוות שרוצה שרת מנוהל. הם מופיעים בפרק לקראת הסוף.

קודם כל, מצאי של חצי שעה

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

פריט	איפה למצוא	למה זה כואב
כל דומיין ותת‑דומיין	לוח הבקרה הישן, ייצוא אזור DNS	תת‑דומיין שכוח של מערכת הזמנות נעלם ברגע המעבר
אזור DNS מלא, לא רק רשומות A	ייצאו את קובץ האזור מספק ה‑DNS הנוכחי	רשומות TXT לאימות דומיין ולאימות דואר הולכות לאיבוד בקלות
גרסת PHP והרחבות	עמוד phpinfo, או לוח הבקרה	תוסף ישן שדורש ענף PHP ישן יקרוס על גרסה חדשה
משימות cron	מדור ה‑cron בלוח הישן	חיוב, גיבוי וייבוא נעצרים בשקט לשבועות
תיבות דואר וגודלן	מדור הדואר בלוח הישן	העתקת שנים עשר ג׳יגה של דואר אורכת הרבה יותר מהאתר
תעודות SSL וסוגן	לוח הבקרה, או המנעול בדפדפן	תעודה בתשלום אינה ניידת כפי שנהוג לחשוב
רשימות היתר של צד שלישי	סולק, ספקי API, ממסר דואר	שירותים שנעולים על כתובת ה‑IP הישנה מפסיקים לעבוד ברגע המעבר
מי שולט בחשבון רשם הדומיין	שאלו מוקדם, לא ביום המעבר	מפתח שעזב ב‑2019 מחזיק בדומיין ולא עונה למיילים

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

שלב 1: בוחרים חבילה שמתאימה לאתר

התאימו את הגודל למה שהאתר הוא, לא למה שאתם מקווים שיהיה. אפשר לעלות דרגה בהמשך תוך דקות, וקנייה מוגזמת ביום הראשון רק עולה כסף שהיה עדיף להשקיע בגיבויים.

אם האתר שלכם הוא	מה לקנות	מחיר התחלה	למה
אתר תדמית, תיק עבודות או בלוג קטן	אחסון שיתופי, Lite	$2.90 לחודש	cPanel, בלי ניהול שרת, מספיק לדפים מקוששים
אתר וורדפרס עמוס יותר או חנות קטנה	אחסון שיתופי, Standard	$5.90 לחודש	יותר זיכרון ומרווח IO לתעבורה מחוברת
אתר וורדפרס שאתם מעדיפים לא לתחזק	וורדפרס מנוהל	ראו עמוד החבילות	הצד הפלטפורמי מטופל עבורכם
אפליקציית Node.js	אחסון Node.js	ראו עמוד החבילות	תמיכה בסביבת ריצה בלי לבנות שרת
כל דבר שדורש root, תוכנה מותאמת או כמה אתרים	VPS מסוג KVM, מ‑Nano ומעלה	$3.49 לחודש	root מלא, בחירת מערכת הפעלה, IPv4 אחת, תעבורה ללא הגבלה בקו 1 Gbps
אחסון ללקוחות שאתם מוכרים	אחסון ריסלר	ראו עמוד החבילות	חשבון נפרד לכל לקוח

שני דברים שכדאי לדעת לפני הבחירה. חיוב שנתי זול יותר לחודש מחיוב חודשי בכל חבילות האחסון השיתופי, אז אם אתם בטוחים, המסלול השנתי משתלם. וחבילות ה‑VPS שלנו אינן מנוהלות: גישת root מלאה על KVM עם מעבדי Intel Xeon Gold 6138 ואחסון NVMe, אבל עדכונים, חומת אש והגדרות שרת האינטרנט הם עליכם. אם המשפט הזה הלחיץ אתכם, קחו אחסון שיתופי. אין פרס על הרצת שרת עצמאית.

שלב 2: מורידים את ה‑TTL יום מראש

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

רשומות ה‑DNS נושאות ערך TTL שאומר לשרתי ההמרה בעולם כמה זמן מותר להם לשמור את התשובה במטמון. אם הערך הוא 86400, שרת שביצע חיפוש שעה לפני המעבר ימשיך לשלוח גולשים לשרת הישן עוד עשרים ושלוש שעות. הורידו ל‑300 שניות ואותו שרת ישכח תוך חמש דקות.

dig +noall +answer example.com
dig +noall +answer www.example.com

המספר שאחרי שם הדומיין הוא ה‑TTL בשניות. היכנסו לספק ה‑DNS, הגדירו 300 לרשומות A, AAAA, CNAME ו‑MX שאתם מתכננים לשנות, וחכו לפחות את משך ה‑TTL הישן לפני המעבר. אם הערך הישן היה יממה, מחכים יממה.

שלב 3: מעתיקים בזמן שהאתר הישן חי

אפשרות א: להעביר את זה אלינו

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

שום דבר באתר החי לא משתנה בזמן הזה. העותק רץ במקביל למקור, ואתם מאשרים את התוצאה לפני שה‑DNS זז.

אפשרות ב: לעשות את זה לבד

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

mysqldump --single-transaction --quick -u DBUSER -p DBNAME > site.sql
gzip site.sql

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

rsync -avz --progress public_html/ user@new-server:/home/user/public_html/

אם אין, ארזו את שורש האתר, הורידו והעלו ב‑SFTP:

tar -czf site.tar.gz public_html

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

mysql -u NEWUSER -p NEWDB < site.sql

בוורדפרס הקובץ הוא wp-config.php ובלראבל הוא .env. טעות כאן היא מסך השגיאה הקלאסי של חיבור למסד הנתונים, וכמעט תמיד מדובר בערך host שגוי ולא בסיסמה שגויה: חלק מהספקים משתמשים ב‑localhost ואחרים בשם מארח ייעודי.

אם הדומיין או הפרוטוקול משתנים, אל תריצו חיפוש והחלפה רגילים על קובץ ה‑SQL. מערכים מסודרים ב‑PHP שומרים אורכי מחרוזת, והחלפה נאיבית הורסת אותם. השתמשו בפקודת search-replace של WP-CLI שמטפלת בזה נכון, ותמיד הריצו קודם בדיקה יבשה:

wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise --dry-run

שלב 4: בודקים לפני שה‑DNS זז

אפשר לראות את השרת החדש מהמחשב שלכם בלי לשנות שום דבר בפומבי, על ידי הפניה ישירה. הוסיפו שורה לקובץ ה‑hosts עם כתובת ה‑IP החדשה והדומיין:

203.0.113.10 example.com www.example.com

בלינוקס וב‑macOS הקובץ נמצא ב‑/etc/hosts, ובחלונות ב‑C:\Windows\System32\drivers\etc\hosts ודורש עורך עם הרשאות מנהל. עכשיו הדפדפן שלכם מגיע לשרת החדש בזמן שכל השאר עדיין מגיעים לישן. עברו על הרשימה:

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

הסירו את שורות ה‑hosts כשסיימתם, אחרת תבזבזו אחר צהריים בתהייה למה השינויים שלכם בלתי נראים לכל השאר.

שלב 5: מחליפים DNS

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

בכל מסלול, השתמשו בשמות שרתי השמות או בכתובת ה‑IP המדויקים שמופיעים בחשבון ובמייל הפתיחה, ולא בערך כלשהו ממאמר ישן. הפרטים האלה משתנים בין חשבונות.

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

dig +short example.com @1.1.1.1
dig +short example.com @8.8.8.8

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

אימייל הוא הגירה נפרדת

• הדואר נשאר במקומו. האפשרות הבטוחה. שנו רק את רשומת ה‑A, אל תיגעו ב‑MX, וודאו אחר כך שה‑MX עדיין מצביע לאן שתמיד הצביע.
• הדואר עובר עם האתר. צרו כל תיבה בשרת החדש לפני המעבר, העתיקו הודעות בכלי סנכרון IMAP בזמן ששני השרתים פעילים, ורק אז הזיזו MX.
• הדואר עובר לספק ייעודי. לרוב התשובה הנכונה לטווח ארוך. הקימו במקביל, בדקו, והחליפו MX בנפרד מהאתר.

בכל מקרה, בדקו שלוש רשומות טקסט אחר כך. SPF חייב לכלול את כל מי ששולח דואר בשמכם, כולל שרת האתר אם הוא שולח הודעות מערכת. מפתחות DKIM נוצרים לכל שרת ואינם עוברים; רשומת DKIM מועתקת לא חותמת על כלום. DMARC יתחיל לדווח על כשלים אם טעיתם באחת מהשתיים, וזו תכונה ולא מטרד.

השבועיים שאחרי

בשעה הראשונה: ודאו שהמנעול מופיע ושהתעודה מכסה גם את הדומיין וגם את גרסת ה‑www, בדקו שבקשות http מופנות ל‑https, וטענו את האתר ברשת סלולרית כדי לראות אותו דרך שרת המרה אחר.

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

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

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

אם משהו משתבש

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

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

מתי Devoster היא היעד הלא נכון

• מידע תחת רגולציה. אין לנו הסמכות אבטחה, אנחנו לא מפרסמים דוח ביקורת ולא חותמים על הסכמי Business Associate. אם העומס שלכם כפוף לכללי בריאות, כרטיסי אשראי או דומיהם, קנו מספק שיכול להציג את הראיות.
• אתם צריכים מיקום באירופה או באסיה. יש לנו מיקום אחד בדרום ארצות הברית. אם רוב הגולשים שלכם בישראל או באירופה, או שהמידע חייב להישאר במדינה מסוימת, המרחק הפיזי הוא עלות אמיתית שאי אפשר לפתור בקאשינג.
• אתם רוצים שמישהו אחר ינהל את השרת. חבילות ה‑VPS שלנו אינן מנוהלות. אם אתם רוצים עדכונים, ניטור וכיוונון מטעם הספק, אחסון שיתופי או וורדפרס מנוהל הם המדף הנכון כאן, וייתכן שספק מנוהל לגמרי יתאים יותר משניהם.
• אתם תלויים ביכולת שאנחנו לא מוכרים. אם ההגדרה הנוכחית שלכם נשענת על רשת הפצת תוכן מובנית, שירות מטמון אובייקטים או חומת אש אפליקטיבית מובנית, ודאו שאתם יכולים להחליף אותם לפני המעבר ולא אחריו.

שאלות נפוצות

האתר שלי ייפול במהלך ההעברה?

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

כמה זמן לוקחת העברת אתר?

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

ההעברה באמת חינם?

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

לשנות שרתי שמות או רק רשומת A?

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

מה קורה לתעודת ה‑SSL?

תעודות מונפקות לכל שרת בנפרד, ולכן מבקשים תעודה חדשה בספק החדש ולא מעתיקים קבצים. הנפיקו לפני המעבר אם הפלטפורמה מאפשרת אימות בלי תעבורה חיה, ובדקו אחר כך שגם הדומיין וגם גרסת ה‑www מכוסים ושיש הפניה מ‑http ל‑https.

ההעברה תפגע בדירוג בגוגל?

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

הצעד הבא

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

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