Stand: 2026-08-05 (erhoben per SSH auf den Proxmox-Host + pct exec)
| Eigenschaft |
Wert |
| Hostname |
AMP-Server |
| Container-ID (VMID) |
104 |
| Proxmox-Node |
proxmox (192.168.2.230) |
| Rolle |
CubeCoders AMP (Application Management Panel) — hostet mehrere Gameserver-Instanzen |
| IP-Adresse |
192.168.2.233 (DHCP, /24) |
| Root-Storage |
Storage:104/vm-104-disk-0.raw (NFS-Storage "Storage"), 100 GB |
| Privilegierung |
Privilegiert (kein unprivileged-Flag gesetzt) |
| Eigenschaft |
Wert |
| Architektur |
amd64 |
| CPU-Kerne (Limit) |
4 |
| RAM-Limit |
10240 MB (10 GB) |
| Swap-Limit |
512 MB |
| Netzwerk |
eth0, Bridge vmbr0, Firewall aktiv, MAC BC:24:11:25:EB:E9, DHCP |
| Features |
nesting=1 |
| OS-Typ (Proxmox-Erkennung) |
debian |
| Storage-Besonderheit |
Root-Disk liegt (anders als die meisten anderen LXCs) auf dem NFS-Storage "Storage", nicht auf local-lvm |
- Keine automatisierte Backup-Job-Konfiguration auf dem Proxmox-Host.
- Zwei manuelle Backups vorhanden:
vzdump-lxc-104-2026_03_14-18_34_19.tar.zst (~10,3 GB), 2026-03-14vzdump-lxc-104-2026_03_23-16_14_14.tar.zst (~19,1 GB), 2026-03-23
- Keine Snapshots vorhanden. Letztes Backup ca. 4,5 Monate alt (Stand Erhebung) — bei ~40 GB Gameserver-Daten (Welten/Saves) relevant.
- OS: Debian GNU/Linux 12 (bookworm)
- Kernel:
7.0.12-1-pve (Proxmox-Host-Kernel)
- Uptime: ca. 5 Wochen, 2 Tage (Stand Erhebung)
| Ressource |
Wert |
| CPU-Kerne |
4 |
| RAM |
10 GiB (davon ~6,7 GiB belegt — Swap fast voll, 511/512 MiB) |
| Root-Disk |
98 GB gesamt, 57 GB belegt (61 %) |
Auffällig: Der Swap-Speicher ist nahezu vollständig ausgelastet (511 von 512 MiB). Bei mehreren gleichzeitig laufenden Gameservern könnte RAM knapp werden — ggf. RAM-Limit erhöhen oder Anzahl gleichzeitig aktiver Instanzen prüfen.
- Interface:
eth0, MAC BC:24:11:25:EB:E9, IP 192.168.2.233/24, DHCP
| Port |
Protokoll |
Dienst/Instanz |
| 22 |
TCP |
SSH |
| 25 |
TCP (nur localhost) |
Postfix (lokal) |
| 8080 |
TCP |
AMP Instance Manager (ADS01) — Haupt-Admin-UI |
| 2223 |
TCP |
ADS01 – interne AMP-Kommunikation |
| 8081 |
TCP |
AMP-Instanz #2 (Web-UI) |
| 2224 |
TCP |
AMP-Instanz #2 – interne Kommunikation |
| 8085 |
TCP |
AMP-Instanz #3 (Web-UI) |
| 2228 |
TCP |
AMP-Instanz #3 – interne Kommunikation |
| 25575 |
TCP |
Palworld RCON |
| 2456 |
(Valheim-Spielport, lokal geproxied) |
Valheim |
CubeCoders AMP läuft nativ im Container (/home/amp/.ampdata, /opt/cubecoders/amp) und startet die Gameserver teils direkt als Prozesse, teils als eigene Docker-Container.
| Instanz |
Spiel |
Disk-Nutzung |
Ausführung |
ADS01 |
— (AMP Instance Manager selbst) |
192 MB |
nativ |
GurkesEnshroudedServer01 |
Enshrouded |
12 GB |
nativ |
GurkesIcarusServer01 |
Icarus |
13 GB |
nativ |
GurkesPalworldServer01 |
Palworld |
5,3 GB |
Docker (cubecoders/ampbase:debian), läuft seit ~3 Wochen |
GurkesValheimServer01 |
Valheim |
3,9 GB |
Docker (cubecoders/ampbase:debian), läuft seit ~4 Wochen |
Satisfactory-Server01 |
Satisfactory |
4,7 GB |
nativ |
Der Valheim-Server läuft passwortgeschützt (Passwort in der Prozessliste sichtbar, hier aus Sicherheitsgründen nicht dokumentiert — bei Bedarf über AMP-UI einsehbar) und ist auf "public" gestellt.
- Docker (Version 29.6.1) ist installiert, wird aber nur für 2 von 5 Gameserver-Instanzen genutzt (Palworld, Valheim) — die anderen laufen nativ auf dem Host-Container.
- Kein projektspezifischer Cron-Job gefunden.
- Backup-Strategie einrichten: Kein automatisierter Job. Letztes Backup vom 2026-03-23 (~4,5 Monate alt) — bei Spielständen/Welten mit potenziell viel Spielfortschritt seit der Erhebung ein reales Risiko.
- Swap-Auslastung beobachten: Swap ist fast vollständig belegt — RAM-Limit (aktuell 10 GB) ggf. erhöhen oder Instanzen reduzieren, um Performance-Probleme bei den Gameservern zu vermeiden.
- Uneinheitliche Ausführung (nativ vs. Docker): Für Wartung/Updates ist es hilfreich zu wissen, dass 2 Instanzen als Docker-Container laufen und 3 nativ — unterschiedliche Update-/Restart-Mechanismen.
- Storage-Sonderfall: Root-Disk liegt auf dem NFS-Storage "Storage" statt
local-lvm wie bei den meisten anderen Containern — bei Storage-Wartung (NAS-Neustart etc.) ist dieser Container mitbetroffen.