تفاوت اسنپ‌شات و بکاپ؛ چرا اسنپ‌شات جای بکاپ را نمی‌گیرد

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

معیار	اسنپ‌شات	نسخه پشتیبان
محل ذخیره	روی همان استوریج یا pool سرور	رسانه یا سرور جداگانه
فضای اولیه	تقریباً صفر، بعد با تغییر داده رشد می‌کند	اندازه داده از همان ابتدا
کاربرد اصلی	برگشت از یک تغییر مشخص	بازیابی بعد از خرابی یا حذف
بازه نگه‌داری (پیشنهاد عملی ما)	چند ساعت تا چند روز	هفته‌ها تا ماه‌ها

مسیر مقاله از پایین به بالا است. اول از مستندات کرنل لینوکس، OpenZFS و QEMU می‌خوانیم که هر فناوری چه چیزی را نگه می‌دارد و حالت خرابی هرکدام چیست. بعد چهار سناریوی از دست رفتن داده را می‌آزماییم و آخر هم دستورهای بررسی فضا و تست بازیابی را دارید.

اسنپ‌شات پشت صحنه چه کاری انجام می‌دهد؟

اسنپ‌شات یک تصویر فقط‌خواندنی از وضعیت داده در یک لحظه مشخص است. مستندات OpenZFS آن را «کپی فقط‌خواندنی از یک فایل‌سیستم یا والیوم» توصیف می‌کند که «بسیار سریع ساخته می‌شود و در ابتدا هیچ فضای اضافه‌ای در pool مصرف نمی‌کند».

ایده مشترک همه پیاده‌سازی‌ها کپی هنگام نوشتن یا copy-on-write است. طبق مستندات کرنل لینوکس برای device-mapper، در dm-snapshot فقط همان قطعه‌هایی از داده کپی می‌شوند که تغییر می‌کنند و برای نگه‌داری‌شان یک دستگاه COW جداگانه به کار می‌رود؛ قطعه‌های دست‌نخورده از دیسک اصلی یا origin خوانده می‌شوند. همین نقطه ریشه تفاوت اسنپ‌شات و بکاپ است: داده قدیمی از دیسک مبدأ جدا نمی‌شود، فقط علامت می‌خورد.

اسنپ‌شات روی سرور مجازی با چه سازوکاری ذخیره می‌شود

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

• اسنپ‌شات داخلی qcow2: طبق مستندات QEMU، اطلاعات وضعیت ماشین «در اولین بلاک‌دیوایس نوشتنی با قالب qcow2 ذخیره می‌شود» و «سکتورهای دیسک مرتبط بین همه اسنپ‌شات‌ها به اشتراک گذاشته می‌شوند». یعنی اسنپ‌شات داخل همان فایل ایمیج می‌نشیند.
• ایمیج پایه و backing file: سازوکار جداگانه‌ای که با اسنپ‌شات داخلی اشتباه گرفته می‌شود. مستندات QEMU گزینه backing_file را «نام فایل یک ایمیج پایه» معرفی می‌کند؛ تغییرات در ایمیج رویی جمع می‌شوند و آن ایمیج بدون پایه معنا ندارد.
• والیوم LVM کلاسیک: همان dm-snapshot مستندات کرنل، با یک دستگاه COW جداگانه و اندازه معین.
• والیوم LVM-thin: روی dm-thin کار می‌کند و دستگاه COW جداگانه ندارد. به تصریح مستندات thin provisioning کرنل، اسنپ‌شات thin «هیچ تفاوتی با سایر دستگاه‌های thin ندارد» و بلاک را از مخزن مشترک برمی‌دارد.
• فایل‌سیستم ZFS: اسنپ‌شات در سطح دیتاست ساخته می‌شود و فضا را از همان pool می‌گیرد؛ به تصریح مستندات OpenZFS، تا وقتی یک clone وجود دارد «اسنپ‌شات اصلی قابل حذف نیست». Btrfs در سطح subvolume کار می‌کند.

پر شدن فضا؛ حالت خرابی در هر فناوری متفاوت است

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

• در LVM کلاسیک و dm-snapshot: مستندات کرنل می‌گوید دستگاه COW «معمولاً از origin کوچک‌تر است» و «اگر پر شود، اسنپ‌شات بی‌فایده و غیرفعال می‌شود و خطا برمی‌گرداند». خسارت به خود اسنپ‌شات محدود است.
• در LVM-thin و dm-thin: دستگاه COW ثابتی نیست، پس فضای مخزن تمام می‌شود. طبق مستندات thin provisioning کرنل، پیش‌فرض این است که «درخواست ورودی و خروجی در صف می‌ماند تا فضا اضافه شود یا مدت no_space_timeout تمام شود» (پیش‌فرض ۶۰ ثانیه) و با error_if_no_space خطا برمی‌گردد. تمام شدن متادیتا هم مخزن را تا آفلاین و تعمیر شدن خطا‌ده می‌کند. اینجا والیوم زنده درگیر است، نه فقط اسنپ‌شات.
• در ZFS: اسنپ‌شات از همان pool تغذیه می‌کند، پس عدد تعیین‌کننده فضای آزاد pool است.

