بکاپ خودکار شرکت اجرا نمی‌شود؛ از کجا بررسی کنیم؟

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

• هیچ اجرای تازه‌ای ثبت نشده: بررسی را از فعال‌بودن برنامه خودکار، زمان بعدی اجرا و وضعیت دستگاهی که کار را انجام می‌دهد شروع کنید.
• اجرا شروع شده و خطا داده: جزئیات همان نوبت و همان منبع ناموفق، مسیر بررسی را مشخص می‌کند.
• اجرا موفق است ولی فایل موردنظر در نسخه نیست: دامنه بکاپ و زمان نسخه را بررسی کنید؛ ممکن است پوشه جدید اصلاً به برنامه اضافه نشده باشد.

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

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

در مستند جاری Veeam Backup & Replication برای کارهای مدیریت‌شده Agent، اجرای خودکار باید فعال باشد و زمان‌بندی بر اساس ساعت محلی سرور بکاپ است. این رفتار را به همه محصولات و حالت‌های Veeam تعمیم ندهید؛ نام محصول و نوع کار را در بررسی مشخص کنید.

خاموشی، راه‌اندازی مجدد یا خواب دستگاه را با زمان توقف مقایسه کنید. برای نمونه، Veeam Agent for Microsoft Windows می‌تواند در شرایط مستندشده دستگاه را برای اجرا بیدار کند، اما خواب تحمیلی حین کار می‌تواند بکاپ را ناموفق کند. بنابراین فقط روشن‌بودن رایانه در ابتدای شب کافی نیست.

در Veeam، تفاوت Next Run با انتظار شما همیشه خرابی ساعت نیست؛ زمان‌بندی نسخه کامل Active Full یا Synthetic Full نیز می‌تواند در آن اثر داشته باشد. پیش از تغییر ساعت سیستم یا بازسازی کار، تنظیمات مرتبط را کنار هم بررسی کنید.

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

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

در خطاهای Veeam با عبارت Unable to allocate processing resources، ادامه پیام اهمیت دارد. مستند رسمی KB1857 چند علت متفاوت برای آن دارد؛ از محدودیت پردازش تا وضعیت مخزن. انتخاب راه‌حل بر اساس فقط چند کلمه اول می‌تواند شما را به بخش اشتباه ببرد.

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

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

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

هشدار را صرفاً به‌خاطر ساخته‌شدن فایل نادیده نگیرید. در مستند Veeam Backup & Replication 13، وضعیت Warning می‌تواند بسته به خطا با ناسازگاری داده بکاپ همراه باشد. جزئیات منبع و پردازش برنامه باید خوانده شوند؛ معنی هر هشدار به همان پیام وابسته است.

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

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

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

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

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

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

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