خرید سرور مجازی

سرور مجازی (VPS) سهمی تضمین‌شده از یک سرور قدرتمند است که مثل یک سرور مستقل در اختیار شماست: سیستم‌عامل دلخواه، دسترسی کامل مدیریتی و منابعی که فقط برای شما رزرو شده. اگر مطمئن نیستید این سطح از کنترل برای شماست یا نه، این فهرست کاربردهای واقعی مشتریان ما تصمیم را روشن می‌کند:

• میزبانی چند سایت یا فروشگاه پرترافیک که از سقف هاست اشتراکی عبور کرده‌اند.
• اجرای اپلیکیشن و API اختصاصی (Node.js، پایتون، .NET و…) با سرویس‌ها و پورت‌های دلخواه.
• ربات‌ها و اتوماسیون‌های همیشه‌روشن (تلگرام، پایش بازار، کرال و زمان‌بندی).
• سرور بازی یا وویس‌سرور تیمی با پینگ قابل پیش‌بینی.
• میکروتیک مجازی برای مهندسان شبکه (پلن‌ها از MikroTik پشتیبانی می‌کنند).
• محیط تست و توسعهٔ ایزوله که با یک اسنپ‌شات به حالت قبل برگردد.
• ویندوز همیشه‌روشن برای نرم‌افزارهای دسکتاپیِ سازمانی یا معاملاتی.

قاعدهٔ ساده: تا وقتی فقط «سایت» دارید و منابع کافی است، هاست اشتراکی ارزان‌تر و بی‌دردسرتر است؛ روزی که به نصب سرویس در سطح سیستم‌عامل، پورت اختصاصی، یا منابع تضمین‌شده نیاز پیدا کردید، وارد قلمرو سرور مجازی شده‌اید. سرور مجازی به شما دسترسی کامل (root/Administrator) می‌دهد و در عوض، مدیریت سیستم‌عامل هم با شما خواهد بود.

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

مرز بعدی هم مشخص است: وقتی بار پردازشی به‌قدری بزرگ شد که کل یک سخت‌افزار را می‌خواهد، یا الزامات امنیتی، ایزولاسیون فیزیکی می‌طلبد، سرور اختصاصی گزینهٔ درست است. مسیر ارتقا در برتینا پلکانی و بدون تغییر ارائه‌دهنده است: هاست → سرور مجازی → سرور اختصاصی، با همراهی تیم فنی در هر جابه‌جایی.

انتخاب سیستم‌عامل تابع نرم‌افزاری است که می‌خواهید اجرا کنید. لینوکس (اوبونتو، دبیان، سنت‌اواس و…) انتخاب پیش‌فرض وب‌سرورها، اپلیکیشن‌های متن‌باز و ربات‌هاست: سبک‌تر است، منابع کمتری مصرف می‌کند و اکوسیستم ابزارهای سروری‌اش بزرگ‌تر است. ویندوز سرور برای نرم‌افزارهای ویندوزی، پشتهٔ .NET و کاربرانی است که محیط دسکتاپ از راه دور (RDP) می‌خواهند.

دربارهٔ مجازی‌ساز هم خیال‌تان راحت باشد: زیرساخت برتینا بر پایهٔ مجازی‌سازهای استاندارد (KVM، Hyper-V و ESXi بسته به پلن) کار می‌کند که ایزولاسیون واقعی منابع را تضمین می‌کنند — یعنی همسایه‌های پرمصرف، سهم شما را نمی‌خورند.

گزینهٔ سوم، میکروتیک، یک سیستم‌عامل شبکه است برای سناریوهای مسیریابی و مدیریت شبکه — انتخاب مهندسان شبکه، نه میزبانی سایت. در پلن‌های برتینا هر سه گزینه هنگام سفارش قابل انتخاب است و بعداً هم با نصب مجدد قابل تغییر؛ اگر مردد بودید، سناریوی استفاده‌تان را به پشتیبانی بگویید تا انتخاب درست را پیشنهاد دهند.

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

• ربات، اسکریپت سبک یا میکروتیک: ۱ گیگ RAM و ۱ هسته کافی است.
• یک سایت وردپرسی متوسط یا اپ کوچک: ۲ گیگ RAM و ۱–۲ هسته.
• چند سایت یا فروشگاه فعال: ۴ گیگ RAM و ۲ هسته به بالا.
• اپلیکیشن با دیتابیس پرکار یا ویندوز سرور: از ۴–۶ گیگ RAM شروع کنید (ویندوز خودش حدود ۲ گیگ می‌خواهد).
• پردازش سنگین، کش بزرگ یا همزمانی بالا: ۸ گیگ به بالا و مانیتور مصرف واقعی در هفتهٔ اول.

سرور مجازی «سرویس + مسئولیت» است و شفاف‌بودن این مرز از سوءتفاهم جلوگیری می‌کند. سمت برتینا: سلامت زیرساخت و سخت‌افزار، شبکه و پورت اعلام‌شده، در دسترس‌بودن سرور و پشتیبانی ۲۴/۷ برای مسائل زیرساختی. سمت شما: هر چیزی داخل سیستم‌عامل — نصب و پیکربندی سرویس‌ها، به‌روزرسانی‌های امنیتی، فایروال و بکاپ داده‌ها.

