A Minecraft world and a plugin database can each be backed up successfully and still disagree when restored together. That is the problem I wanted this infrastructure design to address. Separating services into VMs is useful, but it does not decide which pieces of state belong together or establish a recovery point across them.
This October entry examines my Minecraft infrastructure reference architecture v1.2. It is an architecture study, not a production deployment report. The hardware profiles are planning assumptions; backup coordination, performance, and recovery times still need deployment-specific evidence.
The persistence work in September’s Minasty devlog exposed a related boundary: database durability does not create a transaction with Minecraft world saves. This study approaches that problem from the infrastructure side, without implying that the proposed topology hosts Minasty.
Isolation gives failures a scope
The design uses Proxmox to separate management, game execution, and persistence. The Panel has its own VM, management databases and Redis have another, and Minecraft plugin persistence is separate again. A Game Node VM runs the proxy and Paper containers. The panel product remains a client choice; Wings supplies node management when Pterodactyl or a compatible panel is selected.
Separating persistence reflects different responsibilities. A plugin workload should not consume the database resources that administrators need to diagnose it. The game node and Minecraft database VM therefore need enforceable budgets, while management retains viable capacity.
There is a cost: guest overhead, more access paths, and more dependencies to reconstruct. On one physical host, every VM still shares hardware, storage, power, and networking. A host failure removes all of them. VM isolation limits interference; recoverability also requires complete reconstruction material and usable data. Keeping service available through that failure would require capabilities beyond this baseline.
Even control-plane independence is conditional. Existing game containers are expected to continue during a Panel failure, but a Wings restart retrieves configuration from the Panel. An already running service and a restarting service have different dependencies. That expectation needs testing with the chosen versions before becoming an operational claim.
Capacity starts with the remainder
The reference profiles span 32 GB with six physical cores, 64 GB with six or eight, and 128 GB with eight, twelve, or sixteen. They share baseline allowances rather than prescribed player counts.
On the 32 GB profile, a 1–2 GB Velocity container, a 4 GB lobby, and two 8 GB gamemodes consume 21–22 GB. The remaining 10–11 GB must accommodate Proxmox, guest systems, management, databases, storage cache, and headroom. It is already spoken for before considering another game server.
Increasing both gamemodes to 10 GB leaves only 6–7 GB for that infrastructure. Adding the optional 6 GB testing and 8 GB builds servers to the original baseline would consume 35–36 GB in game containers alone. Those workloads need another placement, a larger host, or fewer simultaneous services.
These are container limits, not Java heap settings. Heap must leave room for non-heap and other process memory. Container totals must also fit inside the Game Node VM, and simultaneous VM maxima must fit physical RAM with host overhead. Swap does not repair the budget.
CPU allowances need similar interpretation. Under the documented quota convention, 100% represents one logical CPU’s worth of time. The baseline totals 750–1000%, but those are ceilings rather than reserved cores. Physical cores, logical threads, and VM allocation remain separate facts; SMT does not double processing power, and a 300% allowance cannot accelerate one busy game thread threefold.
Larger memory profiles therefore require independent CPU and storage assessment. VM CPU caps and scheduling weights can contain contention, while per-disk I/O limits constrain particular disks. Neither establishes an aggregate storage guarantee, and guest throttles may miss host backup traffic. Combined gameplay, database, and backup load must demonstrate both acceptable ticks and responsive management.
Reachability and authority are separate boundaries
Players enter through public Velocity endpoints. Paper backends, databases, Proxmox, and node management remain private. Staff reach the Panel and authorized node endpoints through a restricted management tunnel, then use application accounts and permissions. Tunnel membership does not imply SSH or hypervisor access.
Pterodactyl adds a practical detail: console WebSockets and uploads connect from the staff browser directly to Wings. Connecting only the Panel to the nodes leaves that browser path incomplete. Private DNS, trusted HTTPS, and narrowly scoped reachability must work from authorized staff devices too.
Modern Velocity forwarding authenticates forwarded player identity with a shared secret. It does not encrypt gameplay traffic or replace backend ingress restrictions. The permitted proxy path and forwarding credentials must both be enforced. Loopback also belongs to a particular container or VM; it is only a useful binding when the intended proxy can reach it.
The security boundary has to survive Docker port publishing, bridges, and both IPv4 and IPv6. A private hostname is not enforcement. Acceptance needs legitimate proxy joins alongside rejected direct connections and invalid forwarding credentials, including attempts from unauthorized tunnel devices. An independent provider-console route remains necessary when private administration itself fails.
The recovery unit follows shared state
VM boundaries describe execution. Recovery boundaries describe which facts can be restored together without contradicting one another.
Consider a hypothetical plugin purchase that changes both a player’s world-backed inventory and a database balance. Capturing the world before the purchase and the database after it could restore the debit without the item. Reversing the mismatch could preserve the item without its cost. Both captures might be internally valid. The failure is in their relationship.
This is why the design groups services by shared persistent state, including asynchronous workers and consumers on other nodes. An individual game server is not automatically an independent recovery unit. Conversely, two services using the same database host need not share application state.
Restore granularity is decisive. If restoring one group’s database point would roll back unrelated groups, their proposed independence is insufficient. Either restoration must safely isolate the required data or the recovery group must expand. Moving a service to another node changes placement without necessarily changing this dependency.
The useful question is therefore: which writers must agree on a recoverable boundary? Counting VMs does not answer it.
Two strategies, one consistency requirement
The nightly design supports coordinated maintenance and validated low-interruption capture. Either can establish application-consistent state. Online capture is not inherently a weaker backup; its guarantees depend on the application and capture method.
With coordinated maintenance, every writer in the affected group stops or quiesces, including background workers. Pending writes drain, worlds and plugin state flush, and matching database state is captured while the group remains fixed. The database need not shut down if a supported online method can preserve the required boundary.
The interruption is explicit, but it makes the coordination obligation easier to inspect. Stopping one Paper server is insufficient if another node or worker still mutates shared data. Stopping Velocity prevents player entry; it does not serve as a write barrier for every plugin or database consumer.
Low-interruption capture tries to shorten that pause. A supported mutation barrier drains outstanding work and secures a stable world snapshot plus a matching database snapshot or recovery boundary. Only then can writes resume. Database preparation or required logs remain part of preserving that boundary while export continues.
A backup job’s start and finish timestamps do not prove this relationship. Nor does a world save, filesystem snapshot, or VM freeze independently coordinate all application state. For example, a MariaDB transactional dump depends on compatible tables and protection from conflicting schema changes; a physical backup needs its supported preparation. Either can preserve database consistency without coordinating Minecraft worlds.
The important optimization is separating capture from transfer. Once stable sources preserve every required member, archive work and remote replication can continue after gameplay resumes. Resuming against an unfinished copy of changing originals would discard that safety. Encrypted staging capacity and the mechanism that preserves the sources are therefore prerequisites, not incidental storage details.
Proven independent groups can stagger their boundaries and leave unaffected gameplay available. Shared-state consumers must participate together. If coordination cannot be established, the design falls back to stopping the affected group; it preserves the last valid point rather than treating a newer archive as equivalent.
Classifying what a backup actually proves
The reference distinguishes three useful claims. A coordinated set has a demonstrated common application boundary across dependent members. Independently consistent groups can each have valid boundaries at different times. A noncoordinated collection lacks proven cross-state agreement, even if its individual captures are valid.
That distinction affects restoration. Linked worlds and databases return together from their coordinated set. Independent groups may use different points, but those points should not be advertised as one globally synchronized backup. Crash consistency is a separate property of the capture method.
The weekly complete capture retains an approximately thirty-minute maintenance target, including the broader reconstruction scope. That is neither a measured duration nor a recovery promise. Actual shutdown, database capture, and storage behavior decide whether it is feasible; asynchronous export helps only when stable capture sources exist.
Four destinations must support reconstruction
The proposed destinations are a provider off-site service, encrypted object storage, separate local HDDs, and an owner-controlled off-site setup. They offer different recovery routes: local disks favor access speed, while remote and owner-held copies address failures that remove production access. Local disks still share site risk; provider storage still depends on provider capabilities and account recovery.
Each destination is intended to support reconstruction independently. That requires complete data and manifests, retained incremental dependencies where applicable, compatible tools, and independently obtainable credentials and keys. A provider image that omits another host or required volume is a coverage gap. Temporary production snapshots do not supply another independent destination.
The weekly retention target is seven complete points, with a documented two-to-five-point alternative when capacity constrains it, while protecting a known-good point. Nightly retention is a separate project decision. Pruning must preserve the dependencies of retained points and wait for verified completeness.
Encryption covers all destinations, staging, restore scratch space, and network transfers. Keys need a recovery route outside the failed host, including account-recovery dependencies. Keeping the only key inside its own encrypted backup makes intact data unusable. Encryption also cannot prevent deletion: separate write, restore, and deletion privileges, plus immutability where available, address another failure mode.
An off-site recovery point becomes usable only after complete receipt and validation. An upload in progress cannot meet a site-loss objective.
A running process is incomplete evidence
Monitoring belongs outside the production host, preferably outside its site or provider. Public checks assess player reachability; restricted private checks assess management and internal services. That separation helps distinguish a tunnel failure from a gameplay outage, while an independent heartbeat checks the monitor itself.
Uptime Kuma or an equivalent endpoint monitor supplies useful signals, but an open port, server-list response, or running container does not prove playable service. Readiness includes authentication, routing, world access, and required plugin reads and writes. A healthy proxy cannot certify every advertised gamemode.
Tick timing, GC pauses, process memory, database pool pressure, query latency, and storage errors help explain degradation. For a standard 20 TPS server, 50 ms is the average tick budget, not a universal alert threshold. Thresholds need actual workload baselines and useful responder actions. Zero players alone is not an outage.
Backup health also needs usable-point age, group coordination, destination receipt, and key access. Coordination failure threatens recoverability without necessarily interrupting gameplay. During rolling maintenance, suppression applies only to expected checks for the affected group and expires; unaffected gameplay and unexpected failures remain visible.
Recovery objectives include people and access
Incident handling needs diagnosis before data replacement. A Panel outage, lost tunnel, saturated disk, and corrupted world have different recovery paths. The design calls for preserving evidence, attempting safe ordinary recovery where supported, and selecting a known-good point when restoration is necessary. Suspected compromise or ongoing corruption requires containment and a clean target.
Recovery Point Objective describes tolerated loss in time. Its evidence comes from the data boundary of the latest usable, sufficiently consistent point available for that failure scenario. Nightly scheduling alone cannot guarantee a 24-hour RPO: missed captures, replication lag, or corruption can push the usable boundary further back.
Recovery Time Objective runs from disruption to validated restoration of the agreed service. Detection, notification, operator availability, replacement capacity, access, transfer, and application checks all contribute. A timed restore exercise measures only the dependencies it actually exercises.
Those targets need an owner’s acceptance and explicit responsibilities. The operator handles agreed diagnosis and recovery; the owner sets priorities and accepted loss, retains independent recovery access, and authorizes decisions outside operator scope. Provider obligations and application defects remain separate support boundaries. Continuous monitoring does not imply continuous staffing, and alert delivery is not human acknowledgment. This baseline assumes neither 24/7 support nor guaranteed recovery times.
Isolated restore tests must ultimately exercise database behavior and representative gameplay from each destination, including an owner-led recovery path. Production writes and outward integrations must stay blocked during those tests. Checksums can establish integrity; they cannot demonstrate a functioning service.
The design’s central distinction remains the same at every layer: an isolated VM limits interference, a recoverable service can be reconstructed, and a consistent recovery point preserves agreement between dependent state. Each requires its own evidence. Until capture and isolated restoration have been demonstrated on the selected deployment, the architecture defines those obligations rather than proving they have been met.
Illustration disclosure: The diagrams in this article were AI-generated. The architecture and technical explanations were designed by me. I can do software. I can't do art.