> La lista completa de artículos está en [llms.txt](https://docs.f3cloud.com/llms.txt). Cada página tiene versión en Markdown, basta con añadir .md a su dirección. Esta página en Markdown: [https://docs.f3cloud.com/es/games/project-zomboid-server.md](https://docs.f3cloud.com/es/games/project-zomboid-server.md).

# Servidor de Project Zomboid en un VPS – instalación con SteamCMD, inicio automático y copias de seguridad

Cómo crear un servidor de Project Zomboid en un VPS. Instalación con SteamCMD, límite de memoria de Java, primer inicio y contraseña de administrador, ajustes de servertest.ini, apertura de los puertos 16261 y 16262 por UDP, inicio automático con systemd que guarda el mundo al detenerse, actualización y copias de seguridad. Probado en Debian 12 con Project Zomboid Build 42.21.

Un servidor propio de Project Zomboid en un VPS funciona las 24 horas, y tus amigos pueden entrar al mundo compartido a cualquier hora, sin esperar a que alguien encienda su ordenador. Tú decides cuántos jugadores habrá, si el PVP está activado y quién puede entrar. En este artículo instalaremos un servidor dedicado con SteamCMD, limitaremos su memoria, abriremos los puertos necesarios y configuraremos el inicio automático con una parada segura y las copias de seguridad del mundo. Hemos repetido todos los pasos en un servidor de pruebas con Debian 12. En el momento de la prueba, la versión actual del juego era la **Build 42.21**.

***

## Cómo funciona el servidor de Project Zomboid

El servidor de Project Zomboid es un programa gratuito aparte que Valve distribuye a través de Steam con el número de aplicación **380870**. Para instalarlo no hacen falta ni una cuenta de Steam ni el juego comprado, porque se puede descargar de forma anónima, y de ello se encarga el cliente de consola **SteamCMD**. El juego está escrito en Java, y el servidor incluye su propia Java 25 en la carpeta `jre64`, así que no hay que instalarla por separado. El programa y los datos están en sitios distintos. Los archivos del juego están en la carpeta del servidor, mientras que el mundo, las cuentas de los jugadores, los ajustes y los registros se guardan en la carpeta `Zomboid` dentro de la carpeta personal del usuario. Gracias a eso, la actualización con SteamCMD sustituye el juego y no toca tu mundo.

Los jugadores se conectan por el protocolo UDP. Al arrancar, el propio servidor escribe en el registro que escucha el puerto 16261 para las conexiones de Steam y el puerto 16262 para las conexiones de RakNet, y recomienda a los clientes usar el puerto 16261. Comprobamos los dos puertos desde fuera. En el 16261 el servidor responde a las consultas de Steam sobre su nombre y el número de jugadores, y en el 16262 responde al ping de servicio de RakNet, así que en el cortafuegos hay que abrir los dos puertos. Si los puertos están cerrados, los paquetes UDP simplemente se pierden y el servidor guarda silencio, porque no le llega nada. Así se veía nuestro servidor en la comprobación desde fuera mientras en UFW no había ninguna regla.

El recurso principal del servidor es la memoria. En el archivo `ProjectZomboid64.json`, el límite de memoria de Java por defecto es **-Xmx8g**, es decir, 8 GB, y para un VPS pequeño es demasiado. Nosotros ponemos 3 GB. Aun así, el proceso ocupa más que el límite indicado, porque a la memoria del montón (heap) se suma la memoria de servicio de la propia Java. En nuestro servidor, con `-Xmx3g` el proceso ocupó unos 4 GB, y con `-Xmx2g`, unos 2,9 GB, es decir, el límite más unos 0,9 GB. El servidor usa el recolector de basura ZGC (el parámetro `-XX:+UseZGC` del mismo archivo), y la memoria ocupada no se libera en reposo. Seis minutos después del arranque, sin un solo jugador, el proceso seguía ocupando los mismos 3,9 GB, así que calcula la memoria con margen.

> **Build 42 y Build 41.**
>
> La rama `public` de SteamCMD, que obtienes por defecto, contiene ahora la Build 42. En nuestro registro de arranque aparece `version=42.21.0`, y en los anuncios oficiales de Steam la versión 42.21 figura como estable. Además, SteamCMD tiene las ramas `unstable` para pruebas, `legacy41` con la Build 41.78.21 y `42.19` con la Build 42.19.2. La rama se elige con el parámetro `-beta`, por ejemplo `+app_update 380870 -beta legacy41 validate`. Comprobamos que SteamCMD acepta este parámetro y empieza a descargar la Build 41, que ocupa unos 5 GB. La versión del cliente de los jugadores debe coincidir con la del servidor. No hemos iniciado el juego en un servidor con la Build 41 ni hemos probado el cambio entre ramas, así que antes de hacerlo haz una copia del mundo.

***

## Qué necesitas

* **Un servidor** con Debian 12 y **al menos 6 GB de memoria**, por ejemplo el plan **DE-RZ9-3**. Con `-Xmx3g` el proceso ocupa unos 4 GB, y además hacen falta unos 7 GB de disco. Si todavía no tienes servidor, contrátalo siguiendo la [guía](https://docs.f3cloud.com/es/client-area/order-vps.md). En el plan **DE-RZ9-2**, con 4 GB, el servidor arranca con `-Xmx2g`, pero el margen es pequeño y no hemos probado su funcionamiento con jugadores.
* **Conexión por SSH**, por ejemplo con [Termius](https://docs.f3cloud.com/es/vps/termius-connection.md). Los comandos se ejecutan como `root`, salvo que se indique otra cosa.
* **El juego Project Zomboid** en cada jugador, de la misma versión que el servidor.

> **Qué hemos probado y qué no.**
>
> No hemos iniciado el cliente del juego ni hemos entrado al servidor como jugador. Hemos comprobado otras cosas. El servidor arranca, escucha los puertos 16261 y 16262 por UDP y responde a las consultas de Steam y RakNet desde otro ordenador. La parada, el reinicio, la actualización y las copias de seguridad funcionan. No hemos probado la carga de los jugadores, los mods ni el funcionamiento en la lista de servidores del juego.

***

## Paso 1. Instala las bibliotecas y crea un usuario

SteamCMD es un programa de 32 bits, y en un Debian de 64 bits necesita dos bibliotecas. De paso, instala también `screen`, que hará falta para la consola del servidor.

```bash
apt update
apt install -y screen curl ca-certificates lib32gcc-s1 lib32stdc++6
```

Ejecutar el servidor como `root` no es seguro, así que crearemos para él un usuario aparte, `zomboid`, con la carpeta personal `/opt/zomboid`. Encontrarás más detalles sobre los usuarios en el artículo sobre los [usuarios de Linux](https://docs.f3cloud.com/es/linux/linux-users.md).

```bash
useradd -r -m -d /opt/zomboid -s /bin/bash zomboid
```

***

## Paso 2. Instala SteamCMD

Entra como el usuario `zomboid` y descarga SteamCMD del servidor de Valve. Los comandos de los pasos 2 a 5 se ejecutan con este usuario.

```bash
su - zomboid
mkdir ~/steamcmd && cd ~/steamcmd
curl -fsSL https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz | tar zxf -
```

Es un cargador pequeño, y el programa completo se descargará en el primer inicio.

***

## Paso 3. Descarga el servidor

El siguiente comando entra en Steam de forma anónima y descarga la aplicación 380870 en la carpeta `/opt/zomboid/server`. En el primer inicio, SteamCMD primero se actualiza a sí mismo, unos 41 MB, y después empieza a descargar el servidor.

```bash
./steamcmd.sh +force_install_dir /opt/zomboid/server +login anonymous +app_update 380870 validate +quit
```

En nuestro servidor se descargaron unos 2 GB, y en el disco el servidor ocupó unos 7 GB. La instalación duró unos tres minutos. Al final, SteamCMD escribe **Success! App '380870' fully installed.**

Ahora, en la carpeta del servidor están el script de inicio `start-server.sh`, la Java propia en `jre64` y el archivo `ProjectZomboid64.json` con los ajustes de memoria.

***

## Paso 4. Limita la memoria

En `ProjectZomboid64.json`, sustituye el límite de 8 GB por 3 GB. Si tu plan tiene 4 GB, pon `-Xmx2g`.

```bash
sed -i 's/-Xmx8g/-Xmx3g/' ~/server/ProjectZomboid64.json
grep Xmx ~/server/ProjectZomboid64.json
```

En la respuesta debe aparecer la línea `"-Xmx3g",`. Es mejor no tocar el resto de los parámetros del archivo.

> **La comprobación de archivos restablece este parámetro.**
>
> Si ejecutas SteamCMD con el parámetro `validate`, devolverá `ProjectZomboid64.json` a su estado original y el límite volverá a ser de 8 GB. Lo comprobamos en el servidor de pruebas. Cómo actualizar el servidor sin perder el límite se muestra más abajo, en la sección sobre la actualización.

***

## Paso 5. Inicia el servidor por primera vez

El primer inicio hay que hacerlo a mano, porque el servidor pedirá la contraseña de administrador.

```bash
cd ~/server
./start-server.sh
```

Al principio, el servidor imprimirá muchas líneas sobre la carga del juego. Después aparecerán las líneas **Enter new administrator password** y **Confirm the password**. Escribe la contraseña que hayas elegido y pulsa <kbd>Enter</kbd>, y luego repítela para confirmarla. Después, el servidor informará **Administrator account 'admin' created.** Así se crea la cuenta `admin`, con la que entrarás al juego como administrador.

<figure><img src="https://docs.f3cloud.com/img/zomboid-admin-password.png" alt="Primer inicio del servidor de Project Zomboid, petición de la contraseña de administrador y el mensaje Administrator account 'admin' created"><figcaption><p>El servidor pide la contraseña de administrador en el primer inicio, las contraseñas en pantalla están ocultas</p></figcaption></figure>

> **La contraseña se ve mientras la escribes.**
>
> En nuestro terminal, la contraseña escrita se mostraba en pantalla en texto claro. Asegúrate de que no haya nadie detrás de ti y no hagas capturas de esta ventana. Es mejor generar la contraseña en un gestor de contraseñas y pegarla. No uses el parámetro `-adminpassword` en el script de inicio, porque entonces la contraseña quedaría en texto claro en el archivo.

A continuación, el servidor crea el mundo. Después de introducir la contraseña, nos llevó unos 50 segundos. Cuando en el registro aparezca la línea **SERVER STARTED**, el servidor estará listo.

<figure><img src="https://docs.f3cloud.com/img/zomboid-server-started.png" alt="Servidor de Project Zomboid iniciado, mensaje SERVER STARTED y la línea sobre los puertos 16261 y 16262"><figcaption><p>El servidor escucha los puertos 16261 y 16262</p></figcaption></figure>

Detén el servidor con el comando `quit`, escribiéndolo en esta misma ventana. Guarda el mundo y cierra el servidor, y a nosotros nos llevó unos 10 segundos. Después de la parada, vuelve a `root`. A partir de ahora, el servidor arrancará solo.

```bash
exit
```

Los ajustes y el mundo se han creado en la carpeta `/opt/zomboid/Zomboid`. Esto es lo principal que hay allí.

* `Server/servertest.ini` con los ajustes principales del servidor.
* `Server/servertest_SandboxVars.lua` con las reglas del mundo, por ejemplo la cantidad de zombis y la velocidad con que cambian el día y la noche.
* `Saves/Multiplayer/servertest` con el propio mundo.
* `db/servertest.db` con las cuentas de los jugadores.
* `Logs` con los registros del servidor.

El nombre `servertest` es el nombre del servidor por defecto, y todos estos archivos se llaman así por él.

***

## Paso 6. Configura el servidor

Abre el archivo de ajustes. Modifícalo con el servidor detenido, porque el servidor reescribe este archivo al arrancar.

```bash
nano /opt/zomboid/Zomboid/Server/servertest.ini
```

Junto a cada parámetro del archivo hay un comentario en inglés. Hemos reunido lo más importante en una tabla, y los valores por defecto están tomados del archivo creado.

| Parámetro | Por defecto | Qué significa |
| --- | --- | --- |
| `PublicName` | My PZ Server | Nombre del servidor en las listas del juego y de Steam |
| `Password` | vacío | Contraseña que hay que conocer para entrar al servidor |
| `MaxPlayers` | 32 | Cuántos jugadores pueden estar a la vez en el servidor, los administradores no cuentan |
| `PVP` | true | Los jugadores pueden herirse y matarse entre sí |
| `Open` | true | Un jugador puede entrar sin una cuenta creada de antemano, que se crea en el primer acceso |
| `Public` | false | Mostrar el servidor en la lista de servidores del juego |
| `PauseEmpty` | true | El tiempo del juego se detiene mientras no haya nadie en el servidor |
| `SaveWorldEveryMinutes` | 0 | Cada cuánto guardar el mundo. Con cero, el mapa se guarda sobre todo cuando los jugadores salen de la zona cargada |
| `UPnP` | true | Intento de configurar el router automáticamente. En un VPS no hay router, así que pon false |

Para un servidor con amigos cambiamos algunos valores. Hemos comprobado estas líneas en el servidor de pruebas.

```ini
PublicName=Friends Server
Password=tu_contraseña
MaxPlayers=8
PVP=false
UPnP=false
SaveWorldEveryMinutes=15
```

Después de iniciar el servidor, comprobamos que los ajustes se habían aplicado. El comando `showoptions` de la consola mostró los valores nuevos, y la consulta de Steam desde otro ordenador devolvió el nombre del servidor, 8 plazas y la indicación de que hace falta contraseña.

> **Contraseña del servidor y lista cerrada.**
>
> Para un grupo de amigos basta con establecer `Password`, y esa contraseña simplemente se la dices a tus amigos. Si necesitas un control estricto, pon `Open=false`. Entonces las cuentas de los jugadores las creas tú con el comando `adduser Nombre Contraseña` en la consola del servidor. Comprobamos este comando, y el servidor respondió que el usuario se había creado.

***

## Paso 7. Abre los puertos 16261 y 16262

Abre los dos puertos en el cortafuegos UFW. Los puertos se necesitan precisamente por UDP.

```bash
ufw allow 16261:16262/udp
```

Encontrarás más detalles sobre el cortafuegos en el artículo sobre [UFW](https://docs.f3cloud.com/es/vps/security/firewall.md).

Hay que comprobar el servidor desde internet, es decir, desde otro ordenador. Para ello escribimos un pequeño script en Python 3, que envía al servidor la consulta estándar de Steam con la información del servidor (A2S_INFO). Guárdalo en el archivo `pz-check.py` en tu ordenador.

```python
import socket, sys

host, port = sys.argv[1], 16261
req = b"\xff\xff\xff\xffTSource Engine Query\x00"
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
s.settimeout(3)
try:
    s.sendto(req, (host, port))
    data, _ = s.recvfrom(4096)
    if data[4:5] == b"A":  # el servidor pide repetir la consulta con un código de verificación
        s.sendto(req + data[5:9], (host, port))
        data, _ = s.recvfrom(4096)
    print("El servidor responde, nombre:", data[6:data.index(0, 6)].decode())
except socket.timeout:
    print("No hay respuesta, el puerto está cerrado o el servidor no está iniciado")
```

Ejecútalo indicando la dirección IP del VPS. Probamos el script dos veces, antes y después de la regla de UFW.

```bash
python3 pz-check.py IP-del-servidor
```

<figure><img src="https://docs.f3cloud.com/img/zomboid-udp-check-es.png" alt="Comprobación del puerto 16261 por UDP, primero no hay respuesta y, tras la regla de UFW, el servidor responde y dice su nombre"><figcaption><p>Mientras el puerto está cerrado, no hay respuesta. Tras la regla de UFW, el servidor dice su nombre</p></figcaption></figure>

Si ves el nombre del servidor, el puerto 16261 es accesible desde internet. El puerto 16262 lo comprobamos aparte con el ping de servicio de RakNet, y también respondió.

***

## Paso 8. Configura el inicio automático

Para que el servidor funcione en segundo plano, arranque junto con el VPS y se levante tras un fallo, lo configuraremos como un servicio de systemd. Cómo funcionan los servicios se explica con detalle en el artículo sobre [systemd](https://docs.f3cloud.com/es/linux/systemd-services.md). La consola del servidor, igual que en el artículo sobre el [servidor de Minecraft](https://docs.f3cloud.com/es/games/minecraft-server.md), la ejecutaremos dentro de `screen`. A través de ella, el servidor recibe los comandos, entre ellos el de guardar y detenerse.

Primero crea el script de parada. Envía a la consola el comando `quit` para que el servidor guarde el mundo, y espera a que el servidor termine.

```bash
nano /opt/zomboid/stop.sh
```

```bash
#!/bin/sh
# Envía el comando quit a la consola del servidor y espera a que el servidor guarde el mundo y termine
screen -p 0 -S zomboid -X stuff "quit$(printf '\r')"
while kill -0 "$MAINPID" 2>/dev/null; do sleep 1; done
```

Haz el script ejecutable y crea el servicio.

```bash
chmod +x /opt/zomboid/stop.sh
chown zomboid:zomboid /opt/zomboid/stop.sh
nano /etc/systemd/system/zomboid.service
```

```ini
[Unit]
Description=Project Zomboid server
After=network-online.target
Wants=network-online.target

[Service]
User=zomboid
WorkingDirectory=/opt/zomboid/server
ExecStart=/usr/bin/screen -DmS zomboid /opt/zomboid/server/start-server.sh
ExecStop=/opt/zomboid/stop.sh
Restart=always
RestartSec=10
TimeoutStopSec=120

[Install]
WantedBy=multi-user.target
```

Activa el inicio automático e inicia el servidor.

```bash
systemctl daemon-reload
systemctl enable --now zomboid
systemctl status zomboid
```

<figure><img src="https://docs.f3cloud.com/img/zomboid-systemd-status.png" alt="systemctl status zomboid, servicio active (running), procesos screen y ProjectZomboid64, y los puertos UDP 16261 y 16262"><figcaption><p>El servicio funciona y el servidor escucha los dos puertos</p></figcaption></figure>

Después de iniciar el servicio, el servidor tarda unos 40 segundos en cargarse y luego empieza a responder a las consultas. A partir de ahora hay que gestionarlo a través de systemd.

* `systemctl stop zomboid` guarda el mundo y apaga el servidor.
* `systemctl restart zomboid` reinicia el servidor.
* `systemctl start zomboid` enciende el servidor.

Comprobamos cómo se comporta el servicio en distintas situaciones.

* La parada con el comando `systemctl stop zomboid` duró unos 10 segundos, y en el registro del servidor aparecieron las entradas sobre el comando `quit` y sobre el guardado del mundo.
* Cuando terminamos Java a la fuerza, systemd levantó el servidor de nuevo a los 10 segundos. El script `start-server.sh` termina con el código 0 incluso después de un fallo así, por eso hace falta precisamente `Restart=always`.
* El comando `quit` escrito directamente en la consola también provoca un reinicio, y no un apagado. Para apagar el servidor, usa `systemctl stop zomboid`.

Los mensajes del juego no llegan a `journalctl`, porque el servidor los escribe en la consola dentro de `screen`. Los registros están en `/opt/zomboid/Zomboid/Logs`, y el último arranque queda guardado en el archivo `/opt/zomboid/Zomboid/server-console.txt`. Encontrarás más detalles sobre los registros en el artículo sobre los [logs de Linux](https://docs.f3cloud.com/es/linux/linux-logs.md).

***

## Paso 9. Consola del servidor y conexión de los jugadores

Para abrir la consola del servidor, conéctate a la sesión de `screen`.

```bash
su - zomboid -c "screen -r zomboid"
```

Para salir de la consola y dejar el servidor funcionando, pulsa <kbd>Ctrl</kbd> + <kbd>A</kbd> y después <kbd>D</kbd>. Encontrarás más detalles sobre `screen` en un [artículo aparte](https://docs.f3cloud.com/es/linux/screen-linux-tool.md). La lista de todos los comandos la muestra `help`. Estos son los que hemos probado.

* `players` muestra los jugadores conectados.
* `save` guarda el mundo al instante.
* `servermsg "Texto"` envía un mensaje a todos los jugadores.
* `adduser Nombre Contraseña` crea la cuenta de un jugador.
* `quit` guarda el mundo y detiene el servidor, tras lo cual el servicio lo inicia de nuevo.

Los jugadores deben introducir en el juego la dirección IP del VPS, el puerto **16261**, la contraseña del servidor si la has establecido, y después el nombre y la contraseña de su personaje. En un servidor abierto con `Open=true`, la cuenta se crea en el primer acceso. En lugar de la dirección IP resulta cómodo usar un dominio, y cómo hacerlo se describe en el artículo sobre [cómo vincular un dominio](https://docs.f3cloud.com/es/vps/domain-to-vps.md). Para entrar como administrador, usa el nombre `admin` y la contraseña del paso 5.

***

## Actualización del servidor

Cuando sale una versión nueva del juego, los clientes se actualizan solos a través de Steam, y la versión del servidor debe coincidir con ella. En la actualización 42.21, los desarrolladores añadieron un aviso para los jugadores que intentan entrar a un servidor de otra versión. El servidor se actualiza por separado. Hemos preparado un script que detiene el servidor, lo actualiza, restablece el límite de memoria y lo inicia de nuevo.

```bash
nano /usr/local/bin/zomboid-update.sh
```

```bash
#!/bin/sh
# Detiene el servidor, lo actualiza con SteamCMD, restablece el límite de memoria y lo inicia de nuevo
systemctl stop zomboid
su - zomboid -c "~/steamcmd/steamcmd.sh +force_install_dir /opt/zomboid/server +login anonymous +app_update 380870 +quit"
su - zomboid -c "sed -i 's/-Xmx[0-9]*[gGmM]/-Xmx3g/' /opt/zomboid/server/ProjectZomboid64.json"
systemctl start zomboid
```

Si has elegido otro límite de memoria, cambia `3g` en el script. Haz el script ejecutable y ejecútalo cuando necesites actualizar.

```bash
chmod +x /usr/local/bin/zomboid-update.sh
zomboid-update.sh
```

Cuando no hay actualizaciones, SteamCMD escribe **Success! App '380870' already up to date.** En nuestro caso, todo el script se ejecutó en 14 segundos. En el script no hay parámetro `validate` a propósito. Comprobamos que la actualización normal no toca el `ProjectZomboid64.json` modificado, mientras que la comprobación de archivos con `validate` le devuelve los 8 GB.

<figure><img src="https://docs.f3cloud.com/img/zomboid-steamcmd-validate.png" alt="SteamCMD con el parámetro validate comprobó 7 GB de archivos y descargó 359 bytes, es decir, sustituyó ProjectZomboid64.json"><figcaption><p>La comprobación de archivos duró alrededor de un minuto y sustituyó un archivo pequeño con los ajustes de memoria</p></figcaption></figure>

`validate` solo hace falta para reparar, por ejemplo si los archivos del juego se han dañado. Después, ejecuta de nuevo el comando del paso 4.

***

## Copias de seguridad del mundo

El mundo está en `/opt/zomboid/Zomboid/Saves`, y las cuentas de los jugadores, en `/opt/zomboid/Zomboid/db`. El propio servidor hace copias al arrancar y al cambiar de versión, y las guarda en `/opt/zomboid/Zomboid/backups`. Por defecto conserva cinco copias (el parámetro `BackupsCount`). Pero están en el mismo disco que el mundo. Para mayor seguridad, añadiremos nuestro propio script. Guarda el mundo con el comando `save`, empaqueta el mundo, las cuentas y los ajustes en un archivo en la carpeta `/opt/zomboid/archives` y conserva los 7 últimos archivos. El servidor no se detiene mientras se hace la copia.

```bash
nano /opt/zomboid/backup.sh
```

```bash
#!/bin/sh
# Guarda el mundo, lo archiva junto con los ajustes y conserva los 7 últimos archivos
cd /opt/zomboid || exit 1
screen -p 0 -S zomboid -X stuff "save$(printf '\r')"
sleep 10
mkdir -p archives
tar -czf "archives/zomboid-$(date +%F-%H%M).tar.gz" Zomboid/Saves Zomboid/db Zomboid/Server
ls -1t archives/zomboid-*.tar.gz | tail -n +8 | xargs -r rm --
```

Haz el script ejecutable y añádelo a la programación del usuario `zomboid`, por ejemplo todas las noches a las 4:00.

```bash
chmod +x /opt/zomboid/backup.sh
chown zomboid:zomboid /opt/zomboid/backup.sh
echo "0 4 * * * /opt/zomboid/backup.sh" | crontab -u zomboid -
```

Probamos el script a mano y según la programación, y las dos veces apareció el archivo. En un mundo recién creado, el archivo ocupó menos de 1 MB, y en una partida real crecerá junto con el mundo. Encontrarás más detalles sobre la programación en el artículo sobre [cron](https://docs.f3cloud.com/es/linux/cron-linux.md). Las copias en este mismo servidor no te salvarán si desaparece el propio servidor, así que de vez en cuando descarga los archivos a tu ordenador o envíalos a otro servidor, por ejemplo con el comando [rsync](https://docs.f3cloud.com/es/linux/rsync-linux.md).

Para restaurar el mundo, detén el servidor, descomprime el archivo necesario sobre la carpeta `/opt/zomboid` e inicia el servidor. Comprobamos la restauración, y el servidor arrancó después de ella.

```bash
systemctl stop zomboid
su - zomboid -c "tar -xzf /opt/zomboid/archives/NOMBRE-ARCHIVO.tar.gz -C /opt/zomboid"
systemctl start zomboid
```

***

## Preguntas frecuentes

<details>

<summary>./steamcmd.sh: cannot execute: required file not found</summary>

Completo se ve así: `./steamcmd.sh: line 85: /opt/zomboid/steamcmd/linux32/steamcmd: cannot execute: required file not found`. Faltan las bibliotecas de 32 bits. Obtuvimos este mensaje cuando desinstalamos `lib32gcc-s1` y `lib32stdc++6`. Instálalas como se describe en el paso 1.

</details>

<details>

<summary>El servicio funciona, pero el servidor no responde, en la consola Enter new administrator password</summary>

En el primer inicio, el servidor espera la contraseña de administrador, y en el servicio no hay nadie que la introduzca. Lo reprodujimos con un nombre de servidor nuevo. El servicio seguía `active`, pero nadie escuchaba los puertos 16261 y 16262, y la comprobación desde fuera no recibía respuesta. Detén el servicio con el comando `systemctl stop zomboid`, haz el paso 5 a mano, introduce la contraseña y espera a **SERVER STARTED**, después detén el servidor con el comando `quit` y vuelve a iniciar el servicio.

</details>

<details>

<summary>ERROR en rojo al arrancar, libjsig.so y Property Name not found</summary>

En el registro de arranque vimos dos grupos de líneas con errores, y los dos son inofensivos.

* **ERROR: ld.so: object 'libjsig.so' from LD_PRELOAD cannot be preloaded** aparece al arrancar. Al final de la línea, el servidor escribe que ha omitido esta biblioteca (`ignored`) y sigue funcionando.
* **IsoPropertyType.lookupOrDefaultStr> Exception thrown** con un texto como `Property Name not found: ladderW` y una larga pila de llamadas aparece varias veces al crear un mundo nuevo.

Si después de ellos en el registro aparece la línea **SERVER STARTED**, todo está bien.

</details>

<details>

<summary>If the server hangs here, set UPnP=false</summary>

Es una línea del registro de arranque, que va justo después del mensaje **Router detection/configuration starting**. Mientras el parámetro `UPnP` sea `true`, el servidor busca en la red un router para abrir los puertos. En un VPS no hay router. En nuestro servidor, el arranque esperó unos 12 segundos y escribió **No UPnP-enabled Internet gateway found**, y después arrancó. Pon `UPnP=false` en `servertest.ini`, y el arranque será más rápido en ese tiempo.

</details>

<details>

<summary>No hay respuesta, el puerto está cerrado o el servidor no está iniciado</summary>

Así responde nuestro script `pz-check.py` cuando desde otro ordenador no llega ninguna respuesta. Obtuvimos este mensaje mientras en UFW no había una regla para UDP. Comprueba que el servicio funciona con el comando `systemctl status zomboid`, que la regla existe con el comando `ufw status`, y que los puertos están a la escucha con el comando `ss -ulpn | grep 1626`. Abre precisamente **UDP**, una regla para TCP no ayudará.

</details>

<details>

<summary>Killed process (ProjectZomboid6) en el registro del kernel</summary>

El servidor se cerró de repente sin mensajes en la consola. Esto pasa cuando el proceso ha ocupado más memoria de la que hay en el servidor o de la asignada al servicio, y el kernel ha protegido el sistema de la falta de memoria. Compruébalo con el comando `journalctl -k | grep -i "killed process"`. Lo reprodujimos limitando el servicio a 2 GB de memoria con un límite de Java de 3 GB, y el kernel escribió `Memory cgroup out of memory: Killed process … (ProjectZomboid6)`. Reduce `-Xmx` en `ProjectZomboid64.json` o elige un plan con más memoria.

</details>

<details>

<summary>Tras la actualización, el servidor vuelve a ocupar 8 GB</summary>

Ejecutaste SteamCMD con el parámetro `validate`, y devolvió `ProjectZomboid64.json` a su estado original. Lo obtuvimos cuando comprobamos los archivos, SteamCMD descargó 359 bytes y en el archivo volvió a aparecer `-Xmx8g`. Restablece el límite con el comando del paso 4 y actualiza el servidor con el script de la sección sobre la actualización.

</details>

***

## Nuestros recursos

**Canal de Telegram:** [https://t.me/f3cloud_news](https://t.me/f3cloud_news)\
**Web del hosting:** [https://f3cloud.com](https://f3cloud.com/es)
