پاسخ کوتاه: برای بازیابی به نسخهٔ سالم نیاز دارید
کپی فایل، یک نسخهٔ دیگر می‌سازد؛ همگام‌سازی، تغییرات را میان محل‌ها منتقل می‌کند؛ بکاپ باید امکان برگرداندن اطلاعات سالمِ موردنیاز را با سیاست نگهداری مشخص فراهم کند. اگر حذف یا خرابی فوراً به نسخهٔ دوم هم برسد، داشتن دو محل به‌تنهایی حفاظت کافی نیست.
برای تصمیم درست، به جای نام برنامه از یک سؤال شروع کنید: «اگر فایل امروز اشتباه حذف یا خراب شود، دقیقاً کدام نسخه را، تا چه زمانی و با چه روشی برمی‌گردانیم؟» این مقاله تفاوت هدف‌ها را توضیح می‌دهد؛ راه‌اندازی یک محصول یا اجرای عملیات بازیابی روی اطلاعات واقعی شما انجام نمی‌دهد.
۱. جدول تفاوت بکاپ، کپی و همگام‌سازی
| روش | کار اصلی | نکتهٔ مهم برای حفاظت |
|---|---|---|
| کپی فایل | ساخت یک نسخه در زمان انجام کپی | به‌روزبودن، نگهداری نسخه‌ها و استقلال مقصد خودبه‌خود تضمین نمی‌شود. |
| همگام‌سازی | هماهنگ‌کردن وضعیت فایل‌ها میان محل‌ها طبق تنظیمات | ویرایش یا حذف ممکن است منتقل شود؛ تاریخچه و بازیابی را جدا بررسی کنید. |
| بکاپ برنامه‌ریزی‌شده | ساخت نقاط بازیابی طبق نیاز و سیاست نگهداری | نسخهٔ سالم باید موجود، قابل دسترسیِ مجاز و عملاً قابل بازگردانی باشد. |
این‌ها الزاماً سه محصول جدا نیستند. یک سامانه می‌تواند هم Sync و هم تاریخچه یا قابلیت بکاپ داشته باشد. معیار، رفتار تنظیم‌شده و نتیجهٔ آزمون بازیابی است؛ نه صرفاً عنوان تجاری ابزار.
۲. چه زمانی کپی دستی کافی نیست؟
کپی دستی برای جابه‌جایی یا نگه‌داشتن یک فایل در یک لحظه مفید است. اما اگر همان فایل مقصد هر روز با نسخهٔ جدید بازنویسی شود، شاید نسخهٔ سالمِ هفتهٔ قبل باقی نماند. اگر مبدأ و مقصد روی یک دیسک باشند، خرابی همان دیسک می‌تواند هر دو را درگیر کند.
کپی می‌تواند بخشی از برنامهٔ حفاظت باشد؛ به شرط اینکه زمان‌بندی، نسخه‌های نگهداری‌شده، محل و مسئول بررسی روشن باشند. برای داده‌ای که مرتب تغییر می‌کند، کار وابسته به حافظهٔ یک نفر معمولاً گزارش قابل اتکایی دربارهٔ پوشش و تازگی نسخه‌ها نمی‌دهد.
۳. چرا همگام‌سازی همیشه جای بکاپ نیست؟
در سرویس همگام‌سازی، هدف معمولاً دسترسی به وضعیت تازهٔ فایل روی چند محل است. در مثال OneDrive، حذف فایل همگام‌شده می‌تواند آن را از دستگاه‌ها و فضای ابری هم حذف کند؛ امکان برگشت از سطل بازیافت به نوع حساب و سیاست نگهداری وابسته است. رفتار حذف فایل همگام‌شده در مستند مایکروسافت
پس «روی لپ‌تاپ و فضای ابری دیده می‌شود» پاسخ کاملِ سؤال بازیابی نیست. باید بدانید حذف، رمزگذاری یا بازنویسی چطور منتقل می‌شود و نسخهٔ سالم چه مدت می‌ماند. این پرسش برای هر سرویس باید با مستند و تنظیمات همان محیط بررسی شود؛ رفتار OneDrive را به همهٔ ابزارها تعمیم ندهید.
کاربری فایل گزارش را از پوشهٔ Sync حذف می‌کند و حذف به مقصد منتقل می‌شود. اگر بازیابی سرویس در محدودهٔ مجاز ممکن باشد، شاید بتوان فایل را برگرداند؛ اما اگر بازهٔ نگهداری گذشته یا نسخهٔ لازم در دسترس نباشد، داشتن پوشهٔ Sync به‌تنهایی پاسخ نمی‌دهد. پیش از حادثه، این سناریو را با فایل آزمایشی بسنجید.
۴. تاریخچهٔ نسخه‌ها و سطل بازیافت را چگونه ارزیابی کنیم؟
تاریخچهٔ نسخه می‌تواند برای برگشت از ویرایش اشتباه مفید باشد. در OneDrive و SharePoint، دسترسی و نگهداری نسخه‌ها به نوع حساب و تنظیمات وابسته است؛ نبودن گزینه یا نبودن نسخهٔ موردنیاز باید با مدیر بررسی شود. راهنمای Version History مایکروسافت
چهار سؤال عملی بپرسید: نسخه‌ها تا چه زمانی باقی می‌مانند؟ چه کسی می‌تواند آن‌ها را حذف کند؟ بازیابی یک فایل یا مجموعهٔ فایل‌ها چگونه است؟ پس از بسته‌شدن یا ازدست‌رفتن حساب چه دسترسی‌ای داریم؟ سرویس ابری را بدون بررسی این پاسخ‌ها «بکاپ مستقل» فرض نکنید.
سطل بازیافت نیز امکان نامحدود ایجاد نمی‌کند. مایکروسافت برای بازیابی فایل‌های حذف‌شده، محدودیت و تفاوت حساب‌ها را توضیح می‌دهد؛ در برنامهٔ سازمان باید سیاست واقعی بررسی شود، نه یک عدد حفظی. گزینه‌ها و محدودیت‌های بازیابی OneDrive
۵. بکاپ قابل اتکا چه مشخصاتی دارد؟
- پوشش مشخص: بدانید کدام پوشه‌ها، برنامه‌ها، تنظیمات و داده‌ها داخل برنامه هستند و کدام نیستند.
- نقاط بازیابی: تعیین کنید چقدر ازدست‌رفتن تغییرات قابل‌قبول است و به نسخهٔ چند روز یا هفتهٔ قبل نیاز دارید.
- نگهداری و استقلال: تعداد محل‌ها، مدت نگهداری و جدایی دسترسی مدیریت نسخه‌ها را متناسب با خطر تعیین کنید.
- گزارش و هشدار: برای شکست کار، پرشدن مقصد یا جاافتادن دادهٔ مهم، مسئول پیگیری وجود داشته باشد.
- آزمون بازگردانی: ساخت فایل بکاپ را از بازشدن و قابل استفاده بودن دادهٔ بازیابی‌شده جدا تأیید کنید.
برای مثال، نیاز یک پوشهٔ عکس با پایگاه دادهٔ نرم‌افزار مالی یکسان نیست. کپی فایلِ بازِ یک پایگاه داده الزاماً نسخهٔ سازگار و قابل بازیابی نمی‌سازد؛ باید از روش پشتیبانی‌شدهٔ همان برنامه استفاده شود. اهمیت برنامه و آزمون بازیابی در مستند SQL Server
۶. چرا جدایی نسخه‌ها در برابر باج‌افزار مهم است؟
اگر حساب یا دستگاه آلوده بتواند نسخه‌های پشتیبان را هم تغییر دهد یا حذف کند، وجود آن‌ها کافی نیست. CISA نگهداری بکاپ‌های آفلاین و رمزگذاری‌شده و آزمون منظم دسترس‌پذیری و صحت آن‌ها را توصیه می‌کند. طراحی واقعی می‌تواند از جداسازی دسترسی و حفاظت متناسب با سامانه نیز استفاده کند؛ هیچ گزینه‌ای به‌تنهایی مصونیت کامل نمی‌سازد. راهنمای مقابله با باج‌افزار CISA و MS-ISAC
معماری Sync بدون نقاط بازیابیِ محافظت‌شده ممکن است خرابی یا رمزگذاری فایل را به مقصد منتقل کند. از طرف دیگر، یک بکاپ رمزگذاری‌شده بدون کلید قابل دسترسیِ مجاز هم هنگام حادثه قابل استفاده نیست. محل نگهداری کلید و مسئول دسترسی باید از پیش مشخص باشد؛ کلیدها را در تیکت یا پوشهٔ عمومی قرار ندهید.
قاعدهٔ ۳-۲-۱، یعنی سه نسخهٔ داده شامل نسخهٔ اصلی، روی دو نوع رسانه با یک نسخه خارج از محل، نقطهٔ شروع شناخته‌شده‌ای است؛ اما جای تعیین سطح دسترسی، نگهداری و آزمون را نمی‌گیرد. بررسی گزینه‌های بکاپ و قاعدهٔ ۳-۲-۱ در منبع CISA
۷. یک آزمون بازیابی کم‌خطر طراحی کنید
- یک فایل آزمایشی غیرمحرمانه بسازید و نام و محتوای اولیه را ثبت کنید.
- طبق روش واقعی سازمان از آن نسخه بگیرید؛ نتیجهٔ کار و زمان نقطهٔ بازیابی را بررسی کنید.
- فقط روی همین فایل آزمایشی، یک ویرایش مشخص انجام دهید تا دو وضعیت قابل تشخیص داشته باشید.
- نسخهٔ اولیه را در پوشهٔ جدا بازگردانید؛ فایل جاری یا دادهٔ عملیاتی را بازنویسی نکنید.
- بازشدن، محتوای موردانتظار و زمان لازم را بررسی و مسئول انجام کار را ثبت کنید.
این آزمایش کوچک، آزمون کامل بازیابی سرور یا نرم‌افزار نیست. برای سامانه‌های سازمانی، محیط جدا، وابستگی‌ها، مجوز و روش تأیید صحت باید برنامه‌ریزی شود. هیچ فایل واقعی را فقط برای امتحان، حذف یا رمزگذاری نکنید.
به‌جای «از همه‌چیز بکاپ داریم»، بنویسید: «آیا می‌توانیم نسخهٔ سالم گزارش روز مشخص را در مسیر جدا برگردانیم و باز کنیم؟» سپس تاریخ آخرین آزمون و نتیجه را ثبت کنید. این یک نمونهٔ آموزشیِ تعریف معیار است، نه ادعای آزمون موفق روی اطلاعات شما.
۸. چک‌لیست تصمیم برای شرکت
برای هر دادهٔ مهم، یک ردیف با این موارد بسازید: مالک داده، محل اصلی، روش حفاظت، آخرین اجرای موفق، مدت نگهداری، محل مستقل، حساب دارای اختیار حذف و تاریخ آخرین بازیابیِ آزموده‌شده. خانهٔ خالی در این جدول بهتر از اطمینان فرضی است؛ نشان می‌دهد کدام بخش باید بررسی شود.
اگر مسئلهٔ روزمرهٔ شما بازنشدن فایل‌سرور است، راهنمای خطاهای پوشهٔ اشتراکی را بخوانید. برای برنامه‌ریزی حفاظت و بازگردانی اطلاعات، خدمات بکاپ و بازیابی ویوان و طراحی استراتژی پشتیبان‌گیری به این موضوع مرتبط‌اند.
پرسش‌های پرتکرار
آیا وجود فایل در فضای ابری یعنی بکاپ داریم؟
لزوماً نه. باید رفتار حذف و خرابی، نسخه‌های نگهداری‌شده، دسترسی و امکان بازیابی موردنیاز را در همان سرویس بررسی کنید.
آیا کپی روی هارد اکسترنال می‌تواند بخشی از بکاپ باشد؟
بله، اگر زمان‌بندی، نسخه‌ها، حفاظت مقصد و روش بازیابی مشخص باشد. صرف یک کپی قدیمی یا مقصدِ همیشه در دسترس، همهٔ نیازهای حفاظت را پوشش نمی‌دهد.
Sync و بکاپ را باید هم‌زمان داشته باشیم؟
نیاز به کار تیمی و نیاز به بازیابی دو مسئله‌اند. ممکن است ابزارها ترکیبی باشند؛ تصمیم باید بر اساس ریسک، تنظیمات و نتیجهٔ آزمون گرفته شود.
پیام موفقیت نرم‌افزار بکاپ کافی است؟
گزارش اجرای موفق مهم است، اما جای بازگردانی آزمایشی و بررسی قابل استفاده بودن داده را نمی‌گیرد.
آیا قاعدهٔ ۳-۲-۱ امنیت کامل را تضمین می‌کند؟
خیر. دسترسی، حفاظت در برابر حذف، نگهداری کلید، پوشش داده و آزمون بازگردانی همچنان باید بررسی شوند.
منابع و حدود مقاله
منابع رسمی مایکروسافت و CISA کنار موضوع‌های مرتبط آمده‌اند. رفتار هر محصول باید با نسخه، مجوز و سیاست نگهداری همان سازمان تأیید شود. این مقاله توصیهٔ خرید محصول خاص یا تضمین بازیابی همهٔ اطلاعات نیست.
از قابل بازیابی بودن اطلاعات شرکت مطمئن نیستید؟
نوع داده و روش فعلی نگهداری را توضیح دهید؛ برای بررسی اولیه، ارسال فایل محرمانه یا کلید رمزگذاری لازم نیست.
ثبت درخواست بررسی