چرا تداوم عملیات مالی به یک برنامه بازیابی نیاز دارد؟

وقتی سامانه مالی یک سازمان از دسترس خارج می‌شود، مسئله فقط باز نشدن چند صفحه نرم‌افزار نیست. ثبت اسناد حسابداری متوقف می‌شود، واحد فروش نمی‌تواند وضعیت اعتبار مشتری را بررسی کند، انبار برای تأیید خروج کالا معطل می‌ماند و مدیر مالی تصویر قابل اتکایی از تعهدات و جریان نقدی ندارد. حتی اگر اختلال کوتاه باشد، تراکنش‌های نیمه‌تمام، ورود دوباره اطلاعات و مغایرت میان واحدها می‌تواند آثار آن را تا روزها ادامه دهد.

استقرار ERP روی سرورهای محلی به سازمان امکان می‌دهد کنترل بیشتری بر محل نگهداری داده، شبکه و زیرساخت داشته باشد؛ اما «محلی بودن» به‌تنهایی به معنی ایمنی نیست. همان سرور ممکن است گرفتار باج‌افزار، خرابی دیسک، قطع برق یا حذف اشتباه اطلاعات شود. از طرف دیگر، نسخه پشتیبانی که هرگز بازیابی نشده است، هنوز یک راهکار اثبات‌شده محسوب نمی‌شود.

برای حفاظت از داده‌های مالی، باید از پیش مشخص باشد چه فرایندهایی در بحران ادامه پیدا می‌کنند، چه کسی درباره توقف یا بازیابی تصمیم می‌گیرد، اطلاعات تا چه نقطه‌ای قابل بازگردانی است و کاربران چگونه دوباره به سامانه متصل می‌شوند. این تصمیم‌ها در قالب برنامه تداوم کسب‌وکار و برنامه بازیابی پس از فاجعه به یکدیگر پیوند می‌خورند.

تفاوت تداوم کسب‌وکار با بازیابی پس از فاجعه چیست؟

برنامه تداوم کسب‌وکار یا BCP به این پرسش پاسخ می‌دهد: «تا زمان رفع بحران، فعالیت‌های حیاتی سازمان چگونه ادامه یابد؟» برای مثال، اگر دسترسی به ERP قطع شود، ممکن است سازمان برای پرداخت‌های ضروری، تأیید سفارش‌های حساس یا ثبت رویدادهای انبار رویه‌ای موقت و کنترل‌شده داشته باشد.

برنامه بازیابی پس از فاجعه یا DRP بر بازگرداندن سامانه‌ها و داده‌ها تمرکز دارد: تشخیص دامنه خرابی، انتخاب نسخه سالم، راه‌اندازی زیرساخت جایگزین، بازیابی پایگاه داده و آزمون صحت عملکرد. DRP بخشی از برنامه گسترده‌تر تداوم کسب‌وکار است، نه جایگزین آن.

این تمایز برای واحد مالی مهم است. ممکن است سرور ظرف یک ساعت دوباره روشن شود، اما اگر سندهای ثبت‌شده در دوره اختلال قابل ردیابی نباشند یا فایل‌های پیوست به اسناد برنگردند، عملیات مالی هنوز واقعاً بازیابی نشده است. بنابراین معیار موفقیت باید «بازگشت فرایند قابل اتکا» باشد، نه صرفاً «بالا آمدن نرم‌افزار».

دو معیار تصمیم‌ساز: RTO و RPO

RTO یا هدف زمان بازیابی، حداکثر مدت قابل‌قبول برای از دسترس خارج بودن یک سرویس است. RPO یا هدف نقطه بازیابی، نشان می‌دهد سازمان حداکثر از دست رفتن چه بازه‌ای از تغییرات داده را می‌پذیرد. این دو معیار باید بر اساس اثر اختلال بر فرایندهای واقعی تعیین شوند، نه صرفاً توان خرید تجهیزات. تعاریف این شاخص‌ها در راهنمای برنامه‌ریزی تداوم NIST نیز مبنای ارزیابی بازیابی هستند. (nvlpubs.nist.gov)

برای نمونه، فرض کنید یک شرکت برای ثبت سفارش و صدور سند مالی، RTO برابر ۳۰ دقیقه و RPO برابر ۵ دقیقه تعیین کرده است. این اعداد صرفاً یک مثال طراحی هستند: تیم فنی باید نشان دهد در سناریوهای مشخص می‌تواند خدمت را حداکثر پس از ۳۰ دقیقه برگرداند و بیش از پنج دقیقه تغییرات تأییدشده را از دست ندهد. اگر بازیابی آزمایشی دو ساعت طول بکشد، هدف روی کاغذ تحقق نیافته است.