اگر دانش سرور ندارید، سه راه دارید: از همان ابتدا با پنل‌های مدیریتی (مثل کنترل‌پنل‌های وب‌هاستینگ روی سرور خودتان) کار کنید، مدیریت را به توسعه‌دهنده/ادمین‌تان بسپارید، یا اصلاً به‌جای سرور مجازی، با هاست اشتراکی شروع کنید و مهاجرت را به وقتی موکول کنید که تیم فنی دارید. مشاورهٔ قبل از خرید برتینا رایگان است — سناریو را بگویید تا صادقانه بگوییم سرور مجازی برایتان زود است یا نه.

این پنج کار را در همان روز تحویل انجام دهید؛ بخش بزرگی از حمله‌های خودکار را همین‌ها دفع می‌کنند:

• ۱. رمز پیش‌فرض را عوض کنید و برای لینوکس، ورود با کلید SSH را جایگزین رمز کنید.
• ۲. پورت‌های مدیریتی (SSH/RDP) را از پیش‌فرض تغییر دهید یا پشت فایروال محدود کنید.
• ۳. فایروال را فعال کنید و فقط پورت‌های لازم را باز بگذارید.
• ۴. به‌روزرسانی‌های امنیتی سیستم‌عامل را نصب و به‌روزرسانی خودکار را فعال کنید.
• ۵. برنامهٔ بکاپ مشخص کنید: اسنپ‌شات قبل از هر تغییر بزرگ + بکاپ دوره‌ای داده‌ها به خارج از سرور.

مسیر امن مهاجرت: سرور را تحویل بگیرید و محیط را کامل آماده کنید (وب‌سرور، دیتابیس، SSL)، سایت را منتقل و با فایل hosts خودتان تست کنید، و فقط بعد از تست موفق، DNS دامنه را به سرور جدید بدهید. هاست قبلی را هم تا چند روز فعال نگه دارید تا انتشار DNS کامل شود و مسیر بازگشت اضطراری باز بماند.

زمان‌بندی مهاجرت را هم هوشمندانه انتخاب کنید: ساعات کم‌ترافیک سایت (معمولاً نیمه‌شب تا صبح) بهترین پنجره است و روزهای منتهی به کمپین‌ها و مناسبت‌های فروش، بدترین. یک اعلان کوتاه «به‌روزرسانی زیرساخت» به کاربران وفادار هم حرفه‌ای‌تر از سکوت است، حتی اگر قطعی‌ای در کار نباشد.

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

دو عدد شبکه در مشخصات هر پلن آمده و معنای درست‌شان مهم است. «سرعت پورت» حداکثر پهنای باند لحظه‌ای اتصال سرور شماست (مثلاً ۱۰۰۰ مگابیت)؛ یعنی ظرفیت لوله، نه مصرف. «ترافیک ماهانه» مجموع داده‌ای است که در ماه جابه‌جا می‌کنید؛ برای یک سایت معمولی چند صد گیگابایت فضای بسیار بزرگی است، اما برای سرویس‌های دانلود/استریم باید حساب‌شده انتخاب شود.

هنگام مقایسه، به این هم دقت کنید که بعد از عبور از سقف ترافیک چه اتفاقی می‌افتد — قطع سرویس، کاهش سرعت یا هزینهٔ مازاد. اگر الگوی مصرف‌تان را نمی‌دانید، یک ماه با پلن متوسط شروع کنید و از آمار مصرف واقعی برای تصمیم بعدی استفاده کنید؛ ارتقا همیشه ساده‌تر از حدس اولیهٔ بزرگ است.

اسنپ‌شات، عکس فوری از کل سرور در یک لحظه است و بهترین کاربردش قبل از تغییرات بزرگ است: به‌روزرسانی سیستم‌عامل، تغییر پیکربندی حساس یا نصب نرم‌افزار جدید — اگر چیزی خراب شد، در چند دقیقه به لحظهٔ قبل برمی‌گردید. اما اسنپ‌شات جایگزین بکاپ نیست: روی همان زیرساخت ذخیره می‌شود و برای خطاهای انسانی روی داده‌ها (حذف اشتباه جدول، باگ منطقی) هم دیر است.

برای دیتابیس‌ها یک نکتهٔ تکمیلی: خروجی منطقی (dump) علاوه بر بکاپ فایل‌سیستم بگیرید؛ بازگردانی جدول یا رکورد مشخص از dump بسیار ساده‌تر است و در مهاجرت بین سرورها هم همین فایل بهترین دوست شماست.

بکاپ واقعی یعنی نسخهٔ دوره‌ای داده‌های حیاتی (دیتابیس، فایل‌های کاربر، تنظیمات) در جایی خارج از خود سرور. ترکیب درست برای اغلب کسب‌وکارها: اسنپ‌شات قبل از هر تغییر بزرگ + بکاپ شبانهٔ دیتابیس به مقصدی جدا. همین دو خط، تفاوت یک حادثهٔ نیم‌ساعته با فاجعهٔ ازدست‌رفتن داده است.

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

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

قبل از سفارش، این موارد را با هر ارائه‌دهنده‌ای شفاف کنید:

• منابع تضمین‌شده است یا اشتراکی؟ (RAM/CPU تضمینی معیار مقایسهٔ واقعی است)
• نوع دیسک چیست؟ (NVMe/SSD تفاوت محسوس با HDD دارد)
• ترافیک ماهانه چقدر است و بعد از سقف چه اتفاقی می‌افتد؟
• سیستم‌عامل‌های قابل انتخاب و امکان نصب مجدد از پنل وجود دارد؟
• اسنپ‌شات/بکاپ چگونه است و دست خودتان است؟
• تحویل چقدر طول می‌کشد؟ (در برتینا: آنی پس از پرداخت)
• ارتقای منابع بدون جابه‌جایی ممکن است؟

