חלופות ל-DigitalOcean: השוואת מחירים וביצועים למפתחים

מה באמת משתנה בחלופות ל-DigitalOcean

רוב החלופות ל-DigitalOcean משנות את החשבונית, לא את המכונה. בכל מקרה תקבלו מכונה וירטואלית מבוססת Linux עם כתובת IP ציבורית, כונן virtio וגישת root, וה-kernel שלכם לא "יודע" איזה לוגו מופיע בלוח הבקרה. ההבדלים שקובעים את הבחירה הם המחיר ל-GB של RAM, נפח תעבורת הרשת הכלול והעלות של כל byte חורג, ממה באמת עשוי הכונן, וכמה משכבות ה-stack שמעל מערכת ההפעלה ספק השירות ינהל עבורכם.

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

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

המחיר לכל GB של RAM הוא המדד להשוואה

[
  {
    "provider": "DigitalOcean 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "DigitalOcean 4 GB",
    "ram_gb": 4,
    "monthly_usd": "24.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "ram_gb": 1,
    "monthly_usd": "5.00",
    "usd_per_gb_ram": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "ram_gb": 1,
    "monthly_usd": "6.00",
    "usd_per_gb_ram": "6.00"
  },
  {
    "provider": "Hetzner CX23 4 GB (unavailable Oct 2026)",
    "ram_gb": 4,
    "monthly_usd": "6.49",
    "usd_per_gb_ram": "1.62"
  }
]

אצל ספק יחיד, המחיר לכל GB של RAM כמעט ואינו משתנה. DigitalOcean גובה $6.00 לכל GB בתוכנית של 1 GB, ואותו סכום של $6.00 לכל GB בתוכנית של 4 GB, שמחירה הרשמי הוא $24.00 לחודש. בחירה בתוכנית גדולה יותר אצל אותו ספק אינה מעניקה הנחה, לכן גודל התוכנית אינו השיקול המכריע. הספק הוא השיקול.

Akamai, שמוכרת כעת את מה שהיה בעבר Linode, מתמחרת את התוכניות המשותפות של 2 GB ו-4 GB ב-$12 ו-$24, בדיוק כמו DigitalOcean. תוכנית הכניסה שלה זולה יותר ועומדת על $5.00. העובדה ששתי חברות מתמחרות את השירותים שלהן באופן זהה היא סימן שחשוב להבין: שכבת מחיר זו נקבעת מול מתחרה, לא מול עלות החומרה, והיא תמשיך לעקוב אחרי אותו מתחרה.

הפער נוצר אצל ספקים שבונים מרכזי נתונים משלהם ומוכרים באירו. ב-5 באוגוסט 2026, שרת Hetzner מדגם CX23 סיפק 4 GB של RAM תמורת כ-$6.49 לחודש, כלומר $1.62 לכל GB – קרוב לרבע מהתעריף של DigitalOcean. נכון ל-21 באוקטובר 2026, עדיין לא ניתן להזמין שרת זה. Hetzner מציגה את ה-CX23, וכל תוכנית אחרת בקו ה-Cost-Optimized שלה, כלא זמינה כרגע, ומסבירה שהקו מבוסס על חומרה ישנה ולכן מספר השרתים מוגבל. דף הסטטוס של החברה מציג הודעה על זמינות מוגבלת של מופעי ענן מאז ה-26 ביוני 2026, והודעה זו עדיין הופיעה ב-21 באוקטובר 2026. לתוכנית שלא ניתן להזמין אין מחיר לכל GB שראוי להשוואה. ב-6 באוקטובר 2026 הוסיפה Hetzner את ה-CPX02, תוכנית Regular Performance עם 1 vCPU, 1 GB של RAM ו-20 GB של NVMe, כשרת המשותף הקטן ביותר שלה. ב-21 באוקטובר 2026, הדף של Hetzner הציג מחיר של €6.49 לחודש לפני מע"מ במיקומי האיחוד האירופי, כלומר €6.49 לכל GB של RAM לפני המרה לדולרים, לעומת $6.00 של DigitalOcean. אותו דף סימן את ה-CPX02, וכל תוכנית Regular Performance אחרת, כלא זמינה כרגע, לכן יש לוודא שניתן להזמין את השירות במיקום הרצוי לפני ביצוע השוואה. כל נתון דולרי עבור Hetzner מומר ממחיר רשמי באירו, ולכן הוא משתנה בהתאם לשער החליפין. Hetzner גם העלתה את מחירי הענן במהלך 2026, כך שפוסטים ישנים יותר מצטטים מספרים שכבר אינם קיימים.

