راهنمای عملی راه‌اندازی بکاپ خودکار با JetBackup روی فضای ریموت: اتصال SFTP، S3 و Backblaze B2، زمان‌بندی و Retention، بکاپ افزایشی و تست بازیابی.

راه‌اندازی بکاپ خودکار با JetBackup روی فضای ریموت

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

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

چرا بکاپ روی خود سرور یک توهم امنیتی است

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

  • خرابی سخت‌افزار: کنترلر RAID یا دیسک NVMe از کار می‌افتد و کل volume از دسترس خارج می‌شود.
  • نفوذ و باج‌افزار: مهاجم بعد از گرفتن دسترسی، اولین کاری که می‌کند حذف یا رمزگذاری بکاپ‌های محلی است تا مجبور به پرداخت شوید.
  • خطای انسانی سطح سیستم: یک دستور اشتباه در پارتیشن‌بندی یا حذف اکانت از WHM.
  • از دست رفتن خود سرور: اختلاف مالی، تعلیق سرویس یا مشکل در دیتاسنتر، دسترسی شما به ماشین را قطع می‌کند.

قاعده‌ای که سال‌هاست جواب داده همان 3-2-1 است: سه نسخه از داده، روی دو رسانه متفاوت، که یکی از آن‌ها بیرون از محل اصلی باشد. JetBackup ابزاری است که بخش «بیرون از محل اصلی» را بدون اسکریپت‌نویسی دستی برایتان مدیریت می‌کند.

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

انتخاب مقصد ریموت: SFTP، S3 یا Backblaze B2

JetBackup مفهومی به نام Destination دارد؛ یعنی جایی که فایل‌های بکاپ نهایتاً آنجا می‌نشینند. سه گزینه‌ای که در عمل بیشترین کاربرد را دارند این‌ها هستند.

SFTP / SSH

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

روی سرور مقصد، کاربر بکاپ را بدون دسترسی shell کامل بسازید و فقط به دایرکتوری خودش محدودش کنید:

adduser --disabled-password --gecos "" jbbackup
mkdir -p /home/jbbackup/.ssh
chmod 700 /home/jbbackup/.ssh
# کلید عمومی تولیدشده در JetBackup را اینجا قرار دهید
vi /home/jbbackup/.ssh/authorized_keys
chmod 600 /home/jbbackup/.ssh/authorized_keys
chown -R jbbackup:jbbackup /home/jbbackup/.ssh

قبل از ساختن Destination، اتصال را دستی تست کنید تا اثر انگشت میزبان در فایل known_hosts ثبت شود؛ در غیر این صورت اولین Job با خطای احراز هویت شکست می‌خورد:

ssh -i /usr/local/jetapi/keys/id_rsa jbbackup@backup.example.com "df -h /home"

مقاصد سازگار با S3 و Backblaze B2

اگر نمی‌خواهید سرور دوم را خودتان اداره کنید، آبجکت استوریج انتخاب منطقی‌تری است. JetBackup هم درایور S3 Compatible دارد و هم درایور اختصاصی Backblaze B2. نکاتی که موقع استفاده باید حواستان باشد:

  • کلید دسترسی محدود بسازید: برای هر سرور یک Application Key جدا با دسترسی فقط به همان باکت. اگر سروری لو رفت، بقیه بکاپ‌ها دست‌نخورده می‌مانند.
  • مراقب هزینه خروجی باشید: آپلود معمولاً رایگان است اما دانلود برای بازیابی هزینه دارد. این را در محاسبه ماهانه لحاظ کنید.
  • تعداد ترد همزمان را متعادل کنید: ترد زیاد روی سرور با I/O محدود، لود را بالا می‌برد و سایت‌ها کند می‌شوند.
  • Region نزدیک انتخاب کنید: تأخیر شبکه مستقیماً روی زمان اتمام Job اثر می‌گذارد.

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

ساختن Destination در JetBackup

در پنل JetBackup از بخش Destinations یک مقصد جدید بسازید و بعد از پر کردن اطلاعات، حتماً دکمه Validate را بزنید. اگر اعتبارسنجی سبز نشد، سراغ ساختن Job نروید. سه تنظیم مهم در همین صفحه:

  • Path: برای هر سرور یک مسیر یا باکت جداگانه. هرگز دو سرور را در یک مسیر ننویسید.
  • Reindex: این گزینه به JetBackup اجازه می‌دهد ساختار بکاپ‌های موجود روی مقصد را دوباره بخواند؛ هنگام مهاجرت سرور به کار می‌آید.
  • Disk Limit: سقف فضای مصرفی روی مقصد را مشخص کنید تا یک اکانت غول‌پیکر کل باکت را پر نکند.

