How do I backup the .onion key securely?

Encrypt the hs_ed25519_secret_key file with GPG symmetric encryption using a strong passphrase (gpg --symmetric --cipher-algo AES256 hs_ed25519_secret_key). Store the encrypted backup in at least three locations: encrypted USB in a physically secure location, encrypted cloud storage with separate encryption key, and optionally a paper backup (hex representation or QR code in a sealed envelope). Test recovery by decrypting the backup and verifying the restored hostname matches the original .onion address.

Should backup servers be in the same data center as the primary?

No. Backup servers in the same data center are lost if the entire data center experiences an outage (power failure, flooding, seizure). Use a different provider in a different country for offsite backups. This is especially important for hidden services where a data center seizure could compromise the primary server's .onion key - if offsite backups are encrypted and in a different jurisdiction, the key survives.

How do I verify database backup integrity without restoring to production?

Restore the backup to a separate test database: createdb testdb; pg_restore -d testdb /backup/db_latest.dump. Run application-specific integrity checks (count records, verify key tables are not empty, check for referential integrity). Drop the test database after verification: dropdb testdb. Run this monthly and after any backup system changes. Automated verification: script the restore and basic checks, report pass/fail via monitoring.

What happens to users if I do disaster recovery and restore from a 12-hour-old backup?

Users who took actions in the 12-hour gap before the backup will have their actions reversed: created accounts will not exist, posts will be gone, settings changes will be reverted. Minimize RPO for user-facing data with WAL archiving (reduces gap to minutes). Communicate outages proactively (announcement via all channels including forum posts and PGP-signed messages). For critical lost data: if you have application logs from the gap period, some data may be reconstructable manually.

How do I test disaster recovery without taking production down?

Provision a test server, restore the latest backup to it, configure a different .onion address (different key - generate a new one, do NOT use the production key on the test server), and verify the restoration process works. The test server tests everything except the actual .onion address restoration (which you verify by confirming the key file restores correctly, even if you use a test key for the actual service). Document what you learned from the test and update the runbook accordingly.

Backup and Disaster Recovery for .onion Services: 2026 Guide

A Tor hidden service is both software and a cryptographic identity. Losing either - the application data or the .onion private key - may be unrecoverable. This guide covers comprehensive backup strategies and disaster recovery procedures.

Need this done for your project?

We implement, you ship. Async, documented, done in days.

Start a Brief

What Must Be Backed Up: The Complete Inventory

Tier 1 (Irreplaceable - loss is permanent): hs_ed25519_secret_key (the .onion address private key), application-specific private keys and secrets (API keys, signing keys), database data containing user accounts and content. Tier 2 (Replaceable but time-consuming): server configuration (torrc, Nginx config, application config), database schema (reconstructable from migrations, but easier to restore), application code (should be in version control, but deployments need the specific running version). Tier 3 (Reconstructable): TLS certificates (re-issuable, but Let's Encrypt has rate limits), Tor's cached network state (rebuilds in minutes). Priority order: back up Tier 1 first, most frequently, and most securely. A complete server loss with Tier 1 backups intact is recoverable; a Tier 1 loss (especially the .onion key) is permanent.

Database Backup Strategy

PostgreSQL backup: pg_dump creates a complete database snapshot. Automated daily: pg_dump -Fc dbname > /backup/db_$(date +%Y%m%d).dump (custom format for efficiency). Retention: keep 7 daily, 4 weekly, 12 monthly. Offsite storage: encrypt and transfer to offsite storage immediately after each dump. Encryption: gpg --encrypt --recipient YOUR_KEY_FINGERPRINT /backup/db_$(date +%Y%m%d).dump. Continuous backup: pg_basebackup + WAL archiving for point-in-time recovery (PITR). Configuration in postgresql.conf: archive_mode = on, archive_command = 'gzip -c %p > /backup/wal/%f.gz'. PITR allows recovery to any point in time (not just daily snapshot times). Test restores: monthly, restore a recent backup to a test database and verify data integrity. A backup you have never tested may not work when needed.

Offsite Backup Destinations for .onion Services

Offsite backup options that maintain the privacy model: encrypted backup to a separate VPS (different provider, different jurisdiction) via rsync over SSH, encrypted backup to object storage (Backblaze B2 or similar) with client-side encryption (rclone with crypt backend encrypts before upload), and cold storage backups on encrypted physical media stored in a separate location. Privacy consideration: the backup server or storage provider should not be able to infer the nature of the service from backup content. Client-side encryption before upload ensures the storage provider sees only encrypted blobs. Backup via Tor: rsync over SSH using Tor as a SOCKS5 proxy (torify rsync or ProxyCommand in SSH config) hides the hidden service server's IP from the backup server - important if the backup and primary servers are in different trust zones.

Recovery Time Objective and Recovery Point Objective

RTO (Recovery Time Objective): how quickly must the service be restored after a disaster? For a critical hidden service: target 1-4 hours RTO. Requires: documented runbook, pre-configured warm standby server (not a blank server), tested restoration procedure, and monitoring alerts that detect outage quickly. RPO (Recovery Point Objective): how much data loss is acceptable? Daily backups = up to 24 hours of data loss. WAL archiving = up to minutes of data loss. Most hidden services can tolerate 1-24 hours RPO; mission-critical services need continuous replication. Documenting RTO/RPO: write down your targets before a disaster. Post-incident, measure actual recovery time against targets. Each incident is an opportunity to improve.

Runbook: Executing a Full Disaster Recovery

Step-by-step disaster recovery procedure: (1) Provision a new server (same or similar specifications as original). (2) Install base OS and dependencies (Tor, Nginx, PostgreSQL, application runtime). (3) Restore torrc configuration (from backup). (4) Restore hs_ed25519_secret_key to the hidden service directory (this restores the .onion address). (5) Start Tor and verify the .onion address matches (cat /var/lib/tor/hidden_service/hostname). (6) Restore database from latest backup (pg_restore -d dbname /backup/db_YYYYMMDD.dump). (7) Restore application configuration (from backup or version control). (8) Start application services and verify they connect to the database. (9) Start Nginx. (10) Verify the .onion service is accessible (test from Tor Browser). (11) Update monitoring with new server details. Practice: run through this runbook on a test server annually to identify gaps before they matter in production.

Related Services

Offshore VPS from $17.90/mo Dedicated Servers DevOps Services

Why Anubiz Host

100% async — no calls, no meetings

Delivered in days, not weeks

Full documentation included

Production-grade from day one

Security-first approach

Post-delivery support included

Bulletproof Hosting Providers

DMCA-Ignored Servers

Offshore VPS Hosting

Anonymous Hosting Solutions

Ready to get started?

Skip the research. Tell us what you need, and we'll scope it, implement it, and hand it back — fully documented and production-ready.

Start a Brief Iceland VPS III