איך לבחור אסטרטגיית גיבוי אפקטיבית

הקדמה

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

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

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

חלק 1 — מה ההבדל בין רדונדנטיות ל לבין גיבוי?

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

הריאליות

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

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

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

גיבוי

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

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

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

חלק 2 — גיבוי ברמת קובץ

אחד מסוגי הגיבויים המוכרים ביותר הוא גיבוי ברמת קובץ. סוג זה של גיבוי משתמש בכלים רגילים להעתקת מערכות הקבצים כדי להעביר קבצים למיקום או מכשיר אחרים.

איך להשתמש בפקודת cp

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

mount /dev/sdc /mnt/my-backup
cp -a /etc/* /mnt/my-backup
umount /dev/sdc

דוגמה זו מרכיבה דיסק נייד, sdc, כ-/mnt/my-backup ולאחר מכן מעתיקה את התיקייה /etc אל הדיסק. לאחר מכן היא מנתקת את הדיסק, שניתן לאחסן במקום אחר.

איך להשתמש ב-Rsync

A better alternative to cp is the rsync command. Rsync is a powerful tool that provides a wide array of options for replicating files and directories across many different environments, with built-in checksum validation and other features. Rsync can perform the equivalent of the cp operation above like so:

mount /dev/sdc /mnt/my-backup
rsync -azvP /etc/* /mnt/my-backup
umount /dev/sdc

-azvP הוא סט טיפוסי של אפשרויות Rsync. כפירוט של מה כל אחד מהם עושה:

• a enables “Archive Mode” for this copy operation, which preserves file modification times, owners, and so on. It is also the equivalent of providing each of the -rlptgoD options individually (yes, really). Notably, the -r option tells Rsync to recurse into subdirectories to copy nested files and folders as well. This option is common to many other copy operations, such as cp and scp.
• z compresses data during the transfer itself, if possible. This is useful for any transfers over slow connections, especially when transferring data that compresses very effectively, like logs and other text.
• v enables verbose mode, so you can read more details of your transfer while it is in progress.
• P tells Rsync to retain partial copies of any files that do not transfer completely, so that transfers can be resumed later.

ניתן לבדוק אפשרויות אחרות של rsync בעמוד המדריך שלועמוד ראשי.

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

rsync -azvP /etc/* username@remote_host:/backup/

זה יגבה את ספריית /etc של המכונה המקומית לספרייה ב-remote_host השוכנת ב-/backup. זה יצליח אם יש לך הרשאה לכתוב לספרייה זו ויש מקום פנוי.

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

כיצד להשתמש בכלי גיבוי אחרים

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

Bacula

בקולה היא פתרון מורכב וגמיש שעובד על בסיס מודל לקוח – שרת. בקולה מותכנת עם מושגים נפרדים של לקוחות, מיקומי גיבוי, ומנהיגים (הרכיב המנחה את הגיבוי האמיתי). היא גם מגדירה כל משימת גיבוי ליחידה בשם "משימה".

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

Duplicity

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

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

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

חלק 3 — גיבויים ברמת בלוקים

A slightly less common, but important alternative to file-level backups are block-level backups. This style of backup is also known as “imaging” because it can be used to duplicate and restore entire devices. Block-level backups allow you to copy on a deeper level than a file. While a file-based backup might copy file1, file2, and file3 to a backup location, a block-based backup system would copy the entire “block” that those files reside on. Another way of explaining the same concept is to say that block-level backups copy information bit after bit. They do not know about the files that may span those bits.

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

שימוש ב-dd לביצוע גיבויים ברמת בלוקים

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

כדי להשתמש ב־dd, עליך לציין מיקום קלט ומיקום פלט, כך:

dd if=/path/of/original/device of=/path/to/place/backup

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

לדוגמה, כדי לגבות מחיצה המכילה את המסמכים שלך, הנמצאת ב־/dev/sda3, ניתן ליצור תמונה של אותו תיקייה על ידי ספק נתיב פלט לקובץ .img:

dd if=/dev/sda3 of=~/documents.img

חלק 4 — גיבויי גרסאות

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

לדוגמה, דרך ידנית להגשים זאת היא ליצור גיבוי של קובץ לפני עריכתו ב־nano:

cp file1 file1.bak
nano file1

אתה יכול אפילו לאוטומטז תהליך זה על ידי יצירת קבצים מוסתרים עם חותמות זמן בכל פעם שאתה משנה קובץ עם העורך שלך. לדוגמה, תוכל לשים את זה בקובץ ~/.bashrc, כך שכל פעם שתפעיל את nano מתוך השלך של bash (כלומר $), זה ייצור בקאפ עם חותמת שנה (%y), חודש (%m), יום (%d), וכן הלאה:

nano() { cp $1 .${1}.`date +%y-%m-%d_%H.%M.%S`.bak; /usr/bin/nano $1; }

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

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

חלק 5 — גיבויים ברמת השרת

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

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

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

תוכל ללמוד עוד על גיבויים וצילומי מסך של DigitalOcean מתוך המסמך מכלי ניהול מיכלים ותמונות.

GitOps

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

מסקנה

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