سرور ابری ساعتی چیست؟ راهنمای کامل برای کاهش هزینه‌ی سرور

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

سرور ابری ساعتی چیست و چه فرقی با اجاره‌ی ماهانه دارد؟

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

پیامد اصلی مالی نیست، رفتاری است: در مدل ماهانه هر تصمیم اشتباه دست‌کم یک ماه هزینه دارد، در مدل ساعتی یک ساعت. این ابزار مدیریت عدم قطعیت است.

دقت کنید که «ساعتی» ویژگی صورتحساب است، نه نوع سخت‌افزار: همان ماشین KVM با دیسک NVMe و دسترسی کامل root.

مدل ساعتی دقیقاً چطور محاسبه می‌شود؟

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

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

«خاموش» با «حذف» یکی نیست

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

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

چه چیزی یک سرور را «ابری» می‌کند؟

واژه‌ی «ابری» در تبلیغات آن‌قدر تکرار شده که تقریباً بی‌معنا شده، اما تعریف فنی روشنی دارد: سند NIST SP 800-145 پنج ویژگی ذاتی برای رایانش ابری برمی‌شمارد که سه‌تای آن‌ها مدل ساعتی را ممکن می‌کند:

• خودسرویسِ درخواستی — سرور را بدون تیکت خودتان می‌سازید؛ اگر ساخت به تأیید انسانی نیاز داشته باشد، صورتحساب ساعتی بی‌فایده است.
• کشسانی سریع — منابع باید در مقیاس دقیقه تغییر کنند، نه روز.
• سرویس اندازه‌گیری‌شده — اگر ریز مصرف را نبینید، راهی برای راستی‌آزمایی صورتحساب نیست.

دو ویژگی دیگر — دسترسی گسترده‌ی شبکه‌ای و اشتراک منابع — زیرساخت را توصیف می‌کنند: ماشین شما روی میزبانی اجرا می‌شود که منابعش میان چند مستأجر تقسیم شده و لایه‌ی تقسیم هایپروایزر است. در سرورهای ابری ایران این KVM است؛ چرایی اهمیتش در توضیح ساده‌ی KVM و NVMe آمده. نوع مجازی‌سازی را از داخل ماشین می‌بینید:

systemd-detect-virt
kvm

lscpu | grep -i 'model name\|^CPU(s):'
CPU(s):                               2
  Model name:                         AMD EPYC Processor

چرخه‌ی عمر یک سرور ساعتی: از ساخت تا حذف

۱) ساخت: سه انتخاب که دوتایشان بعداً سخت عوض می‌شود

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

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

۲) تحویل و اولین ورود: چیزی که تحویل گرفته‌اید را راستی‌آزمایی کنید

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

ssh root@203.0.113.24
The authenticity of host '203.0.113.24 (203.0.113.24)' can't be established.
ED25519 key fingerprint is SHA256:8Xq2p1s0hVwK7mYtRz9c4LbNfQeJdA6uG3xT5oPiWkE.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '203.0.113.24' (ED25519) to the list of known hosts.
root@203.0.113.24's password:

root@web-01:~# nproc
2
root@web-01:~# free -m
               total        used        free      shared  buff/cache   available
Mem:            3936         210        3402           1         323        3512
Swap:              0           0           0
root@web-01:~# lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME     SIZE TYPE MOUNTPOINT
vda       40G disk
└─vda1  39.9G part /

بار اول اثر انگشت کلید میزبان پرسیده می‌شود؛ پیش از تایپ yes آن را با اثر انگشتِ کنسول گرافیکی پنل مقایسه کنید — تنها لحظه‌ی راستی‌آزمایی هویت سرور. اگر بنر اثر انگشت بالا رفته باشد، در کنسول وارد شوید و ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub را بزنید تا دوباره چاپش کند.

عدد 3936 در free -m همان چهار گیگابایت (۴۰۹۶ مگابایت) است؛ آن ۱۶۰ مگابایت را کرنل پیش از شمردن حافظه کنار گذاشته: بخش‌های آزادنشدنیِ ایمیج کرنل، چند مگابایت نواحی رزروشده‌ی فریم‌ویر، و ساختارهای مدیریت حافظه (۶۴ بایت برای هر صفحه‌ی چهار کیلوبایتی، یعنی ۱٫۶ درصد کل رم). هیچ‌کدام در MemTotal ثبت نمی‌شوند، پس این کسری طبیعی است. رم‌دیسک اولیه در این فهرست نیست؛ بعد از بوت آزاد و به MemTotal برمی‌گردد.

فضای دیسک هم اگر کمتر از انتظار بود، عجله نکنید: df و lsblk هر دو بر مبنای ۱۰۲۴ می‌شمارند (با واحد فروشِ گیگابایت ده‌دهی، ۴۰ گیگابایت در هر دو حدود 37.3G دیده می‌شود)، بخشی صرف متادیتای فایل‌سیستم می‌شود و ext4 پیش‌فرض ۵ درصد را برای کاربر ریشه رزرو می‌کند. فقط وقتی نگران شوید که Size با اندازه‌ی پارتیشن در lsblk نخواند — راه‌حلش در بخش بعدی است. مراحل ورود از ویندوز، لینوکس و موبایل در آموزش اتصال SSH به سرور آمده است.

