...
درحال بروزرسانی سایت هستیم

صفحه اصلی » آموزش سرور » بکاپ سرور مجازی لینوکس با rsync؛ آموزش بکاپ خودکار و بازیابی

بکاپ سرور مجازی لینوکس با rsync؛ آموزش بکاپ خودکار و بازیابی

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

پادکست مقاله : بکاپ سرور مجازی لینوکس با rsync؛ آموزش بکاپ خودکار و بازیابی

فهرست مطالب

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

بکاپ سرور مجازی چیست و چرا به آن نیاز داریم؟

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

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

تفاوت بکاپ، Snapshot و آرشیو فایل

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

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

چه اطلاعاتی را باید در نسخه پشتیبان قرار دهیم؟

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

نوع داده نمونه مسیر یا منبع نکته
فایل‌های برنامه /var/www/ مسیر نصب در هر سرور متفاوت است
تنظیمات سیستم /etc/ اطلاعات حساس را محافظت کنید
دیتابیس MySQL / MariaDB / PostgreSQL خروجی سازگار تهیه کنید
داده کاربران مسیر آپلود و Volumeها حتماً در آزمون بازیابی بررسی شوند
لیست نرم‌افزارها مستندات و نسخه‌ها به بازسازی محیط کمک می‌کند

معرفی rsync و روش کار آن

rsync ابزاری شناخته‌شده برای همگام‌سازی فایل‌ها در لینوکس است. این ابزار پس از انتقال اولیه می‌تواند در اجرای بعدی تغییرات را شناسایی کند و لازم نباشد همه فایل‌ها دوباره منتقل شوند. rsync قابلیت انتقال روی SSH را دارد و برای انتقال دوره‌ای فایل‌های یک VPS به سرور پشتیبان مناسب است.

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

مرحله اول: آماده‌سازی مقصد بکاپ

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

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

مرحله دوم: انتقال آزمایشی فایل‌ها با rsync

در مثال زیر فرض می‌کنیم مسیر داده /var/www/example/ است و یک حساب پشتیبان روی ماشین دیگری دارید. مسیرها و شناسه‌ها را با مقادیر واقعی خود جایگزین کنید. ابتدا با گزینه --dry-run فقط پیش‌نمایش تغییرات را ببینید تا اشتباه در انتخاب مبدأ یا مقصد باعث انتقال ناخواسته نشود.

rsync -avh --dry-run -e ssh \
/var/www/example/ \
backupuser@backup.example:/srv/backups/site-files/

پس از اطمینان از فهرست فایل‌ها، گزینه --dry-run را حذف کنید. علامت اسلش انتهای مسیر مبدأ مهم است: example/ محتویات پوشه را منتقل می‌کند و بدون اسلش ممکن است خود پوشه به ساختار مقصد اضافه شود. برای بکاپ سرور مجازی از استفاده بدون بررسی گزینه --delete خودداری کنید؛ زیرا می‌تواند فایل‌های مقصد را حذف کند.

مرحله سوم: تهیه خروجی سازگار از دیتابیس

کپی کردن مستقیم فایل‌های دیتابیس در حالی که سرویس در حال نوشتن است، همیشه یک نسخه سازگار تولید نمی‌کند. برای MySQL و MariaDB می‌توان از ابزار منطقی mysqldump استفاده کرد. برای جدول‌های InnoDB گزینه --single-transaction به گرفتن خروجی سازگار کمک می‌کند؛ البته محدودیت‌های آن و نوع جدول‌ها را در نظر بگیرید.

mysqldump --single-transaction --quick \
--databases appdb > appdb-backup.sql

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

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

مرحله چهارم: ساخت نسخه‌های زمان‌دار

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

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

مرحله پنجم: خودکارسازی بکاپ در لینوکس

زمان‌بندی با Cron یا systemd timer امکان‌پذیر است، اما پیش از اجرای خودکار باید اسکریپت بکاپ به‌صورت دستی موفق شده باشد. اسکریپت لازم است خطا را بررسی کند، وضعیت خروج را ثبت کند و هنگام شکست اعلان بفرستد. اجرای بدون خطای فرمان rsync به‌تنهایی کافی نیست؛ خروجی دیتابیس و فایل‌های مقصد را نیز بررسی کنید.

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

30 2 * * * /usr/local/sbin/vps-backup.sh

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

اصل ۳-۲-۱ در بکاپ سرور مجازی

قاعده مشهور ۳-۲-۱ پیشنهاد می‌کند سه نسخه از داده داشته باشید، از دو نوع رسانه یا محل نگهداری متفاوت استفاده کنید و حداقل یک نسخه را خارج از محیط اصلی قرار دهید. این قاعده راهنمای طراحی است، نه ضمانت بازیابی. برای بسیاری از پروژه‌ها نگهداری یک نسخه آفلاین یا تغییرناپذیر نیز در برابر باج‌افزار و حذف عمدی ارزش بالایی دارد.

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

رمزگذاری و حفاظت از نسخه‌های پشتیبان

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

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

آموزش آزمایش بازیابی بکاپ

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

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

بازیابی بکاپ سرور مجازی و کنترل نسخه پشتیبان وب سایت

چه خطاهایی نسخه پشتیبان را بی‌فایده می‌کنند؟

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

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

تفاوت بکاپ در VPS و هاست اشتراکی

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

بکاپ سرور مجازی به‌ویژه وقتی چند وب‌سایت، دیتابیس یا کانتینر روی یک VPS قرار دارد ضروری‌تر می‌شود؛ زیرا خرابی یک ماشین می‌تواند چند سرویس را به‌طور هم‌زمان مختل کند.

دانلود داپلیکیتور 

چند سؤال رایج درباره بکاپ VPS

آیا rsync خودش نسخه پشتیبان کامل می‌سازد؟

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

هر چند وقت یک‌بار باید بکاپ بگیریم؟

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

آیا Snapshot جای بکاپ را می‌گیرد؟

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

می‌توان از دیتابیس فعال بکاپ گرفت؟

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

مهم‌ترین آزمون پس از بکاپ چیست؟

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

جمع‌بندی

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

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

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

آیا rsync به‌تنهایی بکاپ کامل سرور مجازی می‌سازد؟

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

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

نه لزوماً. Snapshot برای بازگشت سریع مناسب است، اما به زیرساخت و سیاست نگهداری ارائه‌دهنده وابسته است. بهتر است یک نسخه مستقل بیرون از سرور اصلی هم نگهداری شود.

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

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

نظرات کاربران

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *


جستجو

اخبار

مقالات مرتبط