کدام بحران‌ها سرور محلی و داده مالی را تهدید می‌کنند؟

حمله باج‌افزاری و آلودگی نسخه‌های پشتیبان

باج‌افزار ممکن است فایل‌های سرور، مخزن پشتیبان یا حساب‌های مدیریتی را هدف بگیرد. اگر نسخه‌های پشتیبان همیشه از همان حساب کاربری و همان شبکه قابل‌تغییر باشند، مهاجم می‌تواند پیش از رمزگذاری داده اصلی، امکان بازیابی را هم از بین ببرد. به همین دلیل، داشتن چند نسخه روی یک فضای ذخیره‌سازی متصل، لزوماً معادل داشتن چند مسیر مستقل بازیابی نیست.

در این سناریو، نخست باید آلودگی مهار و محدوده نفوذ مشخص شود. سپس بازیابی باید از نسخه‌ای انجام شود که سالم بودن آن بررسی شده است؛ بازگرداندن سریع یک سرور آلوده می‌تواند بحران را تکرار کند. راهنمای CISA بر نگهداری نسخه‌های پشتیبان آفلاین و رمزگذاری‌شده و آزمون منظم بازیابی تأکید می‌کند. (cisa.gov)

اختلال ارتباطی و وابستگی‌های پنهان شبکه

قطع ارتباطات بیرونی همیشه به معنی توقف ERP مستقر در ساختمان سازمان نیست. اگر برنامه، پایگاه داده، شبکه داخلی و مسیر دسترسی کاربران همگی در دسترس باشند، بخشی از عملیات می‌تواند ادامه یابد. اما این نتیجه فقط زمانی درست است که وابستگی‌های بیرونی نیز شناسایی شده باشند.

برای مثال، ممکن است ورود کاربران به سرویس احراز هویتی خارج از شبکه محلی وابسته باشد، آدرس سامانه از طریق DNS بیرونی resolve شود یا صدور فاکتور به سرویس دیگری نیاز داشته باشد. ارتباط با شعب، بانک‌ها، درگاه‌های پرداخت و سامانه‌های بیرونی نیز ممکن است مختل بماند. در DRP باید مشخص شود کدام فعالیت‌ها واقعاً آفلاین یا در شبکه داخلی قابل انجام‌اند و داده‌های ثبت‌شده در دوره اختلال چگونه بعداً با سامانه‌های بیرونی تطبیق داده می‌شوند.

خرابی سخت‌افزار و خطای انسانی

خرابی ذخیره‌ساز، کنترلر، منبع تغذیه یا میزبان مجازی‌سازی ممکن است بدون هشدار طولانی رخ دهد. افزونگی سخت‌افزاری احتمال توقف را کاهش می‌دهد، اما جای نسخه پشتیبان را نمی‌گیرد؛ خطای نرم‌افزاری یا حذف داده می‌تواند به محیط جایگزین نیز منتقل شود.

خطای انسانی هم همیشه محدود به حذف یک فایل نیست. اجرای دستور روی پایگاه داده اشتباه، تغییر نادرست سطح دسترسی یا نصب نسخه ناسازگار یک ماژول می‌تواند داده‌های مالی را مخدوش کند. در چنین مواردی، «بازگشت به لحظه پیش از خطا» اغلب مهم‌تر از روشن کردن سریع سرور دوم است.

نقطه شروع DRP: شناخت فرایندها و وابستگی‌های مالی

پیش از انتخاب ابزار پشتیبان‌گیری یا کلاسترینگ، باید نقشه فرایندهای حیاتی تهیه شود. این نقشه مشخص می‌کند توقف هر خدمت چه اثری بر دریافت و پرداخت، حسابداری، فروش، خرید، انبار و گزارشگری دارد. همچنین نشان می‌دهد هر فرایند به کدام سامانه، فایل، کاربر کلیدی و سرویس شبکه وابسته است.

