העברת קבצים גדולים בין שני שרתים בעזרת פקודת rsync על גבי SSH

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

מה לעשות אם אתם משתמשים בפורט SSH שונה?

למטרות אבטחה, ייתכן ש-Port SSH פועל על פורט שונה מ-22. במקרה זה יש לציין את פרמטר ה-SSH ב-rsync. לדוגמה: rsync -avz -e ssh -p 2222 /תיקייה/מקור/ משתמש@כתובת-ip-של-שרת-יעד:/תיקייה/יעד/. עם זאת, יש להשתמש בערך של פרמטר -e בשורת הפקודה. ההיגיון הנכון הוא: rsync -avz -e 'ssh -p 2222' /תיקייה/מקור/ משתמש@כתובת-ip-של-שרת-יעד:/תיקייה/יעד/.

ב-JavaScript ובחלק מהפאנלים, השימוש במרכאות יחידות יכול להתנהג בצורה שונה, לכן ודאו שהמרכאות נכונות בעת כתיבת הפקודה ישירות בטרמינל. אם אתם מתחברים בעזרת מפתח SSH, ניתן להוסיף גם את הפרמטר -i: rsync -avz -e 'ssh -p 2222 -i /root/.ssh/id_rsa' /תיקייה/מקור/ משתמש@כתובת-ip-של-שרת-יעד:/תיקייה/יעד/. שיטה זו משמשת לעיתים קרובות במשימות אוטומטיות ובגיבויים מבוססי cron.

בדיקות לפני ההעברה: שימוש ב--dry-run

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

פקודת בדיקה לדוגמה: rsync -avz --dry-run /var/www/site/ משתמש@כתובת-ip-של-שרת-יעד:/var/www/site/. בדו"ח תראו את הקבצים שיתקבלו, את התיקיות שיתווספו ואת סיכום הפעולה. אם תשתמשו בפרמטר --delete, השימוש ב-dry-run הופך להיות קריטי אף יותר. כיוון ש--delete עלול למחוק קבצים שבלתי קיימים במקור, השימוש הנכון בו יכול לשכפל את היעד בדיוק; השימוש בו בתיקיה שגויה עלול לגרום לאובדן נתונים חמור.

סדר הפעולה המקצועי בדרך כלל הוא: קודם כל לבדוק את ה-SSH, לאחר מכן לבדוק את שטח הדיסק, לאחר מכן להריץ rsync --dry-run, לבצע בדיקה אמיתית עם תיקיה קטנה, ולאחר מכן להתחיל את ההעברה הראשית. גישה זו עשויה לדרוש מספר דקות נוספות, אך היא מונעת העברות שגויות שיכולות להימשך שעות.

הגדרות דחיסה, רוחב פס והצפנה לביצועים

ביצועי rsync אינם תלויים רק בגודל הקובץ. כוח ה-CPU של השרתים, סוג הדיסק, השהייה ברשת, רוחב הפס ומספר הקבצים גם הם חשובים. הרבה קבצים קטנים עשויים להיות מועברים לאט יותר מקובץ גדול בודד, כיוון שלכל קובץ מתבצע עיבוד של מטא-דאטה. בסביבות VPS עם דיסקי NVMe, יכולת הסריקה וכתיבת הקבצים עשויה להיות הרבה יותר טובה. לכן, אם אתם מתכננים העברה אינטנסיבית, זה הגיוני לשקול את האפשרויות של שרת VPS NVMe.

הפרמטר -z לדחיסה מסייע עם קבצי טקסט, לוגים וסוגים מסוימים של גיבויים. אולם בקבצים שכבר דחוסים כמו zip, tar.gz, jpg, mp4 או gzip, השימוש בו עשוי להעמיס על ה-CPU ולא לספק יתרון משמעותי. אם אתם מעבירים קבצי מדיה גדולים בין שני שרתים חזקים עם חיבור של 1 Gbps, תוכלו להשיג ביצועים טובים יותר ללא -z. מצד שני, ברוחב פס נמוך ובקבצים עם משקל טקסטואלי -z עשוי לחסוך משמעותית.

כדי להגביל את רוחב הפס, ניתן להשתמש ב--bwlimit. לדוגמה, --bwlimit=50000 מגביל את המהירות לכ-50 MB/s. זה חשוב כדי לא להעמיס על תנועת הרשת של אתר פעיל. ביצוע העברות במהירות מלאה בשעות העומס עשוי להשפיע על חוויית המשתמש. תכנון ההעברה לשעות הלילה, הגבלת רוחב הפס ומעקב אחרי ערכי הטעינה במהלך התהליך הוא רעיון טוב.

השוואה בין rsync, scp, SFTP ו-FTP

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

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

דוגמת תהליך העברת אתר חי

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

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

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

בדיקת שלמות הנתונים

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

כדי לבצע אימות checksum, ניתן להשתמש בפקודה: rsync -avc --dry-run /תיקייה/מקור/ משתמש@כתובת-ip-של-שרת-יעד:/תיקייה/יעד/. כאן, הפרמטר -c משווה את הקבצים לא רק לפי חותמות זמן וגודל, אלא גם לפי checksum. בשימוש עם נתונים גדולים, יש להשתמש בזהירות מכיוון שזה יכול להעמיס על ה-CPU והדיסק. עבור ארכיונים קריטיים, קבצי גיבוי של מסדי נתונים או מסמכים של לקוחות, אימות נוסף זה מספק ביטחון.

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

