
به اشتراک بگذارید

به اشتراک بگذارید
دفتر مرکزی یک سند را ثبت میکند و شعبه دوم تا فردا آن را نمیبیند؛ همین یک جمله دلیل اصلی مهاجرت به حسابداری روی سرور مجازی است. در این مدل، نرمافزار و دیتابیس آن روی یک سرور ویندوز متمرکز میشوند و هر شعبه با ریموت دسکتاپ به همان یک نسخه از داده وصل میشود؛ پس «فایل را برایم بفرست» از چرخه کار حذف میشود.
| موضوع | پاسخ کوتاه |
|---|---|
| چه چیزی متمرکز میشود؟ | نرمافزار حسابداری و دیتابیس آن روی یک سرور ویندوز؛ شعبهها فقط میزکار را میبینند. |
| اولین سقفی که میخورید | ریموت دسکتاپ فقط دو اتصال همزمان میدهد؛ نفر سوم به نقش RD Session Host و مجوز نیاز دارد. |
| فایل دیتابیس کجا بنشیند؟ | روی دیسک محلی سرور؛ اشتراک SMB از SQL Server 2012 پشتیبانی میشود اما توصیه نمیشود. |
| چه چیزی را نباید حدس زد؟ | ادیشن تاییدشده دیتابیس و سقف کاربر همزمان در لایسنس نرمافزار. |
💡 نکته کلیدی
تمرکز داده یعنی یک دیتابیس و یک مرجع واحد برای همه شعبهها.
✅ پیش از خرید منابع سه عدد را بنویسید: تعداد کاربر همزمان در ساعت شلوغ، حجم فعلی فایل دیتابیس، و فاصله قابلقبول بین دو بکاپ.
این راهنما همان مسیری را طی میکند که یک کسبوکار دو یا سه شعبهای در عمل طی میکند: اول روشن میکنیم فایل داده کجا باید بنشیند، بعد سقف نشستهای ریموت و پیشنیازها را از مستندات خود مایکروسافت میخوانیم و آخر سر دسترسی کاربران و بکاپ را میبندیم.
📌 آنچه در این مقاله میخوانید
◀️ حسابداری متمرکز چه مشکلی را حل میکند؟
◀️ فایل دیتابیس روی دیسک محلی یا اشتراک شبکه؟
◀️ سقف نشست ریموت، ادیشن دیتابیس و لایسنس
◀️ راهاندازی، دسترسی کاربران و بکاپ در برابر باجافزار