این خطاها را هر هفته می‌بینیم: خرید سرور مجازی برای کاری که هاست اشتراکی انجام می‌داد (هزینه و مسئولیت اضافه)؛ انتخاب ویندوز بدون نیاز واقعی و ازدست‌دادن نیمی از RAM برای خود سیستم‌عامل؛ رهاکردن سرور بدون به‌روزرسانی تا اولین هک؛ نگه‌داشتن تنها نسخهٔ بکاپ روی خود سرور؛ و انتخاب موقعیت جغرافیایی بدون فکر به مخاطب.

خطای ششم هم رایج است: مقایسهٔ پلن‌ها فقط با قیمت، بدون توجه به تضمینی‌بودن منابع و نوع دیسک. دو پلن «۲ گیگ رم» می‌توانند تجربه‌ای کاملاً متفاوت بسازند؛ مشخصات کامل پلن‌های برتینا در جدول هر موقعیت شفاف آمده است تا مقایسه واقعی باشد.

دیسک: مهم‌ترین تفاوت نسل‌هاست. NVMe چند برابر سریع‌تر از SSD معمولی و ده‌ها برابر سریع‌تر از HDD پاسخ می‌دهد؛ برای دیتابیس و سایت‌های پرمراجعه، دیسک کند یعنی صف انتظار در هر کوئری. پلن‌های برتینا روی SSD/NVMe ارائه می‌شوند و حجم دیسک در جدول هر پلن شفاف است.

رم: کمبود RAM بدترین نوع کندی را می‌سازد — سیستم به swap می‌افتد و همه‌چیز به دیسک گره می‌خورد. قاعدهٔ عملی: مصرف پایدارتان باید زیر ۷۰٪ رم بماند تا اوج‌ها جا داشته باشند. پردازنده: تعداد هسته برای همزمانی است، نه سرعت تک‌درخواست؛ اپ‌های تک‌رشته‌ای از هستهٔ بیشتر سود نمی‌برند اما وب‌سرور پرترافیک چرا.

هر سه مجازی‌ساز کلاس Enterprise هستند و ایزولاسیون واقعی منابع می‌دهند؛ تفاوت اصلی از دید کاربر نهایی، اکوسیستم است: KVM متن‌باز و ستون فقرات ابرهای مدرن است، Hyper-V با ویندوز سرور یکپارچگی عالی دارد و ESXi استاندارد قدیمی محیط‌های سازمانی است. آنچه باید از آن پرهیز کنید مجازی‌سازی سطح کانتینر (مثل OpenVZ قدیمی) با منابع اشتراکی است — جایی که «رم تضمینی» واقعاً تضمینی نیست.

پلن‌های برتینا روی KVM/Hyper-V/ESXi ارائه می‌شوند؛ یعنی رم و پردازندهٔ اعلام‌شده به‌صورت سخت‌افزاری برای شما رزرو است و همسایهٔ پرمصرف نمی‌تواند سهم شما را بخورد.

اگر می‌خواهید چند سایت را مثل هاست اشتراکی ولی با منابع اختصاصی مدیریت کنید، نصب کنترل‌پنل منطقی است: cPanel کامل‌ترین اکوسیستم را دارد (لایسنس جداگانه)، DirectAdmin سبک‌تر و اقتصادی‌تر است و برای اغلب سناریوها کافی. هر دو مدیریت سایت/دیتابیس/ایمیل/SSL را یکپارچه می‌کنند.

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

سرور مجازی یعنی دسترسی کامل: در لینوکس کاربر root و در ویندوز Administrator — نصب هر نرم‌افزار، تغییر هر تنظیم و مدیریت فایروال داخلی در اختیار شماست. همین قدرت، مسئولیت هم می‌آورد: برای کارهای روزمره کاربر عادی بسازید و root را فقط برای مدیریت نگه دارید.

کنسول VNC/نمایشگر مجازی هم بیمهٔ شماست: اگر SSH/RDP را با تنظیم فایروال اشتباه قفل کردید، از طریق کنسول پنل — انگار پشت خود سرور نشسته‌اید — وارد می‌شوید و خطا را برمی‌گردانید. قبل از هر تغییر فایروال، مطمئن شوید مسیر کنسول را بلدید.

آپتایم زیرساخت برتینا ۹۹.۹٪ است و وضعیت سرویس‌ها به‌صورت عمومی قابل پایش است؛ اما آپتایم «سرویسِ شما» به پیکربندی خودتان هم وابسته است: سرویسی که بعد از ری‌استارت خودکار بالا نمی‌آید، با هر به‌روزرسانی هسته چند دقیقه پایین می‌ماند. سرویس‌هایتان را systemd/service تعریف کنید و ری‌استارت خودکار را تست کنید.

برای سرویس‌های حیاتی، مانیتورینگ بیرونی (پینگ/HTTP هر دقیقه) راه‌اندازی کنید تا پیش از مشتری از مشکل باخبر شوید — و اگر توقف برایتان هزینهٔ جدی دارد، معماری دو نوده که در بخش موقعیت‌ها آمد، پاسخ ساختاری است.

سرور مجازی یک جعبهٔ خالی قدرتمند است و همین باعث می‌شود اولین سؤال هر خریدار این باشد: «دقیقاً برای نیاز من مناسب است؟» تجربهٔ پشتیبانی برتینا نشان می‌دهد بیشتر سرورهای مجازی برای یکی از پنج سناریوی زیر خریداری می‌شوند و شناخت سناریوی خودتان، هم انتخاب پلن را ساده می‌کند و هم از هزینهٔ اضافه جلوگیری می‌کند.

