{"slug": "cli-disaster-recovery-backup-restore-and-inspect-commands-for-self-hosted", "title": "CLI Disaster Recovery: backup, restore, and inspect Commands for Self-Hosted Wallets", "summary": "WAIaaS has introduced a CLI disaster recovery workflow for self-hosted wallets, featuring backup create, backup inspect, and backup list commands. The tool enables operators running their own wallet infrastructure to snapshot wallet state, verify backup contents, and restore data, addressing the risk of permanent loss from drive failures or misconfigured Docker volumes.", "body_md": "Backing up a self-hosted wallet is one of those tasks that feels optional right up until the moment it isn't — and for AI agents managing real funds on your own server, a failed drive or a misconfigured Docker volume can mean permanent loss. WAIaaS ships a built-in CLI disaster recovery workflow with `backup create`\n\n, `backup inspect`\n\n, and `backup list`\n\ncommands designed specifically for operators who have chosen to run their own wallet infrastructure rather than hand keys to a third party.\n\nWhen you use a hosted wallet service, the provider handles backups, redundancy, and key recovery. You trade control for convenience. But if you're running WAIaaS on your own hardware or VPS — your keys, your server, your rules — the responsibility for data durability sits entirely with you.\n\nThat's not a downside. It's the whole point. You get no API rate limits from an external service, no terms-of-service changes that could freeze your agent's funds overnight, and no third-party ever touches your private keys. The crypto equivalent of running your own email server — except WAIaaS is actually practical to operate. The tradeoff is that operational discipline matters more. A self-hosted wallet with no backup strategy is one bad `docker compose down -v`\n\naway from disaster. The CLI makes that discipline easy to maintain.\n\nWAIaaS CLI includes 20 commands (fact CLI-01). Three of them form the complete disaster recovery workflow:\n\n`backup create`\n\n`backup list`\n\n`backup inspect`\n\n`restore`\n\nLet's walk through each one in context.\n\nBefore you can back anything up, you need a running WAIaaS daemon. If you haven't set one up yet, the fastest path is:\n\n```\nnpm install -g @waiaas/cli\nwaiaas init --auto-provision     # Generates random master password → recovery.key\nwaiaas start                     # No password prompt\nwaiaas quickset                  # Creates wallets + sessions automatically\n```\n\nOr via Docker, which many self-hosters prefer since it keeps the process isolated and restartable:\n\n```\ngit clone https://github.com/minhoyoo-iotrust/WAIaaS.git\ncd WAIaaS\ndocker compose up -d\n```\n\nWith the daemon running on `127.0.0.1:3100`\n\n(fact DOCKER-02), you now have wallet data worth protecting.\n\nThe `backup create`\n\ncommand snapshots your current wallet state. Run it after any significant configuration change — new wallets, updated policies, or new session tokens issued to agents.\n\n```\nwaiaas backup create\n```\n\nThat's the whole command. WAIaaS handles the rest: serializing wallet keys, policy configurations, session metadata, and anything else needed to reconstruct a working instance. The result is a timestamped archive stored in your data directory.\n\nFor Docker deployments, wallet data lives in the named volume defined in `docker-compose.yml`\n\n:\n\n```\nvolumes:\n  waiaas-data:\n    driver: local\n```\n\nThis means your backups persist across container restarts and even across image upgrades — `docker compose down`\n\n(without `-v`\n\n) leaves your data intact. But the volume is still on a single host. A good backup strategy copies that archive off-box.\n\nA practical routine for a homelab setup:\n\n```\n# Create a backup\nwaiaas backup create\n\n# Then copy the latest backup file off-box\n# (rsync, rclone, S3, whatever fits your setup)\n```\n\nThe specific destination is yours to choose — WAIaaS creates the archive, you own the transport layer.\n\nHere's the part most operators skip: verifying that a backup is actually usable before you need it. `backup inspect`\n\nlets you examine the contents of a backup file without restoring it.\n\n```\nwaiaas backup inspect\n```\n\nThis is useful in two scenarios. First, as part of a regular health check — run it weekly to confirm your backups contain the wallet IDs and configuration you expect. Second, before a restore — when you're recovering from an incident, you want to confirm you're restoring the right snapshot, not an old one that's missing recently created wallets.\n\nThe inspect command gives you visibility into what's inside the archive: which wallets are included, timestamps, and structural integrity. Think of it as `tar -tvf`\n\nfor your wallet infrastructure.\n\nWhen you need to choose between multiple restore points, `backup list`\n\nshows you what's available:\n\n```\nwaiaas backup list\n```\n\nThis is particularly useful if you've automated backup creation (a cron job or a post-deploy hook, for example) and have accumulated multiple snapshots. You can identify the most recent clean backup, compare timestamps against when you last made a configuration change, and pick the right restore point before committing.\n\nWhen the moment comes — hardware failure, accidental `docker compose down -v`\n\n, a botched config migration — `restore`\n\ngets you back:\n\n```\nwaiaas restore\n```\n\nThe restore command reconstructs your wallet state from the backup archive. After restore, you'll want to verify the daemon is healthy:\n\n```\nwaiaas status\n```\n\nAnd if you're running Docker, confirm the health check passes:\n\n```\ndocker compose logs -f\n```\n\nThe Docker Compose configuration includes a built-in health check (fact FEAT-DOCKER):\n\n```\nhealthcheck:\n  test: [\"CMD\", \"curl\", \"-f\", \"http://localhost:3100/health\"]\n  interval: 30s\n  timeout: 5s\n  start_period: 10s\n  retries: 3\n```\n\nOnce the daemon is healthy again, your AI agents can reconnect using their existing session tokens — nothing on the agent side needs to change.\n\nFor production self-hosted deployments, WAIaaS supports Docker Secrets via a secrets overlay file (fact DOCKER-04). This keeps your master password out of environment variables and shell history:\n\n```\n# Create secret files\nmkdir -p secrets\necho \"your-secure-password\" > secrets/master_password.txt\nchmod 600 secrets/master_password.txt\n\n# Deploy with secrets overlay\ndocker compose -f docker-compose.yml -f docker-compose.secrets.yml up -d\n```\n\nThe entrypoint also supports `WAIAAS_AUTO_PROVISION`\n\nfor headless first-run scenarios (fact DOCKER-03):\n\n```\ndocker run -d \\\n  --name waiaas \\\n  -p 127.0.0.1:3100:3100 \\\n  -v waiaas-data:/data \\\n  -e WAIAAS_AUTO_PROVISION=true \\\n  ghcr.io/minhoyoo-iotrust/waiaas:latest\n\n# Retrieve auto-generated master password\ndocker exec waiaas cat /data/recovery.key\n```\n\n`recovery.key`\n\nis the credential you absolutely need to include in your backup strategy. Back it up separately from the wallet data archive, stored in a different physical location. If you lose the wallet archive, you can rebuild. If you lose the master password, you cannot.\n\nOnce you've manually set a hardened password, delete `recovery.key`\n\n:\n\n```\nwaiaas set-master\n# Then: rm /data/recovery.key (or equivalent path)\n```\n\nHere's a concrete routine that covers the fundamentals without overcomplicating things:\n\n**Step 1: Initial setup with auto-provision**\n\n```\nwaiaas init --auto-provision\nwaiaas start\nwaiaas quickset\n```\n\n**Step 2: Create your first backup immediately after setup**\n\n```\nwaiaas backup create\n```\n\n**Step 3: Inspect it to confirm it's good**\n\n```\nwaiaas backup inspect\n```\n\n**Step 4: Copy it somewhere else.** Your NAS, an encrypted S3 bucket, a USB drive kept offline — anywhere that isn't the same disk. WAIaaS creates the archive; you handle the transport.\n\n**Step 5: Set a calendar reminder** to run `backup create`\n\n+ `backup inspect`\n\nafter any significant change to wallets or policies, and on a regular schedule regardless.\n\nThat's it. Five steps, most of which take seconds. The goal isn't a perfect enterprise DR strategy — it's not losing months of wallet configuration and key material because you forgot to plan ahead.\n\nHosted services abstract away backup and recovery entirely. That's convenient, but it means you're dependent on the provider's infrastructure, their uptime, their policies, and their continued existence. Self-hosting with WAIaaS means none of those dependencies apply — but it also means the CLI is your primary operational interface, and these three commands are genuinely critical.\n\nThe WAIaaS CLI has 20 commands total (fact CLI-01), covering everything from daemon management (`start`\n\n, `stop`\n\n, `status`\n\n) to wallet operations (`wallet create`\n\n, `wallet info`\n\n) to the MCP integration setup (`mcp setup`\n\n) that connects your wallets to AI agents. Backup and restore are first-class citizens in that list — not afterthoughts.\n\nCombined with the 683+ test files across the codebase (fact TEST-01) and a 7-stage transaction pipeline with validation built in (fact PIPE-01), WAIaaS is built with the kind of operational rigor that makes self-hosting viable rather than heroic.\n\nIf you're running a self-hosted WAIaaS instance, the next logical step is locking down what your AI agents can actually do with those wallets. The policy engine supports 21 policy types across 4 security tiers (fact POLICY-01, POLICY-02) — from simple spending limits to DeFi-specific controls like `PERP_MAX_LEVERAGE`\n\nand `LENDING_LTV_LIMIT`\n\n. Combine solid backup hygiene with a well-configured policy set, and you have wallet infrastructure that's both recoverable and defensible.\n\nExplore the full source code and documentation at [github.com/minhoyoo-iotrust/WAIaaS](https://github.com/minhoyoo-iotrust/WAIaaS), or visit [waiaas.ai](https://waiaas.ai) to learn more about what the platform can do.", "url": "https://wpnews.pro/news/cli-disaster-recovery-backup-restore-and-inspect-commands-for-self-hosted", "canonical_source": "https://dev.to/walletguy/cli-disaster-recovery-backup-restore-and-inspect-commands-for-self-hosted-wallets-1c9f", "published_at": "2026-06-18 10:50:37+00:00", "updated_at": "2026-06-18 10:51:12.334846+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents"], "entities": ["WAIaaS", "CLI", "Docker"], "alternates": {"html": "https://wpnews.pro/news/cli-disaster-recovery-backup-restore-and-inspect-commands-for-self-hosted", "markdown": "https://wpnews.pro/news/cli-disaster-recovery-backup-restore-and-inspect-commands-for-self-hosted.md", "text": "https://wpnews.pro/news/cli-disaster-recovery-backup-restore-and-inspect-commands-for-self-hosted.txt", "jsonld": "https://wpnews.pro/news/cli-disaster-recovery-backup-restore-and-inspect-commands-for-self-hosted.jsonld"}}