مشکل اصلی چند شعبه، کمبود سرعت نیست؛ چندنسخهشدن داده است. وقتی هر شعبه فایل خودش را دارد، مانده حساب یک مشتری در دو شعبه دو عدد متفاوت نشان میدهد. حسابداری روی سرور مجازی این چندگانگی را حذف میکند، چون نرمافزار و دیتابیس یک نسخه دارند.
تصور سادهاش یک دفترکل است که به میز پیشخان پیچ شده باشد؛ هرچه در آن نوشته شود، بقیه هم همان را میبینند. با یک دفترچه جداگانه در هر شعبه، آخر شب باید کسی دو دفترچه را تطبیق بدهد، و تطبیق دستی همان جایی است که اختلاف متولد میشود.
سود عملیاش روشن است: حسابها بدون انتظار برای فایل بسته میشوند، گزارش همه شعبهها لحظهای است، و بکاپ یک نقطه مشخص دارد.
یک نکته پیش از ادامه: همه بستههای حسابداری روی SQL Server کار نمیکنند و بعضی قالب فایل اختصاصی دارند. پس نخستین پرسش به فروشنده این است که نرمافزار داده را روی چه موتوری نگه میدارد؛ ادامه مقاله حالت SQL Server را باز میکند.
اگر پرسش شما این است که برای نرمافزار حسابداری یا ERP چه سروری بخرید، مطلب راهنمای انتخاب سرور حسابداری و ERP به همان پرسش جواب میدهد. تمرکز اینجا چیز دیگری است: چند شعبه چطور روی یک دیتابیس کار میکنند.
🔶 بستر اجرا
سرور مجازی ویندوز ایران وبداده در دیتاسنتر تهران و روی شبکه رسپینا میزبانی میشود و نصب ویندوز سرور، اسنپشات و بازگردانی از پنل اختصاصی انجام میشود. تغییر IP و ارتقای منابع هم از پنل و بدون تیکت است و امکان تست ساعتی رایگان سرور وجود دارد.
پاسخ کوتاه این است که فایل داده روی دیسک محلی همان سروری بنشیند که موتور دیتابیس روی آن اجرا میشود. حسابداری روی سرور مجازی با اشتراک شبکه هم ممکن است، ولی هزینه و ریسکی دارد که کمتر کسبوکار کوچکی دلیلی برای پذیرفتنش دارد.
اول آن چیزی که درست نیست: این تصور که فایل دیتابیس روی مسیر شبکه «پشتیبانی نمیشود». طبق صفحه نصب SQL Server با اشتراک SMB، از SQL Server 2012 به بعد دیتابیسهای سیستمی و کاربر میتوانند روی یک فایلسرور SMB نصب شوند، چه مستقل و چه در کلاستر. خطای 5110 هم مربوط به SQL Server 2008 و قبلتر بود و فلگ 1807 از SQL Server 2012 لازم نیست.
اما «ممکن» با «بیهزینه» یکی نیست. همان صفحه شرط میگذارد که حسابهای سرویس روی پوشه اشتراکی دسترسی FULL CONTROL اشتراک و NTFS داشته باشند و هنگام نصب یک حساب دامین تعیین شود. درایو شبکه نگاشتهشده پشتیبانی نمیشود و FILESTREAM روی اشتراک SMB کار نمیکند. برای یک شرکت سهشعبهای این یعنی یک دامین و یک فایلسرور دیگر.
طرف دوم ریسک است. طبق سند «Description of support for network database files» (بهروزرسانی 2025)، توصیه عمومی مایکروسافت نگهداشتن فایل دیتابیس روی دیسک محلی یا SAN است و ذخیرهسازی که تضمین نوشتن مستقیم روی رسانه و ترتیب نوشتن را برآورده نکند پشتیبانی نمیشود. دلیلش هم در همان صفحه آمده: پروتکل بازیابی بر این فرض استوار است که وقتی یک درخواست نوشتن به موتور برمیگردد، نوشتن واقعاً تمام شده است. پس مشکل خودِ شبکه نیست، نبودِ آن تضمین است.
| معیار | فایل داده روی اشتراک شبکه | فایل داده روی دیسک محلی |
|---|---|---|
| وضعیت پشتیبانی | از SQL Server 2012 پشتیبانی میشود | پشتیبانی میشود |
| توصیه مایکروسافت | توصیه نمیشود | حالت توصیهشده |
| شرط پشتیبانی | تضمین نوشتن مستقیم و ترتیب نوشتن | شرط جداگانه ندارد |
| پیشنیاز دسترسی | FULL CONTROL اشتراک و NTFS، حساب دامین | دسترسی محلی حساب سرویس |
⚠️ فایل داده در پوشه اشتراکی ساده، همان چیزی نیست که بالا گفتیم
آنچه مستندات بالا توصیف میکنند یک فایلسرور SMB با حساب دامین و مجوزهای مشخص است که فقط موتور دیتابیس روی آن مینویسد. استقرارهای قدیمی چیز دیگری میکنند: فایل داده در یک پوشه اشتراکی معمولی و چند کلاینت مستقیم روی آن. این تفکیک استدلال ما است و نقل مستندات نیست؛ اگر نرمافزار شما چنین معماری را لازم دارد، شرایط پشتیبانی آن را از فروشنده مکتوب بگیرید.

