The archive at /DataHDD500G1/backup/dump/vzdump-lxc-161-2026_08_13-21_11_34.tar.zst is 6,479,585,133 bytes. It was produced 97 seconds before I started the drill, by the live snapshot backup of CT 161 gamelab — the DayZ box, a 60 GB rootfs on LVM-thin, of which 9.7 GiB was actually written. The backup run is documented in the piece that produced this archive. A file on disk proves nothing about a disaster recovery plan. A backup is a hypothesis until it is restored. So I restored it onto a fresh container and timed every stage.
A disaster recovery plan is a restore with a clock
CT 161 is still running. That is the first real obstacle a disaster recovery plan has to name, and most templates skip it. The archive carries /etc/hostname, the hostname gamelab, and the network configuration, including net0 at 10.0.0.161. Restoring it as-is onto the same network would have put a second machine on a live address. The restore therefore overrode both the identity and the address:
pct restore 141 /DataHDD500G1/backup/dump/vzdump-lxc-161-2026_08_13-21_11_34.tar.zst \
--hostname gamelab-restored --storage local-lvm \
--net0 name=eth0,bridge=vmbr0,ip=10.0.0.141/24,gw=10.0.0.1,type=veth --unprivileged 1House convention on this fleet is CTID == the last octet of the IP, so restoring to 10.0.0.141 dictated CTID 141. vzdump’s own output confirmed the override landed: merging backed-up and given configuration..
I bracketed the restore with date +%s. It started at 2026-08-13T21:14:29-07:00 and finished at 2026-08-13T21:15:28-07:00. That is 59 seconds.
Total bytes read: 10341632000 (9.7GiB, 184MiB/s) — the restore read at 184 MiB/s, against 104 MiB/s for the backup that produced it. Restoring was faster than backing up.
Boot and identity check
pct start 141, then I polled systemctl is-system-running until it reported running or degraded. Six seconds.
Total: 65 seconds from archive on disk to a booted machine. Backup 97 s + restore 59 s + boot 6 s.
A booted container is not the same as the original machine. I ran the same checks on the restored box and the live original:
| check | CT 161 gamelab | CT 141 gamelab-restored |
|---|---|---|
hostname | gamelab | gamelab-restored |
stat -c %s serverfiles/DayZServer | 35,606,192 | 35,606,192 |
files in ~/.local/share/DayZ/ | 42 | 42 |
du -sh serverfiles | 3.8G | 3.8G |
The server binary is byte-identical, the profile directory holds the same 42 files, and the game directory is the same size. Only the hostname differs, because it was deliberately overridden.
The restored box reported in without being asked
CT 161 had already been configured to ship its logs to the central collector at 10.0.0.140. That configuration was inside the archive, so the restored container started forwarding on its own, with no intervention, and appeared on the collector as a second host directory.
Before the restore the collector held one directory, gamelab. After, it held two:
gamelab
gamelab-restored/var/log/remote/gamelab-restored/ filled with the restored box’s own estate:
dayz-rpt.log12,199,184 Bdayz-console.log3,720,494 Bdayz-crash.log98,065 Bdayz-script.log538 Bsystemd.log9,040 Bsystemd-networkd.log834 Bpostfix.log616 Brsyslogd.log555 Bcron.log172 Bsshd.log86 Bsystemd-logind.log80 Brestore-drill.log84 B
Nobody configured any of that after the restore. It came back with the machine.
What this disaster recovery plan did not test
- The game server was not started on the restored box. The files were verified; the process was not run. DayZ holds roughly 4.7 GB at zero players and running two copies was not worth it. So this measures recovery of the machine, not of the service.
- The archive was 97 seconds old and on a local CIFS-backed store. It does not test an offsite copy, a corrupted archive, or a restore onto different hardware.
- The original was never actually lost. A drill where the source still exists is easier than the real thing in one specific way: nobody was under pressure.
So the measured recovery time for the machine is 65 seconds. It is not an RTO for DayZ, and I am not going to pretend otherwise.