המחיר לכל GB של RAM אינו מעיד דבר על ה-CPU שתקבלו. vCPU משותף אומר שה-hypervisor מתזמן את הליבה שלכם מול דיירים אחרים, והבדיקה האמינה ביותר מתבצעת על שרת ששכרתם בפועל:

vmstat 1 10

עיינו בעמודה st. היא מודדת את אחוז הזמן שבו ה-vCPU שלכם היה מוכן לפעולה, אך ה-hypervisor העביר את הליבה הפיזית למישהו אחר. אחוזים בודדים תחת עומס הם תקינים. מספר דו-ספרתי מתמשך אומר שהמארח (host) עמוס מדי, ושום מחיר לכל GB לא יפצה על ליבה שאינכם יכולים להשתמש בה. בצעו את הבדיקה בשעות העומס שלכם, כיוון ש-steal time הוא בעיה של שכנים, ולשכנים יש לוחות זמנים משלהם. לתמונה רחבה יותר על העלות האמיתית של אירוח לחודש לאחר הוספת אחסון ותעבורה, קראו את כמה עולה VPS מחודש לחודש.

מהו העלות האמיתית של התעבורה הכלולה

[
  {
    "provider": "DigitalOcean 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Akamai Nanode 1 GB",
    "included_tb": 1,
    "overage_usd_per_tb": "5.00"
  },
  {
    "provider": "Vultr NVMe 1 GB",
    "included_tb": 2,
    "overage_usd_per_tb": "10.00"
  },
  {
    "provider": "Hetzner CX23 4 GB (unavailable Oct 2026)",
    "included_tb": 20,
    "overage_usd_per_tb": "1.20"
  }
]

DigitalOcean כוללת כ-1 TB (1,000 GiB) של תעבורה יוצאת בתוכנית ה-$6.00 שלה (1 GiB RAM), ומחייבת על חריגה לפי $0.01 לכל GiB, מה שמתרגם לכ-$10.00 לכל TB נוסף. תוכנית הכניסה האמיתית שלה, 512 MiB RAM ב-$4.00 לחודש, כוללת 500 GiB בלבד, והמכסה גדלה בהתאם לגודל התוכנית עד ל-6,000 GiB בתוכניות ה-Basic הגדולות יותר; לכן, בדקו את הנתון עבור התוכנית שבחרתם בפועל. Akamai כוללת את אותו נפח TB ב-Nanode שלה ומחייבת בערך בחצי מהמחיר, כ-$5.00 לכל TB. Vultr כוללת 2 TB בתעריף חריגה דומה. ב-5 באוגוסט 2026, ה-Hetzner CX23 כללה 20 TB וגבתה כ-$1.20 לכל TB מעבר לכך, מה שמהווה הבדל של סדר גודל בהשוואה לאחרות. ב-21 באוקטובר 2026, הדף של Hetzner עדיין הציג 20 TB של תעבורה כלולה במיקומי ה-EU שלה, גם ב-CPX02, אם כי כמות קטנה בהרבה במיקומים בסינגפור ובארה"ב, שם ה-CPX02 מקבל 0.5 TB בסינגפור.

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

כל זה לא משנה אם אתם רחוקים מהמכסה. בלוג, API עם תגובות JSON או SaaS קטן לא יגיעו ל-1 TB בחודש. וידאו, גלריות תמונות, שרתי משחקים, מראות (mirrors) של חבילות ויעדי גיבוי מרוחקים יגיעו גם יגיעו. מדדו לפני שתניחו הנחות:

sudo apt update && sudo apt install -y vnstat
sudo systemctl enable --now vnstat
vnstat -m

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

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

NVMe או SATA, ואיך לבדוק מה באמת קיבלתם

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

בתוך המערכת האורחת, שניהם נראים זהים:

lsblk -d -o NAME,ROTA,MODEL,SIZE
cat /sys/block/vda/queue/rotational

הפקודות ROTA ו-rotational מדווחות על 0 עבור כל מה שהמארח מצהיר עליו כלא-מסתובב (non-rotational), לכן נפח רשתי המגובה ב-NVMe מדווח בדיוק על מה ש-NVMe מקומי מדווח. הערך אומר לכם שהדיסק אינו פלטה מסתובבת. הוא אינו יכול לומר לכם היכן הדיסק נמצא. אימות דיסק NVMe בלינוקס עובר על שמות ההתקנים ועל המשמעות של כל אחד מהם.

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

