برای اطمینان از سلامت بک‌آپ Odoo 19، فایل پشتیبان را در محیطی جدا بازیابی کنید، وجود پیوست‌ها را بسنجید و چند فرایند واقعی کسب‌وکار را بدون ارتباط با سامانه‌های عملیاتی بیازمایید. موفقیت دانلود یا نمایش پیام «Backup completed» به‌تنهایی ثابت نمی‌کند که فردا بتوانید کار سازمان را از همان نسخه ادامه دهید.
این راهنما برای مدیران نصب‌های اختصاصی و Docker نوشته شده است. هدف، طراحی یک آزمون بازیابی تکرارپذیر است؛ دستورهای نمونه فقط برای محیط آزمایش آماده‌شده‌اند. هیچ‌یک را روی دیتابیس فعال سازمان اجرا نکنید. نام‌ها و مسیرهای مثال ساختگی‌اند و باید با مشخصات محیط آزمایش شما جایگزین شوند.
چرا داشتن فایل بک‌آپ کافی نیست؟
بک‌آپ ممکن است سالم منتقل شده باشد، اما بخشی از فایل‌ها، کد یک ماژول اختصاصی یا ابزار تولید گزارش در مقصد موجود نباشد. حتی ممکن است صفحهٔ ورود باز شود و اولین فاکتور PDF یا تصویر محصول خطا بدهد. پس باید میان «سلامت آرشیو»، «قابل بازیابی بودن» و «قابل استفاده بودن سامانه» تفاوت بگذاریم. هر کدام آزمون جدا و مدرک جدا می‌خواهد.
در مقالهٔ تأثیر استفاده از اودو در رشد کسب‌وکارها، یکپارچگی اطلاعات میان واحدها مطرح شده است. همان یکپارچگی، دامنهٔ آزمون بازیابی را هم تعیین می‌کند: بررسی یک فرم، سلامت همهٔ مسیر فروش، انبار و مالی را اثبات نمی‌کند.
بستهٔ بازیابی Odoo 19 باید چه چیزهایی داشته باشد؟
در ذخیره‌سازی استاندارد Odoo، بخشی از اطلاعات پیوست در دیتابیس و محتوای فایل‌ها در filestore نگهداری می‌شود؛ برخی پیوست‌ها نیز می‌توانند داخل دیتابیس باشند. محل filestore تابع تنظیم data_dir و نام دیتابیس است. بنابراین کپی دیتابیس به‌تنهایی لزوماً همهٔ اسناد و تصویرها را برنمی‌گرداند. پیاده‌سازی رسمی پیوست‌ها مبنای این تفکیک است.
| جزء | کنترل پیشنهادی پیش از آزمون |
|---|---|
| دیتابیس و filestore | شناسایی قالب بک‌آپ و اطمینان از وجود فایل‌های متناظر با همان نوبت پشتیبان‌گیری |
| نسخهٔ Odoo و افزونه‌ها | ثبت نسخهٔ دقیق برنامه، ویرایش Community یا Enterprise و نسخهٔ ماژول‌های اختصاصی |
| وابستگی‌ها و پیکربندی | آماده بودن ابزار گزارش، فونت فارسی و مسیرهای داده در محیط مقصد |
| ذخیره‌سازی و اتصال‌های بیرونی | شناسایی فایل‌های خارج از filestore و تعیین روش بازیابی و مسدودسازی اتصال‌های واقعی |
نسخهٔ تولید را مبنای محیط آزمایش بگیرید؛ هم‌زمان کردن آزمون بازیابی با ارتقای نسخه یا تغییر گستردهٔ افزونه‌ها، تشخیص علت خطا را دشوار می‌کند. فهرست نسخه‌ها را کنار بک‌آپ نگه دارید، اما رمزها و کلیدها را داخل گزارش آزمون ننویسید. اطلاعات لازم برای بازیابی اسرار باید در محل امن جداگانه و با دسترسی محدود موجود باشد.
نکتهٔ سازگاری: PostgreSQL با pg_dump از دیتابیس در حال استفاده یک نمای سازگار تهیه می‌کند؛ این تضمین مربوط به دیتابیس است. هماهنگی آن با کپی فایل‌های بیرون از دیتابیس باید در طراحی بک‌آپ بررسی شود. روش snapshot یا هماهنگ‌سازی مناسب را با توجه به ابزار پشتیبان‌گیری خود انتخاب کنید و کپی مستقل دو جزء را خودکار معادل یک نقطهٔ بازیابی هماهنگ ندانید. مرجع PostgreSQL 16 دامنهٔ تضمین ابزار را توضیح می‌دهد.
گام اول: محیط آزمایش را پیش از اولین اجرا جدا کنید
دیتابیس مقصد، مسیر داده، volume و نام سرویس باید مستقل باشند. ظرف آزمایشی را به volume زندهٔ Odoo متصل نکنید؛ تغییر مسیر در فایل تنظیمات، وقتی mount همچنان به دادهٔ اصلی اشاره می‌کند، جداسازی کافی نیست. پیش از شروع، مقصد اتصال PostgreSQL و مسیر ذخیره‌سازی را دوباره تطبیق دهید.
به‌عنوان اقدام عملیاتی پیشنهادی، دسترسی خروجی محیط تست را به مقصدهای ضروری محدود کنید و ورودی آن را فقط برای تیم آزمون باز بگذارید. SMTP، پیامک، پیام‌رسان، پرداخت، وب‌هوک و تلفنی که از دادهٔ تولید کپی شده‌اند باید زیر کنترل باشند. خنثی‌سازی استاندارد Odoo بخشی از این خطر را پوشش می‌دهد، اما دربارهٔ رفتار هر افزونهٔ اختصاصی باید جدا تصمیم گرفت.
خنثی‌سازی چه کمکی می‌کند؟
Odoo 19 برای دیتابیس آزمایشی امکان neutralize دارد. مستند رسمی از غیرفعال شدن قابلیت‌هایی مانند اقدامات زمان‌بندی‌شده، ایمیل خروجی و ارائه‌دهندگان پرداخت نام می‌برد و تأکید می‌کند فهرست آن کامل نیست. این کار را جایگزین محدودسازی شبکه یا ناشناس‌سازی اطلاعات محرمانه ندانید. مرجع دیتابیس خنثی‌شده حدود این رفتار را شرح می‌دهد.
گام دوم: سلامت و نوع آرشیو را بررسی کنید
فایل را از مخزن معتبر دریافت کنید و زمان تهیه، اندازه و شناسهٔ نسخه را ثبت کنید. اگر checksum معتبر در مبدأ دارید، مقدار مقصد را با آن مقایسه کنید. ساختن هش فقط پس از دانلود، به‌تنهایی درستی فایل نسبت به مبدأ یا کامل بودن محتوای آن را اثبات نمی‌کند. همچنین آرشیو پشتیبان دادهٔ حساس دارد؛ نگهداری آن در پوشهٔ عمومی وب مناسب نیست.
نمونهٔ زیر فقط یک فایل ZIP محلی را می‌خواند و در دیتابیس چیزی نمی‌نویسد. خروجی موفق آزمون ZIP، تأیید ساختار آرشیو است؛ آزمون بازیابی و کاربردپذیری همچنان باقی می‌ماند.
sha256sum /srv/restore-input/backup.zip
python3 -m zipfile -t /srv/restore-input/backup.zipقالب فایل را از ابزار تولیدکننده تشخیص دهید، نه فقط پسوند. آرشیو ZIP اودو، dump سفارشی PostgreSQL و فایل SQL روش یکسانی برای بازیابی ندارند. در CLI بررسی‌شدهٔ شاخهٔ 19.0، مسیر db load برای ZIP است؛ dump خام باید با ابزار متناظر PostgreSQL بازیابی شود. این تفاوت در کد رسمی فرمان دیتابیس نیز مشخص است.
گام سوم: ZIP را با نام جدید و خنثی‌سازی بازیابی کنید
ابتدا راهنمای همان binary نصب‌شده را بخوانید. نمونهٔ زیر برای نصب از سورس Odoo 19 است؛ مسیر برنامه و تنظیمات باید متعلق به محیط تست باشند. در Docker، همین دستور باید داخل کانتینر آزمایشی مناسب و با مسیر فایل قابل دسترس برای همان کانتینر اجرا شود. هیچ نام کانتینری در این راهنما مفروض نیست.
./odoo-bin db --help
./odoo-bin db load --help
./odoo-bin db --config /etc/odoo/restore-test.conf \
load --neutralize restore_check_19 /srv/restore-input/backup.zipپیش‌شرط این مثال آن است که فایل تنظیمات، اتصال پایگاه داده، مسیر داده و افزونه‌های محیط آزمایش را تعریف کند و نام مقصد از قبل وجود نداشته باشد. از گزینهٔ --force استفاده نشده است، چون می‌تواند دیتابیس موجود مقصد را حذف کند. در صورت برخورد نام، ابتدا علت را بررسی کنید؛ نام تازهٔ تأییدشده انتخاب کنید و خطا را با حذف مقصد دور نزنید. گزینه‌ها را با مرجع CLI نسخهٔ ۱۹ تطبیق دهید.
پس از موفقیت restore، تنظیم انتخاب دیتابیس و سرویس وب آزمایشی را به همان نام جدید محدود کنید. پیش از باز کردن برنامه برای کاربران تست، وضعیت خنثی‌سازی، اتصال‌های اختصاصی و محدودیت خروجی را کنترل کنید. این مراحل مجوزی برای فعال‌کردن دوبارهٔ سرویس‌های عملیاتی کپی‌شده نیستند.
گام چهارم: فراتر از صفحهٔ ورود آزمون کنید
یک چک‌لیست کوچک اما نمایندهٔ کار روزانه بسازید. نمونه‌ها را از قبل و با دسترسی مجاز انتخاب کنید تا بعداً نتیجه قابل مقایسه باشد. باز شدن منوها را با سلامت سندها یا رابطهٔ میان رکوردها اشتباه نگیرید.
- ورود و دسترسی: با یک کاربر مجاز، شرکت درست و چند منوی اصلی را بررسی کنید؛ آزمون همه‌چیز با حساب مدیر، نقص دسترسی کاربران عادی را پنهان می‌کند.
- فایل‌ها: چند پیوست قدیمی و جدید، تصویر محصول و سند بارگذاری‌شده را باز کنید. انتخاب نمونه از چند دوره، احتمال ندیدن نقص بخشی از filestore را کمتر می‌کند.
- گزارش فارسی: یک گزارش مجاز را در محیط تست تولید و جهت متن، فونت، ارقام و صفحه‌بندی را ببینید. وجود فایل PDF به‌تنهایی نشانهٔ خوانایی آن نیست.
- رابطهٔ فرایندها: یک مسیر سفارش تا سندهای وابسته را مشاهده کنید. اگر ایجاد سند آزمایشی لازم است، سناریو و اثر مورد انتظار را پیشاپیش تعیین کنید و ارتباط بیرونی را بسته نگه دارید.
- نسخه و خطا: وضعیت افزونه‌های لازم و لاگ همان بازهٔ آزمون را بررسی کنید؛ خطاهای قدیمی را از خطاهای تکرارپذیر مقصد جدا ثبت کنید.
خطاهای رایج را چگونه تفکیک کنیم؟
| نشانه | فرضیه برای بررسی | کنترل بعدی |
|---|---|---|
| رکورد باز می‌شود، پیوست باز نمی‌شود | کمبود فایل، مسیر اشتباه یا مجوز خواندن | تطبیق فایل متناظر با دیتابیس و مسیر واقعی mount |
| Registry یا یک ماژول بارگذاری نمی‌شود | کد یا وابستگی نامتناسب با نسخهٔ بک‌آپ | مقایسهٔ نسخه‌ها و اولین خطای معنادار لاگ |
| گزارش فارسی ناقص است | فونت یا وابستگی گزارش در مقصد متفاوت است | مقایسهٔ محیط گزارش‌گیری با نسخهٔ مبنا |
| تلاش برای ارتباط بیرونی دیده می‌شود | اتصال اختصاصی زیر پوشش کامل neutralize نیست | حفظ انسداد خروجی و بازبینی همان اتصال در تست |
این جدول علت قطعی هیچ رخدادی را اعلام نمی‌کند. هر مورد یک مسیر تشخیص پیشنهادی است؛ شواهدی مانند نام فایل گمشده، نسخهٔ افزونه یا خطای اتصال باید فرضیه را تأیید کند. برای رفع مشکل، بک‌آپ اصلی را دست‌کاری نکنید و اصلاحات آزمایش را در کپی جدا نگه دارید.
چه زمانی آزمون بازیابی را موفق بدانیم؟
معیار پذیرش را پیش از اجرا بنویسید: همهٔ کنترل‌های حیاتی باید نتیجهٔ روشن داشته باشند و خطای حل‌نشده‌ای که ادامهٔ کار را متوقف می‌کند باقی نماند. زمان را از آغاز دریافت نسخه تا آماده شدن محیط قابل استفاده اندازه بگیرید و زمان انتقال، restore و بررسی کاربردی را جدا ثبت کنید. عدد حاصل فقط نتیجهٔ همین آزمون و همین منابع است؛ آن را بدون شواهد به همهٔ بازیابی‌ها تعمیم ندهید.
در گزارش نهایی، زمان نسخهٔ پشتیبان، محیط و نسخهٔ مقصد، نمونه‌های بررسی‌شده، خطاها، نتیجه و مسئول پیگیری را بیاورید. فاصلهٔ زمانی نسخه تا رخداد احتمالی و مدت لازم برای بازگشت به خدمت را با نیاز واقعی سازمان مقایسه کنید. اگر نتیجه پذیرفتنی نیست، برنامهٔ بک‌آپ یا روش بازیابی باید بازطراحی و دوباره آزموده شود.
پس از آزمون، محیط کپی‌شده را تا پایان دورهٔ بررسی محدود نگه دارید و تعیین تکلیف داده‌های آن را طبق سیاست نگهداری سازمان انجام دهید. آزمایش دوره‌ای و تکرار آن پس از تغییر مهم نسخه، افزونه یا ذخیره‌سازی، یک توصیهٔ عملیاتی است؛ تناوب مناسب به حساسیت و سرعت تغییر دادهٔ شما بستگی دارد.
جمع‌بندی و اقدام بعدی
بک‌آپ قابل اتکا، نسخه‌ای است که بتوانید بازیابی و استفاده از آن را نشان دهید. برای Odoo 19، مسیر عملی از کنترل بسته شروع می‌شود، با بازیابی خنثی‌شده در محیط مستقل ادامه پیدا می‌کند و با آزمون فایل‌ها، گزارش‌ها و فرایندهای ضروری پایان می‌یابد. برای شروع، یک نسخهٔ معتبر و یک سناریوی محدود انتخاب کنید و نتیجه را مستند بسنجید.
اگر برای طراحی سناریوی بازیابی یا ارزیابی وابستگی‌های استقرار Odoo به بررسی فنی نیاز دارید، از طریق تماس با آسیاپرداز دامنهٔ بررسی را مشخص کنید. برای اتصال‌های سازمانی نیز بهتر است آزمون سامانهٔ اصلی و اتصال‌های اختصاصی در یک برنامهٔ هماهنگ تعریف شوند.
منابع و محدودهٔ اعتبار
مبنای فنی این راهنما مستندات و کد رسمی Odoo 19.0 و مرجع PostgreSQL 16 است؛ بررسی منابع در ۱۰ آبان ۱۴۰۵ انجام شده است. دستورها نمونهٔ آموزشی‌اند و اجرای بازیابی روی یک سامانهٔ واقعی در این مقاله ادعا نشده است.