برای یک ERP مبتنی بر اودوو، توجه فقط به پایگاه داده کافی نیست. پیوست‌های اسناد و سایر فایل‌ها ممکن است در filestore نگهداری شوند؛ تنظیمات برنامه، ماژول‌های سفارشی و اجزای ارتباطی نیز برای راه‌اندازی مجدد لازم‌اند. مستندات اودوو بر پشتیبان‌گیری از پایگاه داده و filestore و انتقال نسخه‌ها به محل آرشیوی که از سرور اصلی قابل‌دسترسی نباشد تأکید می‌کند. (odoo.com)

خروجی این مرحله باید برای هر خدمت روشن کند: مالک فرایند چه کسی است، چه داده‌ای حیاتی است، RTO و RPO قابل‌قبول چیست و در زمان اختلال چه رویه موقتی مجاز است. بدون این توافق، تیم فنی ممکن است سامانه‌ای را زودتر بازیابی کند که برای عملیات مالی در آن لحظه اولویت پایین‌تری دارد.

پشتیبان‌گیری گرم و سرد؛ دو نقش متفاوت در حفاظت از داده

اصطلاحات «گرم» و «سرد» در گفت‌وگوهای فنی گاهی برای موضوعات متفاوت به کار می‌روند. پشتیبان‌گیری گرم یا Hot Backup معمولاً به تهیه نسخه سازگار در زمانی اشاره دارد که پایگاه داده همچنان فعال است. در مقابل، نسخه سرد ممکن است به پشتیبانی تهیه‌شده در حالت توقف سرویس یا به نسخه‌ای اشاره کند که پس از تهیه، از محیط عملیاتی جدا و آفلاین نگهداری می‌شود. بنابراین در سند اجرایی DRP باید دقیقاً نوشته شود منظور از «سرد» کدام است.

برای ERP مالی که توقف روزانه آن دشوار است، تهیه نسخه پشتیبان در حین کار سامانه اهمیت دارد. PostgreSQL روش‌هایی برای تهیه نسخه پایه و نگهداری سوابق تغییرات در WAL ارائه می‌کند. با ترکیب نسخه پایه و آرشیو پیوسته WAL، می‌توان در شرایط مناسب پایگاه داده را تا نقطه زمانی مشخصی بازیابی کرد؛ قابلیتی که برای بازگشت به پیش از یک حذف اشتباه ارزشمند است. البته pg_dump به‌تنهایی نسخه پایه لازم برای بازپخش WAL نیست. (postgresql.org)

نسخه‌های جداشده یا آفلاین نقش دیگری دارند: حفظ مسیر بازیابی زمانی که محیط اصلی یا حساب‌های مدیریتی آن آسیب دیده‌اند. سیاست مناسب باید دست‌کم به این پرسش‌ها پاسخ دهد: نسخه‌ها کجا قرار می‌گیرند، چه کسی اجازه حذف آن‌ها را دارد، تا چه مدت نگهداری می‌شوند، چگونه رمزگذاری می‌شوند و بازیابی آن‌ها هر چند وقت یک‌بار آزموده می‌شود.

چرا زمان‌بندی پشتیبان‌گیری باید از RPO پیروی کند؟

اگر کسب‌وکار فقط از دست رفتن چند دقیقه تراکنش را می‌پذیرد، یک نسخه کامل روزانه به‌تنهایی کافی نیست. در چنین حالتی باید روش ثبت و انتقال تغییرات میان دو نسخه کامل نیز طراحی شود. برعکس، زیاد کردن تعداد نسخه‌ها بدون سنجش زمان بازگردانی ممکن است فضای ذخیره‌سازی را پر کند، اما RTO را بهبود ندهد.

حجم داده، سرعت نوشتن تراکنش‌ها، پهنای باند، زمان انتقال نسخه به محل امن و مدت بازپخش سوابق تغییرات همگی بر نتیجه اثر دارند. علاوه بر آن، نسخه پایگاه داده و filestore باید به نحوی نگهداری شوند که هنگام بازیابی، رکوردها و فایل‌های وابسته به آن‌ها با یکدیگر سازگار باشند. این سازگاری باید در آزمون بازیابی بررسی شود، نه صرفاً از موفق بودن وظیفه زمان‌بندی‌شده پشتیبان‌گیری نتیجه گرفته شود.

کلاسترینگ PostgreSQL چگونه زمان توقف را کاهش می‌دهد؟