sudo apt update && sudo apt install -y fio
fio --name=lat --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based --group_reporting
fio --name=iops --filename=/var/tmp/fiotest --size=1G --rw=randread --bs=4k \
  --ioengine=libaio --direct=1 --iodepth=32 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fiotest

ההרצה הראשונה מדפיסה בלוק clat, שהוא השהיית השלמה. קראו את שורת האחוזון ה-99 במקום את הממוצע, מכיוון שהממוצע מסתיר את העיכובים שהמשתמשים מרגישים. ההרצה השנייה מדפיסה IOPS= בשורת הסיכום שלה. הריצו את שניהם אצל הספק הנוכחי שלכם ועל מופע ניסיון של הספק שאתם שוקלים, באותו היום, והשוו בין שני המספרים שלכם. נתון שפורסם על ידי ספק כלשהו נמדד על מכונה שאינכם יכולים לראות. הריצו זאת שלוש פעמים בשעות שונות, מכיוון שמארח שקט ומארח עמוס נותנים תשובות שונות באותה תוכנית. ביצוע Benchmarking תקין ל-VPS מכסה את השיטה, ו-מה המשמעות האמיתית של SSD VPS מכסה את מונחי השיווק שמאחורי זה.

אזורים: מדדו את השיהוי, אל תסתמכו על המפה

רשימת אזורים היא שיווקית בלבד עד שתמדדו אותה. מה שהמשתמש חווה הוא זמן הלוך-חזור (round trip) מהרשת שלו לשרת שלכם, וזה תלוי בנתיב שהחבילות עוברות, לא במרחק על המפה. שרת שנמצא במרחק 300 ק"מ מאחורי קישור עמוס יפסיד לשרת שנמצא במרחק 1,500 ק"מ על נתיב נקי.

ping -c 20 203.0.113.10
mtr -rwc 50 203.0.113.10
curl -o /dev/null -s -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} total %{time_total}\n' https://example.com

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

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

Snapshots וגיבויים מחויבים בנפרד

תוספי אחסון הם הנקודה שבה תוכנית זולה הופכת ליקרה. DigitalOcean גובה $0.06 לכל GiB בחודש עבור snapshots, ומתמחרת גיבויים אוטומטיים כאחוז ממחיר השרת: 20% ממחיר התוכנית עבור גיבויים שבועיים, 30% עבור גיבויים יומיים, עם אפשרות מבוססת שימוש המחויבת לפי GiB. שני המודלים הגיוניים, אך הם נכשלים בכיוונים מנוגדים. מחיר המבוסס על אחוזים גדל בהתאם לגודל השרת, כך ששרת גדול המכיל כמות קטנה של נתונים משלם יותר מדי. מחיר לכל GiB גדל בהתאם לכמות הנתונים שלכם, כך ששרת קטן המחובר לנפח אחסון גדול משלם יותר מדי.

בררו כמה עולה שחזור וכמה זמן הוא לוקח, כיוון שמחיר החזקת הגיבוי הוא רק החצי המשעמם של השאלה. בדקו האם מחיקת השרת מוחקת גם את ה-snapshots שלו.

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

כמה משכבות ה-stack אתם רוצים לנהל בעצמכם

ספקי שירותים נמצאים על רצף. בקצה אחד אתם שוכרים מכונה ומריצים עליה הכל בעצמכם. בקצה השני אתם דוחפים branch של git ולעולם לא רואים שרת. השוואת מחיר ל-GB של RAM רלוונטית רק לקצה הראשון, כיוון שבקצה השני אתם קונים עבודה ולא זיכרון, ולעבודה אין מחיר לפי GB.

היו כנים לגבי המיקום שלכם על הרצף לפני שאתם משווים משהו. מסד נתונים מנוהל בעלות של $15.15 לחודש נראה יקר ליד שרת של $6, עד שמתמחרים את השעות שמאחוריו: שכפול (replication), התאוששות מכשל (failover), שחזור לנקודת זמן (point in time restore), שדרוגי גרסאות משניות, וההתראה שמעירה מישהו ב-03:00. אם העבודה הזו היא התפקיד שלכם, הריצו אותה בעצמכם וחסכו את ההפרש. אם התפקיד שלכם הוא היישום, קניית השירות בחזרה היא זולה. ההפרדה בין מנוהל ללא-מנוהל קובעת איזו עמודה במחירון אתם בכלל צריכים לקרוא. אם התשובה הכנה היא שאתם רוצים את כל המכונה והדיסקים שלה לעצמכם, זו שאלה של VPS לעומת שרת ייעודי ולא שאלה של ספק. אותה שאלה עולה בשאר החשבון החודשי של מפתח, שבו השוואה בין תוכניות Claude ל-ChatGPT תלויה בכמה מהעבודה אתם רוצים להעביר הלאה, ולא במחיר המוצהר.

