فرض کنید صبح یک روز کاری، سرور فایل شرکت در دسترس نیست. واحد مالی به اسناد خود دسترسی ندارد، نرمافزار ERP متوقف شده است و کارشناسان IT متوجه میشوند که بخشی از دادهها در جریان یک حمله باجافزاری، رمزگذاری شدهاند. در چنین شرایطی اولین سؤال مدیریت معمولاً این است: «بکاپ داریم؟»
اما سؤال دقیقتر باید این باشد: «آیا بکاپ سالم، امن و قابل بازیابی داریم و در چه مدت میتوانیم سرویس را برگردانیم؟»
این تفاوت کوچک در ظاهر، یکی از مهمترین موضوعات مدیریت زیرساخت IT است. داشتن چند فایل با عنوان Backup روی یک NAS یا هارد اکسترنال لزوماً به معنای داشتن یک سیستم پشتیبانگیری قابل اعتماد نیست. بکاپ زمانی ارزش واقعی دارد که هنگام خرابی سختافزار، حذف اشتباهی اطلاعات، حمله سایبری، اختلال نرمافزاری یا حتی ازدسترفتن کامل یک سایت بتوان اطلاعات موردنیاز را از آن بازیابی کرد.
دادههای جدید نیز این فاصله میان «داشتن بکاپ» و «توانایی واقعی بازیابی» را نشان میدهند. در گزارش Data Trust and Resilience 2026، میزان ۹۰ درصد مدیران امنیتی گفتهاند که به توانایی سازمان خود برای بازیابی سریع اطمینان دارند؛ درحالیکه تنها ۲۸ درصد سازمانهایی که با باجافزار مواجه شدهاند توانستهاند دادههای خود را بهطور کامل بازیابی کنند.
با توجه به آنچه گفتیم، در این مقاله فقط به این سؤال پاسخ نمیدهیم که Backup چیست؛ بلکه بررسی میکنیم که یک بکاپ استاندارد چه ویژگیهایی دارد، انواع Backup چه تفاوتی با یکدیگر دارند، RPO و RTO چه نقشی در طراحی بکاپ دارند، چرا Snapshot و Replication جای بکاپ را نمیگیرند و سازمانها در سال ۲۰۲۶ چگونه باید از دادههای خود محافظت کنند. با ما همراه باشید.
فهرست مطالب
برای مشاوره رایگان با متخصصان رسام تماس بگیرید
گفتوگو در واتساپ
بکاپ چیست؟
Backup یا نسخه پشتیبان، یک نسخه مستقل از داده، تنظیمات یا وضعیت یک سیستم است که با هدف بازیابی اطلاعات در آینده نگهداری میشود. به زبان ساده، اگر اطلاعات اصلی از بین بروند، خراب شوند، اشتباهی حذف شوند یا دیگر قابل اعتماد نباشند، Backup باید امکان بازگرداندن نسخه سالم آنها را فراهم کند.
دادهای که از آن بکاپ گرفته میشود فقط فایلهای Word، Excel یا تصاویر نیست. در یک سازمان، Backup میتواند شامل موارد زیر باشد:
- فایلها و پوشههای کاربران
- پایگاههای داده
- ماشینهای مجازی
- تنظیمات سیستمعامل و سرورها
- تنظیمات تجهیزات شبکه
- Active Directory و اطلاعات هویتی
- ایمیلها و دادههای Microsoft 365 یا سایر سرویسهای SaaS
- کدهای نرمافزاری و Repositoryها
- تنظیمات برنامههای سازمانی
- دادههای تجهیزات صنعتی و Operational Technology
- اطلاعات سیستمهای ابری
AWS نیز Backup را ایجاد یک نسخه اضافی از داده تعریف میکند که برای بازیابی پس از بروز مشکل مورد استفاده قرار میگیرد؛ اما یک نکته مهم وجود دارد: کپیکردن اطلاعات با داشتن یک راهکار Backup یکسان نیست.
اگر پوشه مهم شرکت را روی NAS دیگری کپی کنید، یک نسخه دوم ایجاد کردهاید؛ اما اگر همان NAS در دسترس باجافزار باشد، فایلها همزمان با اطلاعات اصلی رمزگذاری شوند یا هیچوقت صحت آنها آزمایش نشود، این نسخه دوم الزاماً یک Backup قابل اتکا نیست.
چرا بکاپ در سال ۲۰۲۶ مهمتر شده است؟
در گذشته، مهمترین سناریوهای Backup معمولاً خرابی هارددیسک، حذف اشتباهی فایل یا خرابی سرور بودند. این خطرها هنوز هم وجود دارند؛ اما تهدیدهای جدید باعث شدهاند طراحی Backup پیچیدهتر شود.
یکی از مهمترین خطرهای جدید، باجافزار است. براساس گزارش State of Ransomware 2026 شرکت Sophos که بر پاسخ ۲۱۵۸ مدیر و متخصص IT و امنیت سایبری از ۱۷ کشور مبتنی است، در ۵۶ درصد حملات موفق باجافزاری، اطلاعات سازمانها رمزگذاری شده است. متوسط هزینه بازیابی پس از حمله نیز حدود ۱٫۷ میلیون دلار و میانگین مبلغ باج پرداختشده ۷۶۹ هزار دلار گزارش شده است.
مسئله مهمتر این است که مهاجمان فقط اطلاعات عملیاتی را هدف نمیگیرند. زیرساخت Backup نیز به یکی از اهداف اصلی حملات تبدیل شده است؛ به همین دلیل CISA توصیه میکند سازمانها نسخههای پشتیبان مهم را رمزگذاریشده، آفلاین و بهصورت منظم آزمایششده نگهداری کنند؛ زیرا بسیاری از گونههای باجافزار تلاش میکنند بکاپهای متصل به شبکه را نیز پیدا کرده و حذف یا رمزگذاری کنند.
در سال ۲۰۲۶ موضوع دیگری نیز جدیتر شده است: دادههای SaaS و هویتی. گزارش ۲۰۲۶ Arcserve نشان میدهد ۱۹ درصد سازمانهای مورد بررسی هیچ Backup مستقلی برای دادههای SaaS خود ندارند. همین گزارش نشان داده است که پوشش Backup برای Microsoft 365 حدود ۶۳٫۱ درصد بوده است؛ اما این رقم برای Microsoft Entra ID به ۳۷ درصد، Google Workspace به ۲۱ درصد و Salesforce به ۲۰٫۵ درصد کاهش پیدا میکند.
به همین دلیل Gartner نیز در فهرست روندهای اصلی Backup و Data Protection در سال ۲۰۲۶، موضوعاتی مانند Identity Backup، بازیابی Cloud-Native، مقابله با باجافزار، استفاده از هوش مصنوعی در Backup و الزامات حاکمیت داده را برجسته کرده است.
Backup با Snapshot چه تفاوتی دارد؟
Snapshot وضعیت یک Volume، ماشین مجازی یا Storage را در یک نقطه زمانی ثبت میکند و معمولاً بسیار سریعتر از Backup ساخته میشود؛ اما Snapshot لزوماً Backup نیست.
در بسیاری از معماریها Snapshot به Storage یا سیستم اصلی وابسته است. اگر کل Storage از بین برود یا مهاجم به سطح مدیریتی آن دسترسی پیدا کند، Snapshotهای آن نیز ممکن است از بین بروند.
Backup در معماری صحیح باید بتواند در Failure Domain جداگانه نگهداری شود؛ یعنی خرابی سیستم اصلی الزاماً باعث ازبینرفتن نسخه پشتیبان نشود؛ بنابراین Snapshot برای موارد زیر بسیار مفید است؛ اما نباید تنها لایه حفاظت از داده باشد:
- بازگشت سریع پس از Update
- Rollback ماشین مجازی
- ایجاد Recovery Point کوتاهمدت
Replication هم Backup نیست
Replication یا همانندسازی، اطلاعات را از یک سیستم به سیستم دیگری منتقل و تغییرات را بین آنها هماهنگ میکند.
فرض کنید دیتابیس اصلی در Site A روی Site B نیز Replicate میشود. اگر سرور Site A خراب شود، Replica میتواند زمان Downtime را بسیار کاهش دهد؛ اما یک مشکل وجود دارد و آن هم اینکه اگر کاربر بهاشتباه ۵۰۰۰ رکورد را حذف کند، عملیات حذف نیز ممکن است روی Replica اعمال شود.
Microsoft بهصراحت تأکید میکند که Replication جای Backup را نمیگیرد؛ زیرا Replication تغییرات، از جمله حذف یا خرابشدن داده را میان Replicaها منتقل میکند، درحالیکه Backup امکان بازگشت به نسخه قبلی داده را فراهم میکند.
در نتیجه میتوان گفت:
Replication برای Availability است؛ Backup برای Recoverability و در یک زیرساخت حرفهای معمولاً هر دو مورد نیاز هستند.
RPO و RTO؛ دو عددی که باید قبل از خرید راهکار Backup مشخص شوند
یکی از اشتباهات متداول این است که ابتدا نرمافزار یا Storage تهیه شود و سپس درباره Backup Policy تصمیم گرفته شود. روش صحیح، از نیاز کسبوکار شروع میشود. دو شاخص کلیدی این تصمیم عبارت هستند از:
RPO
Recovery Point Objective یا RPO بیشترین مقدار اطلاعاتی است که سازمان میتواند در یک حادثه از دست بدهد و معمولاً برحسب زمان بیان میشود.
اگر RPO سیستم مالی ۱۵ دقیقه باشد، یعنی در سناریوی Disaster نباید مجبور شویم اطلاعات را به نسخهای برگردانیم که بیش از ۱۵ دقیقه از اطلاعات جاری عقبتر است؛ بنابراین Backup روزانه برای چنین سیستمی کافی نیست.
RTO
Recovery Time Objective یا RTO بیشترین زمان قابل قبول برای بازگرداندن سرویس بعد از اختلال است.
اگر RTO سامانه ERP دو ساعت باشد، معماری Backup و Recovery باید امکان بازگرداندن سرویس حداکثر در همین بازه را فراهم کند.
AWS نیز RPO را حداکثر فاصله قابل قبول تا آخرین Recovery Point و RTO را حداکثر تأخیر قابل قبول میان توقف سرویس و بازیابی آن تعریف میکند.
نکته مهم این است که RPO و RTO باید توسط نیاز کسبوکار تعیین شوند؛ نه براساس قابلیت پیشفرض نرمافزار Backup.
قانون ۳-۲-۱ Backup چیست؟
یکی از شناختهشدهترین اصول پشتیبانگیری، قانون ۳-۲-۱ است:
۳: سه نسخه از داده داشته باشید؛ یک نسخه Production و حداقل دو Backup.
۲: نسخهها را روی حداقل دو نوع رسانه یا زیرساخت ذخیرهسازی متفاوت قرار دهید.
۱: حداقل یک نسخه در محل دیگری نگهداری شود.
برای مثال:
- Production Storage
- Backup Repository در دیتاسنتر اصلی
- نسخه Backup در دیتاسنتر دوم یا Cloud
اما در مقابل باجافزارهای جدید، مدل کلاسیک ۳-۲-۱ همیشه کافی نیست.
قانون ۳-۲-۱-۱-۰؛ نسخه جدیدتر برای مقابله با باجافزار
یکی از مدلهایی که در سالهای اخیر مورد توجه بیشتری قرار گرفته ۳-۲-۱-۱-۰ است.
در این مدل:
۳ = سه نسخه از اطلاعات
۲ = دو رسانه یا بستر متفاوت
۱ = یک نسخه خارج از سایت
۱ = یک نسخه Offline، Air-Gapped یا Immutable
۰ = صفر خطا در فرایند صحتسنجی بازیابی
Veeam در بهروزرسانی سال ۲۰۲۶ راهنمای خود نیز این مدل را برای افزایش مقاومت در برابر تهدیدهایی مانند Ransomware توصیه کرده است.
عدد«۱» اهمیت بیشتری دارد. اگر تمام Backup Repositoryها همیشه از شبکه Production قابل دسترسی باشند و مهاجم به حساب مدیریتی Backup دسترسی پیدا کند، ممکن است تمام نسخهها حذف شوند؛ به همین دلیل حداقل یکی از نسخهها باید به شکلی طراحی شود که تغییر یا حذف آن برای مهاجم بسیار دشوار باشد.
Immutable Backup چیست؟
Immutable Backup نسخهای است که در یک بازه زمانی مشخص نمیتوان محتوای آن را تغییر داد یا حذف کرد؛ حتی اگر یک حساب کاربری معمولی یا در برخی پیادهسازیها Administrator تلاش کند آن را دستکاری کند. این ویژگی برای مقابله با باجافزار اهمیت زیادی دارد؛ البته سه اصطلاح را نباید یکسان فرض کرد:
Offline Backup: در حالت عادی به سیستم Production متصل نیست.
Air-Gapped Backup: میان نسخه پشتیبان و محیط اصلی جداسازی فیزیکی یا منطقی کنترلشده وجود دارد.
Immutable Backup: داده برای مدت تعیینشده قابل تغییر یا حذف نیست.
هر سه رویکرد با هدف کاهش احتمال ازبینرفتن Backup استفاده میشوند؛ اما مکانیزم فنی آنها متفاوت است. CISA نیز توصیه میکند Backupهای سازمانی، بهخصوص در برابر Ransomware، رمزگذاریشده و Immutable باشند و امکان حذف یا تغییر آنها محدود شود.
آیا موفقشدن Backup Job به معنی سالمبودن بکاپ است؟
در یک کلام باید بگوییم: خیر. این موضوع یکی از مهمترین نکاتی است که باید در طراحی سیستم Backup در نظر گرفته شود.
پیغام Backup Completed Successfully فقط نشان میدهد عملیات Backup طبق معیارهای نرمافزار بدون خطای ثبتشده پایان یافته است. این موضوع الزاماً ثابت نمیکند که کل سرویس در شرایط واقعی قابل Restore است.
در گزارش State of Data Resilience 2026 شرکت Arcserve، میزان ۶۵٫۱ درصد پاسخدهندگان اطمینان داشتند که میتوانند پس از حمله باجافزاری در کمتر از ۴۸ ساعت بازیابی شوند؛ اما تنها ۳۵٫۴ درصد در تست واقعی توانستهاند اهداف RPO و RTO خود را محقق کنند؛ همچنین حدود ۲۴ درصد گفتهاند هیچگاه Full Recovery را آزمایش نکردهاند؛ بنابراین Backup باید آزمایش شود.
تست میتواند شامل موارد زیر باشد:
- Restore تصادفی چند فایل
- بازیابی Database
- بررسی Application Consistency
- Boot کردن ماشین مجازی بازیابیشده
- تست Bare-Metal Recovery
- Restore در شبکه ایزوله
- اندازهگیری زمان واقعی Recovery
- مقایسه نتیجه با RTO
- بررسی آخرین Recovery Point و مقایسه با RPO
اصل مهم این است:
هدف Backup ساخت فایل Backup نیست؛ هدف، Recovery موفق است.
هر چند وقت یکبار باید Backup بگیریم؟
واقعیت این است که هیچ عدد ثابتی برای همه سازمانها وجود ندارد و نمیتوان گفت سازمانها هر چند وقت یکبار باید بکاپ بگیرند. فرکانس Backup باید براساس حداقل چهار عامل تعیین شود:
- RPO
- نرخ تغییر اطلاعات
- اهمیت سرویس
- هزینه از دست رفتن داده
برای مثال، این سناریو صرفاً یک نمونه طراحی است:
| سرویس | RPO نمونه | استراتژی احتمالی |
|---|---|---|
| دیتابیس تراکنشی حیاتی | ۱۵ دقیقه | Backup/Log Protection پرتکرار |
| File Server سازمان | ۴ ساعت | Incremental چندبار در روز |
| سیستم آرشیوی کمتغییر | ۲۴ ساعت | Backup روزانه |
| تنظیمات برخی تجهیزات شبکه | بعد از هر تغییر | Backup مبتنی بر Change |
بنابراین عبارتهایی مانند «بکاپ روزانه کافی است» بدون دانستن RPO معنای دقیقی ندارند.
از چه اطلاعاتی باید Backup بگیریم؟
یکی دیگر از خطاهای رایج، تمرکز بیش از حد روی File Server و Database است. یک برنامه Backup سازمانی باید Inventory کاملی از دادهها و Dependencyها داشته باشد؛ برای مثال، بازیابی یک نرمافزار سازمانی ممکن است علاوهبر Database به موارد زیر وابسته باشد:
- ماشین مجازی
- فایلهای Application
- Certificateها
- DNS
- Active Directory
- تنظیمات Firewall
- License Server
- Configuration Fileها
- سرویسهای جانبی
به همین دلیل NIST در راهنمای جدید SP 1339 که در ژوئن ۲۰۲۶ برای محیطهای Operational Technology منتشر شده است تأکید میکند Backup باید بخشی از Change Management باشد، مرتب تهیه شود، آزمایش شود و در Recovery Exerciseها مورد بررسی قرار گیرد. این موضوع فقط مختص OT نیست؛ همان منطق در شبکههای Enterprise نیز کاربرد دارد.
یک سناریوی واقعی برای طراحی Backup سازمانی
فرض کنیم یک شرکت متوسط دارای زیرساخت زیر است:
- دو Host مجازیسازی
- ۲۰ ماشین مجازی
- یک ERP
- SQL Server
- File Server
- Active Directory
- Microsoft 365
- حدود ۱۰ ترابایت داده
رویکرد اشتباه این است که فقط یک NAS تهیه شود و تمام ماشینهای مجازی هر شب روی آن Backup شوند؛ زیرا NAS ممکن است:
- در همان ساختمان قرار داشته باشد؛
- با همان Domain Account مدیریت شود؛
- دائماً به شبکه متصل باشد؛
- هیچ Immutable Protection نداشته باشد؛
- خود نیز در حمله باجافزاری آسیب ببیند.
رویکرد مقاومتر میتواند چند لایه داشته باشد:
لایه اول: Backup سریع روی Repository محلی برای Restoreهای روزمره.
لایه دوم: Backup Copy روی Storage مستقل با قابلیت Immutability.
لایه سوم: نسخه خارج از سایت یا Cloud برای Disasterهای گسترده.
لایه چهارم: تست دورهای Restore برای اثبات RPO و RTO.
همچنین برای ERP و SQL ممکن است Protection کوتاهتری نسبت به File Server تعریف شود و دادههای Microsoft 365 نیز بهطور مستقل تحت Backup Policy قرار گیرند.
این مثال نشان میدهد خرید Storage برای Backup با طراحی Backup Architecture تفاوت دارد.
اشتباهات رایج در Backup سازمانی
رایجترین اشتباهات در بکاپ سازمانی به شرح زیر هستند:
نگهداری Backup کنار اطلاعات اصلی
اگر Production و Backup در یک Failure Domain باشند، خرابی Storage، آتشسوزی، خطای مدیریتی یا حمله سایبری ممکن است هر دو را همزمان از بین ببرد.
اتصال دائمی همه بکاپهابه شبکه
هر Backup متصل و قابل نوشتن میتواند هدف مهاجم قرار گیرد.
یکی دانستن Sync با Backup
سرویس Sync برای هماهنگکردن اطلاعات طراحی شده است. حذف یا خرابشدن فایل میتواند به سایر نسخهها نیز منتقل شود.
نداشتن Restore Test
این یکی از جدیترین خطاها است. Backup آزمایشنشده فقط یک امید به بازیابی است.
استفاده از همان حسابهای مدیریتی Production
جداکردن Credentialها و سطح دسترسی زیرساخت Backup میتواند Blast Radius یک Account Compromise را کاهش دهد.
فراموشکردن SaaS و Identity
تمرکز فقط روی سرورهای On-Premises دیگر کافی نیست. دادههای Microsoft 365، Google Workspace، CRM و سرویسهای Identity نیز بخشی از Data Protection Strategy هستند.
هنگام انتخاب راهکار Backup باید چه مواردی را بررسی کنیم؟
برای یک سازمان حرفهای، ظرفیت Storage تنها معیار انتخاب نیست.
پیش از انتخاب نرمافزار، Appliance یا Backup Storage باید حداقل موارد زیر بررسی شوند:
- Workloadهای تحت پشتیبانی
- RPO و RTO
- حجم داده و نرخ رشد
- نرخ تغییر روزانه اطلاعات
- Retention Policy
- قابلیت Immutable Storage
- رمزگذاری Data at Rest و Data in Transit
- Role-Based Access Control
- MFA برای حسابهای مدیریتی
- Application-Aware Backup
- Granular Restore
- Bare-Metal Recovery
- پشتیبانی از Virtualization Platformهای سازمان
- Backup سرویسهای SaaS
- امکان Off-Site Backup
- Deduplication و Compression
- محدودیت پهنای باند
- سرعت Restore
- خودکارسازی Recovery Test
- Monitoring و Alerting
- گزارشهای Audit و Compliance
- هزینه License و Storage در بلندمدت
مهمتر از همه اینکه محصول باید براساس Recovery Requirement سازمان انتخاب شود، نه صرفاً فهرست امکانات Vendor.
انتخاب راهکار در سال ۲۰۲۶ به کدام سمت میرود؟
Backup دیگر فقط یک نرمافزار زمانبندیشده برای کپیکردن فایلها در نیمهشب نیست. چند ترند مهم در سال ۲۰۲۶ عبارت هستند از:
Identity Backup:
Active Directory و سرویسهایی مانند Entra ID به بخش حیاتی Recovery تبدیل شدهاند؛ زیرا بدون هویت و Authentication، بازیابی بسیاری از سرویسهای دیگر دشوار میشود.
Immutable Recovery:
تمرکز سازمانها از «داشتن چند Backup» به «داشتن Recovery Point سالمی که مهاجم نتواند حذف کند» تغییر کرده است.
Cloud-Native Backup:
با افزایش استفاده از Kubernetes، Object Storage و سرویسهای Cloud-Native، Data Protection باید این Workloadها را نیز پوشش دهد.
SaaS Backup:
فرض اینکه ارائهدهنده SaaS تمام سناریوهای حذف، خرابشدن یا حمله به داده مشتری را پوشش میدهد، میتواند یک شکاف جدی ایجاد کند.
AI در Backup:
یکی از کاربردهای درحال رشد هوش مصنوعی، تشخیص Anomaly در رفتار Backup و شناسایی نشانههایی مانند افزایش ناگهانی Encryption یا تغییر غیرعادی حجم داده است. با این حال استفاده عملی هنوز نسبت به میزان توجه بازار محدود است. در پژوهش Arcserve در سال ۲۰۲۶، ۵۷٫۹ درصد پاسخدهندگان Anomaly Detection مبتنیبر AI را کاربرد مهمی دانستهاند؛ اما فقط ۱۷٫۴ درصد آن را در محیط Production پیادهسازی کردهاند.
Backup در سادهترین تعریف، نسخهای از داده است که برای بازیابی اطلاعات پس از حذف، خرابی یا بروز حادثه نگهداری میشود؛ اما در یک زیرساخت سازمانی، تعریف عملی آن بسیار فراتر از کپیکردن چند فایل روی NAS یا فضای Cloud است.
یک راهکار Backup قابل اعتماد باید مشخص کند چه دادهای، با چه تناوبی، در کجا، برای چه مدتی و با چه سطح حفاظتی ذخیره میشود و در صورت حادثه چگونه و در چه مدت بازیابی خواهد شد.
Full، Incremental و Differential فقط روشهای مختلف ساخت نسخه پشتیبان هستند. برای طراحی واقعی Backup باید موضوعاتی مانند RPO، RTO، Retention، Immutability، Off-Site Copy، جداسازی دسترسیها و Restore Testing نیز مشخص شوند.
گزارشهای منتشرشده در سال ۲۰۲۶ یک نکته مشترک دارند: فاصله قابل توجهی میان اعتماد سازمانها به Backup و توانایی اثباتشده آنها در Recovery وجود دارد. به همین دلیل معیار موفقیت دیگر نباید تعداد Jobهای سبزرنگ کنسول Backup باشد؛ معیار واقعی این است که آیا سازمان میتواند در زمان بحران، داده سالم را در محدوده RPO و سرویس را در محدوده RTO تعیینشده بازیابی کند یا خیر.
برای بسیاری از سازمانها، حرکت از قانون کلاسیک ۳-۲-۱ به معماریهایی شامل نسخه Off-Site، Backup تغییرناپذیر یا Air-Gapped و تست مستمر Recovery میتواند مقاومت زیرساخت را در برابر خرابی و باجافزار به شکل محسوسی افزایش دهد.
در نهایت Backup یک محصول نیست؛ یک فرایند مستمر مدیریت ریسک و بخشی از استراتژی Data Resilience سازمان است.
اگر برای زیرساخت سازمان خود در حال انتخاب Backup Storage، سرور، تجهیزات ذخیرهسازی یا معماری مناسب پشتیبانگیری هستید، کارشناسان رسام میتوانند براساس حجم داده، زیرساخت فعلی، RPO، RTO و الزامات امنیتی سازمان، راهکار مناسب را بررسی و پیشنهاد کنند.
