העברת אתר לשרת חדש עם זמן השבתה מינימלי

תארו לעצמכם שאתם מחליטים לעבור לשרת חדש כדי לשפר ביצועים. אבל משהו משתבש במהלך ההעברה — גיבוי מסד נתונים פגום, קבצים שלא הועתקו, האתר נופל ליום שלם. זהו מצב טיפוסי למי שמנסה העברת אתר בפעם הראשונה. למהנדסים שלנו (ניסיון של 5+ שנים) יש 200+ העברות מוצלחות עם אחוז הצלחה של 99.9%. התהליך שלנו מבטיח זמן השבתה של פחות מ-15 דקות — אנו משתמשים בפעולה מקבילה ובדיקות מקדימות. בפירוט: לפני שינוי ה-DNS, אנו מקימים עותק מלא על השרת החדש, בודקים את כל התרחישים (התחברות, תשלום, טפסים). רק אז אנו משנים את רשומת ה-A עם TTL של 300 שניות. גישה זו מונעת אובדן נתונים וזמן השבתה ארוך. אנו גם שומרים על שני השרתים פעילים עד 72 שעות לאחר המעבר — למקרה של צורך בחזרה לגרסה קודמת.

מהם הסיכונים בשינוי אירוח?

העברת אירוח לא נכונה מובילה ל:

• שגיאות בתצורת שרת האינטרנט (גרסאות PHP לא תואמות, מודולים)
• אובדן נתונים עקב גיבוי DB לא מלא או ארכיון פגום
• זמן השבתה ארוך (12+ שעות במקום 15 דקות)
• קישורים שבורים בתוכן (נתיבים מוחלטים שנשארו מהשרת הישן)

אנו פותרים בעיות אלו צעד אחר צעד עם בדיקות כפולות.

איך למזער זמן השבתה במהלך העברה?

העיקרון המרכזי הוא פעולה מקבילה (גיבוי חם). אנו מבצעים את ההעברה על השרת החדש בזמן שהשרת הישן משרת את המבקרים. לאחר אימות מלא דרך קובץ ה-hosts, אנו משנים את ה-DNS עם TTL נמוך (300 שניות). זמן ההשבתה הממוצע הוא 5–15 דקות. השיטה שלנו מפחיתה את זמן ההשבתה ב-95% בהשוואה להעברה מסורתית.

השוואת שיטות העברת נתונים

rsync מהיר פי 5–10 מ-FTP עבור נפחים >10 GB לפי תיעוד rsync. אנו משתמשים ב-rsync להעתקה ראשית וב-tar לארכיון גיבוי. בנוסף, אנו משתמשים ב-pigz לדחיסה מקבילה — מה שמאיץ את התהליך ב-30%.

מה כלול בעבודה?