# فضای فایل‌سیستم و مخزن را پیش از ساخت اسنپ‌شات ببینید
df -h /
sudo lvs -o lv_name,lv_size,data_percent,metadata_percent
sudo zpool list -o name,size,alloc,free,capacity
sudo zfs list -t snapshot

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

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

طبق مستندات رسمی Proxmox VE، بکاپ‌های این هایپروایزر «همیشه کامل» هستند و کانفیگ ماشین و تمام داده آن را در بر می‌گیرند. حالت stop بالاترین سازگاری را می‌دهد و یک قطعی کوتاه دارد. حالت snapshot کمترین قطعی را دارد، ولی خود مستندات آن را «به بهای یک ریسک کوچک ناسازگاری» توصیف می‌کند؛ با guest agent فعال، فایل‌سیستم مهمان freeze و thaw می‌شود تا این ریسک کمتر شود. حالت suspend را همان مستندات توصیه نمی‌کند.

بکاپ کامل، افزایشی و فایل‌محور

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

پیش از انتخاب نوع، فهرست محتویات آرشیو را بنویسید: ریشه سایت، دامپ منطقی دیتابیس، پوشه /etc، کرون‌تب کاربران و گواهی‌های TLS. هر چه در فهرست نباشد، در روز بازیابی هم نیست.

چرخه نگه‌داری و حذف خودکار نسخه‌ها

در نگه‌داری بلندمدت، تفاوت اسنپ‌شات و بکاپ به یک محدودیت فنی سخت تبدیل می‌شود: هر اسنپ‌شات زنده فضای مشترک مصرف می‌کند، پس ده‌ها نسخه را ماه‌ها نمی‌توان نگه داشت؛ برای آرشیو چنین محدودیتی نیست. Proxmox گزینه prune-backups را دارد که نسخه‌ها را بر اساس keep-last، keep-hourly، keep-daily، keep-weekly، keep-monthly و keep-yearly نگه می‌دارد؛ نسخه‌های protected از حذف خودکار معاف هستند.

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

چهار شکستی که اسنپ‌شات جلوی آن‌ها را نمی‌گیرد

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

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

خرابی استوریج و از دست رفتن حساب

اوراکل در صفحه رسمی Snapshots Are NOT Backups سه دلیل می‌آورد. آن صفحه درباره دیتابیس اوراکل و RMAN نوشته شده، ولی هر سه دلیل از جنس استوریج است. اول اینکه روی همان آرایه داده اصلی می‌نشیند و «در برابر خرابی‌هایی که آرایه استوریج را تحت تأثیر قرار می‌دهند آسیب‌پذیر است». دوم اینکه در سطح بلاک کار می‌کند و از ساختار بلاک دیتابیس «آگاهی ندارد». سوم اینکه «مجموعه‌ای از اشاره‌گرها به‌جای بلاک‌ها» است و برای بکاپ شدن باید «روی آرایه استوریج دیگر یا نوار بازسازی شود».

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

باج‌افزار و نسخه‌ای که در دسترس مهاجم است

راهنمای #StopRansomware سیسا با همکاری MS-ISAC و NSA و FBI منتشر شده و نسخه روی سایت به سپتامبر ۲۰۲۳ بازنگری شده است. توصیه‌اش این است: «نسخه‌های پشتیبان آفلاین و رمزنگاری‌شده از داده حیاتی نگه دارید و دسترس‌پذیری و صحت آن‌ها را به‌طور منظم تست کنید». دلیلش را هم می‌گوید: «بسیاری از گونه‌های باج‌افزار تلاش می‌کنند نسخه‌های پشتیبان قابل دسترسی را پیدا و سپس حذف یا رمزنگاری کنند».

اسنپ‌شاتی که در همان پنل و با همان دسترسی قابل حذف است، مصداق روشن «نسخه پشتیبان قابل دسترسی» است. مسئله دوم طول حضور مهاجم است: گزارش Active Adversary سوفوس در نسخه ۲۰۲۵، بر پایه پرونده‌های ۲۰۲۴، میانه این مدت را در پرونده‌های باج‌افزار ۴ روز گزارش کرده است. قاعده روشن است؛ اگر زنجیره نسخه‌های شما کوتاه‌تر از مدت حضور مهاجم باشد، همه نسخه‌ها آلوده‌اند.

