Backup and Disaster Recovery for .onion Hidden Services

The HiddenServiceDir directory (configured in torrc) contains hs_ed25519_secret_key and hs_ed25519_public_key files that are the cryptographic identity of your .onion service. Losing these files means losing the .onion address permanently - a new key generates a completely different address. Back up these files immediately after initial service creation. Store the backup in at least two separate locations: an encrypted external drive kept offline and an encrypted file in secure cloud storage (encrypted client-side before upload with GPG). Set restrictive permissions (chmod 700) on the HiddenServiceDir and back up the entire directory to preserve hostname and authorized_clients directories if present.

Automated database backups should run at a minimum daily, preferably hourly for active services. PostgreSQL: use pg_dump for logical backups (pg_dump -Fc database_name > backup.pgc) that are portable and restorable on different versions. Use pg_basebackup for physical backups combined with WAL archiving for point-in-time recovery. MySQL/MariaDB: mysqldump for logical backups, Percona XtraBackup for hot physical backups. Encrypt backup files before transfer (gpg --symmetric or asymmetric encryption) and upload to off-server storage. For .onion services handling sensitive data (where backup storage is also sensitive), encrypt backups and store encrypted copies in privacy-respecting cloud storage or dedicated backup servers. Test restoration quarterly by performing actual restoration to a test environment.

Backups must survive ransomware attacks that could encrypt or delete production data. Implement immutable or write-once backup storage: S3-compatible object storage with Object Lock (prevents deletion for a defined retention period), dedicated backup servers with separate SSH keys and restricted permissions (rsync-only, no shell access, SFTP only), and offline copies on encrypted drives physically stored off-site. The 3-2-1 backup rule: 3 copies, 2 different media types, 1 off-site. For an .onion service handling sensitive user data, the off-site copy should be stored with the same privacy considerations as production: jurisdictionally appropriate storage, encrypted with keys not stored alongside the backup.

Define Recovery Time Objective (RTO - maximum acceptable downtime) and Recovery Point Objective (RPO - maximum acceptable data loss) before an incident occurs. For most .onion services, RTO of 4-8 hours and RPO of 24 hours is achievable with standard backup practices. Document the complete restoration procedure step-by-step: server provisioning, OS configuration, application deployment, database restoration, and critical: restoring the hs_ed25519_secret_key files to restore the original .onion address. Without the key restoration step, a recovered server will have a completely different .onion address. Test the recovery procedure annually against a clean test environment to verify documentation accuracy and actual recovery capability.

For zero-downtime operation, OnionBalance provides active-active redundancy across multiple backend servers. Each backend has a unique .onion address; OnionBalance advertises a single master .onion address whose introduction points spread across all backends. If one backend fails, its introduction points become unreachable but other backends continue serving. This provides hot standby without manual failover for single-server failures. Configure OnionBalance with at least three backends to maintain service if one fails and another requires maintenance simultaneously. Combine OnionBalance with per-backend database replication (PostgreSQL streaming replication) to maintain data consistency across the cluster.