This guide explains how Vorliq production backups work, how to verify them, and how to restore a node on a fresh Ubuntu server without guessing.
Vorliq server backups do not contain private wallet keys. Private keys are created for users and must be saved by users locally. If a user loses a private key, it cannot be recovered from the server, the blockchain data folder, the backup archive, GitHub, or the Vorliq team.
Server recovery restores the public Vorliq node: the blockchain data folder, public transactions, forum content, lending records, exchange offers, governance data, treasury data, price signals, achievements, and safe operational logs. It does not restore a user's private wallet key.
Wallet recovery depends on the user's own backup. A user can recover a wallet only if they still have the private key or an encrypted wallet backup plus the password for that backup. The production server backup cannot recreate a lost private key, cannot reveal a wallet password, and cannot move VLQ from a wallet whose key has been lost.
The backup archive contains the complete /home/vorliq/app/blockchain/data folder. This is the critical node state folder used by the Python blockchain API. It includes the saved chain, pending transactions, peer list, node registry, lending records, exchange offers, governance proposals and settings, treasury proposals, price signals, forum posts, achievements, and operational blockchain logs when those files exist.
The backup also includes safe backend log files from /home/vorliq/app/backend/data. It does not include .env files, private keys, SSH keys, node_modules, frontend build artifacts, dependency caches, or unrelated large files.
Production backups are written to /home/vorliq/backups on the server. Archive names follow the exact format vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz. Each successful backup also writes a contents listing next to the archive and appends a line to /home/vorliq/backups/backup.log.
The production cron job runs /home/vorliq/backup.sh daily at 02:15 server time. The script keeps the last 14 days of backup archives and deletes older backup archives after a new backup has been created and verified.
Before restoring, verify that the archive opens cleanly and that every critical JSON file inside the backup is valid JSON. This command does not modify live data.
sudo /home/vorliq/app/deployment/verify_backup.sh /home/vorliq/backups/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gzUse these commands on a new Ubuntu server after pointing DNS or firewall rules as needed. They install Vorliq, configure the system services, copy a backup archive into place, verify it, dry-run the restore, and then perform the restore.
sudo apt-get update -y
sudo apt-get install -y git
git clone https://github.com/vorliq/Vorliq.git /tmp/Vorliq
cd /tmp/Vorliq
sudo bash deployment/setup_server.sh
sudo bash /home/vorliq/app/deployment/configure_server.sh
sudo mkdir -p /home/vorliq/backups
sudo cp /tmp/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz /home/vorliq/backups/
sudo bash /home/vorliq/app/deployment/verify_backup.sh /home/vorliq/backups/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz
sudo bash /home/vorliq/app/deployment/restore_backup.sh /home/vorliq/backups/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz --dry-run
sudo bash /home/vorliq/app/deployment/restore_backup.sh /home/vorliq/backups/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz
curl -fsS http://localhost:5000/api/health
curl -fsS http://localhost:5000/api/diagnosticsA live restore stops the blockchain API, backend API, and heartbeat services. The restore script creates a safety copy of the current blockchain/data folder before replacing it. If health checks fail after restart, keep the safety copy and investigate before deleting anything.
Start by preserving the newest backup archive from /home/vorliq/backups. If the old server is still reachable, copy the newest archive off the server with scp. If the server is gone, restore from the external copy or snapshot that contains the same backup folder. Bring up a clean Ubuntu server, install Vorliq from GitHub, verify the archive, run the restore script in dry-run mode, then perform the live restore only after verification passes.