מתי DigitalOcean היא הבחירה הנכונה

DigitalOcean מנצחת כאשר אתם קונים את הפלטפורמה במקום את המכונה הווירטואלית.

• מסדי נתונים מנוהלים. מסדי נתונים מנוהלים מסוג PostgreSQL ו-MySQL מתחילים ב-$15.15 לחודש עבור 1 GiB של RAM ו-10 GiB של אחסון, כאשר אחסון נוסף מחויב לפי GiB וצמתים במצב המתנה (standby nodes) מתומחרים לפי צומת. בנייה עצמית של אותה רמת אמינות דורשת שימוש ב-Patroni או ב-repmgr, מאגר קונסנזוס, proxy לחיבורים ותרגול failover שבאמת ביצעתם. צוות של שני אנשים לא יכול לתחזק מערכת כזו ובמקביל לפתח פיצ'רים.
• App Platform. דחיפת branch מובילה לביצוע build, הנפקת תעודה והרצת שירות, ללא צורך בעדכון מערכת הפעלה. הגרסה הזולה של מוצר זה ב-VPS היא אתם, ביום שבת.
• אחסון אובייקטים ו-load balancers הנתמכים על ידי ספק Terraform בוגר. לצי שרתים שניתן להשמיד ולבנות מחדש מתוך קוד יש ערך רב יותר מאשר למחיר יחידה נמוך יותר.
• החברה שמאחורי המוצר. רמות תמיכה מפורסמות, דף סטטוס עם היסטוריה, וארגון שיענה על שאלון אבטחה של לקוח. אם אתם משווקים שירותי אירוח, זה שווה הרבה יותר מכמה דולרים לכל GB.

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

מעבר לספק חדש ללא השבתה

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

התחילו ב־DNS, לפחות 48 שעות לפני המעבר. שרתי DNS שומרים ב־cache את רשומת ה־A שלכם למשך זמן ה־TTL (זמן חיים) שלה. לכן, רשומה עם TTL של 24 שעות תמשיך להפנות משתמשים לשרת הישן עד יום שלם לאחר שתשנו אותה. הנמכת ה־TTL ברגע המעבר אינה עוזרת, כיוון שהשרתים כבר מחזיקים בערך הישן עם תאריך התפוגה המקורי שלו. הנמיכו אותו מראש, המתינו עד שיפוג הערך הישן, ורק אז בצעו את ההגירה.

dig +noall +answer example.com A
dig +noall +authority example.com SOA

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

לאחר מכן פעלו לפי הסדר הבא:

1. הקימו את השרת החדש ובצעו לו הקשחה (hardening) לפני שכל דבר אחר מועלה אליו. המדריך עשר הדקות הראשונות ב-VPS חדש מכסה את החלק שאנשים מדלגים עליו כשהם ממהרים.
2. התקינו את ה-stack של היישום ובצעו העתקה ראשונית של הנתונים בעזרת rsync, בזמן שהשרת הישן ממשיך לעבוד כרגיל.
3. הנפיקו את תעודת ה-TLS במארח החדש כעת, באמצעות אתגר DNS-01, כיוון שאתגר HTTP-01 מאמת מול ה-IP שאליו ה-DNS מצביע כרגע, שהוא עדיין השרת הישן. אתגר DNS-01 פותר את בעיית הסדר הזו לחלוטין.
4. בדקו את המארח החדש לפני כל שינוי פומבי על ידי דריסת ה-DNS במחשב האישי שלכם. הוסיפו את 203.0.113.20 example.com ל-/etc/hosts, גלשו לאתר האמיתי, ואז מחקו את השורה. אף משתמש לא יושפע מבדיקה זו.
5. טפלו בשאלת גודל מסד הנתונים. בנפח של כמה GB בודדים, גיבוי ושחזור נכנסים בתוך חלון הקפאת הכתיבה. מעבר לכך, הגדירו שכפול (replication) ממסד הנתונים הישן לחדש ימים מראש ותנו לו להסתנכרן, כך שההקפאה תכסה רק את שלב הקידום (promotion).
6. הקפיאו כתיבה. העבירו את היישום למצב תחזוקה או לקריאה בלבד. זהו החלק היחיד שהמשתמשים יכולים לראות, והוא אמור להימשך דקות ספורות.
7. בצעו את ה-delta הסופי: שוב את אותו rsync, ולאחר מכן את סנכרון מסד הנתונים האחרון.
8. שנו את רשומות ה-A וה-AAAA ל-IP החדש. עם TTL של 300 שניות, רוב שרתי ה-DNS יתעדכנו תוך כחמש דקות.
9. השאירו את השרת הישן פועל ונגיש למשך יום לפחות, כיוון שחלק מהשרתים מתעלמים מ-TTL קצר. אם היישום הישן עדיין מאפשר כתיבה, פניות מאוחרות יכתבו למסד הנתונים הלא נכון; לכן, הפנו את המארח הישן למסד הנתונים החדש או הציגו ממנו דף תחזוקה.
10. עקבו אחר שיעור השגיאות של השרת החדש במשך יום, החזירו את ה-TTL לערכו הרגיל, והשמידו את השרת הישן לאחר שבוע ולא באותו ערב.

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

