Backup, Recovery, and High Availability
What must be backed up
A complete backup covers MongoDB (users, permissions, workflows, schedules, metadata), the Alteryx Service database (execution/queue state), the data directories (workflow files, outputs), and configuration (System Settings, SSL certs, credential store keys). Missing any one piece yields a partial restore: restoring MongoDB without the credential store key means encrypted credentials are unreadable.
Recovery strategy
Know the difference between RPO (how much data you can lose) and RTO (how fast you must be back). Backup frequency is driven by RPO; restore procedures and testing drive RTO. A backup you have never restored is a hypothesis, not a backup - test restores regularly.
High availability
HA reduces downtime via redundancy: multiple Gallery nodes behind a load balancer, a MongoDB replica set, and multiple workers so one failure doesn't halt scheduling. Understand that HA is not backup - replication protects against node failure, not against accidental deletion or corruption, which replicates too.
Traps
Classic traps: treating a MongoDB replica set as a backup (it isn't); forgetting the credential encryption key so restored credentials fail; and assuming workers need individual backups (they're stateless - the controller/MongoDB hold state). Also watch for restoring MongoDB to a different version than the service expects.
Worked example
Your RPO is 1 hour. That means MongoDB snapshots at least hourly plus continuous capture of data directories, and a documented restore that you rehearse quarterly. If you only snapshot nightly, your real RPO is 24 hours - a mismatch to fix.
Rule of thumb
Back up MongoDB, the service DB, data directories, and the credential key together. Replication ≠ backup; test the restore.