اشتباهی که دیر پیدا می‌شود

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

قاعده 3-2-1 و تست بازیابی؛ ترکیب درست دو ابزار

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

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

چک‌لیست و دستورهای تست بازیابی

آرشیوی که بدون خطا باز می‌شود لزوماً سرویس را برنمی‌گرداند؛ یک دامپ نیمه‌کاره هم بدون خطا extract می‌شود. به همین دلیل سیسا از تست منظم «دسترس‌پذیری و صحت» حرف می‌زند. سه فرمان زیر همین تست را روی یک ماشین خالی انجام می‌دهند.

# 1) سلامت آرشیو، بدون استخراج
tar -tzf backup-2026-10-24.tar.gz > /dev/null && echo "archive OK"
sha256sum -c backup-2026-10-24.tar.gz.sha256

# 2) بازیابی روی ماشین خالی، نه روی سرور اصلی
mkdir -p /restore && tar -xzf backup-2026-10-24.tar.gz -C /restore

# 3) صحت داده را با یک کوئری واقعی بسنجید
mysql -u root -p restore_test < /restore/db/shop.sql
mysql -u root -p -e "SELECT COUNT(*) FROM restore_test.orders;"

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

# LVM: ادغام اسنپ‌شات در والیوم اصلی (اسنپ‌شات بعد از merge حذف می‌شود)
sudo lvconvert --merge /dev/vg0/snap-before-update
sudo lvremove /dev/vg0/snap-before-update

# ZFS: بازگردانی دیتاست؛ گزینه -r اسنپ‌شات‌های جدیدتر را حذف می‌کند
sudo zfs rollback -r tank/vm-101@before-update
sudo zfs destroy tank/vm-101@before-update

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

• 🎯 اسنپ‌شات: پیش از آپدیت کرنل، تغییر فایروال یا بازنویسی کانفیگ وب‌سرور؛ پنجره استفاده‌اش چند ساعت است.
• 🎯 نسخه پشتیبان: داده مشتری، دیتابیس فروشگاه و هر کانفیگی که بازسازی دستی‌اش روزها وقت می‌برد.
• ⚠️ هیچ‌کدام: جایگزین مانیتورینگ و لاگ نیستند؛ بدون دانستن ساعت شروع خرابی، انتخاب نسخه درست هم سخت است.

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

اشتباه‌های رایج در لحظه بازیابی

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

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

جمع‌بندی؛ اسنپ‌شات دکمه برگشت است و بکاپ بیمه
تفاوت اسنپ‌شات و بکاپ یک بحث لغوی نیست، یک تقسیم کار است. اسنپ‌شات روی همان استوریج ساخته می‌شود و بر پایه copy-on-write فقط بلاک‌های تغییریافته را نگه می‌دارد. همین ساختار آن را برای برگشت از یک تغییر عمدی بی‌رقیب و برای نجات داده بی‌فایده می‌کند. حالت خرابی هم به فناوری بستگی دارد: در LVM کلاسیک پر شدن دستگاه COW خود اسنپ‌شات را غیرفعال می‌کند، و در LVM-thin و ZFS تمام شدن فضای مشترک نوشتن روی داده زنده را هم تهدید می‌کند. اوراکل تصریح می‌کند اسنپ‌شات در برابر خرابی آرایه استوریج آسیب‌پذیر است و برای بکاپ شدن باید روی رسانه دیگری بازسازی شود. برنامه عملی روشن است: پیش از هر آپدیت اسنپ‌شات بگیرید و تا اطمینان از سلامت سرویس نگهش دارید. در موازات آن یک چرخه بکاپ خودکار بیرون از سرور بسازید که سه شرط قاعده 3-2-1 را برآورده کند. یک نسخه‌اش باید از دسترس خود سرور خارج بماند و هر ماه روی محیطی خالی بازیابی شود.

اگر سوالی داشتید، در بخش نظرات با ما در ارتباط باشید.

• منبع: مستندات کرنل لینوکس، device-mapper snapshot
• منبع: مستندات QEMU، Disk Images
• منبع: مستندات OpenZFS، صفحه zfsconcepts
• منبع: اوراکل، Snapshots Are NOT Backups
• منبع: سیسا، راهنمای StopRansomware، بازنگری سپتامبر ۲۰۲۳
• نام‌برده بدون لینک: مستندات thin provisioning کرنل، مستندات Proxmox VE، گزارش Active Adversary سوفوس ۲۰۲۵