هنگام تحویل سرور، سیستم‌عامل را شما انتخاب می‌کنید و این انتخاب مسیر مدیریت سرور را تعیین می‌کند. قاعدهٔ کلی ساده است: اگر نرم‌افزارتان به ویندوز وابسته نیست، لینوکس بگیرید — سبک‌تر است، منابع کمتری برای خود سیستم‌عامل مصرف می‌کند و اکوسیستم ابزارهای سروری روی آن غنی‌تر است.

در دنیای لینوکس، اوبونتو LTS انتخاب پیش‌فرض ماست برای کسانی که راهنمای فارسی و انگلیسی فراوان می‌خواهند؛ نسخه‌های LTS پنج سال به‌روزرسانی امنیتی دارند. دبیان برای کسانی که پایداری را به تازگی بسته‌ها ترجیح می‌دهند گزینهٔ محافظه‌کارانه‌تر است. اگر از دنیای CentOS می‌آیید، AlmaLinux و Rocky Linux جایگزین‌های امروزی همان مسیرند و با cPanel/DirectAdmin سازگاری کامل دارند.

ویندوز سرور را وقتی انتخاب کنید که واقعاً به آن نیاز دارید: اپلیکیشن ASP.NET قدیمی، SQL Server، نرم‌افزار حسابداری ویندوزی، یا نیاز به دسکتاپ گرافیکی از راه دور. حواستان به منابع باشد — خود ویندوز سرور به‌تنهایی حداقل ۲ گیگابایت رم مصرف می‌کند؛ برای کار جدی روی ویندوز از پلن‌های ۴ گیگ به بالا شروع کنید.

• اوبونتو LTS: پیش‌فرض امن برای اغلب کاربردها؛ بیشترین مستندات
• دبیان: پایداری حداکثری برای سرویس‌های حساس به تغییر
• AlmaLinux / Rocky: مسیر جایگزین CentOS؛ سازگار با پنل‌های هاستینگ
• ویندوز سرور: فقط برای وابستگی واقعی به اکوسیستم مایکروسافت؛ رم ۴ گیگ به بالا

پس از تحویل سرور، ایمیل حاوی IP، نام کاربری root و رمز اولیه را دریافت می‌کنید. اتصال از ویندوز با PowerShell یا PuTTY و از مک/لینوکس با ترمینال انجام می‌شود: دستور «ssh root@IP» و سپس رمز. بار اول اثر انگشت سرور را می‌پرسد — تأیید کنید تا در فهرست شناخته‌شده‌ها ذخیره شود.

اولین کار پس از ورود، تغییر رمز اولیه است و بلافاصله بعد از آن، ساخت کلید SSH. کلید عمومی/خصوصی هم امن‌تر از رمز است (حمله‌های حدس رمز را بی‌اثر می‌کند) و هم راحت‌تر — ورود بدون تایپ رمز. با «ssh-keygen» روی سیستم خودتان کلید بسازید و با «ssh-copy-id» کلید عمومی را به سرور منتقل کنید؛ بعد از اطمینان از ورود با کلید، ورودِ رمزی را در تنظیمات sshd غیرفعال کنید.

دو سفارش عملی از تجربهٔ پشتیبانی: اول، قبل از هر تغییر در تنظیمات SSH یک نشست دوم باز نگه دارید تا اگر تنظیم اشتباه بود، قفل نشوید؛ دوم، مسیر کنسول اضطراری پنل (VNC) را پیش از نیاز پیدا کنید — همان دری که وقتی فایروال یا sshd را اشتباه بستید، شما را به سرور برمی‌گرداند.

سرور ویندوزی با Remote Desktop مدیریت می‌شود: در ویندوزِ خودتان برنامهٔ «Remote Desktop Connection» را باز کنید، IP سرور را وارد کنید و با کاربر Administrator و رمز تحویلی وارد شوید. از مک، اپ رسمی Windows App (نام جدید Remote Desktop مایکروسافت) همین کار را می‌کند.

RDPِ باز روی اینترنت، هدف دائمی ربات‌های حدس رمز است؛ پس همان روز اول: رمز Administrator را به یک عبارت طولانی تغییر دهید، یک کاربر مدیریتی با نام غیرقابل حدس بسازید و در صورت امکان پورت RDP را از ۳۳۸۹ به عددی غیرمعمول ببرید یا دسترسی RDP را در فایروال ویندوز به IPهای ثابت خودتان محدود کنید. احراز سطح شبکه (NLA) را هم روشن نگه دارید — پیش‌فرض ویندوزهای جدید است و اتصال‌های بدون احراز را قبل از رسیدن به صفحهٔ ورود دفع می‌کند.

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

• ۱. تغییر رمزهای تحویلی (root/Administrator) به عبارت‌های طولانی و یکتا
• ۲. به‌روزرسانی کامل سیستم‌عامل (apt update && apt upgrade یا Windows Update)
• ۳. ساخت کاربر روزمره و کنار گذاشتن root/Administrator برای کارهای مدیریتی
• ۴. راه‌اندازی کلید SSH و غیرفعال‌کردن ورود رمزی (لینوکس)
• ۵. فعال‌کردن فایروال و بازکردن فقط پورت‌های لازم
• ۶. نصب fail2ban یا محدودسازی تلاش‌های ورود ناموفق
• ۷. تنظیم منطقهٔ زمانی و NTP — لاگ با ساعت غلط، عیب‌یابی را کور می‌کند
• ۸. فعال‌کردن به‌روزرسانی امنیتی خودکار
• ۹. گرفتن اولین اسنپ‌شات/بکاپ به‌عنوان نقطهٔ بازگشت تمیز
• ۱۰. یادداشت مسیر کنسول اضطراری (VNC) و تست ورود از آن

