Amir Jabbari
Satisfactory Dedicated Server برای زمانی است که می‌خواهید کارخانه همیشه روشن بماند و پیشرفت World به کامپیوتر یکی از بازیکن‌ها وابسته نباشد. سرور رسمی روی Linux و Windows اجرا می‌شود و از طریق SteamCMD قابل نصب است. در کارخانه‌های بزرگ، مشکل اصلی معمولاً فقط RAM نیست؛ Satisfactory به عملکرد تک‌هسته‌ای CPU حساس است و هرچه Save بزرگ‌تر و تعداد Conveyor، Pipeline، Train و ساختمان بیشتر شود، Tick Rate و زمان Autosave اهمیت بیشتری پیدا می‌کنند.
در زمان بازبینی این مقاله در ۲۰ اکتبر ۲۰۲۶، نسخه Stable بازی 1.2.4.1 است و شاخه Public سرور اختصاصی نیز در اکتبر Build جدید دریافت کرده است. Dedicated Server با App ID رسمی 1690800 منتشر می‌شود و نسخه 64 بیتی Windows و Linux دارد.
در این راهنما سرور را با SteamCMD نصب می‌کنیم، پورت‌های جدید 1.1 یعنی 7777 TCP/UDP و 8888 TCP را درست باز می‌کنیم، Server Manager را راه می‌اندازیم، Save و Backup را می‌شناسیم و بعد سراغ دو دردسر اصلی می‌رویم: Lag کارخانه‌های بزرگ و Freeze هنگام Autosave. هدف این است که به‌جای دستکاری تصادفی تنظیمات، بفهمیم Bottleneck از CPU، Save Size، Disk I/O یا Network است.
نکته مهم برای آموزش‌های قدیمی: از Patch 1.1 به بعد، فقط بازبودن 7777 کافی نیست. سرور به‌طور پیش‌فرض از 7777 TCP/UDP و 8888 TCP برای Reliable Messaging استفاده می‌کند. پورت‌های قدیمی 15000 و 15777 از 1.0 دیگر استفاده نمی‌شوند.
Satisfactory Dedicated Server در ۲۰۲۶ چه وضعیتی دارد؟
نسخه Stable فعلی 1.2.4.1 در ۱۲ اکتبر ۲۰۲۶ منتشر شده است. SteamDB نیز برای Dedicated Server، App ID 1690800 و Build Public جدید اکتبر ۲۰۲۶ را نشان می‌دهد. بنابراین اگر سرور قدیمی دارید و با Crash، Join مشکل‌دار یا Lag غیرعادی روبه‌رو هستید، قبل از هر Tuning ابتدا Client و Server را روی Build سازگار قرار دهید.
برای نصب با SteamCMD:
+login anonymous
+app_update 1690800 validate
+quitبرای سرور Satisfactory چه CPU و RAM لازم است؟
راهنمای رسمی Wiki حداقل‌های Community را این‌طور جمع‌بندی می‌کند: CPU x86-64، حداقل حدود 8GB RAM و برای Saveهای بزرگ یا بیش از چهار بازیکن 16GB RAM انتخاب منطقی‌تری است. مهم‌تر از تعداد Core این است که Server اگرچه چند Thread استفاده می‌کند، هنوز عملکرد تک‌هسته‌ای قوی را ترجیح می‌دهد.
| سناریو | شروع مناسب | نکته اصلی |
|---|---|---|
| World تازه، ۲ تا ۴ نفر | ۸GB RAM | CPU جدید با Single-core مناسب |
| Factory متوسط، ۴ تا ۸ نفر | ۱۶GB RAM | SSD/NVMe و CPU غیر Oversold |
| Factory بسیار بزرگ | ۱۶GB یا بیشتر بر اساس اندازه Save | CPU و Save Time از RAM مهم‌تر می‌شوند |
در VPS فقط به عبارت «۸ vCPU» نگاه نکنید. اگر Host شلوغ باشد، vCPU زیاد با Clock پایین یا Steal Time بالا می‌تواند از ۴ Core سریع بدتر عمل کند.
اگر سرور روی Proxmox یا VM شخصی اجرا می‌شود، Wiki رسمی هشدار می‌دهد CPU Type عمومی kvm64 با Binary سرور سازگار نیست و ممکن است هنگام ساخت Game Crash کند؛ در چنین محیطی CPU Model مناسب مثل host لازم است.
مطلب مرتبط: اگر VPS از نظر RAM آزاد است ولی بازی همچنان لگ دارد، Bottleneck را بین CPU، Disk و Network تفکیک کنید.
نصب Satisfactory Dedicated Server روی Linux با SteamCMD
روی Ubuntu/Debian یک User جدا برای Game Server بسازید:
sudo apt update
sudo apt install -y steamcmd
sudo useradd --system --create-home \
--home-dir /home/satisfactory \
--shell /bin/bash satisfactory
sudo mkdir -p /home/satisfactory/server
sudo chown -R satisfactory:satisfactory /home/satisfactoryنصب:
sudo -u satisfactory /usr/games/steamcmd \
+force_install_dir /home/satisfactory/server \
+login anonymous \
+app_update 1690800 validate \
+quitاجرا:
cd /home/satisfactory/server
sudo -u satisfactory ./FactoryServer.shفایل رسمی Linux همان FactoryServer.sh است. روی Windows فایل اجرایی اصلی FactoryServer.exe است.
نصب روی Windows Server
SteamCMD را در یک پوشه جدا قرار دهید:
C:\\SteamCMD\\steamcmd.exe ^
+force_install_dir C:\\SatisfactoryServer ^
+login anonymous ^
+app_update 1690800 validate ^
+quitاجرا:
C:\\SatisfactoryServer\\FactoryServer.exe -log -unattendedپورت‌های Satisfactory در نسخه 1.2
از Patch 1.1 ساختار شبکه سرور تغییر کرده است:
| Port | Protocol | کاربرد |
|---|---|---|
| 7777 | UDP | Game Traffic و Lightweight Query API |
| 7777 | TCP | Server Traffic و HTTPS API |
| 8888 | TCP | Reliable Messaging |
روی Ubuntu:
sudo ufw allow 7777/udp
sudo ufw allow 7777/tcp
sudo ufw allow 8888/tcp
sudo ufw statusروی Windows:
New-NetFirewallRule `
-DisplayName "Satisfactory UDP 7777" `
-Direction Inbound `
-Protocol UDP `
-LocalPort 7777 `
-Action Allow
New-NetFirewallRule `
-DisplayName "Satisfactory TCP 7777" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 7777 `
-Action Allow
New-NetFirewallRule `
-DisplayName "Satisfactory TCP 8888" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 8888 `
-Action Allowبرای Port اصلی 7777، Port Remap عادی پشتیبانی نمی‌شود؛ Internal و External باید یکسان باشند. Reliable Port را می‌توان با -ReliablePort= تعیین کرد و اگر NAT Remap دارید -ExternalReliablePort= را هم اعلام کنید.
Server Manager چیست و اولین بار چطور Server را Claim کنیم؟
بعد از روشن‌شدن Server، داخل خود Satisfactory Client به Server Manager بروید، IP و Port را اضافه کنید و سرور را Claim کنید. Server Manager مسیر رسمی برای تنظیم Admin Password، Client Password، Auto Load Session، Autosave، Auto Pause و Save Management است.
Server Settings در یک فایل Unreal Save نگهداری می‌شوند:
Linux:
~/.config/Epic/FactoryGame/Saved/SaveGames/ServerSettings.7777.sav
Windows:
%LocalAppData%\\FactoryGame\\Saved\\SaveGames\\ServerSettings.7777.savاین فایل را مثل INI دستی ویرایش نکنید. روش پشتیبانی‌شده برای تغییر تنظیمات اصلی، Server Manager یا HTTPS API است.
Save Server دقیقاً کجا است؟
مسیر پیش‌فرض Dedicated Server:
Linux:
~/.config/Epic/FactoryGame/Saved/SaveGames/server
Windows user:
%LocalAppData%\\FactoryGame\\Saved\\SaveGames\\serverاگر روی Windows با Service یا NSSM اجرا می‌کنید، Profile سرویس متفاوت است و Save ممکن است زیر systemprofile یا NetworkService باشد. همیشه مسیر واقعی Process را پیدا کنید و قبل از Backup مطمئن شوید فایل Session درست را برداشته‌اید.
Blueprintها نیز پوشه جدا دارند و اگر برای Factory شما مهم‌اند، آن‌ها را همراه Save Backup بگیرید.
چرا Autosave در کارخانه بزرگ Freeze ایجاد می‌کند؟
Autosave باید وضعیت بسیار بزرگی از World را Serialize و روی Disk ذخیره کند. هرچه Factory بزرگ‌تر، تعداد Buildableها، Conveyorها، Pipelineها، Trainها و داده‌های World بیشتر باشد، فایل Save بزرگ‌تر و عملیات Save سنگین‌تر می‌شود.
Coffee Stain طی نسخه‌های مختلف Save System را بهینه کرده است؛ در 1.0 نیز Save و Autosave سریع‌تر شده‌اند و این بهبود مخصوصاً در Factoryهای بزرگ محسوس است. با این حال Autosave همچنان یک عملیات رایگان نیست و Wiki رسمی صریحاً می‌گوید کاهش فاصله Autosave باعث افت بیشتر Performance هنگام Save می‌شود.
مقدار پیش‌فرض:
Autosave interval = 300 seconds
= 5 minutesپس اگر روی Factory سنگین هر ۶۰ ثانیه Save می‌کنید، خودتان تعداد Freezeهای قابل‌مشاهده را پنج برابر کرده‌اید.
فاصله Autosave را چطور تنظیم کنیم؟
روش ساده، Server Manager است. مقدار Autosave Interval را از بخش Gameplay تنظیم کنید. همچنین از Console می‌توان این CVar را تغییر داد:
FG.AutosaveInterval 600عدد بالا ۶۰۰ ثانیه یعنی ۱۰ دقیقه است و فقط یک مثال برای Factory سنگین است. انتخاب بازه باید بین دو ریسک تعادل ایجاد کند:
| فاصله Autosave | مزیت | هزینه |
|---|---|---|
| کوتاه‌تر | Progress کمتری در Crash از دست می‌رود | Freeze/Save Spike بیشتر |
| بلندتر | Freeze کمتر | RPO بدتر و Progress بیشتری در Crash از دست می‌رود |
Autosave را کاملاً خاموش نکنید مگر اینکه سیستم Backup/Save دیگری واقعاً دارید و ریسک Data Loss را پذیرفته‌اید.
سه Autosave چرخشی را حفظ کنید
Dedicated Server به‌صورت پیش‌فرض سه Autosave چرخشی نگه می‌دارد:
SessionName_autosave_0.sav
SessionName_autosave_1.sav
SessionName_autosave_2.savمی‌توان تعداد را در Engine.ini تغییر داد:
[/Script/FactoryGame.FGSaveSession]
mNumRotatingAutosaves=5افزایش تعداد Autosave تاریخچه بیشتری می‌دهد، اما Backup خارج از VPS را جایگزین نمی‌کند.
Freeze هنگام Autosave از CPU است یا Disk؟
قبل از Upgrade منابع، هنگام همان لحظه Autosave اندازه‌گیری کنید.
روی Linux:
sudo apt install -y sysstat
pidstat -p $(pgrep -f FactoryServer-Linux-Shipping) 1
iostat -xz 1
vmstat 1اگر هنگام Freeze یک Core به سقف می‌رسد ولی Disk Latency نرمال است، CPU Bottleneck محتمل‌تر است. اگر CPU معمولی است اما await و Disk Utilization هنگام Save جهش می‌کنند، Storage مسئله مهم‌تری است.
روی Windows می‌توانید Task Manager/Resource Monitor یا Performance Monitor را هم‌زمان با Autosave باز کنید و CPU per-core و Disk Response Time را ببینید.
Lag دائم با Autosave Freeze فرق دارد
اگر Lag فقط هر ۵ یا ۱۰ دقیقه و دقیقاً هم‌زمان با Save دیده می‌شود، Save Path را بررسی کنید. اگر Lag دائمی است، احتمال CPU Tick Bottleneck بیشتر است.
| نشانه | علت محتمل |
|---|---|
| Freeze منظم دقیقاً هنگام Autosave | Save Serialization یا Disk I/O |
| Lag دائمی در Factory بزرگ | CPU/Tick Rate و Simulation |
| Lag فقط هنگام Join | Replication، Network Quality یا Save بسیار بزرگ |
| Lag فقط برای یک Player | Route/Internet Client |
| Server Tick پایین ولی CPU کل فقط ۳۰٪ | یک Thread/Core اصلی Bottleneck شده است |
| Freeze همراه Swap/Pagefile | Memory Pressure |
Average Tick Rate را از HTTPS API ببینید
نسخه‌های جدید Dedicated Server یک HTTPS API روی Endpoint پایه زیر دارند:
https://SERVER_IP:7777/api/v1در Server Game State، Metricی به نام AverageTickRate وجود دارد. این Metric برای تشخیص اینکه Server واقعاً در Simulation عقب افتاده یا مشکل فقط Client-side است بسیار مفید است.
Applicationهای مانیتورینگ بهتر است از Application Token استفاده کنند. Token با Console Command زیر ساخته می‌شود:
server.GenerateAPITokenToken دائمی است تا زمانی که آن را Invalidate کنید؛ بنابراین در Repository یا Script عمومی قرار ندهید.
Network Quality را بی‌دلیل روی بالاترین مقدار نگذارید
Server Manager تنظیم Network Quality دارد. Wiki رسمی توضیح می‌دهد افزایش Network Quality ممکن است Load Time و Network Performance Client را بهتر کند، اما در عوض Server Framerate را پایین بیاورد.
پس اگر Factory بزرگ از قبل CPU-bound است، افزایش Network Quality می‌تواند وضعیت را بدتر کند. این تنظیم را مرحله‌ای تغییر دهید و Average Tick Rate را قبل و بعد مقایسه کنید.
Factory بزرگ چرا CPU را بیشتر درگیر می‌کند؟
Satisfactory باید شبکه بزرگ Factory را شبیه‌سازی و State را برای Clientها Replicate کند. Buildableهای زیاد، خطوط Conveyor و Pipeline، Train Network، Vehicleها و سیستم‌های گسترده باعث افزایش کار Simulation و Replication می‌شوند.
Coffee Stain در نسخه‌های جدید چند Optimization مهم برای Saveهای بزرگ منتشر کرده است. برای نمونه، Spline Collision مربوط به Conveyor Belt، Pipeline و Hypertube بهینه شده تا در Saveهای بزرگ مصرف RAM کاهش یابد؛ همچنین Bulk Data Replication برای Multiplayer/Dedicated Server جهت کاهش Bottleneck شبکه و Replication بهبود یافته است.
بنابراین اولین راه‌حل Factory Lag این نیست که تنظیم ناشناخته Engine.ini را کپی کنید. ابتدا:
🔹 Server را روی نسخه Stable روز نگه دارید.
🔹 Single-core CPU Performance را بررسی کنید.
🔹 Average Tick Rate را ثبت کنید.
🔹 اندازه Save و زمان Autosave را اندازه بگیرید.
🔹 Disk Latency هنگام Save را بررسی کنید.
🔹 Network Quality را بی‌دلیل بالا نبرید.
اندازه Save را ثبت کنید؛ حدس نزنید
یک Factory بزرگ را با «تعداد ساعت بازی» نسنجید. اندازه فایل Save و مدت‌زمان واقعی Save را ثبت کنید.
Linux:
SAVE_DIR="$HOME/.config/Epic/FactoryGame/Saved/SaveGames/server"
du -sh "$SAVE_DIR"
find "$SAVE_DIR" -type f -name '*.sav' \
-printf '%TY-%Tm-%Td %TH:%TM %10s %f\\n' \
| sortاگر Autosave Freeze در طول ماه‌ها از نیم ثانیه به چند ثانیه افزایش یافته و Save Size نیز هم‌زمان رشد کرده، رابطه قابل‌اندازه‌گیری دارید. اگر Save ثابت است ولی Freeze ناگهان شدید شده، Storage یا CPU Host را بررسی کنید.
Backup درست؛ قبل از Stop اول Save بگیرید
طبق مستند Running as a Service، Satisfactory حتی هنگام Graceful Shutdown هم لزوماً خودکار Save جدید ایجاد نمی‌کند. پس قبل از Maintenance، اگر بازیکن داخل Server است، از Console دستور Save اجرا کنید:
server.SaveGame "pre-update-backup"بعد از ساخته‌شدن Save می‌توانید Process را Stop و پوشه Save را Backup کنید.
نمونه Linux:
sudo systemctl stop satisfactory
mkdir -p /home/satisfactory/backups
tar -czf \
/home/satisfactory/backups/satisfactory-$(date +%F-%H%M).tar.gz \
-C /home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames \
server \
blueprintsاگر ServerSettings و Certificate/Claim State هم برای Recovery مهم‌اند، فایل ServerSettings.PORT.sav را نیز در Backup نگه دارید.
Backup را خارج از همان VPS نگه دارید
اگر فایل Backup روی همان Disk باشد، در خرابی Storage یا حذف VPS همراه World از بین می‌رود. حداقل یک Copy روی Object Storage، Backup Server یا VPS دیگر داشته باشید.
آپلود و بازیابی Save از Server Manager
Server Manager فقط برای Status نیست. از بخش Manage Saves می‌توانید Save محلی را روی Server Upload کنید و در نسخه‌های جدید Save سرور را برای ادامه محلی Download کنید.
برای Recovery:
🔹 Server را Stop یا Session را کنترل‌شده Pause/خالی کنید.
🔹 از Save خراب فعلی هم Backup بگیرید.
🔹 یکی از Autosaveهای سالم یا Backup خارجی را انتخاب کنید.
🔹 Save را Upload/Restore کنید.
🔹 Auto-Load Session را روی Session درست قرار دهید.
🔹 قبل از ورود همه کاربران، Factory و Trainها را تست کنید.
اجرای Server با systemd و Update خودکار هنگام Start
برای Linux می‌توانید Service رسمی‌مانند زیر داشته باشید:
[Unit]
Description=Satisfactory Dedicated Server
Wants=network-online.target
After=network-online.target
[Service]
User=satisfactory
Group=satisfactory
WorkingDirectory=/home/satisfactory/server
ExecStartPre=/usr/games/steamcmd \
+force_install_dir /home/satisfactory/server \
+login anonymous \
+app_update 1690800 validate \
+quit
ExecStart=/home/satisfactory/server/FactoryServer.sh
Restart=on-failure
RestartSec=60
KillSignal=SIGINT
TimeoutStopSec=120
[Install]
WantedBy=multi-user.targetفایل را در این مسیر قرار دهید:
/etc/systemd/system/satisfactory.serviceسپس:
sudo systemctl daemon-reload
sudo systemctl enable --now satisfactory
sudo systemctl status satisfactoryKillSignal=SIGINT مهم است؛ مستند Server اشاره می‌کند SIGTERM می‌تواند Process را بلافاصله Kill کند. با این حال حتی SIGINT جای دستور Save قبل از Maintenance را نمی‌گیرد.
SteamCMD خطای 0x606 می‌دهد
اگر این خطا را می‌بینید:
Error! App '1690800' state is 0x606رایج‌ترین علت این است که SteamCMD می‌خواهد فایلی را Update کند که Server هنوز باز نگه داشته است. Server را کامل Stop کنید و سپس Update را دوباره اجرا کنید. اگر Process مرده ولی Lock باقی مانده، Reboot Host می‌تواند مشکل را رفع کند.
Monitoring؛ چه چیزهایی را برای Factory بزرگ ثبت کنیم؟
| Metric | چرا مهم است؟ |
|---|---|
| Average Tick Rate | سلامت Simulation Server |
| CPU per-core | پیداکردن Single-thread Bottleneck |
| RAM / Swap | تشخیص Memory Pressure |
| Disk await | تشخیص Freeze ناشی از Save I/O |
| Save Size | رشد پیچیدگی World |
| Autosave Duration | اندازه‌گیری واقعی Freeze |
| Player Count | Correlation با Load |
| Network Loss/RTT | تفکیک Server Lag از Client Lag |
بهترین کار این است که زمان Autosave را روی Graph مشخص کنید. اگر هر افت Tick Rate دقیقاً با Save هم‌زمان است، علت را بسیار سریع‌تر پیدا می‌کنید.
راهکار مرحله‌ای برای رفع Lag کارخانه بزرگ
🔹 Server و Client را به Stable فعلی Update کنید.
🔹 Average Tick Rate را از API یا ابزار مانیتورینگ ثبت کنید.
🔹 CPU per-core را بررسی کنید؛ CPU کل ۳۰٪ می‌تواند گمراه‌کننده باشد.
🔹 هنگام Autosave، Disk Latency و CPU را هم‌زمان اندازه بگیرید.
🔹 Save Size را ثبت و با ماه‌های قبل مقایسه کنید.
🔹 اگر Freeze فقط از Autosave است، Interval را با ریسک Data Loss متعادل کنید.
🔹 Network Quality را روی بالاترین حالت رها نکنید؛ قبل و بعد Tick Rate را مقایسه کنید.
🔹 Backup Compression، Antivirus Scan یا Jobهای سنگین را هم‌زمان با Autosave اجرا نکنید.
🔹 در VPS Oversold، Migration به CPU سریع‌تر از اضافه‌کردن RAM نتیجه بهتری می‌دهد.
اشتباه‌های رایج
🔹 استفاده از راهنمای قدیمی با Portهای 15000 و 15777.
🔹 بازکردن فقط UDP 7777 و فراموش‌کردن TCP 7777 و TCP 8888.
🔹 خرید VPS فقط بر اساس تعداد vCPU.
🔹 کاهش Autosave به ۳۰ یا ۶۰ ثانیه روی Factory بزرگ.
🔹 اجرای Backup فشرده سنگین دقیقاً هم‌زمان با Autosave.
🔹 توقف Service بدون Save دستی قبل از Maintenance.
🔹 نگهداری Backup فقط روی همان Disk.
🔹 افزایش Network Quality بدون نگاه‌کردن به Server Framerate/Tick Rate.
🔹 فرض اینکه RAM بیشتر هر نوع Factory Lag را حل می‌کند.
مطلب مرتبط: برای مقایسه Satisfactory با بازی‌های دیگری که روی VPS قابل میزبانی‌اند، این راهنما را هم ببینید.
برای Factory بزرگ یک سرور دائمی می‌خواهید؟
اگر اندازه Save، تعداد بازیکن‌ها و وضعیت Factory مشخص باشد، می‌توان VPS را بر اساس CPU واقعی، RAM، SSD و مسیر شبکه انتخاب کرد و قبل از انتقال World، Portها و Backup را آماده کرد.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
نسخه Stable فعلی Satisfactory چیست؟
در زمان بازبینی ۲۰ اکتبر ۲۰۲۶، نسخه Stable برابر 1.2.4.1 است و Dedicated Server نیز در شاخه Public اکتبر ۲۰۲۶ به‌روزرسانی شده است.
App ID سرور Satisfactory در SteamCMD چیست؟
App ID رسمی Dedicated Server برابر 1690800 است و با Login ناشناس SteamCMD قابل نصب و Update است.
چه پورت‌هایی برای Satisfactory Server لازم‌اند؟
در نسخه‌های فعلی 7777 روی TCP و UDP و 8888 روی TCP لازم‌اند. Portهای قدیمی 15000 و 15777 دیگر مربوط به ساختار فعلی نیستند.
چرا Autosave باعث Freeze می‌شود؟
Save باید وضعیت World بزرگ را Serialize و روی Disk بنویسد. هرچه Save بزرگ‌تر باشد این عملیات سنگین‌تر می‌شود. فاصله Autosave خیلی کوتاه تعداد Freezeها را بیشتر می‌کند.
Autosave پیش‌فرض چند دقیقه است؟
Dedicated Server به‌صورت پیش‌فرض هر ۵ دقیقه یا ۳۰۰ ثانیه Autosave می‌کند و سه Autosave چرخشی نگه می‌دارد.
چرا CPU کل پایین است ولی Server لگ دارد؟
چون Satisfactory از چند Core استفاده می‌کند اما همچنان به Single-core Performance حساس است. ممکن است یک Thread اصلی اشباع باشد در حالی که میانگین CPU کل پایین دیده می‌شود.
Save سرور کجا قرار دارد؟
روی Linux مسیر پیش‌فرض ~/.config/Epic/FactoryGame/Saved/SaveGames/server و روی Windows User مسیر %LocalAppData%\\FactoryGame\\Saved\\SaveGames\\server است.
آیا Server Manager برای Backup هم کاربرد دارد؟
بله. از Manage Saves می‌توان Save محلی را Upload کرد و Admin می‌تواند Save سرور را Download کند. برای Disaster Recovery بهتر است علاوه بر آن Backup خارج از VPS داشته باشید.
جمع‌بندی
راه‌اندازی Satisfactory Dedicated Server در ۲۰۲۶ با SteamCMD ساده است: App ID برابر 1690800 است و Linux و Windows هر دو به‌صورت رسمی پشتیبانی می‌شوند. تفاوت مهم نسبت به آموزش‌های قدیمی، پورت Reliable Messaging است؛ امروز باید 7777 TCP/UDP و 8888 TCP را در نظر بگیرید.
برای Factory بزرگ، فقط RAM را ارتقا ندهید. Satisfactory به Single-core Performance حساس است و Saveهای بزرگ می‌توانند هنگام Autosave Spike ایجاد کنند. Average Tick Rate، CPU per-core و Disk Latency را در همان لحظه Autosave ثبت کنید.
Autosave پیش‌فرض ۵ دقیقه است. کوتاه‌کردن آن Freezeهای بیشتری ایجاد می‌کند و بلندکردن آن ریسک از دست رفتن Progress را بالا می‌برد؛ Interval را متناسب با Save Size و Backup Strategy تنظیم کنید.
در نهایت، قبل از Update یا Stop مهم، یک Save دستی بسازید و Save، Blueprint و Server Settings را خارج از همان VPS Backup کنید. Rolling Autosave جای Disaster Recovery را نمی‌گیرد.
دیدگاه‌ها (۰)