גיבויים בענן איטיים דרך VPN: מצאו את השלב האמיתי
גיבוי איטי עשוי לסרוק, לחשב גיבוב או לנסות שוב במקום להעביר. השוו את השלב, סוג היעד והשחזור לפני שתשנו מסלולים.
גיבוי שזוח דרך VPN מזמין את הניסוי המובן מאליו: לנתק את המנהרה ולמדוד שוב. לעתים קרובות הניסוי הזה עונה על שאלה אחרת, כי ייתכן שהמשימה חישבה גיבובים של קבצים או המתינה לניסיון חוזר במקום להעביר בייטים. הפרידו קודם את השלבים, והתלונה הופכת לבדיקה מדויקת עם תוצאה צפויה מדויקת. המסלול הופך למועמד רק כאשר שלב ההעברה הוא זה שבאמת איטי.
באיזה שלב נמצאת המשימה כשהיא מרגישה איטית
כלי גיבוי עוברים שלבים: גילוי קבצים, קריאתם וחישוב גיבוב שלהם, דחיסה, הצפנה, העלאה ואז אימות. לכל שלב צוואר הבקבוק שלו, ורק חלקם נוגעים ברשת בכלל. כלי שעדיין לא מדווח על שלב אומר לכם שהוא לא סיים לסרוק.
משימה שמבלה עשרים דקות בהכנת מיליון קבצים קטנים לא תתמהר כשהמנהרה תהפוך למהירה יותר. משימה שמרווה את קישור ההעלאה היא בעיית קיבולת עם פתרון אחר. קראו את פלט ההתקדמות בזמן שהעיכוב מתרחש, רשמו את השלב וכתבו את חתימת הזמן, כי השלב ברגע התלונה הוא היחיד שחשוב. קבצים קטנים גם מתנהגים אחרת מאובייקט גדול אחד, כי הלוך-ושוב לכל קובץ שולט וההעברה לעולם לא מגיעה לקצב יציב. השוו דומה לדומה לפני הסקת מסקנות על המנהרה.
נקודת קצה ציבורית ו-NAS פרטי נכשלים אחרת
שירות גיבוי ציבורי נושא את חיבור האפליקציה המאומת שלו, והמנהרה היא קפיצה אחת במסלול ארוך יותר. NAS פרטי בדרך כלל תלוי במנהרה הזו כדי להגיע לרשת שלכם. ההבדל הזה קובע אם ניתוק הוא קו בסיס תקף או בדיקה של כלום.
במקרה הציבורי, אותה משימה במסלול אחר יכולה להיות השוואה הוגנת כשהמדיניות מאפשרת. במקרה הפרטי, הסרת המנהרה לא משאירה שום מסלול לשרת, ולכן התוצאה מתארת את המסלול שמחקתם ולא את זה שאתם משתמשים בו.
| Destination | What the tunnel provides | Valid baseline |
|---|---|---|
| Public backup service | One hop among several | The same job over another route |
| Private NAS | The only path to the server | None that removes the tunnel |
| Self-hosted gateway | Path plus split-DNS policy | Only if the policy is unchanged |
תקיעה היא כשל אחר מהעברה איטית
העמודה השלישית בטבלה הזו קובעת אם בדיקת יציבות יכולה להתבצע כלל, כי קו בסיס שמסיר את המנהרה משמעותי רק במקום שבו קיים מסלול אחר. עם קו בסיס שמיש, הביטו בצורת הכשל ולא בקצב הממוצע. העלאה נמוכה אך יציבה מצביעה על קיבולת, ואילו משימה שנתקעת ומתחילה מחדש מצביעה על קטיעה, אימות או קובץ אחד בעייתי. שני אלה מייצרים תלונות כמעט זהות ותיקונים שונים לחלוטין.
ניסיונות חוזרים מעוותים כל מדידה, כי הבייטים על הקו יכולים להיות גדולים מהכמות שבאמת השתנתה. קראו את התנהגות ההמשכה לפני שתקטעו את המשימה שוב כדי לראות מה קורה, כי העלאות מפוצלות הניתנות להמשכה מתאוששות בזול והתחלה מחדש של קובץ שלם לא. מנהרה שמתחברת מחדש כל כמה דקות גם נראית כמו בעיית רוחב פס כשהיא בעצם בעיית יציבות. ה-MTU של המסלול מחמיר זאת, כי מנהרה שמקטינה את המטען השמיש תוקעת מקטעים גדולים בזמן שהקטנים עוברים.
journalctl -u wg-quick@wg0 -n 50 --no-pager
ss -tin dst :443
ping -M do -s 1400 -c 3 backup.example.comהעלאה אחת יכולה להרעיב את כל הזרמים האחרים
העלאה שממלאת את קישור ההעלאה הופכת שיחות וגלישה ללא מגיבות, והגיבוי הוא לעתים רחוקות הדבר היחיד שמתחרה עליו. לקוח סנכרון שני יוצר את אותו סימפטום בעצמו. לפני שאתם מאשימים את המנהרה, ראו מה עוד מועלה.
השתמשו בלוח הזמנים או במגבלת רוחב הפס שהכלי מתעד ולא במאבק על תפוקה שיא; השארת מרווח לעבודה אינטראקטיבית שווה בדרך כלל יותר מהאחוזים האחרונים. אחר כך בדקו למה המגבלה חלה באמת, כי כלים מסוימים מגבילים לכל קובץ, אחרים לכל הריצה, ואחרים מתעלמים לגמרי מעלות קבצים קטנים. מגבלה שאינה מתאימה לעומס העבודה לא משנה דבר. גם מינהור מפוצל ראוי לחשד כאן, כי הוצאת המשגר מהמנהרה אינה מוציאה את שירות העזר שמבצע את ההעלאה. Rclone, למשל, מפרסם גם מגבלות העברה וגם התנהגות ניסיון חוזר בתיעוד שלו, מה שהופך אותו להתייחסות שימושית למה שמגבלה אמורה לשלוט בו.
סיימו בשחזור, לא בבדיקת מהירות
העלאה שהושלמה אינה גיבוי עד שמשהו משוחזר ממנה. ודאו שהגרסה הצפויה קיימת, ואז שחזרו קובץ מייצג לפי הנוהל שהכלי מתעד. שמרו את פרטי השחזור במקום אחר מהמכונה או הפרופיל שאולי תאבדו, ולעולם אל תזרקו גיבוי שעובד רק כדי לשמור על ניסוי מסודר.
restic snapshots --latest 3
restic restore latest --target /tmp/restore-check --include /etc/hostsחזרו גם על ההעברה וגם על השחזור לאחר שינוי הרשת, כדי שהשיפור ייראה משרת את הגיבוי ולא רק העברת נתונים מהירה יותר. הריצה השנייה היא זו שסוגרת את הפנייה. העברה מהירה יותר עם שחזור שלא נבדק היא דרך איטית יותר להישאר בלי הגנה.