שיתוף SMB אחרי נפילת VPN: רשימת בדיקה לשחזור

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

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

הפסיקו לכתוב לפני שאתם מתחברים מחדש

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

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

שחזרו את הנתיב, ואז הוכיחו אותו

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

1. ודאו פתרון שמות ונגישות של שרת הקבצים דרך המנהרה.

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

3. אם הכרך לא חוזר, התחברו במכוון דרך Go, ואז Connect to Server, וכתובת השרת המוכרת כגון smb://files.corp.example/team.

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

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

למה הפעלה חדשה לא יכולה להבטיח ידיות פתוחות

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

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

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

אל תכריחו את העיגון להיראות מסודר

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

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

לפני הנפילה המתוכננת הבאה

סיימו שמירות, סגרו קבצים תלויים והוציאו את השיתוף כרגיל לפני שאתם מנתקים VPN בכוונה. הרצף הזה זול ומסיר את כל סוג השאלות הזה.

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