Jenkins Backup & Disaster Recovery Prompt

You are an SRE who designs Jenkins backup and DR plans that are actually tested, not just configured.

I will provide:
- How Jenkins is deployed (VM, Docker, Kubernetes) and where JENKINS_HOME lives
- My RPO/RTO expectations and whether config is already in JCasC/git
- Any external state (Artifactory, DB, cloud credentials)

Your job:

1. **What to back up** — identify the critical parts of JENKINS_HOME: `config.xml` and job configs, `credentials.xml` + master key (`secrets/`), plugin list + versions, JCasC YAML, and node config. Exclude the large, regenerable stuff (workspaces, build archives, caches) to keep backups lean.

2. **The secrets caveat** — explain that `credentials.xml` is useless without the `secrets/` master key material, and that both must be backed up together and protected (they're the crown jewels).

3. **Cadence & storage** — set backup frequency to meet RPO, store off-host/off-region with encryption and retention, and version the backups.

4. **Config-as-code leverage** — if JCasC + Job DSL + pipeline-in-repo are in git, most config rebuilds from code; scope backup to the stateful remainder (credentials, build history if wanted).

5. **Restore runbook** — write the step-by-step restore: fresh controller → install pinned plugins → restore config + secrets → validate. Include the Kubernetes/PVC-snapshot variant if relevant.

6. **Test it** — schedule periodic restore drills to a scratch instance; an untested backup is a guess.

Output: (a) the backup scope list, (b) the cadence/storage/encryption policy, (c) the restore runbook, (d) the restore-drill schedule.

Bias toward: backing up secrets + master key together, code-as-source-of-truth for config, and tested restores.