زیرساخت برتینا حفاظت شبکه و ایزولاسیون منابع را فراهم می‌کند، اما امنیتِ داخل سرور — سیستم‌عامل و نرم‌افزارهای شما — مسئولیت مدیر سرور است. خبر خوب این‌که چهار لایهٔ سادهٔ زیر، بخش بزرگی از حمله‌های خودکار را همان لبهٔ کار متوقف می‌کند.

لایهٔ اول فایروال است: ufw در اوبونتو/دبیان با سه دستور فعال می‌شود — پیش‌فرض ورودی را ببندید، پورت‌های سرویس‌هایتان (مثلاً ۸۰ و ۴۴۳ و پورت SSH) را باز کنید و بقیه را بسته بگذارید. هر پورتِ باز اضافه، یک دعوت‌نامه است. لایهٔ دوم سخت‌سازی ورود: کلید به‌جای رمز، پورت SSH غیرپیش‌فرض و fail2ban برای مسدودسازی IPهای مهاجم پس از چند تلاش ناموفق.

لایهٔ سوم به‌روزرسانی است — نه به‌عنوان کاری فصلی، بلکه به‌صورت خودکار برای وصله‌های امنیتی (unattended-upgrades در اوبونتو). اکثر نفوذهای واقعی از آسیب‌پذیری‌هایی رخ می‌دهد که ماه‌ها قبل وصله شده‌اند اما روی سرور قربانی نصب نشده‌اند. لایهٔ چهارم، حداقل‌سازی سطح حمله: سرویسی که استفاده نمی‌کنید را حذف یا متوقف کنید؛ دیتابیس را فقط روی localhost گوش‌به‌زنگ بگذارید مگر واقعاً دسترسی بیرونی لازم باشد.

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

قاعدهٔ کلاسیک ۳-۲-۱ همچنان بهترین راهنماست: سه نسخه از دادهٔ مهم، روی دو رسانهٔ متفاوت، که یکی خارج از سرور اصلی باشد. در عمل برای یک سرور وب این یعنی: دادهٔ زنده روی سرور + بکاپ شبانهٔ خودکار (فایل‌ها و دامپ دیتابیس) + انتقال همان بکاپ به مقصدی بیرونی (سرور دوم، فضای ابری یا حتی دانلود منظم). اسکریپت ساده با rsync و cron برای اغلب سناریوها کافی است.

و مهم‌ترین نکته‌ای که بیشترِ افراد تا روز حادثه نادیده می‌گیرند: بکاپی که هرگز بازیابی‌اش را تست نکرده‌اید، فقط یک امید است، نه بکاپ. هر چند ماه یک‌بار، بازیابی را واقعاً تمرین کنید — یک دیتابیس را از دامپ برگردانید و چند فایل را از آرشیو باز کنید.

سرور بی‌مانیتور مثل ماشین بدون آمپر است — تا وقتی خاموش نشده، «مشکلی ندارد». برای شروع، ابزارهای داخل سرور کافی‌اند: htop برای وضعیت لحظه‌ای CPU و رم، df -h برای دیسک، و iotop وقتی مشکوک به گلوگاه دیسک هستید. اگر داشبورد مرورگری می‌خواهید، Netdata با یک خط نصب می‌شود و همه‌چیز را با نمودار زنده نشان می‌دهد.

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

زمان ارتقا را داده تعیین می‌کند، نه حس: اگر مصرف رم به‌طور پایدار بالای ۸۰٪ است، اگر Load Average از تعداد هسته‌ها بیشتر مانده، یا اگر دیسک از ۸۵٪ گذشته — وقت ارتقاست. در برتینا ارتقای پلن بدون جابه‌جایی سرویس انجام می‌شود؛ منتظر نمانید که کندی، خودش را به کاربرها معرفی کند.

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

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

• پیش از خرید، از سرور موردنظر تا بروکر خود پینگ بگیرید (پشتیبانی برتینا IP تست می‌دهد)
• به‌روزرسانی خودکار ویندوز را به ساعات بسته‌بودن بازار منتقل کنید تا ری‌استارت وسط معامله رخ ندهد
• متاتریدر را در Startup ویندوز بگذارید تا پس از هر ری‌استارت، خودکار بالا بیاید
• برای چند حساب همزمان، مصرف رم هر ترمینال را جمع بزنید و ۳۰٪ حاشیه نگه دارید

این فهرست از الگوی واقعی تیکت‌های پشتیبانی جمع شده است؛ اگر فقط همین‌ها را رعایت کنید، تجربهٔ سال اول‌تان با VPS آرام خواهد بود:

• خرید بر اساس «بزرگ‌ترین عدد»: پلن ۱۶ گیگی برای رباتی که ۵۰۰ مگ مصرف می‌کند — اول مصرف واقعی را بسنجید، ارتقا همیشه ممکن است
• نادیده‌گرفتن موقعیت دیتاسنتر: مخاطب ایرانی → سرور ایران؛ وابستگی به سرویس‌های خارجی → آلمان/فرانسه
• رها کردن سرور بدون به‌روزرسانی: بیشترین نفوذها از آسیب‌پذیری‌های وصله‌شدهٔ قدیمی است
• همه‌چیز روی یک سرور بدون بکاپ بیرونی: یک اشتباه انسانی کافی است
• مدیریت سرور مهم با رمزِ کوتاه و پورت‌های پیش‌فرض: هدف اول ربات‌های اسکن
• انتخاب ویندوز «چون آشناتر است» برای کاری که روی لینوکس نصف منابع می‌خواهد
• تست‌نکردن مسیر کنسول اضطراری تا روزی که فایروال، خودتان را هم بیرون نگه می‌دارد