در معماری متداول دسترس‌پذیری بالا، یک سرور PostgreSQL نقش اصلی را دارد و یک یا چند سرور آماده‌به‌کار تغییرات آن را دریافت می‌کنند. اگر سرور اصلی از دسترس خارج شود، سرور آماده‌به‌کار می‌تواند پس از طی فرایند کنترل‌شده جای آن را بگیرد. مستندات PostgreSQL میان warm standby، که پس از ارتقا نقش آماده خدمت‌رسانی می‌شود، و hot standby، که پیش از ارتقا نیز می‌تواند پرس‌وجوی فقط‌خواندنی پاسخ دهد، تمایز می‌گذارد؛ این اصطلاحات را نباید با پشتیبان‌گیری گرم و سرد یکی دانست. (postgresql.org)

در همان حال، تکثیر داده پشتیبان‌گیری نیست. اگر کاربری یک سند را اشتباه حذف کند یا داده در سرور اصلی مخدوش شود، تغییر ممکن است به سرور آماده‌به‌کار نیز برسد. کلاستر بیشتر برای کاهش زمان توقف ناشی از خرابی یک جزء به کار می‌رود؛ نسخه‌های مستقل و امکان بازیابی نقطه‌ای برای خطاهای منطقی و حملات ضروری‌اند.

تکثیر هم‌زمان یا ناهم‌زمان؛ انتخاب میان دوام و دسترس‌پذیری

در تکثیر ناهم‌زمان، ممکن است تراکنشی روی سرور اصلی تأیید شده باشد اما هنوز به سرور آماده‌به‌کار نرسیده باشد. بنابراین هنگام خرابی ناگهانی سرور اصلی، احتمال از دست رفتن بخشی از آخرین تراکنش‌ها وجود دارد. تکثیر هم‌زمان می‌تواند این فاصله را برای تراکنش‌های تأییدشده کاهش دهد، اما انتظار برای پاسخ سرور دیگر بر تأخیر ثبت تراکنش اثر می‌گذارد و در بعضی شرایطِ قطع ارتباط می‌تواند دسترس‌پذیری نوشتن را تحت تأثیر قرار دهد. تنظیمات دقیق و رفتار مورد انتظار باید بر اساس معماری انتخاب شوند. (postgresql.org)

بنابراین ادعای «RPO صفر» بدون توضیح شیوه تأیید تراکنش، وضعیت ارتباط میان سرورها و محل نگهداری فایل‌های پیوست دقیق نیست. هدف حرفه‌ای، نزدیک کردن RPO و RTO به صفر در سناریوهای تعریف‌شده و اثبات نتیجه در آزمون است؛ نه وعده حذف کامل هر نوع توقف یا از دست رفتن داده.

همچنین جابه‌جایی خودکار باید از فعال شدن هم‌زمان دو سرور اصلی جلوگیری کند. تیم زیرساخت لازم است وضعیت سرورها، تأخیر تکثیر، مسیر اتصال برنامه و شرایط بازگرداندن سرور قبلی به چرخه را پیشاپیش تعریف و آزمایش کند. در غیر این صورت، سرعت جابه‌جایی ممکن است به بهای ابهام در نسخه معتبر داده تمام شود.

رمزنگاری داده‌های مالی در استقرار محلی اودوو

امنیت داده مالی به یک گزینه «فعال‌سازی رمزنگاری» خلاصه نمی‌شود. باید مسیر حرکت داده، محل ذخیره آن و افرادی که به نسخه‌های پشتیبان و کلیدها دسترسی دارند، جداگانه بررسی شوند. در پروژه ERP مبتنی بر اودوو، کنترل‌های امنیتی باید متناسب با معماری واقعی استقرار و ماژول‌های مورد استفاده طراحی و راستی‌آزمایی شوند؛ نمی‌توان بدون بررسی پیاده‌سازی، قابلیتی را به یک نسخه بومی‌سازی‌شده نسبت داد.

حفاظت از داده در زمان انتقال

ارتباط کاربر با اودوو باید از مسیر امن برقرار شود. مستندات استقرار اودوو استفاده از HTTPS را برای جلوگیری از شنود اطلاعات احراز هویت ضروری می‌داند. اگر برنامه و PostgreSQL روی میزبان‌های جداگانه قرار دارند، ارتباط میان آن‌ها نیز باید بررسی شود؛ PostgreSQL از اتصال رمزگذاری‌شده با TLS پشتیبانی می‌کند. امن بودن صفحه ورود به‌تنهایی به معنی امن بودن تمام مسیرهای ارتباطی پشت سامانه نیست. (odoo.com)

حفاظت از داده در زمان نگهداری