rsync -aHAX --numeric-ids --delete -e ssh /srv/ deploy@203.0.113.20:/srv/

-a שומר על בעלות, הרשאות וחותמות זמן, -H שומר על hard links, -AX שומר על ACLs ומאפיינים מורחבים, ו---numeric-ids מונע מ-rsync למפות מחדש מזהי משתמשים דרך שמות ששונים בין שתי המכונות. הריצו זאת ימים מראש, ואז שוב במהלך ההקפאה, אז יועברו רק השינויים.

עבור PostgreSQL קטן מספיק לגיבוי:

pg_dump --format=custom --no-owner --dbname=appdb --file=appdb.dump
scp appdb.dump deploy@203.0.113.20:/var/tmp/
pg_restore --clean --if-exists --no-owner --dbname=appdb /var/tmp/appdb.dump

עבור MySQL או MariaDB:

mysqldump --single-transaction --routines --triggers --databases appdb > appdb.sql

--single-transaction מבצע את הגיבוי בתוך טרנזקציה אחת על טבלאות InnoDB, כך שהתוצאה עקבית והיישום ממשיך לכתוב בזמן שהתהליך רץ. ללא דגל זה, mysqldump נועל את הטבלאות, מה שאומר שהקפאת הכתיבה שלכם התחילה מוקדם מהמתוכנן ולא אתם בחרתם מתי.

שני דברים עלולים להשתבש מחוץ לשרתים שלכם. לכתובת IP חדשה אין מוניטין דואר, לכן דואר שנשלח ישירות מהשרת החדש יסונן כ-spam: שלחו דרך relay שכבר מחזיק במוניטין. כמו כן, כל שותף שמבצע allowlist ל-IP היוצא שלכם, כגון שער תשלומים או firewall של לקוח, חייב להתעדכן לפני המעבר, אחרת הקריאות יתחילו להיכשל ברגע שהתעבורה תעבור.

מה לבדוק לפני התחייבות

• האם ניתן להזמין את התוכנית בפועל היום, במיקום הרצוי. תוכנית שמסומנת כלא זמינה במחירון אינה אופציה, ללא קשר למחיר האטרקטיבי לכל GB.
• האם המחיר הוא מחיר מבצע ומה יהיה המחיר בחידוש. הנחה לתקופה ראשונה שמוכפלת בחידוש היא עלות אמיתית, פשוט נדחית.
• האם התקופה משולמת מראש. תוכניות בתשלום מראש למספר שנים, כפי ש-SSD Nodes מוכרת, מאפשרות מחיר נמוך משמעותית לכל GB של RAM בתמורה לתשלום מראש. הפשרה היא שלא ניתן לעזוב בחודש הבא, לכן התאימו את התקופה לרמת הוודאות שלכם.
• מהי העלות החודשית של snapshot, ומהי העלות של שחזור בכסף ובדקות.
• האם חריגה ממכסה מחויבת בתשלום או מוגבלת ברוחב פס (throttled).
• האם IPv6 מנותב כראוי או שמדובר בכתובת בודדת שמחוברת טכנית.
• האם קיים API עם ספק Terraform מתוחזק, אם בכוונתכם לבנות מחדש מתוך קוד ולא ידנית.
• כיצד ניתן להגיע לתמיכה, ומהו יעד המענה המפורסם עבור שרת שאינו זמין, לעומת שאלות מכירה.

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

