מהו היקף הדוגמה ומה אפשר ללמוד ממנה
בניסוי נוצרו שלושה קבצים בתיקייה זמנית: עמוד HTML, קובץ הגדרות ורשומות הזמנה מלאכותיות בפורמט JSON. הקבצים הועתקו לתיקיית גיבוי והוחזרו לתיקיית שחזור נפרדת. לאחר מכן הושוו ערכי SHA-256 ונבדק גם תוכן ההזמנות ששוחזר.
אין כאן מסד נתונים, WordPress, תוסף, שירות ענן או פעולה ברשת. הגיבוי והמקור נמצאים באותו מחשב לצורך ההמחשה ולכן אינם דוגמה להפרדת גיבוי אמיתית. מטרת הניסוי היא להראות איך מחברים היקף, ראיה ומסקנה בדוח, ולא להוכיח יכולת התאוששות של חנות פעילה.
| רכיב | מה נעשה | מה לא נבדק |
|---|---|---|
| קבצים | העתקה ושחזור של שלושה קבצים מלאכותיים | מערכת קבצים מלאה והרשאות ייצור |
| שלמות | השוואת SHA-256 לגיבוי שנוצר | אמינות מקור הגיבוי וזיהוי נוזקה |
| תוכן | פענוח JSON והשוואת מזהים וסכום מלאכותי | מסד נתונים ותהליכי חנות |
| פער זמן | רשומה שנוספה אחרי הגיבוי אינה בשחזור | עמידה ביעד RPO עסקי |
| סביבה | Node.js מקומי ותיקייה זמנית | ענן, הצפנה, מפתחות ו-RTO ייצור |
תוצאה צפויה ותוצאה שנמדדה נשמרות בנפרד
בדיקות הקבלה בקוד דורשות התאמה של שלושת הקבצים לעותק הגיבוי, שתי הזמנות עם המזהים LAB-001 ו-LAB-002 וסכום של 2,000 יחידות מלאכותיות. אלו ערכי הדגמה שנקבעו מראש, לא הכנסה, תשלום או נתון של עסק. קובץ התוצאה מתעד את זמן ההרצה, גרסת Node.js וההשוואות שעברו.
לאחר יצירת הגיבוי מתווספת למקור הרשומה LAB-003. השחזור אינו כולל אותה, והקוד מאמת את היעדרה. זהו פער צפוי בין נקודת הגיבוי לבין המקור החדש: אפשר לשחזר נכון את העותק ובכל זאת להחמיץ מידע שנוצר אחריו. הדוח אינו מתרגם את ההדגמה להבטחה לגבי אובדן נתונים במערכת אמיתית.
ההרצה המתועדת בוצעה ב-30.10.2026, בשעה 05:00:12 UTC, עם Node.js v24.18.0 על Windows. שלוש השוואות הקבצים ובדיקות התוכן עברו; קובץ התוצאה כולל את ערכי ההשוואה המלאים. זמן ההרצה הוא תיעוד הניסוי בלבד ואינו מדד ביצועי שחזור.
איך מריצים את ההדגמה המקומית
קראו את הקוד לפני הפעלה. דרוש Node.js בגרסה 22 ומעלה. הורידו את restore-test-lab.mjs לתיקייה מקומית והריצו בה node restore-test-lab.mjs. התוכנית אינה מקבלת יעד או פרטי התחברות, אינה פונה לרשת ואינה משתמשת בקבצים קיימים שלכם. היא יוצרת תיקייה זמנית ייעודית ומסירה רק אותה בסיום.
פלט JSON מוצג במסוף וניתן לשמור אותו לקובץ חדש בשם שתבחרו. הרצה מוצלחת מסתיימת בקוד יציאה אפס; אי התאמה בבדיקות גורמת לכשל. השתמשו בתוצאה חדשה כדי לתעד את ההרצה שלכם, בלי להציג את זמן ההרצה המקורית כתוצאה שנמדדה אצלכם. אין להרחיב את הקוד לשחזור בייצור בלי תכנון נפרד.
- הורידו וקראו את קוד הניסוי ואת גבולותיו.
- בדקו גרסת Node.js מקומית מתאימה.
- הריצו את הקוד ללא פרמטרים וללא מידע אישי.
- בדקו התאמת קבצים, קבלת תוכן ופער הרשומה החדשה בפלט.
- שמרו תוצאה חדשה בנפרד אם נדרש תיעוד.
מה למלא בתבנית דוח אמיתית
התבנית להורדה מתחילה בנכס, בעל הרשאה, מטרה והחרגות. מוסיפים מזהה גיבוי, נקודת זמן ואזור זמן, רכיבים ותלות בין קבצים למסד נתונים. מתעדים היכן תתבצע הבדיקה וכיצד יבודדו דואר, תשלומים, חשבוניות וחיבורים אחרים. כתבו גם מה לא ייבדק כדי למנוע מסקנה רחבה מהראיות.
לכל בדיקת קבלה מגדירים תוצאה צפויה, תוצאה בפועל וראיה מצומצמת. רשמו את נקודת ההתחלה והסיום אם מודדים משך, ואת התנאים שמגבילים השוואה. שם קובץ ותוצאת העתקה אינם מוכיחים שהנתונים עקביים או שהיישום מתפקד; יש להוסיף בדיקות עסקיות מתאימות.
| שדה | מה לתעד |
|---|---|
| הרשאה והיקף | מי אישר, אילו נכסים ומה הוחרג |
| עותק ונקודת זמן | מזהה גיבוי, תאריך, אזור זמן ותכולה |
| סביבה ובידוד | יעד נפרד, גישה ופעולות חיצוניות שנוטרלו |
| קבלה וראיה | פעולה עסקית, תוצאה צפויה ותוצאה בפועל |
| פער מידע וזמן | מה חסר מאז הגיבוי ומה נמדד בפועל |
| סגירה | מסקנה מוגבלת, בעל טיפול ומועד בדיקה חוזרת |
RTO ו-RPO אינם מספר שמסיקים מהעתקת קובץ
RTO הוא יעד למשך החזרה לפעילות שהוגדרה, ו-RPO מתאר את נקודת השחזור הרצויה מבחינת אובדן נתונים. כדי להשוות ליעדים צריך להגדיר פעילות, התחלה וסיום, תלויות ונקודת זמן. זמן העתקה במחשב מקומי אינו זמן התאוששות עסקי.
במערכת אמיתית משך ההתאוששות עשוי לכלול קבלת גישה, זמינות ספק, הורדת עותק, התקנה ובדיקות משתמש. גם תוצאה טובה בניסיון אחד מוגבלת לתנאים שלו. הדוח צריך להבדיל בין יעד עסקי, מדידה והשערה, ולא להציג הצלחה חלקית כעמידה כוללת בתוכנית התאוששות.
בחנות ובמערכת מחוברת בודקים מעבר לקבצים
כאשר החנות המשיכה לקבל הזמנות אחרי נקודת הגיבוי, צריך למפות מידע שנוצר באתר ובמערכות חיצוניות. שחזור ישן אינו מבטל תשלום אצל ספק או משלוח שכבר נוצר. לפני חזרה לפעילות מגדירים כיצד ישוו ויישבו הזמנות, מלאי ועסקאות בלי פעולה כפולה.
בסביבת בדיקה משתמשים בנתונים ובהרשאות המתאימים ושולטים בחיבורים החיצוניים. WooCommerce מציין שהזמנות ניסיון יכולות לעורר דואר ומערכות המשך. לכן לא מסתפקים בהחלפת כתובת האתר או במצב בדיקה במסוף אחד, ולא מעתיקים מסד ישן לחנות חיה כהוראת שחזור כללית.
מה עושים אחרי הבדיקה
מסכמים הצלחה לפי פעולות שנבדקו ומשאירים פערים גלויים: רכיב שלא שוחזר, גישה חסרה, תוצאה שלא תאמה או רשומה מאוחרת. לכל פער מצמידים בעל תפקיד והמשך טיפול. שמרו ראיות במקום מוגן בהתאם לצורך, עם מידע מצומצם ולא עם סיסמאות או עותקי לקוחות מיותרים.
ניסיון שחזור הוא חלק ממחזור תחזוקה. שינוי אחסון, מבנה נתונים, הצפנה או מערכת חיצונית יכול לדרוש בדיקה חדשה. המקורות המקצועיים מספקים עקרונות לתכנון; הניסוי והתבנית אינם הסמכה, אישור גיבוי או התחייבות לזמן התאוששות.