رمزگذاری دیسک یا فضای ذخیره‌سازی، رمزگذاری نسخه‌های پشتیبان و کنترل دسترسی به فایل‌های پیوست، لایه‌های مکمل هستند. رمزگذاری نسخه پشتیبان زمانی مفید است که کلید بازیابی آن در بحران واقعاً در دسترس افراد مجاز باشد؛ نگهداری کلید فقط روی سروری که ممکن است از کار بیفتد، خود به مانع بازیابی تبدیل می‌شود.

از سوی دیگر، رمزگذاری دیسک مانع سوءاستفاده کاربری که با دسترسی معتبر وارد برنامه شده است نمی‌شود. نقش‌های کاربری محدود، تفکیک وظایف، ثبت رویدادها، مدیریت حساب‌های مدیریتی و بازبینی دسترسی پیمانکاران نیز برای محرمانگی و صحت داده مالی لازم‌اند. طراحی امنیت باید هم خطر سرقت داده را کاهش دهد و هم امکان بازیابی کنترل‌شده را حفظ کند.

سناریوی عملی بازیابی: از تشخیص بحران تا بازگشت عملیات

یک DRP کاربردی باید مانند دستورالعمل اجرایی نوشته شود. فرض کنید سامانه مالی در ساعات کاری از دسترس خارج شده است. نخست، تیم مسئول باید تشخیص دهد با خرابی سخت‌افزار روبه‌روست، قطع ارتباط رخ داده یا نشانه‌ای از آلودگی و دستکاری وجود دارد. اگر احتمال حمله مطرح باشد، اولویت با مهار و حفظ شواهد است؛ اتصال شتاب‌زده سرور جایگزین به همان محیط آلوده، تصمیم امنی نیست.

در گام بعد، مسئول بحران درباره مسیر بازیابی تصمیم می‌گیرد: جابه‌جایی به سرور آماده‌به‌کار، بازیابی از نسخه سالم یا ادامه موقت عملیات با رویه دستی. این تصمیم باید با RTO و RPO مصوب، سلامت نسخه‌ها و وضعیت filestore سازگار باشد. تیم فنی سپس پایگاه داده، فایل‌ها، تنظیمات و مسیر دسترسی کاربران را بازمی‌گرداند.

بازگشت صفحه ورود پایان کار نیست. واحد مالی باید چند کنترل نمونه را انجام دهد: مشاهده آخرین اسناد تأییدشده، باز شدن پیوست‌های مرتبط، صحت مانده‌های کلیدی و تعیین تکلیف تراکنش‌هایی که هنگام اختلال نیمه‌تمام مانده‌اند. ثبت دوباره یک سند بدون کنترل می‌تواند به اندازه حذف آن مشکل‌ساز باشد. پس از تأیید مالکان فرایند، عملیات عادی از سر گرفته می‌شود و برنامه بازگشت از محیط جایگزین به محیط اصلی نیز جداگانه اجرا خواهد شد.

آزمون بازیابی؛ جایی که طرح از وعده به قابلیت تبدیل می‌شود

گزارش «پشتیبان‌گیری موفق» تنها نشان می‌دهد یک عملیات تهیه نسخه اجرا شده است. آزمون بازیابی باید نشان دهد نسخه قابل خواندن است، پایگاه داده و filestore با هم کار می‌کنند، کاربران مجاز می‌توانند وارد شوند و فرایندهای حیاتی نتیجه درست می‌دهند.

آزمون‌ها بهتر است چند سناریو را پوشش دهند: خرابی یک سرور، حذف اشتباه داده، از دسترس خارج شدن محل ذخیره نسخه‌ها و آلودگی محیط اصلی. در هر آزمون باید زمان واقعی تشخیص، زمان تصمیم‌گیری، مدت بازگردانی و نقطه داده بازیابی‌شده ثبت شود. اگر نتیجه با RTO یا RPO هدف فاصله دارد، پاسخ مناسب اصلاح معماری یا بازنگری هدف با مشارکت کسب‌وکار است؛ نه ثبت یک عدد مطلوب در سند.

DRP همچنین باید پس از تغییرات مهم به‌روز شود. افزودن شعبه، تغییر نسخه اودوو، نصب ماژول سفارشی یا جابه‌جایی محل نگهداری فایل‌ها ممکن است مسیر بازیابی قبلی را ناقص کند. برنامه‌ای که با محیط امروز سازمان هم‌خوان نباشد، در روز بحران راهنما نخواهد بود.