שגיאות נפוצות ופתרונות

שגיאת Permission denied

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

שגיאת No space left on device

כאשר אין מספיק מקום בדיסק היעד, ההעברה תיכשל. בדקו את מחיצות הדיסק בעזרת df -h. לפעמים, הדיסק הראשי אינו מלא, אך /tmp או נקודת המתקן של היעד עשויות להיות מלאות. בעת העברות גדולות, ניתן לנקות קבצי לוג, גיבויים ישנים ותיקיות קאש. לפתרון קבוע, ייתכן שיהיה צורך להגדיל את הדיסק או לעבור לתכנית VPS עם קיבולת גבוהה יותר.

שגיאת Connection reset או Broken pipe

בעת העברות ארוכות טווח, ייתכנו ניתוקים ברשת. אם אתם משתמשים בפרמטרים --partial ו--append-verify, תוכלו להריץ שוב את הפקודה ולהמשיך מהמקום שבו הפסקתם. כמו כן, הגדרות keepalive של SSH עשויות לעזור. בצד הלקוח, הגדרה כמו ServerAliveInterval 60 יכולה להפחית את הסיכון לניתוקים ריקים.

העברה מאוד איטית

האיטיות עשויה לנבוע ממספר קבצים, מגבלות I/O של הדיסק, העמסת דחיסה או קיבולת הרשת. כאשר יש הרבה קבצים קטנים, ייתכן שיצירת ארכיון tar קודם תהיה מהירה יותר במקרים מסוימים; אך במקרה זה יתרון השינויים מבוססי הקובץ של rsync יפחת. בקבצים גדולים שכבר דחוסים, נסו לבדוק את ההעברה בלי הפרמטר -z. בנוסף, השתמשו בכלים כמו iotop, htop ו-iftop כדי לקבוע היכן נמצא צוואר הבקבוק - האם ב-CPU, בדיסק או ברשת.

שיטות אבטחה מומלצות

בעת העברת קבצים בין שרתים, יש לשים לב לאבטחה. במיוחד, גישה ל-root, מפתחות SSH וקבצי גיבוי צריכים להיות מטופלים בזהירות. קודם כל, מומלץ להשתמש במפתח SSH במקום גישה עם סיסמה. יש לשמור על ההגדרות של קבצי המפתח בצורה קפדנית, לא לשתף מפתחות פרטיים וככל האפשר להגן עליהם באמצעות passphrase.

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

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

שימוש ב-rsync לגיבויים אוטומטיים

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

ההיגיון לדוגמה: rsync -a --delete --bwlimit=30000 /var/www/site/ backup@כתובת-ip-של-גיבוי:/backup/site/. פקודה זו יכולה לסנכרן את תיקיית היעד עם המקור. עם זאת, יש להשתמש בפרמטר --delete בזהירות. אם קובץ נמחק במקור, הוא גם יימחק ביעד. לכן, באסטרטגיות גיבוי קריטיות, יש להעדיף פתרונות עם snapshot, תיקיות יומיות או תמיכה בגרסאות.

בפעולות אירוח, כלל הגיבוי 3-2-1 הוא הפניה טובה: לפחות 3 עותקים של הנתונים, ב-2 סביבות שונות, עם 1 עותק במקום שונה. rsync מפשט את העברת העותק בין השרתים במסגרת אסטרטגיה זו. עבור תשתית מקיפה יותר, ניתן לחזק את התכנית שלכם עם תכנים על פתרונות גיבוי ו-שירותי אחסון עסקיים.

רשימת בדיקות סופיות

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

• האם rsync מותקן בשרת המקור ובשרת היעד?
• האם נבדק חיבור SSH עם המשתמש והפורט הנכונים?
• האם יש מספיק שטח דיסק בשרת היעד?
• האם התהליך הראשון נבדק בעזרת --dry-run?
• האם תכננתי מצב תחזוקה והסנכרון האחרון לאתר פעיל?
• אם --delete ישתמש, האם נתיב היעד אומת בשום אופן?
• האם יתבצעו בדיקות על גודל הקבצים, הרשאות ואפליקציה לאחר ההעברה?
• האם קבצי גיבוי זמניים ודומם יימחקו בצורה בטוחה?

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

שאלות נפוצות

מה קורה אם החיבור מתנתק במהלך השימוש בפקודת rsync על גבי SSH?

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

האם ניתן להעביר מסד נתונים ישירות בעזרת rsync?

rsync מעביר קבצים; העברת קבצים של מסדי נתונים פעילים אינה בריאה. יש להשתמש ב-mysqldump או בכלים פיזיים לגיבוי עבור MySQL או MariaDB, ולאחר מכן להעביר את קובץ הגיבוי לשרת היעד בעזרת rsync. במערכות חיות יש לתכנן מצב תחזוקה או אסטרטגיות שיחזור נתונים.

האם נדרשת הרשאת root בשני השרתים כדי להשתמש ב-rsync?

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

האם הפרמטר --delete בטוח?

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

מה עדיף בהעברת קבצים גדולים, rsync או scp?

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

סיכום וצעדים הבאים

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

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