FAQ

האם Hetzner תמיד זולה יותר מ-DigitalOcean?

עבור מכונה וירטואלית פשוטה, המחיר ל-GB של RAM היה נמוך משמעותית: כ-1.62$ לעומת 6.00$ בתוכניות שיתופיות קטנות נכון ל-5 באוגוסט 2026. הנתון של Hetzner התבסס על ה-CX23, ש-Hetzner סימנה כלא זמין ב-21 באוקטובר 2026, יחד עם שאר קו ה-Cost-Optimized וה-CPX02 החדש שלה, לכן יש להשוות מול תוכנית שניתן להזמין בפועל כיום. ההשוואה משתנה גם כאשר נכנסים לתמונה שירותים מנוהלים. Hetzner מוכרת שרתים ותשתית רשת, כך שמסד נתונים מנוהל או פלטפורמת push-to-deploy צריכים להגיע ממך או מצד שלישי, ולשעות אלו יש מחיר. Hetzner גם העלתה את מחירי הענן במהלך 2026, לכן יש לבדוק את המחיר הנוכחי ביורו במקום להסתמך על מאמר ישן.

באיזו חלופה ל-DigitalOcean כדאי לבחור אם אני זקוק למסד נתונים מנוהל?

Vultr ו-Akamai מוכרות שתיהן מסדי נתונים מנוהלים, ולכן הן התחליפים הקרובים ביותר אם מסד הנתונים המנוהל הוא הסיבה שבגללה אתה משתמש ב-DigitalOcean. ספקיות האירוח האירופיות הזולות בדרך כלל אינן מוכרות שירות כזה, מה שאומר שתצטרך להריץ PostgreSQL או MySQL בעצמך, כולל רפליקציה ו-failover שנבדק. זו עבודה של ממש. שקלל זאת מול ה-15.15$ לחודש שעולה מופע מנוהל של 1 GiB לפני שתחליט שהשרת הזול יותר חסך לך משהו.

איך מעבירים אתר פעיל לספק חדש ללא זמן השבתה?

הנמך את ה-TTL של ה-DNS ל-300 שניות לפחות 48 שעות לפני המעבר, כיוון ששרתי DNS ממשיכים להגיש את ה-IP הישן כל עוד ה-TTL הקודם בתוקף. בנה ובדוק את המארח החדש בזמן שהישן עדיין מגיש תעבורה, תוך שימוש ב-/etc/hosts על המחשב האישי שלך כדי שאף אחד אחר לא יראה זאת. לאחר מכן, הקפא כתיבות לכמה דקות, הרץ את ה-rsync הסופי ואת סנכרון מסד הנתונים האחרון, החלף את רשומות ה-A וה-AAAA, והשאר את השרת הישן פועל למשך שבוע למקרה ששרת DNS כלשהו התעלם מה-TTL הקצר.

האם VPS זול יותר אומר דיסקים איטיים יותר?

לא בהכרח. מה שקובע הוא האם הדיסק הווירטואלי שלך מקומי למארח או נמצא על אשכול אחסון רשתי, והפאנל לעיתים רחוקות מציין זאת. lsblk -o NAME,ROTA מדווח על 0 עבור שניהם, כיוון ששניהם אינם מסתובבים (non-rotational). במקום זאת, בצע מדידה: הרץ את fio עם --iodepth=1 --bs=4k --direct=1 ובדוק את זמן האחזור (latency) באחוזון ה-99. כונן רשתי מוסיף זמן הלוך-חזור ברשת מרכז הנתונים לכל קריאה, לכן רצפת זמן האחזור שלו גבוהה יותר מאשר NVMe מקומי, גם כאשר ביצועי ה-throughput בתור עמוק נראים דומים.

האם האימייל שלי עדיין יימסר מהשרת החדש?

לרוב לא, בהתחלה. לכתובת IP חדשה אין היסטוריית שליחה, לכן שרתי דואר יתייחסו להודעות ממנה כחשודות והן יגיעו לתיקיית הספאם או יידחו על הסף. רשומות SPF ו-DKIM גם הן מצביעות על המארח הישן עד שתעדכן אותן. שלח דואר מהיישום דרך relay או שירות אימייל שכבר מחזיק במוניטין, ועדכן את רשומות ה-DNS עבור הדואר לפני המעבר ולא אחריו.