אות כונן ממופה יכול להרגיש „מקומי“, אבל הבייטים לעיתים קרובות חיים במחשב אחר לגמרי. שיתופי SMB, התקני NAS ומנועי סנכרון לענן כל אחד עם סמנטיקת מחיקה, סל מחזור ולוח צילומים משלו. כלי שחזור ברמת בלוקים מקומיים רואים רק מה ש־Windows חושפת כנפח — ולעיתים הסיפור המעניין נמצא בצד השרת.

המאמר מגדיר ציפיות לסינון Help Desk: אילו שאלות לשאול, מה לבדוק בממשק הניהול של ה־NAS, ולמה „להריץ את Recuva חזק יותר“ לפעמים הוא המרשם הלא נכון.

מה „שחזור מקומי“ יכול ולא יכול לראות

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

שאלות שחוסכות שעות

האם הנתיב היה UNC, אות ממופה, או תיקייה מקומית שסנכרון לקוח מנהל?
האם המשתמש מחק מסייר הקבצים, מממשק אינטרנט, או מאפליקציה ניידת לאותו חשבון?
האם ל־NAS יש צילומים (ZFS/Btrfs), אינטגרציה לגרסאות קודמות, או תיקיית מחזור לכל שיתוף?
האם „הנתונים החסרים“ הם בעצם קבצי מצביע לא מקוון (רק בענן) ולא בייטים מקומיים שנמחקו?

תיקיות ענן רק־דפדפן

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

מתי כלי מקומיים עדיין משנים

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