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, peer community request records, governance data, treasury data, price signals, achievements, and safe operational metadata. 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 node data folder, for example /path/to/vorliq/blockchain/data. 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, peer community request records, governance proposals and settings, treasury proposals, price signals, forum posts, achievements, and safe operational metadata when those files exist.
The backup also includes protected JSON and safe diagnostic summaries from a backend data folder such as /path/to/vorliq/backend/data. Useful .bak files are included so a recent pre-write copy is available during investigation. It does not include .env files, private keys, SSH keys, node_modules, frontend build artifacts, dependency caches, or unrelated large files.
The public signed snapshot archive is not a backup replacement. It is a transparency aid for comparing recent signed public state. Use node tools/verify_snapshot_archive.js https://vorliq.org, node tools/bootstrap_verify_node.js https://vorliq.org, and the dry-run command in Verified Chain Bootstrap during recovery checks, but restore node state only from verified backups or intentionally chosen known-good chain data.
Vorliq JSON state is written with backup-before-write protection, temporary files in the same directory, fsync, atomic replace, and lightweight write locks. This reduces the chance that a server crash or interrupted write leaves partial JSON as the main state file.
If a main JSON file is malformed but its .bak file is valid, Vorliq restores the backup and preserves the malformed file with a timestamped .corrupt suffix. If chain.json is corrupt and no valid backup exists, Vorliq reports a critical storage error instead of silently creating a fresh chain.
Production backups are written to a protected backup directory such as /path/to/vorliq/backups. Archive names follow the example format vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz. Each successful backup can write a redacted contents summary next to the archive and append an example-log-entry to a private backup log.
The production cron job runs the backup script on a regular schedule. 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 and useful .bak file inside the backup is valid JSON. This command does not modify live data.
sudo /path/to/vorliq/deployment/verify_backup.sh /path/to/vorliq/backups/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gzRecovery and migration are separate operations. Before any future SQLite or Postgres adapter cutover, run the migration dry-run against the restored JSON data and keep rollback to JSON available.
python tools/migration_dry_run.py --output migration-dry-run-report.jsonThe dry run never creates a database and never rewrites chain.json, pending.json, or indexes.json.
The public storage health endpoint returns safe metadata only: file names, JSON validity, backup availability, sizes, timestamps, and warning/error counts. It does not expose full server paths, private keys, wallet passwords, admin tokens, or raw file contents.
curl -fsS https://vorliq.org/api/storage/health
curl -fsS https://vorliq.org/api/system/self-checkUse 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 /path/to/vorliq/deployment/configure_server.sh
sudo mkdir -p /path/to/vorliq/backups
sudo cp /tmp/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz /path/to/vorliq/backups/
sudo bash /path/to/vorliq/deployment/verify_backup.sh /path/to/vorliq/backups/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz
sudo bash /path/to/vorliq/deployment/restore_backup.sh /path/to/vorliq/backups/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz --dry-run
sudo systemctl stop vorliq-backend.service vorliq-blockchain.service vorliq-heartbeat.service
sudo bash /path/to/vorliq/deployment/restore_backup.sh /path/to/vorliq/backups/vorliq-backup-YYYY-MM-DD-HHMMSS.tar.gz
curl -fsS http://localhost:5000/api/health
curl -fsS http://localhost:5000/api/diagnosticsThe restore script refuses to overwrite live data while the blockchain API, backend API, or heartbeat service is active unless an operator explicitly passes a force flag. It creates pre-restore safety copies of the current blockchain and backend data folders before replacing state. If health checks fail after restart, keep the safety copy and investigate before deleting anything.
Start by preserving the newest backup archive from the protected backup directory. If the old server is still reachable, copy the newest archive off the server with a secure file-transfer method. 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.