طراحی زمان‌بندی و Retention

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

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

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

دو نکته اجرایی: اول اینکه Job ها را همزمان اجرا نکنید؛ فاصله بگذارید تا لود دیسک و پهنای باند روی هم نیفتد. دوم اینکه Concurrency را با توجه به توان واقعی سرور تنظیم کنید — روی یک سرور با دیسک SATA، بالا بردن تعداد اکانت‌های همزمان فقط باعث می‌شود Job تا صبح تمام نشود.

بکاپ افزایشی چطور فضا را کم نگه می‌دارد

در حالت Incremental، JetBackup به جای اینکه هر شب یک آرشیو کامل بسازد، فقط فایل‌های تغییرکرده را منتقل می‌کند و برای فایل‌های بدون تغییر لینک به نسخه قبلی می‌سازد. نتیجه این است که هفت نسخه روزانه از یک اکانت ۲۰ گیگابایتی، ۱۴۰ گیگابایت فضا نمی‌گیرد؛ چیزی نزدیک به یک نسخه کامل به‌علاوه حجم تغییرات روزانه مصرف می‌شود.

شرط استفاده از این حالت این است که مقصد از هارد لینک پشتیبانی کند؛ یعنی SSH/SFTP روی فایل‌سیستم لینوکسی یا فضای بلاک محلی. مقاصد آبجکت استوریج مثل S3 و B2 ذاتاً فایل‌سیستم نیستند، بنابراین در آن‌ها با آرشیوهای فشرده کار می‌کنید و مصرف فضا بیشتر است.

یک الگوی متداول و کارآمد: بکاپ افزایشی روزانه روی SFTP برای بازیابی سریع، به علاوه یک Job هفتگی فشرده روی B2 به‌عنوان نسخه دور و مقاوم در برابر فاجعه. اولی سرعت می‌دهد، دومی امنیت.

فعال کردن Self-Restore برای کاربران

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

در بخش Restore Permissions می‌توانید مشخص کنید کاربر اجازه بازگرداندن چه چیزهایی را دارد:

  • File Manager: مرور نسخه‌های قبلی و بازگرداندن یک فایل یا پوشه — پرکاربردترین گزینه.
  • Databases و Database Users: بازگرداندن یک دیتابیس بعد از آپدیت خراب افزونه.
  • Email Accounts: بازیابی صندوق ایمیل حذف‌شده.
  • Full Account: معمولاً بهتر است برای کاربر عادی غیرفعال بماند؛ بازیابی کامل بدون درک عواقب، تغییرات چند روز اخیر را از بین می‌برد.

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

تست بازیابی: تنها معیار درست بودن بکاپ

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

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

سلامت آرشیو را هم می‌توانید سرسری بررسی کنید. برای فایل‌های فشرده روی مقصد:

gzip -t backup_account_2026-08-24.tar.gz && echo OK
tar -tzf backup_account_2026-08-24.tar.gz | head -20

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

چند نکته که معمولاً دیر فهمیده می‌شوند

  • کلید SSH بکاپ را جداگانه نگه دارید: کلیدی که به سرور بکاپ وصل می‌شود نباید همان کلید مدیریتی روزمره باشد.
  • روی مقصد دسترسی حذف را محدود کنید: اگر مقصد اجازه حذف نداشته باشد یا نسخه‌بندی فعال باشد، مهاجم نمی‌تواند بکاپ‌ها را پاک کند. Retention را در این حالت روی خود مقصد اعمال کنید.
  • لیست اکانت‌های Exclude را مرور کنید: اکانت‌های حذف‌شده و مسیرهای کش را بیرون بگذارید تا حجم بی‌دلیل بالا نرود.
  • قبل از آپدیت بزرگ سیستم، یک Job دستی بگیرید: ارتقای نسخه PHP یا کنترل‌پنل، بهترین بهانه برای داشتن یک نقطه بازگشت تازه است.

اگر سرور شما هنوز روی cPanel نیست یا لایسنس‌های سرور را جداگانه تهیه می‌کنید، فهرست کامل لایسنس‌های هاستینگ پارس ابر شامل cPanel، CloudLinux، LiteSpeed و Virtualizor است و همه به‌صورت اشتراکی روی آی‌پی سرور فعال می‌شوند.

جمع‌بندی

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

اما هیچ‌کدام از این‌ها بدون تست دوره‌ای بازیابی ارزشی ندارد. تاریخ تست بعدی را همین حالا در تقویم بگذارید. برای سؤالات مربوط به لایسنس، پشتیبانی ۲۴ ساعته پارس ابر از طریق شماره 021-79703 یا تلگرام t.me/parsabr_com در دسترس است.