Backup and Disaster Recovery

Backup and Disaster Recovery

Xferity is self-hosted infrastructure. The team that deploys it is responsible for backup and recovery.

This page describes what must be backed up, what behavior to expect on recovery, and the limits of what Xferity provides.

What must be backed up

A complete backup covers all of these:

Component	What it contains	Notes
Global configuration	runtime settings	under version control ideally
Partner definitions	endpoint and trust configuration	under version control ideally
Flow definitions	transfer workflow definitions	under version control ideally
Keys and certificates	SSH keys, PGP keys, X.509 certificates	treat as secrets
State files (file backend)	history, idempotency records, lock files	local filesystem
Postgres database (Postgres backend)	all persistent state	standard Postgres backup
Audit log JSONL files	transfer evidence	separate retention policy may apply
Dead-letter files	unprocessed failed files	operational data
Application logs	runtime logs	log retention policy

Configuration under version control

Configuration files, partner definitions, and flow definitions should be stored under version control. This gives you:

• a full history of who changed what and when
• the ability to reproduce any prior configuration state
• change review before production deployment

If configuration is in version control, recovery after data loss is straightforward for the configuration layer.

File-backed runtime backups

For file-backed deployments, backup these paths:

• state/ — flow history, idempotency records, lock files
• audit/ — audit JSONL files and sidecar index
• logs/ — runtime log files
• storage/ — landing and staging paths (if they contain critical in-flight data)
• keys/ — key material

After restore:

• locks should be reviewed and cleared if necessary before resuming flows
• idempotency records should be tested against current file inventory to confirm consistency

Postgres-backed runtime backups

For Postgres-backed deployments:

Use standard Postgres backup tools:

# Consistent dump
pg_dump -Fc xferity > xferity-backup-$(date +%Y%m%d).dump

# Restore from dump
pg_restore -d xferity xferity-backup-20260315.dump

The Postgres database contains:

• flow history and job records
• session and auth data
• certificate and PGP Key inventory
• AS2 message records
• posture snapshots and suppressions
• local-vault encrypted secrets (if used)
• idempotency records

Also back up file-system paths even in Postgres mode:

• audit JSONL files (not stored in Postgres)
• application log files
• storage, key, and dead-letter paths

Audit log retention strategy

Audit logs require a separate retention strategy because:

• they grow continuously
• they may have compliance retention requirements that exceed the audit.retention_days setting
• they are append-oriented files, not database records

Plan for:

• shipping audit records to an external store (see Audit Investigation)
• separate retention and rotation policies
• export to immutable storage where compliance requires it

Recovery testing

Backup is only useful if recovery has been tested.

Minimum recovery tests:

1. restore configuration and confirm xferity validate passes
2. restore Postgres and confirm service starts and shows correct history
3. restore a key or certificate and confirm it is recognized
4. trace a known file from before the backup to confirm audit record continuity
5. run a flow once in --dry-run mode after restore to confirm it can reach endpoints

Document the RPO (recovery point objective) and RTO (recovery time objective) for your deployment before a real incident occurs.

Impact of unrecovered state

If state is not recovered or partially recovered:

File-backed mode

• flow history is lost from the backup gap forward
• idempotency records may cause previously processed files to be reprocessed
• locks from the gap period may not be present, which is usually safe

Postgres-backed mode

• job history for the gap period is lost
• sessions are invalidated and users must re-authenticate
• posture snapshot history for the gap is lost (snapshots resume from next run)
• locally encrypted vault secrets must be re-seeded or restored from backup

Disaster recovery checklist

For a full recovery scenario:

1. restore configuration from version control
2. restore state backend (Postgres dump or file-system files from backup)
3. restore keys and certificates to the expected paths
4. restore audit log files if available
5. run xferity validate to confirm configuration is intact
6. run xferity diag <critical-flow> to confirm endpoint reachability
7. review idempotency state before re-enabling scheduled flows
8. run critical flows manually once before restoring schedules
9. verify audit trace for at least one known file after recovery

What Xferity does not provide

• Xferity does not include built-in backup or snapshot features for its own state
• Xferity does not replicate state to a secondary host automatically
• Xferity does not implement HA failover
• Xferity does not guarantee that missed-run recovery produces exactly the same results as continuous operation

Backup, replication, and recovery are operational responsibilities for the team deploying Xferity.

Related pages

• Deployment
• Postgres Workers
• Audit Investigation
• Operating Xferity
• Deployment: Postgres and Workers