۳) تغییر منابع در میانه‌ی راه

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

بعد از بالا آمدن، اثر تغییر را ببینید:

df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        39G  6.2G   31G  17% /

# after the resize + one restart from the panel
df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        59G  6.2G   50G  11% /

اگر df هنوز اندازه‌ی قدیمی را نشان می‌دهد باید دستی جلو بروید — به نام بسته دقت کنید، چون در خانواده‌ی RHEL هم نام بسته و هم دستور بزرگ‌کردن فایل‌سیستم فرق می‌کند:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT
NAME     SIZE TYPE MOUNTPOINT
vda       60G disk            # the disk is already 60G
└─vda1  39.9G part /          # but the partition is still 40G

growpart /dev/vda 1  # pkg: cloud-guest-utils (Debian/Ubuntu),
                     #      cloud-utils-growpart (AlmaLinux/Rocky/CentOS)
resize2fs /dev/vda1         # ext4 / ext3
# on XFS (the RHEL-family default) use this instead:
xfs_growfs /

۴) پایان کار: اول خروجی، بعد حذف

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

# 1) on the server - pack the things that are not reproducible
set -o pipefail                 # bash only - not POSIX sh
D=$(date +%F)
tar -czf /root/www-$D.tar.gz /var/www /etc/nginx
tar: Removing leading `/' from member names          # normal, not an error
mysqldump --single-transaction --routines --events --databases db1 db2 \
  | gzip > /root/db-$D.sql.gz || echo "DUMP FAILED - do not delete anything"
ls -lh /root/*.gz
-rw-r--r-- 1 root root  38M Sep  7 03:11 /root/db-2026-09-07.sql.gz
-rw-r--r-- 1 root root 214M Sep  7 03:11 /root/www-2026-09-07.tar.gz

# 2) from YOUR machine - pull them off the box
scp root@203.0.113.24:/root/*.gz ./

# 3) verify before you destroy anything - BOTH files
ls *.gz
db-2026-09-07.sql.gz  www-2026-09-07.tar.gz
tar -tzf www-2026-09-07.tar.gz > /dev/null && echo "archive OK"
archive OK
zcat db-2026-09-07.sql.gz | tail -1
-- Dump completed on 2026-09-07  3:11:44

مرحله‌ی سوم مهم‌ترین بخش است: بکاپی که تستش نکرده‌اید بکاپ نیست — و «تست» یعنی هر دو فایل. تست فشرده‌سازی سالم‌بودنِ بسته را می‌سنجد نه محتوا را: اگر دامپ اجرا نشده باشد، فایلی بیست‌بایتی و ظاهراً سالم می‌سازد که آن تست را پاس می‌کند. پس آخرین خط دامپ را ببینید؛ در دامپ کامل همیشه -- Dump completed on … است. تاریخ نام فایل هم تاریخ سرور است نه ماشین شما (سرور معمولاً روی UTC)، پس همان نامی را بزنید که دانلود کرده‌اید.

تله‌ی خاموش دیگر در خودِ دامپ است: --single-transaction فقط برای جدول‌های InnoDB عکس لحظه‌ای سازگار می‌دهد و MyISAM بیرون از تراکنش خوانده می‌شود. موتورها را با SELECT table_name, engine FROM information_schema.tables WHERE table_schema='db1'; ببینید؛ اگر MyISAM بود، موتور را به InnoDB ببرید یا دامپ را روی سرویس متوقف‌شده بگیرید.

دو ریزه‌کاری هم این بلوک را از کار می‌اندازند. گزینه‌ی set -o pipefail در dash — همان /bin/sh دبیان و اوبونتو — تا پیش از نسخه‌ی 0.5.12-7 وجود نداشت: روی اوبونتو ۲۴٫۰۴ و قدیمی‌تر با Illegal option -o pipefail شکست می‌خورد و چون set بیلت‌این ویژه است اسکریپت همان‌جا می‌ایستد و دامپ اصلاً اجرا نمی‌شود (در دبیان ۱۳ و اوبونتو ۲۶٫۰۴ به dash اضافه شده). پس خط اول را #!/bin/bash بنویسید و با bash script.sh اجرا کنید، نه sh script.sh که آن خط اول را نادیده می‌گیرد. و چون tar اسلش ابتدای مسیرها را حذف می‌کند (هشدار است، نه خطا)، هنگام بازگردانی tar -xzf … -C / بزنید.

اسکریپت کامل و روش بازگردانی در راهنمای بکاپ‌گیری از سرور لینوکس است. حذف نهایی عمداً سخت شده: باید هاست‌نیم سرور را دستی تایپ کنید.

وضعیت‌های یک ماشین ساعتی و پیامد هرکدام

روشن‌نبودن مرز این وضعیت‌ها هم پول می‌برد هم داده:

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

برای چه پروژه‌هایی می‌صرفد؟

۱) محیط تست و توسعه

محیط تست را صبح می‌سازید و آخر وقت حذف می‌کنید؛ فردا از فایل Compose در یک دقیقه بالا می‌آید. شرطش خودکاربودن ساخت محیط است — راه‌اندازی داکر روی سرور ابری نقطه‌ی شروع خوبی است.

۲) پروژه‌های کوتاه‌مدت

کمپین، وبینار یا رندر سنگین — هر کاری که «تاریخ پایان» دارد فقط بهای همان بازه را می‌پردازد؛ صرفه‌جویی به نسبت بخشی از ماه است که سرور وجود ندارد: برای یک هفته چشمگیر، برای پروژه‌ای تا آخر ماه ناچیز.

۳) بارهای متغیر

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

۴) یادگیری و آزمایش

با هزینه‌ی چند ساعت سرور واقعی برای تمرین دارید؛ ماشینی که دستور اشتباه نابودش کرده، یک بازسازی چنددقیقه‌ای فاصله دارد.

کجا مدل ساعتی انتخاب اشتباهی است؟

مدل ساعتی همیشه بهتر نیست:

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

مقایسه‌ی سریع: ماهانه یا ساعتی؟

پنج عادت که هزینه را جدی کم می‌کند

1. سرورهای بیکار را حذف کنید، نه فقط خاموش. دیسک و آی‌پیِ رزروشده هم منبع‌اند؛ اگر چند روز نیازی نیست، خروجی بگیرید و حذف کنید.
2. اندازه‌ی درست را انتخاب کنید. با htop و free -m مصرف واقعی را ببینید — ملاک ستون available است نه used؛ لینوکس رم بلااستفاده را صرف کش دیسک می‌کند و بالا بودن buff/cache کمبود حافظه نیست. اگر available در اوج هم بالای نصف رم ماند، یک پله کوچک‌تر بسازید (روش اندازه‌گیری در راهنمای مانیتورینگ سرور لینوکس).
3. ترافیک را هوشمندانه مصرف کنید. فشرده‌سازی gzip — در انجین‌ایکس آماده است و فقط باید روشنش کنید — و بهینه‌کردن تصاویر، هم سایت را سریع‌تر می‌کند هم گیگابایت‌های صورتحساب را کم (brotli بهتر فشرده می‌کند اما ماژول ngx_brotli می‌خواهد). اگر DNS دامنه‌تان در مهران هاست است، شبکه توزیع محتوا را با یک کلید کنار همان رکورد A روشن کنید.
4. مانیتور کنید. نمودار مصرف و دفتر تراکنش‌ها را هفته‌ای یک‌بار ببینید؛ غافلگیری مالی وقتی می‌آید که هیچ‌وقت نگاه نکنید.
5. کارهای زمان‌بندی‌شده را جمع کنید. چند اسکریپت شبانه را روی یک سرور کوچک متمرکز کنید؛ چند ماشین نیمه‌بیکار گران‌تر تمام می‌شود، چون هرکدام سهم رم و دیسکِ بلااستفاده را جدا حساب می‌کند.

امنیت سروری که هر روز ساخته و حذف می‌شود

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

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

سرور ابری ساعتی در مهران هاست چطور کار می‌کند؟

سرورهای ایران ماشین KVM با دیسک NVMe در دیتاسنتر داخل کشورند و تحویل کاملاً خودکار است — بدون تیکت و انتظار برای روز کاری. دسترسی کامل root دارید و مدیریت از پنل فارسی انجام می‌شود: روشن و خاموش، ری‌استارت، افزایش منابع، نصب مجدد و حذف.

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

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

جمع‌بندی

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

سؤالات پرتکرار

سرور ابری ساعتی چیست و چه تفاوتی با سرور مجازی معمولی دارد؟

سرور ابری ساعتی یک ماشین مجازی است که واحد صورتحسابش ساعت است، نه ماه: از لحظه‌ی ساخت تا لحظه‌ی حذف، بهای هر ساعت از کیف پول کسر می‌شود. از نظر سخت‌افزار و دسترسی تفاوتی با سرور مجازی معمولی ندارد — همان ماشین KVM با دسترسی کامل root — اما چون خودتان هر لحظه آن را می‌سازید، تغییر می‌دهید یا حذف می‌کنید، هزینه‌ی یک تصمیم اشتباه به‌جای یک ماه، یک ساعت است.

اگر سرور را خاموش کنم، هزینه‌اش صفر می‌شود؟

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

بعد از حذف سرور، اطلاعاتم برمی‌گردد؟

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

آیا می‌توانم منابع سرور ساعتی را کم کنم؟

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

برای یک سایت وردپرسی که همیشه روشن است، مدل ساعتی به‌صرفه است؟

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