برای حسابداری روی سرور مجازی سه سقف جدا وجود دارد و هر سه میتوانند جلوی شعبه سوم را بگیرند: تعداد اتصال همزمان ریموت دسکتاپ، ادیشن SQL Server، و لایسنس نرمافزار حسابداری. دو سقف اول در مستندات مایکروسافت عدد دارند؛ سقف سوم را فقط فروشنده نرمافزار میگوید.
یک سرور ویندوز تازه، با ریموت دسکتاپ فعال، فقط دو اتصال همزمان میپذیرد. مستندات «Using Remote Desktop» مایکروسافت صریح میگویند برای اتصال با هدف مدیریتی نیازی به نصب نقش RD Session Host نیست، ریموت دسکتاپ فقط از دو اتصال همزمان پشتیبانی میکند، و برای این دو اتصال به RDS CAL نیازی نیست. پس دو شعبه بدون خرید اضافه کار میکنند و شعبه سوم متوقف میشود.
برای رفتن از دو به بیشتر سه قدم لازم است و هر سه را باید پیش از خرید سرور در بودجه دید: نصب نقش RD Session Host، راهاندازی یک Remote Desktop Licensing server، و خرید RDS CAL به تعداد کاربر یا دستگاه. مسیر نصب در مستندات استقرار Remote Desktop Services از Server Manager و گزینه Add Roles and Features توضیح داده شده است.
طبق مستندات RDS CAL، هر کاربر و هر دستگاهی که به یک Session Host وصل میشود به یک مجوز نیاز دارد و این مجوزها از سرور لایسنس صادر میشوند. یک دوره مهلت 120 روزه هم وجود دارد که بعد از پایانش ورود بدون مجوز معتبر انجام نمیشود. مدل Per Device به دستگاه بسته میشود و مدل Per User به حساب کاربر در Active Directory.
⚠️ «وصل شد» به معنی «مجوز دارم» نیست
همان مستندات درباره مدل Per User هشدار میدهند که این مجوزها بهصورت فنی اعمال نمیشوند و میتوانند بیش از تعداد خریداریشده تخصیص بگیرند، که نقض توافقنامه لایسنس است. یعنی کاربر پنجم ممکن است وصل شود، خطایی نبیند و با این حال بدون مجوز باشد. اگر پیام لایسنس را دیدید، رفع خطای provide a license در ویندوز سرور مسیر بررسی را توضیح میدهد.
انتخاب ادیشن از انتخاب منابع مهمتر است. طبق صفحه مقایسه ادیشنهای SQL Server 2022، ادیشن Express سه سقف دارد: حجم هر دیتابیس حداکثر 10 گیگابایت، بافر پول (حافظهای که موتور برای نگهداشتن داده در رم به کار میبرد) حداکثر 1410 مگابایت، و پردازش تا کمترین مقدار بین یک سوکت یا چهار هسته. ادیشن Standard تا 128 گیگابایت بافر پول و تا کمترین مقدار بین چهار سوکت یا 24 هسته میرود.
یک نتیجه عملی را جدی بگیرید: روی سروری با 32 گیگابایت رم، ادیشن Express بیش از حدود 1.4 گیگابایت از آن حافظه را برای بافر پول به کار نمیگیرد. پول رم را دادهاید و دیتابیس از آن استفاده نمیکند.
🔸 سقف 10 گیگابایت چه زمانی میرسد؟
این سقف به حجم دیتابیس مربوط است، نه به تعداد اسناد؛ حجم فعلی فایل دیتابیس و نرخ رشد ماهانه آن را از همین امروز اندازه بگیرید.
نکته دوم از همان صفحه: SQL Server Agent در ادیشن Express موجود نیست، پس زمانبندی بکاپ در Express به یک اسکریپت و Task Scheduler ویندوز نیاز دارد.
درباره نرمافزارهای حسابداری ایرانی یک نکته را صریح میگوییم: شرایط لایسنس چندکاربره و ادیشن تاییدشده دیتابیس از سازندهای به سازنده دیگر فرق میکند و مستندات عمومی هیچکدام در زمان نوشتن این مقاله از این محیط قابل دریافت نبود. پس هیچ عددی از طرف خودمان نمیگذاریم و این چهار پرسش را مکتوب از فروشنده بگیرید:
هیچکدام از این محدودیتها را با ترفند دور نزنید؛ دور زدن لایسنس شما را وسط بازگردانی تنها میگذارد. سمت سختافزار هم صفحه «Hardware and software requirements» مایکروسافت نصب SQL Server 2022 را روی Windows Server 2016 و بالاتر تایید میکند و برای ادیشنهای غیر از Express توصیه چهار گیگابایت حافظه، پردازنده x64 با 2.0 گیگاهرتز و شش گیگابایت فضای آزاد را اعلام میکند.