قبل از خرید، مطمئن شوید VPS واقعاً لایهٔ درست برای نیاز شماست. هر کدام از چهار گزینهٔ زیر جای درستی دارد و انتخاب اشتباه، یا هزینهٔ اضافه است یا محدودیت آزاردهنده.

به‌جای حدس، از الگوهای مصرف واقعی شروع کنید. اعداد زیر نقطهٔ شروع محافظه‌کارانه برای رایج‌ترین سناریوهاست — نه سقف؛ اگر تردید دارید یک پله پایین‌تر بگیرید و با دادهٔ مانیتورینگ ارتقا دهید:

• ربات تلگرام / اسکریپت سبک: ۱ هسته، ۱–۲ گیگ رم، ۲۰ گیگ دیسک
• سایت وردپرسی متوسط یا چند سایت کوچک: ۲ هسته، ۲–۴ گیگ رم، NVMe
• فروشگاه ووکامرس فعال: ۴ هسته، ۴–۸ گیگ رم؛ دیتابیس و وب روی NVMe
• بک‌اند اپ موبایل با چند ده هزار کاربر: ۴ هسته، ۸ گیگ، دیتابیس جدا در پلن دوم
• محیط CI/بیلد: هسته بیشتر مهم‌تر از رم؛ ۴–۸ هسته
• متاتریدر (۱–۲ حساب): ویندوز، ۲ هسته، ۲–۴ گیگ رم

برای سرور تازه، Nginx پیش‌فرض معقول امروزی است: مصرف حافظهٔ پایین، عملکرد عالی در اتصال‌های همزمان و پیکربندی تمیز برای پراکسی‌کردن اپلیکیشن‌ها (Node.js، Python، PHP-FPM). Apache هنوز دو جای قوت دارد: فایل‌های htaccess. که برخی اپلیکیشن‌های قدیمی به آن وابسته‌اند، و اکوسیستم ماژول‌های تاریخی‌اش. اگر مهاجرت از هاست اشتراکی cPanel می‌کنید و htaccess.های پیچیده دارید، Apache (یا LiteSpeed) مسیر کم‌دردسرتر است؛ برای پروژهٔ جدید، Nginx.

هرکدام را انتخاب کردید، دو اصل ثابت است: گواهی SSL را همان ابتدا نصب و تمدید خودکارش را فعال کنید، و نسخهٔ HTTP/2 را روشن کنید — هر دو در چند دقیقه انجام می‌شود و مستقیم روی سرعت و سئوی سایت اثر دارد.

اگر بیش از یک سرویس روی سرور اجرا می‌کنید، Docker نظم را برمی‌گرداند: هر سرویس در کانتینر خودش با وابستگی‌های خودش، بدون تداخل نسخه‌ها، و با قابلیت جابه‌جایی بین سرورها با یک فایل compose. برای تیم‌ها، همین فایل compose یعنی «مستندسازی اجرایی» — سرور جدید در چند دقیقه همان استک قبلی را بالا می‌آورد.

نکات عملی روی VPS: کانتینرها را با کاربر غیر root اجرا کنید، پورت‌ها را فقط روی localhost منتشر کنید و Nginx را جلوی همه به‌عنوان لبهٔ ورودی بگذارید، و برای دادهٔ ماندگار حتماً volume تعریف کنید تا با حذف کانتینر، داده نپرد. مصرف اضافهٔ خود Docker ناچیز است؛ روی پلن‌های ۲ گیگ به بالا راحت جا می‌شود.

سرور آماده است؛ حالا باید دامنه به آن برسد. در پنل مدیریت دامنه، یک رکورد A برای ریشهٔ دامنه و یکی برای www به IP سرور بسازید. TTL را هنگام جابه‌جایی موقتاً کوتاه کنید (مثلاً ۵ دقیقه) تا تغییرها سریع منتشر شود و بعد از تثبیت به مقدار معمول برگردانید.

اگر ایمیل روی همان دامنه دارید، پیش از تغییر NS یا رکوردها فهرست کامل رکوردهای فعلی (MX، TXT/SPF، DKIM) را ذخیره کنید و عیناً منتقل کنید — رایج‌ترین حادثهٔ مهاجرت، قطع ایمیل به‌خاطر جاماندن MX است. برای دامنه‌هایی که در برتینا ثبت شده‌اند، مدیریت DNS در همان پنل در دسترس است و پشتیبانی در انتقال رکوردها همراهی می‌کند.

هر سرور مجازی برتینا با IPv4 اختصاصی تحویل می‌شود — یعنی اعتبار آدرس شما به رفتار همسایه‌ها گره نخورده است؛ برای سرویس‌هایی مثل ارسال ایمیل یا API عمومی، این تفاوت مهمی با محیط‌های اشتراکی است. IP اضافه در صورت نیاز (مثلاً SSL قدیمی یا جداسازی سرویس‌ها) قابل سفارش است.

دو عادت شبکه‌ای خوب: اول، رکورد PTR (reverse DNS) را اگر از سرور ایمیل می‌فرستید حتماً با پشتیبانی تنظیم کنید — بدون آن، بخشی از ایمیل‌ها به اسپم می‌رود. دوم، در فایروال به‌جای بستن همه‌چیز پس از حادثه، از ابتدا فهرست سفید بسازید: فقط پورت‌هایی که سرویس واقعی دارند باز باشند و پنل‌های مدیریتی در صورت امکان به IP ثابت شما محدود شوند.

