بکاپ گیری از سرور اختصاصی؛ راهنمای کامل Backup و Restore

مقدمه:

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

فهرست مطالب

• چرا سرور اختصاصی به برنامه بکاپ نیاز دارد؟
• تفاوت RAID و بکاپ
• چه اطلاعاتی باید پشتیبان‌گیری شوند؟
• مقایسه روش‌های بکاپ سرور اختصاصی
• پیش‌نیازهای شروع پشتیبان‌گیری
• آموزش بکاپ فایل‌ها و دایرکتوری‌ها
• بکاپ پایگاه داده
• بکاپ تنظیمات و اطلاعات سیستمی
• انتخاب مقصد نگهداری بکاپ
• زمان‌بندی و خودکارسازی
• امنیت نسخه‌های پشتیبان
• آموزش بازیابی اطلاعات
• آزمایش سلامت بکاپ
• اشتباهات رایج
• چک‌لیست نهایی
• سؤالات متداول

چرا بکاپ گیری از سرور اختصاصی ضروری است؟

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

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

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

دو معیار مهم RPO و RTO

برای طراحی برنامه پشتیبان‌گیری ابتدا باید دو معیار عملی مشخص شوند:

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

هرچه اطلاعات سریع‌تر تغییر کنند، فاصله میان نسخه‌های پشتیبان باید کوتاه‌تر باشد. هرچه زمان بازیابی مهم‌تر باشد، فرایند Restore نیز باید ساده‌تر، مستندتر و بیشتر آزمایش شده باشد.

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

مطالعه بیشتر: راهنمای خرید سرور اختصاصی

آیا RAID جایگزین بکاپ سرور اختصاصی است؟

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

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

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

در بکاپ سرور اختصاصی چه اطلاعاتی ذخیره شود؟

نوع داده‌های ضروری به کاربرد سرور بستگی دارد. در یک سرور میزبانی وب، بکاپ باید معمولاً این بخش‌ها را پوشش دهد:

• فایل‌های سایت و برنامه
• تصاویر و فایل‌های بارگذاری‌شده کاربران
• پایگاه‌های داده
• تنظیمات Nginx، Apache یا LiteSpeed
• تنظیمات PHP و پایگاه داده
• تنظیمات DNS و سرویس ایمیل، در صورت میزبانی روی سرور
• فایل‌های SSL و اطلاعات لازم برای صدور یا بازیابی گواهی
• تنظیمات فایروال و سرویس‌های امنیتی
• فایل‌های Cron و تایمرهای systemd
• واحدهای سفارشی systemd
• فایل‌های Docker Compose و داده‌های Volume
• فایل‌های تنظیم محیطی و اسرار برنامه
• فهرست نرم‌افزارها و نسخه‌های موردنیاز
• تنظیمات کنترل پنل، در صورت امکان پشتیبان‌گیری از آن‌ها
• مستندات مربوط به شبکه، IP و ساختار دیسک

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

مطالعه بیشتر: بررسی فضای دیسک در لینوکس

مقایسه روش‌های بکاپ گیری از سرور اختصاصی

هیچ روش واحدی برای همه پروژه‌ها مناسب نیست. اغلب بهتر است چند روش مکمل در کنار یکدیگر استفاده شوند.

بکاپ کامل، افزایشی یا تفاضلی؟

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

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

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

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

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

مطالعه بیشتر: خدمات سرور اختصاصی

پیش‌نیازهای بکاپ گیری از سرور اختصاصی

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

فهرست‌برداری از سرویس‌ها

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

تعیین مقصد مستقل

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

بررسی فضای آزاد و پهنای باند

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

انتخاب زمان اجرای مناسب

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

آموزش بکاپ فایل‌های سرور اختصاصی

ایجاد آرشیو با tar

برای تهیه نسخه دستی از یک مسیر مشخص می‌توان از tar استفاده کرد:

sudo tar -czf /backup/site-files.tar.gz /var/www/example

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

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

sudo tar \
  --exclude='/var/www/example/cache' \
  -czf /backup/site-files.tar.gz \
  /var/www/example

پیش از حذف مسیرها از بکاپ مطمئن شوید برای راه‌اندازی مجدد برنامه لازم نیستند.

انتقال فایل‌ها با rsync

rsync برای همگام‌سازی داده‌ها با سرور پشتیبان مناسب است:

sudo rsync -aHAX /var/www/example/ \
  backupuser@backup-host:/data/backups/example/

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

استفاده از گزینه --delete باعث حذف فایل‌های اضافی از مقصد می‌شود. پیش از استفاده از آن، عملیات را در حالت آزمایشی بررسی کنید:

sudo rsync -aHAXn --delete /var/www/example/ \
  backupuser@backup-host:/data/backups/example/

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

بکاپ پایگاه داده روی سرور اختصاصی

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

تهیه بکاپ MySQL و MariaDB

برای یک پایگاه داده می‌توان از mysqldump استفاده کرد:

mysqldump --single-transaction --routines --triggers \
  -u backup_user -p database_name > database_backup.sql

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

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

gzip database_backup.sql

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

تهیه بکاپ PostgreSQL

برای ایجاد نسخه‌ای با فرمت قابل‌بازیابی توسط pg_restore می‌توان از دستور زیر استفاده کرد:

sudo -u postgres pg_dump -Fc database_name > database_backup.dump

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

مطالعه بیشتر: تفاوت MySQL و MariaDB

بکاپ تنظیمات و اطلاعات سیستمی

بازگرداندن فایل سایت و دیتابیس بدون تنظیمات سرویس‌ها ممکن است برای راه‌اندازی کامل سرور کافی نباشد. تنظیمات مهم معمولاً در مسیرهای سیستمی، پوشه پروژه یا فایل‌های مدیریت کانتینر قرار دارند.

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