جمع‌بندی: امنیت مالی نتیجه طراحی، آزمون و مسئولیت‌پذیری است

برای حفظ تداوم کسب‌وکار روی سرورهای محلی، هیچ ابزار واحدی کافی نیست. پشتیبان‌گیری مستقل برای بازگشت از حذف و آلودگی لازم است؛ کلاستر PostgreSQL می‌تواند زمان توقف برخی خرابی‌ها را کاهش دهد؛ رمزنگاری و کنترل دسترسی از محرمانگی داده محافظت می‌کنند؛ و رویه‌های کسب‌وکار اجازه می‌دهند تصمیم‌های مالی در دوره اختلال بدون آشفتگی گرفته شوند. ارزش واقعی این مجموعه زمانی مشخص می‌شود که بازیابی کامل، شامل پایگاه داده، فایل‌های پیوست و فرایندهای مالی، آزموده شده باشد.

اگر ERP سازمان شما بر بستر اودوو یا سرورهای محلی اجرا می‌شود، اکنون زمان مناسبی برای ارزیابی شکاف‌های تداوم عملیات است. برای بررسی وابستگی‌های مالی، تعیین RTO و RPO واقع‌بینانه و طراحی مسیر پشتیبان‌گیری و بازیابی متناسب با زیرساختتان، با تیم تسهیل‌گستر درباره مشاوره، مشاهده دمو یا پیاده‌سازی ERP بومی‌سازی‌شده سازمان‌یار گفت‌وگو کنید. نتیجه مطلوب، صرفاً استقرار یک نرم‌افزار نیست؛ آمادگی سنجش‌پذیر برای ادامه کار در روزی است که زیرساخت مطابق انتظار عمل نمی‌کند.

سوالات متداول

آیا داشتن سرور محلی، مشکل قطع ارتباطات را کاملاً حل می‌کند؟

خیر. اگر کاربران، پایگاه داده و سرویس‌های لازم در شبکه داخلی در دسترس باشند، برخی عملیات می‌توانند ادامه پیدا کنند. اما احراز هویت، ارتباط شعب، خدمات بانکی و سایر یکپارچگی‌های وابسته به بیرون ممکن است همچنان مختل شوند. باید این وابستگی‌ها در آزمون قطع ارتباط بررسی شوند.

تفاوت کلاستر PostgreSQL با نسخه پشتیبان چیست؟

کلاستر با آماده نگه داشتن سرور جایگزین، عمدتاً به کاهش توقف خدمت کمک می‌کند. نسخه پشتیبان امکان بازگشت به داده سالم یا نقطه‌ای پیش از خطا را فراهم می‌کند. حذف اشتباه یا آلودگی داده ممکن است به سرور آماده‌به‌کار نیز منتقل شود؛ بنابراین هر دو راهکار لازم‌اند.

آیا با تکثیر هم‌زمان می‌توان RPO را همیشه صفر کرد؟

برای برخی تراکنش‌های تأییدشده و در یک معماری مشخص، تکثیر هم‌زمان می‌تواند خطر از دست رفتن داده را بسیار کاهش دهد. بااین‌حال، نتیجه به تنظیمات، وضعیت سرورها، نحوه جابه‌جایی و سازگاری فایل‌های خارج از پایگاه داده وابسته است. «صفر» باید برای سناریوی دقیق تعریف و در آزمون اثبات شود، نه به‌عنوان تضمینی عمومی مطرح شود. (postgresql.org)

در پشتیبان‌گیری از اودوو، چرا filestore مهم است؟

زیرا بخشی از فایل‌ها و پیوست‌ها ممکن است بیرون از رکوردهای پایگاه داده و در filestore نگهداری شوند. بازگرداندن پایگاه داده بدون فایل‌های متناظر می‌تواند اسناد یا پیوست‌های ناقص ایجاد کند. برنامه بازیابی باید سازگاری این دو بخش را بررسی کند. (odoo.com)

هر چند وقت یک‌بار باید بازیابی آزمایشی انجام شود؟

فاصله آزمون به اهمیت فرایند، میزان تغییرات سامانه و ریسک قابل‌قبول سازمان بستگی دارد. مهم‌تر از تعیین یک فاصله یکسان برای همه شرکت‌ها، داشتن برنامه دوره‌ای و آزمون دوباره پس از تغییرات مهم زیرساخت یا نرم‌افزار است. در هر نوبت باید زمان واقعی بازیابی و صحت داده‌های مالی ثبت شود.