• העברת קבצים (rsync עם החרגה של .git, cache)
• העברת מסד נתונים (גיבוי + שחזור בגרסת ה-DBMS החדשה)
• הגדרת שרת אינטרנט (Nginx/Apache) וסביבה (PHP, Node.js, Redis)
• התקנת תעודת SSL (Let's Encrypt או תעודה משלכם)
• הגדרת Cron, עובדי תורים, משתני סביבה
• אימות דרך /etc/hosts לפני שינוי DNS
• ניטור 72 שעות לאחר המעבר

תוצרים

• דוח העברה מפורט
• פרטי גישה לשרת
• תמיכה 72 שעות לאחר ההעברה
• הדרכה של 30 דקות על ניהול השרת החדש

העברה חלקה טיפוסית עולה בין $300 ל-$800 בהתאם למורכבות, וחוסכת לכם עד $500 בהכנסות פוטנציאליות שאבדו כתוצאה מזמן השבתה.

מהן הטעויות האופייניות בהעברה עצמית?

מפתחים שוכחים לעתים קרובות:

• לסנכרן הרשאות .env ואחסון (chmod 775)
• לייצא את מסד הנתונים עם דגלי --add-drop-table ו---complete-insert עבור InnoDB
• לבדוק הפניות (http→https, www→non-www) על השרת החדש
• לעדכן IP בהגדרות CDN (Cloudflare, Vercel)

שלבי ההעברה: צעד אחר צעד

שלב 1: הכנת השרת החדש

התקינו את הערימה הנדרשת (LEMP, Node.js וכו'):

# Установка LEMP-стека на Ubuntu 22.04
sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx mysql-server php8.2-fpm php8.2-mysql php8.2-gd \
    php8.2-curl php8.2-zip php8.2-mbstring php8.2-xml php8.2-intl redis-server
# Для Node.js проектов
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

שלב 2: העברת קבצים ומסד נתונים

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

# MySQL: дамп и восстановление
mysqldump -u root -p mysite_db > /tmp/mysite_db.sql
scp /tmp/mysite_db.sql user@new-server:/tmp/
ssh user@new-server "mysql -u root -p new_db < /tmp/mysite_db.sql"

# rsync файлов (исключаем .git)
rsync -avz --progress --exclude='.git' \
  -e "ssh -p 22" \
  user@old-server:/var/www/mysite/ \
  user@new-server:/var/www/mysite/

עבור PostgreSQL, השתמשו ב-# Установка LEMP-стека на Ubuntu 22.04 sudo apt update && sudo apt upgrade -y sudo apt install -y nginx mysql-server php8.2-fpm php8.2-mysql php8.2-gd \ php8.2-curl php8.2-zip php8.2-mbstring php8.2-xml php8.2-intl redis-server # Для Node.js проектов curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs /# MySQL: дамп и восстановление mysqldump -u root -p mysite_db > /tmp/mysite_db.sql scp /tmp/mysite_db.sql user@new-server:/tmp/ ssh user@new-server "mysql -u root -p new_db < /tmp/mysite_db.sql" # rsync файлов (исключаем .git) rsync -avz --progress --exclude='.git' \ -e "ssh -p 22" \ user@old-server:/var/www/mysite/ \ user@new-server:/var/www/mysite/ . חשוב: עבור מסדי נתונים גדולים (50+ GB), השתמשו בגיבוי סטרימינג דרך pg_dump ו-psql למהירות.

שלב 3: הגדרת השרת החדש

• צרו מארח וירטואלי (Nginx/Apache)
• העבירו את .env עם נתונים עדכניים
• התקינו תעודת SSL
• הגדירו הרשאות על תיקיות: storage, cache, uploads
• הגדירו cron ועובדי תורים

שלב 4: אימות דרך קובץ hosts

לפני שינוי DNS, בדקו את האתר מקומית:

# На локальной машине добавляем в /etc/hosts (или C:\Windows\System32\drivers\etc\hosts) NEW_SERVER_IP mysite.com www.mysite.com 

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

שלב 5: ביצוע שינוי DNS

יום לפני השינוי, הורידו את ה-TTL ל-300 שניות. ברגע השינוי, שנו את רשומת ה-A לכתובת ה-IP של השרת החדש. לאחר התפשטות, החזירו את ה-TTL ל-3600+.

# Мониторинг распространения DNS
watch -n 5 "dig @8.8.8.8 mysite.com A +short"
watch -n 5 "dig @1.1.1.1 mysite.com A +short"

שלב 6: ניטור לאחר ההעברה

שמרו על השרת הישן פעיל למשך 48–72 שעות. בצעו:

• בדיקות זמינות עם curl
• אימות תעודת SSL (openssl)
• בדיקות הפניות (http→https, www→non-www)

curl -I https://mysite.com
echo | openssl s_client -connect mysite.com:443 2>/dev/null | grep "Verify return code"
curl -I http://mysite.com # ожидаем 301

חשיבות הבדיקות על השרת החדש לפני שינוי DNS

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

לוח זמנים ומחירים

העברה סטנדרטית אורכת בין 4 ל-16 שעות בהתאם לנפח הנתונים, מספר מסדי הנתונים ומאפייני הסביבה. המחיר הוא אישי — צרו קשר להערכת הפרויקט שלכם. אנו עובדים עם אירוח בכל רמת מורכבות: משיתוף ועד ייעודי. ערבות ההעברה ללא אובדן נתונים שלנו מבטיחה אפס אובדן נתונים, ואנו מציעים שירות העברה ל-VPS עם תמיכה מלאה.

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