• فایل‌های پیکربندی وب‌سرور
• تنظیمات PHP
• تنظیمات دیتابیس
• فایل‌های Cron
• سرویس‌های سفارشی systemd
• تنظیمات فایروال
• فایل‌های محیطی پروژه
• تنظیمات Docker و داده‌های Volume
• تنظیمات کنترل پنل
• اطلاعات کاربران و مجوزهای لازم
• فایل‌های گواهی و کلیدها
• ساختار پارتیشن و Mount Pointها

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

بکاپ سرورهای دارای Docker

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

برای بکاپ صحیح باید این اجزا بررسی شوند:

• فایل Compose
• فایل‌های تنظیم محیطی
• داده‌های Volume
• فایل‌های Bind Mount
• خروجی پایگاه داده داخل یا خارج از کانتینر
• نسخه Imageهای موردنیاز
• تنظیمات شبکه و Reverse Proxy

پیش از کپی داده یک Volume فعال، سازگاری برنامه را در نظر بگیرید. برای پایگاه داده داخل کانتینر نیز بهتر است از ابزار بکاپ سازگار با همان دیتابیس استفاده شود.

مطالعه بیشتر: Docker چیست و چه کاربردی دارد

انتخاب محل نگهداری بکاپ

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

سرور بکاپ مستقل

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

فضای ذخیره‌سازی ابری یا Object Storage

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

فضای ذخیره‌سازی محلی جداگانه

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

آیا دیسک دوم داخل همان سرور کافی است؟

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

زمان‌بندی و نگهداری نسخه‌ها

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

یک برنامه می‌تواند شامل این لایه‌ها باشد:

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

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

خودکارسازی با Cron

بهتر است مراحل بکاپ داخل یک اسکریپت کنترل‌شده قرار بگیرند و Cron فقط آن اسکریپت را اجرا کند:

30 2 * * * /usr/local/sbin/dedicated-backup.sh >> /var/log/dedicated-backup.log 2>&1

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

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

امنیت نسخه‌های پشتیبان

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

برای حفاظت از نسخه‌ها این اقدامات را در نظر بگیرید:

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

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

مطالعه بیشتر: افزایش امنیت سرور

آموزش بازیابی بکاپ سرور اختصاصی

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

بازیابی فایل‌ها

ابتدا آرشیو را در یک مسیر موقت استخراج کنید:

sudo mkdir -p /restore-check
sudo tar -xzf site-files.tar.gz -C /restore-check

ساختار فایل‌ها، مالکیت، Permission و تاریخ نسخه را بررسی کنید. فایل‌ها را بدون بررسی مستقیماً روی داده‌های فعلی استخراج نکنید؛ زیرا ممکن است نسخه سالم یا جدیدتر بازنویسی شود.

بازیابی MySQL یا MariaDB

پس از آماده‌سازی دیتابیس مقصد می‌توان نسخه SQL را وارد کرد:

mysql -u restore_user -p database_name < database_backup.sql

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

بازیابی PostgreSQL

برای فایلی که با فرمت سفارشی ایجاد شده است می‌توان از pg_restore استفاده کرد:

sudo -u postgres pg_restore -d database_name database_backup.dump

بازیابی را ابتدا روی دیتابیس آزمایشی انجام دهید. تفاوت مالکیت کاربران، افزونه‌ها و نسخه نرم‌افزار ممکن است به تنظیمات بیشتری نیاز داشته باشد.

بازیابی کامل روی سرور جایگزین

در خرابی جدی سخت‌افزار، معمولاً باید این مراحل طی شوند:

1. آماده‌سازی سرور جایگزین
2. نصب سیستم‌عامل سازگار
3. تنظیم دیسک، شبکه و فایروال
4. نصب نسخه‌های سازگار نرم‌افزارها
5. بازگرداندن تنظیمات سرویس‌ها
6. بازیابی فایل‌های برنامه
7. بازیابی پایگاه داده
8. اصلاح مالکیت و مجوزها
9. بررسی گواهی‌ها و متغیرهای محیطی
10. آزمایش سرویس با آدرس موقت
11. انتقال ترافیک یا اصلاح DNS
12. پایش لاگ‌ها و عملکرد سرویس

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

چگونه سلامت بکاپ را بررسی کنیم؟

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

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

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

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

سناریوی کاربردی برای یک سرور میزبانی وب

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

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

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

اشتباهات رایج در بکاپ سرور اختصاصی

اتکا به RAID

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

نگهداری تمام نسخه‌ها روی همان سرور

خرابی گسترده، نفوذ یا خطای مدیریتی ممکن است داده اصلی و تمام نسخه‌های محلی را هم‌زمان از بین ببرد.

کپی مستقیم دیتابیس فعال

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

خودکارسازی بدون گزارش خطا

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

نداشتن چند نسخه تاریخی

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

آزمایش‌نکردن Restore

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

چک‌لیست بکاپ گیری از سرور اختصاصی

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

جمع‌ بندی

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

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

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

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

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

هر چند وقت یک‌بار باید از سرور اختصاصی بکاپ گرفت؟

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

آیا RAID برای حفاظت از اطلاعات کافی است؟

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

آیا می‌توان بکاپ را روی دیسک دوم همان سرور نگهداری کرد؟

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

بکاپ کامل بهتر است یا افزایشی؟

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

چگونه بفهمیم بکاپ سرور سالم است؟

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

آیا برای بکاپ دیتابیس باید سرور را خاموش کرد؟

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

آیا بکاپ کنترل پنل تمام اطلاعات سرور را ذخیره می‌کند؟

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