ترتیب کارها در راهاندازی حسابداری روی سرور مجازی اهمیت دارد، چون بعضی تصمیمها را بعداً نمیتوان بدون مهاجرت داده عوض کرد: ادیشن دیتابیس، محل فایل داده و الگوی حسابهای کاربری.
حساب مشترک بزرگترین اشتباه رایج این استقرار است. وقتی پنج نفر با یک نام کاربری Administrator وصل میشوند، نه میتوان فهمید چه کسی سند را حذف کرد و نه دسترسی کارمندی که شرکت را ترک کرده قطع میشود. برای هر نفر یک حساب بسازید و حسابهای دیتابیس را جدا در نظر بگیرید.
پوشه فایلهای دیتابیس هم جای کنجکاوی کاربران نیست؛ دسترسی NTFS آن را به حساب سرویس موتور و مدیر سیستم محدود کنید.
انتخاب مدل بازیابی تعیین میکند در بدترین حالت چقدر کار از دست میرود. طبق مستندات مدلهای بازیابی SQL Server، مدل Simple بکاپ لاگ تراکنش را پشتیبانی نمیکند و بازیابی فقط تا انتهای آخرین بکاپ امکان دارد. مدل Full بکاپ لاگ را لازم دارد و در مقابل بازگردانی به یک لحظه دلخواه را ممکن میکند.
با یک بکاپ کامل شبانه، مشکل ساعت پنج عصر یعنی یک روز کاری سه شعبه رفته است؛ مدل Full به همراه بکاپ دورهای لاگ این فاصله را به چند دقیقه میرساند. دو دستور پایه که در مستندات BACKUP مایکروسافت آمدهاند همین کار را میکنند:
BACKUP DATABASE Accounting
TO DISK = 'E:\Backup\Accounting_full.bak'
WITH FORMAT, CHECKSUM;
GO
BACKUP LOG Accounting
TO DISK = 'E:\Backup\Accounting_log.trn'
WITH CHECKSUM;
GO
گزینه CHECKSUM در همان مستندات یعنی هر صفحه هنگام بکاپ بررسی و برای کل بکاپ یک checksum ساخته میشود؛ پیشفرض NO_CHECKSUM است. گزینه FORMAT رسانه را از نو میسازد، پس فقط برای فایل بکاپ تازه.
⚠️ بکاپی که روی همان سرور است، بکاپ باجافزار هم هست
تجربه ما این را میگوید و نقل مستندات نیست: باجافزار هر مسیری را که سیستمعامل به آن دسترسی نوشتن دارد رمز میکند، از جمله پوشه بکاپ روی درایو دیگر و درایو شبکهای همیشهمتصل. پس دستکم یک نسخه باید جایی باشد که سرور بهطور پیوسته به آن دسترسی نوشتن ندارد.
دو کار دیگر هم ارزش وقت گذاشتن دارند. اول، رمز عبور بلند و قفلشدن حساب پس از چند تلاش ناموفق. دوم، آزمودن بازگردانی روی یک سرور دیگر؛ بکاپ آزمودهنشده هنوز یک فرض است.
پرسشهایی که کسبوکارهای چندشعبهای پیش از خرید سرور میپرسند:
بهطور پیشفرض دو نفر. مستندات Using Remote Desktop مایکروسافت میگویند برای اتصال مدیریتی نیازی به نقش RD Session Host نیست، ریموت دسکتاپ فقط دو اتصال همزمان میدهد و برای این دو به RDS CAL نیازی نیست. از سه نفر به بالا باید نقش RD Session Host، یک سرور لایسنس و RDS CAL داشته باشید.
بستگی به رشد دیتابیس و تایید فروشنده دارد. ادیشن Express حجم هر دیتابیس را به 10 گیگابایت، بافر پول را به 1410 مگابایت و پردازش را به کمترین مقدار بین یک سوکت یا چهار هسته محدود میکند و SQL Server Agent هم ندارد.
بله، از SQL Server 2012 اشتراک SMB گزینه ذخیرهسازی پشتیبانیشده است، ولی شرط دارد: دسترسی FULL CONTROL اشتراک و NTFS برای حسابهای سرویس، یک حساب دامین هنگام نصب، و ذخیرهسازی با تضمین ترتیب نوشتن. درایو نگاشتهشده پشتیبانی نمیشود و مایکروسافت در کل دیسک محلی یا SAN را توصیه میکند.
این خطا میگفت فایل روی دستگاه شبکهای است که برای فایل دیتابیس پشتیبانی نمیشود، و مربوط به SQL Server 2008 و قبلتر بود. در آن نسخهها فلگ 1807 بررسی را دور میزد و از SQL Server 2012 لازم نیست. اگر امروز این خطا را میبینید، نسخه نصبشده شما قدیمی است.
داده روی سرور است و قطعی خط نشست ریموت را میبندد. تراکنشی که کامل نشده باشد، بر اساس همان منطق لاگ تراکنش که مستندات مایکروسافت توصیف میکنند، اثری در دیتابیس نمیگذارد. اما کار آن شعبه تا بازگشت اتصال متوقف میشود.
با سه عدد تصمیم بگیرید: تعداد کاربر همزمان، حجم دیتابیس و زمان اجرای سنگینترین گزارش پایان دوره. اگر گزارشها در زمان قابلقبول تمام میشوند، سرور مجازی ویندوز پاسخ میدهد و مزیتش ارتقای منابع بدون تغییر سرور است. وقتی گزارشها از سقف منابع رد میشوند، سرور اختصاصی گزینه بهتری است.
کافی نیست. با مدل بازیابی Simple تنها میتوانید به انتهای آخرین بکاپ برگردید، پس کار یک روز در خطر است. از آن مهمتر، بکاپی که روی همان سرور است در سناریوی باجافزار یا خرابی کامل سرور همراه داده اصلی از بین میرود.
جمعبندی؛ حسابداری روی سرور مجازی یک تصمیم داده است، نه یک خرید سختافزاری. آنچه این مدل را موفق میکند، متمرکز کردن دیتابیس در یک نقطه و وصل کردن شعبهها به همان نقطه است. دو سقف مستند همان ابتدا مسیر را تعیین میکنند. ریموت دسکتاپ بدون نقش RD Session Host فقط دو اتصال همزمان میدهد، و ادیشن Express حجم دیتابیس و حافظه بافر پول را محدود میکند. فایل داده هم جای دیسک محلی سرور است؛ اشتراک SMB از SQL Server 2012 پشتیبانی میشود ولی مایکروسافت آن را توصیه نمیکند.
سه عدد را پیش از خرید روی کاغذ بیاورید: حجم فعلی دیتابیس و نرخ رشدش، تعداد کاربر همزمان در ساعت شلوغ، و فاصله قابلقبول بین دو بکاپ. عدد اول ادیشن دیتابیس را تعیین میکند، عدد دوم وضعیت نقش RD Session Host و مجوزها را، و عدد سوم مدل بازیابی را. هر سه را با فروشنده نرمافزار چک کنید، چون شرایط لایسنس چندکاربره را فقط او تایید میکند. آخرین کار پیش از انتقال داده واقعی هم یک بازگردانی آزمایشی است؛ تا آن لحظه، بکاپ شما فقط یک فایل است.
🚀 شروع کار روی یک سرور ویندوز
اگر تصمیم گرفتهاید دیتابیس حسابداری را متمرکز کنید، ویندوز سرور را از پنل نصب کنید و با اسنپشات پیش از هر تغییر بزرگ یک نقطه بازگشت بسازید.
اگر سوالی داشتید، در بخش نظرات با ما در ارتباط باشید.