برای کسانی که اولین سرورشان را می‌گیرند، ترسناک‌ترین لحظه همان صفحهٔ سیاه ترمینال است. مسیر استاندارد بالا آوردن یک سایت PHP (مثل وردپرس) روی اوبونتو این است: نصب Nginx، نصب MySQL یا MariaDB و اجرای اسکریپت امن‌سازی اولیه‌اش، نصب PHP-FPM با افزونه‌های رایج، ساخت فایل کانفیگ سایت در Nginx و در نهایت گرفتن گواهی SSL. هر مرحله یکی دو دستور بیشتر نیست و مستندات رسمی هر سه پروژه، به‌روز و دقیق است.

دو انتخاب می‌تواند این مسیر را باز هم کوتاه کند: نصب یک کنترل‌پنل (که بخش قبل مقایسه کردیم) تا همهٔ این اجزا را یک‌جا مدیریت کند، یا استفاده از Docker Compose که کل استک را در یک فایل تعریف می‌کند. اگر هدفتان فقط «یک سایت وردپرسی سریع» است و نمی‌خواهید درگیر مدیریت سرور شوید، صادقانه بگوییم: هاست وردپرس مدیریت‌شده احتمالاً انتخاب درست‌تری از VPS است — سرور مجازی را وقتی بگیرید که به آزادی‌اش نیاز دارید.

خبر خوب برای کسب‌وکارهای در حال رشد این است که مسیر ارتقا پله‌پله و بدون پرش‌های پرریسک است. پلهٔ اول، ارتقای عمودی است: رم و هستهٔ بیشتر روی همان سرور، بدون جابه‌جایی داده. تا وقتی مانیتورینگ می‌گوید گلوگاه «منابع» است نه «معماری»، همین کافی است.

پلهٔ دوم، جداسازی نقش‌هاست: دیتابیس به سرور دوم منتقل می‌شود تا وب و دیتابیس سر منابع رقابت نکنند — رایج‌ترین اولین معماری دوسروره. پلهٔ سوم برای سرویس‌های حیاتی، افزونگی است: دو سرور در دو موقعیت (مثلاً ایران و آلمان) که یکی نقش یدکی گرم را دارد؛ همان الگویی که در بخش موقعیت‌ها شرح دادیم. و وقتی مصرف از بزرگ‌ترین پلن‌ها عبور کرد، سرور اختصاصی ادامهٔ طبیعی مسیر است. در هر پله، تیم برتینا در طراحی و مهاجرت همراه است — از انتقال دیتابیس تا تنظیم DNS با کمترین وقفه.

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

• مجازی‌ساز (Hypervisor): نرم‌افزاری که سرور فیزیکی را به چند سرور مجازیِ ایزوله تقسیم می‌کند — KVM، Hyper-V و ESXi از این خانواده‌اند
• رم تضمینی: حافظه‌ای که به‌صورت سخت‌افزاری برای شما رزرو است و همسایه‌ها نمی‌توانند مصرفش کنند
• NVMe: نسل سریع دیسک‌های SSD با اتصال مستقیم به PCIe؛ محسوس‌ترین جهش سرعت برای دیتابیس
• پهنای باند: حجم دادهٔ قابل جابه‌جایی در ماه؛ «نامحدود منصفانه» یعنی بدون سقف عددی با رعایت استفادهٔ معقول
• آپتایم: درصد زمان در دسترس بودن زیرساخت — ۹۹.۹٪ یعنی حداکثر حدود ۴۳ دقیقه در ماه
• اسنپ‌شات: عکس فوری از کل دیسک برای بازگشت سریع؛ جایگزین بکاپ بیرونی نیست
• کنسول VNC: دسترسی اضطراری به سرور از طریق پنل، حتی وقتی SSH/RDP قطع است
• PTR / Reverse DNS: رکوردی که IP را به نام دامنه برمی‌گرداند؛ برای اعتبار ارسال ایمیل ضروری
• IOPS: تعداد عملیات ورودی/خروجی دیسک در ثانیه؛ معیار واقعی توان دیسک زیر بار
• Load Average: میانگین صف پردازش؛ اگر پایدار از تعداد هسته‌ها بیشتر باشد، CPU گلوگاه است
• Swap: فضای کمکی روی دیسک برای عبور از اوج‌های مصرف رم؛ کندتر از حافظهٔ واقعی اما نجات‌بخش در لحظه‌های فشار
• فایروال: صافی ترافیک ورودی و خروجی سرور؛ هر پورتِ باز باید دلیل روشنی داشته باشد
• ریسورس پول تضمینی: مجموع منابعی که مجازی‌ساز برای ماشین شما کنار گذاشته و به فروش دوباره نمی‌رسد
• دیتاسنتر: ساختمان میزبان سرورها با برق، خنک‌سازی و شبکهٔ افزونه؛ موقعیتش همان چیزی است که پینگ شما را می‌سازد

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

«VPS فقط برای متخصص‌هاست» — مدیریت پایهٔ یک سرور (همان چک‌لیست ده‌گانهٔ بالا) در چند عصر قابل یادگیری است و مستندات فارسی فراوان دارد؛ ضمن این‌که با نصب کنترل‌پنل، تجربهٔ کار عملاً شبیه هاست می‌شود.

