اسنپ شات چیست و چرا با بکاپ فرق دارد؟

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

اسنپ شات یک تصویر لحظه‌ای از وضعیت بلاک‌های دیسک در یک نقطه از زمان است. روی LVM، ZFS، Ceph و تقریباً هر پلتفرم ابری امروزی، این کار با copy-on-write انجام می‌شود: به‌جای کپی کردن داده، فقط متادیتا ثبت می‌شود و بلاک‌های قدیمی تا وقتی دست‌نخورده‌اند سر جای خودشان می‌مانند. به همین دلیل ساختنش چند ثانیه طول می‌کشد، حتی برای یک دیسک ۵۰۰ گیگابایتی. همین سرعت است که فریب‌دهنده است.

اسنپ شات روی همان استوریج می‌نشیند

اگر اسنپ شات یک volume روی همان pool ای گرفته شود که خود volume در آن است، شما دو نسخه از داده دارید که هر دو به یک سخت‌افزار وابسته‌اند. کنترلر RAID می‌سوزد، pool دچار corruption می‌شود، یا کسی اشتباهی zpool destroy می‌زند و هر دو با هم می‌روند. اسنپ شات در برابر خطای انسانی و خرابی منطقی خوب است، در برابر خرابی فیزیکی بی‌فایده است.

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

این‌جا اشتباه می‌کنند

رایج‌ترین اشتباه این است که اسنپ شات روی همان سروری گرفته می‌شود که قرار است از آن محافظت کند، و بعد کسی آن سرور را reinstall می‌کند. علامتش هم مشخص است: بعد از نصب مجدد، لیست اسنپ شات‌ها خالی است و پشتیبانی می‌گوید «اسنپ شات‌ها همراه volume پاک شدند». اسنپ شات به volume گره خورده است؛ volume که برود، اسنپ شات هم می‌رود. اگر snapshot را روی storage جدا نگه نمی‌دارید، در واقع بکاپ ندارید.

بکاپ واقعی چه چیزی باید داشته باشد

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

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

ابزارش هم مهم نیست. pg_dump با فلگ -Fc که خروجی فشرده و قابل انتخاب جدول می‌دهد، یا mysqldump --single-transaction برای InnoDB بدون قفل کردن جدول‌ها، هر دو کار می‌کنند. نکته این است که خروجی را جایی بفرستید که با سرور اصلی نسبت فیزیکی نداشته باشد؛ فضای ذخیره‌سازی آبجکت برای همین کار ساخته شده و نسخه‌بندی هم دارد.

ترکیب درست: اسنپ شات برای سرعت، بکاپ برای بقا

این دو رقیب هم نیستند. اسنپ شات را برای پنجره‌های کوتاه نگه دارید: قبل از یک migration، قبل از آپدیت نسخه دیتابیس، قبل از تغییر schema. اگر upgrade خراب شد، در چند ثانیه برمی‌گردید. این چیزی است که بکاپ نمی‌تواند بدهد، چون restore یک دیتابیس ۲۰۰ گیگابایتی از object storage معمولاً ساعت‌ها طول می‌کشد، نه دقیقه.

بکاپ را برای افق بلند نگه دارید: روزانه، هفتگی، ماهانه، با نگهداری خارج از سرور. یک الگوی عملی که خودم استفاده می‌کنم: اسنپ شات هر شش ساعت با نگهداری ۴۸ ساعته، دامپ منطقی روزانه با نگهداری ۳۰ روز، و یک نسخه ماهانه که به استوریج جداگانه می‌رود و تا یک سال می‌ماند.

هزینه‌ای که باید بپذیرید هم همین است: بکاپ واقعی فضا و پهنای باند می‌خورد و زمان restore دارد. اگر حجم داده‌تان چند ترابایت است، نگه داشتن ۳۰ نسخه روزانه یعنی هزینه استوریج چند برابر خود سرور. اینجا جایی است که باید RPO و RTO را عدد کنید، نه اینکه شهودی تصمیم بگیرید.

اسنپ شات سازگار با اپلیکیشن

یک اسنپ شات crash-consistent با یک اسنپ شات application-consistent فرق دارد. اگر وسط نوشتن دیتابیس اسنپ شات بگیرید، ممکن است نسخه‌ای داشته باشید که در حالت crash است و برای بازیابی به crash recovery نیاز دارد. برای MySQL قبل از اسنپ شات FLUSH TABLES WITH READ LOCK بزنید، اسنپ شات را بگیرید، بعد UNLOCK TABLES. برای PostgreSQL کافی است در حالت pg_start_backup() باشید یا از pg_basebackup استفاده کنید. این جزئیات همان چیزی است که تفاوت بین «بازیابی شد» و «بازیابی شد ولی دو ساعت داده از دست رفت» را می‌سازد.

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

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

اما اگر روی همان سرور دیتابیس مشتری دارید، اسنپ شات تنها یک لایه از سه لایه است. لایه دوم دامپ منطقی روی استوریج جداست، لایه سوم نسخه‌ای خارج از آن دیتاسنتر. روی زیرساخت ابری، این کار با یک volume جدا یا یک bucket در منطقه دیگر انجام می‌شود و لازم نیست معماری پیچیده‌ای بسازید. اگر هنوز روی سرور اختصاصی با دیسک محلی کار می‌کنید، زیرساخت ابری (IaaS) همین جداسازی استوریج از compute را ساده‌تر می‌کند.

آزمون بازیابی، نه آزمون بکاپ

داشبوردی که می‌گوید «بکاپ موفق» هیچ ارزشی ندارد. آنچه ارزش دارد این است که ماهی یک بار یک نسخه را روی یک سرور موقت restore کنید و ببینید اپلیکیشن بالا می‌آید. من این را با یک اسکریپت ساده انجام می‌دهم که آخرین دامپ را می‌گیرد، روی یک instance موقت restore می‌کند، یک کوئری شمارشی می‌زند و نتیجه را در چت تیم می‌فرستد. اگر آن پیام نیامد، یعنی بکاپ ندارید.

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

پرسش‌های پرتکرار

آیا اسنپ شات جای بکاپ را می‌گیرد؟

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

تفاوت اسنپ شات و بکاپ در چیست؟

اسنپ شات یک تصویر لحظه‌ای با copy-on-write است که در ثانیه ساخته می‌شود و به volume وابسته می‌ماند. بکاپ یک نسخه مستقل روی رسانه‌ای جداست که می‌تواند تک‌فایل یا تک‌جدول بازیابی کند، اما ساخت و بازگرداندنش زمان و فضا می‌برد.

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

بستگی به RPO دارد، نه به عادت. اگر تحمل از دست دادن شش ساعت داده را دارید، هر شش ساعت کافی است. برای دیتابیس‌های پرتراکنش، اسنپ شات هر ساعت به‌همراه WAL archiving یا binlog منطقی‌تر است تا نقطه بازیابی دقیق داشته باشید.

چطور بفهمم بکاپم واقعاً کار می‌کند؟

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

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