Coding agents מקבלים גישת shell למחשבים אמיתיים, מריצים migrations, מנקים ומוחקים. עותק שה-agent יכול להגיע אליו הוא עותק שהוא יכול להרוס, גם במהלך משימה שהתבקש לבצע.
זהו סיכון ממשי. הדף מסביר דפוס גיבוי שעובד ואת גבולות ההגנה שלו.
למה הגיבוי הקיים אינו גיבוי ל-AI agent
מודל האיום הרגיל מניח כשל חומרה, טעות אנוש או ransomware. Agent פועל בהרשאות שלכם, במהירות ועם הצדקה סבירה.
כונן רשת mounted, תיקיית sync או object storage עם מפתחות קריאים גלויים גם ל-agent. אם הוא מחליט שתיקייה ישנה, sync מפיץ את המחיקה לעותק.
ההבדל אינו cloud מול local, אלא האם העותק נגיש מסביבת ה-agent.
דפוס הגיבוי: push בלבד, לעולם לא sync
זהו ההבדל המרכזי.
Sync משקף מחיקות, דבר שמתאים לקבצי עבודה ועלול להרוס archive. גם הנחיות CISA ממליצות לבודד עותק מהמערכת המוגנת.
גיבוי מעלה חומר חדש ואינו משקף הסרה. יעדים מתוארכים מוסיפים בכל ריצה. לפי הגודל והתעריף, שלושים עותקים יומיים של database dump עשויים לעלות פחות מכשל restore.
הפרדת פרטי גישה היא כל העניין
השתמשו בנתיב push-only עם credential שסביבת העבודה אינה מחזיקה.
Drive תומך ב-app passwords לכל מכשיר שניתנים לביטול. שמרו credential ייעודי לגיבוי רק במחשב או ב-scheduled job שדוחפים, לא ב-project directory או env file שה-agent קורא. הגבילו הרשאות.
באותו מחשב שמרו אותו מחוץ ל-project tree עם הרשאות OS. Runner נפרד נותן הפרדה טובה יותר. ל-agent אסור להיות נתיב אימות ליעד.
ממה הוא מגן וממה לא
דיוק חשוב יותר מהרגעה.
הוא מגן מפני מחיקה ודריסה בסביבת העבודה, script שמנקה directory, repository reset מקרי, טעות אנוש ומחיקה שמופצת ב-sync, בתנאי שההעלאה והבידוד עובדים.
הוא אינו מגן מפני אדם עם dashboard login והגורם השני, מחיקה מכוונת של archive או נתונים מחוץ ל-scope. הוא גם אינו מחליף version control.
זו שכבה אחת ולא תוכנית security מלאה.
הרשימה הקצרה שכדאי לדחוף
הרשימה קצרה כי רוב working directory ניתן לשחזור.
- Database dumps. ליליים, מתוארכים ונשמרים לפי התוכנית והמדיניות, עם בדיקת שלמות.
- קובצי סביבה והגדרה. קטנים וקשים לשחזור; הצפינו תוכן רגיש והגבילו גישה.
- תוכן משתמשים שהועלה. אינו ב-version control ואינו ניתן ליצירה מחדש.
- Artefacts חשובים שנוצרו. דוחות ו-exports מתהליך שהשתנה.
Remote git repository מתאים בדרך כלל לקוד מקור. השכבה הזאת מיועדת לנתונים שאינם ניתנים לשחזור.
המבנה של nightly job
יישום קצר קל יותר לתחזוקה ולאימות.
Scheduled task יוצרת dump זמני, נותנת לו שם ותיקייה לפי תאריך, מעלה ומוחקת את העותק המקומי הזמני. הגדרות והעלאות פועלות כך. ל-job יש credential משלה ואין בה לוגיקת remote delete.
שני פרטים חשובים: תאריך ביעד מונע החלפה, ואילו filename קבוע משאיר רק עותק אחרון. כשל חייב להיות מדווח ומנוטר. Job שנכשלה בשקט שישה שבועות אינה גיבוי אמין.
בדיקת restore
גיבוי שלא שוחזר הוא השערה.
פעם ברבעון שחזרו ל-disposable environment ובדקו integrity, שלמות, שימושיות ונוהל. Download מוצלח בלבד אינו מוכיח restore.
בדקו גם שה-credential תקפה ו-rotation עודכן. נטרו את צד ה-upload, שעלול להיכשל בשקט.
כמה זמן לשמור
Retention היא שאלת אחסון, מדיניות, חוק ו-privacy.
נזק עשוי להתגלות רק אחרי שבועות. שלושים עותקים יומיים נותנים חודש, אך התקופה תלויה בזמן גילוי, גודל וכללים. חשבו עלות ממשית.
דפוס אפשרי הוא כל יום במשך חודש ואז עותק חודשי לשנה. Prune צריך job נפרדת ומוגבלת. אם uploader יכולה למחוק, הסיכון חוזר.
איפה לשים את הגיבוי
Drive מחובר לאותו חשבון כמו הדואר. לפי ההצעה המתוארת, add-on מתחיל ב-250 GB תמורת $3.20 לחודש על slider עד 100 TB. בדקו תוכניות, retention, encryption ו-egress fees עדכניים.
Storage יכול להיות pooled או מוקצה לכל mailbox. Uploads דרך WebDAV או API כפופות להרשאות. ראו מדריך WebDAV. אפשר לשתף folders עם חשבון אחר לשחזור ללא ה-credential שלכם; בדקו תפקידים וביטול ב-אופן הפעולה של קישורי שיתוף.
העיקר: folder מתוארכת, credential שאין לסביבת העבודה ו-job שרק מוסיפה. אמתו בקביעות שהעותק המבודד שלם וניתן לשחזור.