«هرچه رم بیشتر، سایت سریع‌تر» — رمِ خالی سرعت نمی‌سازد؛ اگر گلوگاه دیسک یا کوئری‌های بهینه‌نشده باشد، دوبرابرکردن رم فقط هزینه را دوبرابر می‌کند. اول اندازه بگیرید، بعد ارتقا دهید.

«سرور خارج همیشه بهتر است» — برای مخاطب ایرانی دقیقاً برعکس است: مسیر شبکهٔ داخلی کوتاه‌تر، پینگ پایین‌تر و ترافیک داخلی نیم‌بها. «بهتر» را مخاطب‌تان تعیین می‌کند، نه جغرافیای برند.

یکی از پرتکرارترین غافلگیری‌های صاحبان سرور: اسکریپت سایت ایمیل می‌فرستد اما هیچ‌کس دریافت نمی‌کند. دلیلش این است که پذیرش ایمیل در دنیا بر پایهٔ اعتبار فرستنده کار می‌کند و یک IP تازه بدون سابقه، بدون PTR و بدون رکوردهای SPF/DKIM/DMARC، از نگاه سرویس‌های بزرگ ایمیل، ناشناس و مشکوک است.

اگر ایمیل برای شما حیاتی است (فاکتور، بازیابی رمز، اطلاع‌رسانی به مشتری)، دو راه درست دارید: یا ارسال را به سرویس ایمیل سازمانی بسپارید و اپلیکیشن را از طریق SMTP همان سرویس متصل کنید — مسیر پیشنهادی ما که تحویل‌پذیری تضمین‌شده‌تری دارد — یا اگر اصرار به ارسال از خود سرور دارید، حداقل‌ها را کامل کنید: PTR با هماهنگی پشتیبانی، SPF و DKIM و DMARC در DNS، و شروع با حجم کم برای ساخت تدریجی اعتبار IP. ترکیب «سایت روی VPS + ایمیل روی سرویس ایمیل برتینا» معماری رایج و کم‌دردسر مشتریان ماست.

قیمت پلن‌ها تابع چهار مؤلفهٔ اصلی است: رم و هسته (سهم اصلی)، نوع و حجم دیسک (NVMe گران‌تر از SSD معمولی اما با جهش عملکردی واقعی)، موقعیت دیتاسنتر (هزینهٔ زیرساخت ایران و اروپا متفاوت است) و دورهٔ پرداخت — پرداخت سالانه در برتینا با تخفیف نسبت به ماهانه همراه است و برای سرویس‌های پایدار، انتخاب اقتصادی‌تری است.

برای بودجه‌بندی واقع‌بینانه، فقط قیمت پلن را نبینید: اگر ویندوز می‌گیرید هزینهٔ سنگین‌تر منابع را لحاظ کنید، اگر cPanel می‌خواهید لایسنس آن جداست، و اگر سرویس حیاتی دارید، هزینهٔ سرور دوم برای بکاپ/افزونگی را از ابتدا در محاسبه بیاورید. در مقابل، هزینه‌هایی که در قیمت پنهان نیستند: ترافیک نامحدود منصفانه، IP اختصاصی، و پشتیبانی ۲۴/۷ — این‌ها در برتینا داخل پلن است، نه آیتم فاکتور.

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

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

سرور تازه با تنظیمات پیش‌فرض محافظه‌کارانه تحویل می‌شود؛ چند تنظیم کوچک، بازده همان منابع را محسوس بالا می‌برد. اول swap: روی سرورهای کم‌رم (۱ تا ۲ گیگ) یک فایل swap متوسط بسازید تا اوج‌های لحظه‌ای مصرف، به‌جای کشتن پردازه‌ها، با کمی کندی عبور کنند — و swappiness را پایین نگه دارید تا سیستم فقط در ضرورت سراغش برود.

دوم، لایهٔ اجرا: اگر PHP دارید، فعال‌بودن OPcache را بررسی کنید (کد را یک‌بار کامپایل می‌کند و در حافظه نگه می‌دارد)؛ برای Node.js از حالت کلاستر یا PM2 استفاده کنید تا همهٔ هسته‌ها کار کنند؛ و برای دیتابیس، بافر اصلی (مثل innodb_buffer_pool_size در MySQL) را متناسب با رمِ آزاد بالا ببرید — پیش‌فرضش برای سرورهای واقعی خیلی کوچک است.

سوم، لاگ‌ها: چرخش لاگ (logrotate) را برای اپلیکیشن‌هایتان تنظیم کنید تا فایل‌های لاگ، بی‌سروصدا دیسک را نبلعند — پرشدن دیسک از لاگ، یکی از کلاسیک‌ترین علت‌های ازکارافتادن ناگهانی سرویس‌هاست. همین سه دسته تنظیم، با نیم ساعت وقت، از خیلی از تیکت‌های «سرور کند شده» پیشگیری می‌کند.

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

داخل سیستم‌عامل قلمرو شماست: نصب و پیکربندی نرم‌افزارها، امنیت سرویس‌ها، بکاپ داده‌ها و عملکرد اپلیکیشن. با این حال «قلمرو شما» به معنی تنها ماندن نیست — پشتیبانی در نصب سیستم‌عامل مجدد، مشاورهٔ انتخاب پلن و مسیر ارتقا، تنظیم PTR و مسائل شبکه همراهی می‌کند و برای مدیریت کامل، سرویس مدیریت سرور به‌صورت جداگانه قابل سفارش است. پیش از خرید اگر تردید فنی دارید، مشاورهٔ رایگان همین گفت‌وگو را قبل از هزینه‌کردن انجام می‌دهد.