שחזור אתר שנפרץ: תכנון לשמירת הזמנות חדשות

הגדירו נקודת מידע ומצב נוכחי לפני החלפה

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

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

מפו רשומות ותלות שנוצרו אחרי הגיבוי

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

מיקום הנתונים ושיטת השחזור חייבים להתאים לחנות

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

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

התאימו תשלום ומצב הזמנה בלי לחייב מחדש

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

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

דוגמה: מסד ישן החזיר הזמנה לסטטוס קודם

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

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

חזרה לשירות דורשת גם כיסוי פגיעה וגם התאמת מידע

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

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