اسنپ شات در فضای ابری؛ نجات‌بخش قبل از تغییرات پرخطر

چرا اسنپ شات قبل از تغییر پرخطر ضروری است؟

هر کسی که با سرور ابری کار کرده باشد، حداقل یک بار تجربه تلخ خراب شدن سرویس را داشته است. یک آپدیت بد، یک تغییر اشتباه در تنظیمات Nginx، یا یک دستور rm -rf که مسیر را اشتباه گرفته — و ناگهان سایت down است و کاربران پیام خطا می‌بینند. در این لحظات، تنها چیزی که می‌تواند شما را نجات دهد، یک اسنپ شات تازه و سالم است.

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

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

چه زمانی باید اسنپ شات بگیرید؟

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

• ارتقاء هسته لینوکس یا آپدیت امنیتی بزرگ (مثل apt upgrade یا yum update)
• تغییر نسخه PHP، MySQL یا Nginx
• اجرای مهاجرت دیتابیس (migration) در پروژه‌های لاراول یا Django
• تغییر تنظیمات فایروال یا شبکه که ممکن است دسترسی SSH را قطع کند
• نصب یک پنل مدیریتی جدید یا افزونه حیاتی
• تغییر در ساختار پارتیشن‌بندی یا افزایش حجم دیسک

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

تفاوت اسنپ شات و ایمیج سفارشی

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

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

گرفتن اسنپ شات در عمل

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

آماده‌سازی سرور قبل از اسنپ شات

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

1. دیتابیس را flush کنید: mysql -u root -p -e "FLUSH TABLES WITH READ LOCK;" (و بعد از اسنپ شات، UNLOCK TABLES; را اجرا کنید)
2. فایل‌سیستم را sync کنید: sync
3. اگر از LVM استفاده می‌کنید، از LVM snapshot استفاده کنید که خودش سازگاری را تضمین می‌کند.

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

مثال عملی با OpenStack API

اگر سرور شما روی OpenStack اجرا می‌شود (که بسیاری از ارائه‌دهندگان ابری از جمله زیرساخت‌های مبتنی بر آن استفاده می‌کنند)، می‌توانید با دستور زیر اسنپ شات بگیرید:

openstack server image create --name "snapshot-before-update-$(date +%Y%m%d)" --wait my-server

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

openstack server create --flavor my-flavor --image "snapshot-before-update-20250601" --network my-network restored-server

اگر از API خود ServerNet استفاده می‌کنید، مستندات آن را بررسی کنید — معمولاً یک endpoint برای ایجاد snapshot وجود دارد که می‌توانید با curl آن را صدا بزنید.

بازگردانی سریع از اسنپ شات

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

مرحله ۱: تشخیص و قطع دسترسی

اولین کار این است که سرور را از مدار خارج کنید تا ترافیک جدید به آن نرسد. اگر سرور پشت Load Balancer است، آن را از pool خارج کنید. اگر IP عمومی دارد، می‌توانید فایروال را فعال کنید یا سرویس وب را متوقف کنید. این کار باعث می‌شود در حین بازگردانی، وضعیت بدتر نشود.

مرحله ۲: انتخاب روش بازگردانی

دو روش اصلی دارید:

• بازگردانی روی همان سرور: در این روش، دیسک فعلی با اسنپ شات جایگزین می‌شود. این کار معمولاً نیاز به ریبوت دارد و ممکن است چند دقیقه طول بکشد. در پنل ServerNet، معمولاً گزینه «Restore from Snapshot» در منوی دیسک وجود دارد.
• ساخت سرور جدید از روی اسنپ شات: اگر سرور فعلی آنقدر خراب شده که نمی‌خواهید ریسک کنید، یک سرور جدید با همان مشخصات از روی اسنپ شات بسازید، IP را به آن اختصاص دهید و بعد سرور قدیمی را حذف کنید. این روش امن‌تر است.

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

مرحله ۳: بررسی سلامت بعد از بازگردانی

بعد از بازگردانی، این موارد را چک کنید:

1. دسترسی SSH برقرار است؟
2. سرویس‌های اصلی (MySQL، Nginx، PHP-FPM) با systemctl status سالم هستند؟
3. دیتابیس قابل اتصال است و دیتاهای حیاتی موجودند؟
4. لاگ‌ها را بررسی کنید: journalctl -xe

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

مدیریت چرخه عمر اسنپ شات‌ها

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

• اسنپ شات‌های موقت (قبل از تغییر پرخطر) را بعد از ۲۴ تا ۴۸ ساعت حذف کنید، اگر همه چیز خوب بود.
• اسنپ شات‌های هفتگی را به مدت ۲ هفته نگه دارید.
• اسنپ شات‌های ماهانه را به مدت ۳ ماه نگه دارید.

در OpenStack، می‌توانید با cron job این کار را خودکار کنید:

0 2 * * * openstack server image create --name "weekly-snapshot-$(date +\%Y\%m\%d)" --wait my-server && openstack image delete $(openstack image list --name "weekly-snapshot-" --format value -c ID | head -n -2)

این cron هر شب ساعت ۲ یک اسنپ شات می‌گیرد و فقط دو مورد آخر را نگه می‌دارد. دقت کنید که \% در cron برای escape کردن % است.

اشتباهات رایج و راه‌حل‌ها

در طول سال‌ها کار با اسنپ شات، چند اشتباه رایج را بارها دیده‌ام که باعث از دست رفتن داده‌ها شده است:

اشتباه ۱: اسنپ شات گرفتن بدون توقف سرویس‌های نوشتاری

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

اشتباه ۲: تست نکردن اسنپ شات

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

اشتباه ۳: نگه داشتن بیش از حد اسنپ شات‌ها

اسنپ شات‌های قدیمی نه تنها هزینه دارند، بلکه باعث سردرگمی می‌شوند — کدام یکی را باید بازگردانی کنم؟ راه‌حل: نام‌گذاری استاندارد با تاریخ و دلیل (مثلاً pre-update-20250601) و حذف منظم اسنپ شات‌های غیرضروری.

جمع‌بندی و بهترین روش‌ها

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

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

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