SRS: UC_9.3 — Flow 18: Configuration Database Backup & Disaster Recovery Sync
| Field | Value |
|---|---|
| BA in Charge | linh.nguyen34 |
| Date Created | 2026-08-21 |
| Version | v1.3 |
| Last Updated | 2026-11-04 — Client sheet (Adam/Adrian): schedule fixed 02:00 UTC (no DST; all backend crons run on fixed UTC); lifecycle = S3 Standard 90 days → S3 Glacier → expire at 1,856 days (5 years + 1 month), native S3 Lifecycle Rule only. Previous: 2026-10-28 — Flow 18 spec update: schedule 02:00 AM CST (08:00 AM UTC); Object Lock mandatory (Compliance Mode); HOT/WARM/COLD lifecycle tiering + 61-month expiration; retry 3× with exponential backoff before alerting; table scope conflict closed (Tables A–F + newly added). Alerts: Slack #ops-dev only (no Freshdesk). |
| Document References | Zapier Integration V7.pdf (§Flow 18: Configuration Database Backup lines 2099–2121; §Flow 40: Zapier DR Recovery Snapshot lines 2625–2660) · RFQ_ Stack Trading Prop Tech V7.pdf (§5.0 Immutable Archival S3 Object Lock lines 3339–3357; §NFA Audit Requirements lines 3357–3362) · slack_channel_usage.md (CR-15.2 — #ops-dev) · Flow 18 spec 2026-10-28 · Open questions: UC_9.x_Client_Questions.md §Flow 18 |
UC Index
| UC_ID | Use Case Name | Business Description |
|---|---|---|
| UC_9.3 | Config DB Backup & DR Sync | Daily 02:00 UTC (fixed, no DST): export all Zapier Tables (A–F + newly added) to JSON with schema_version + SHA-256 checksum → upload to the S3 bucket shared with Flow 40 (SSE-KMS, versioning, Object Lock Compliance Mode, S3 Standard 90 days → S3 Glacier, expire at 1,856 days). Independent verification re-downloads the file, re-checks the checksum and test-parses the JSON. Backup or verification failure → retry up to 3× (exponential backoff) → Slack alert. All alerts go to Slack #ops-dev only. |
<a id="UC_9.3"></a>
UC_9.3 — Flow 18: Configuration Database Backup & Disaster Recovery Sync
1. Overview
| Field | Content |
|---|---|
| ID | UC_9.3 |
| Use Case | Config DB Backup & DR Sync |
| Description | Backs up all Zapier Table configuration data (Tables A–F plus any newly added tables) daily to an immutable S3 bucket for disaster recovery and regulatory audit. An independent verification step validates the backup's integrity. Failures are retried automatically before Ops is alerted. This flow protects the business logic layer (risk limits, pricing matrices, platform registry, email/event mappings) which is not covered by the RDS PostgreSQL Multi-AZ backup that handles trader transaction data. |
| Zapier Flow | Flow 18 (Configuration Database Backup) · Flow 40 (Zapier DR Recovery Snapshot — shares the same S3 bucket/prefix) |
| Zapier Table | Tables A–F (all active configuration tables) + any newly added tables discovered at runtime |
| 3rd Party | Zapier (table export source) · AWS S3 (backup storage — SSE-KMS, versioning, Object Lock, lifecycle tiering) · AWS KMS (encryption key management) · Slack (#ops-dev — success confirmation and failure alert) |
2. Trigger
Schedule: Scheduled cron job, daily at 02:00 UTC — fixed UTC, no Daylight Saving Time shift. All backend cron schedules across the stack run on fixed UTC.
(Source: QnA_BACKGROUND_MECHANISMS_CRON.md [BG-011] — client sheet 2026-11-04; overrides Zapier Integration V7.pdf §Flow 18 line 2101 "Daily at 02:00 AM CST")
3. Basic Flow
Step 1 — Export Zapier Tables
- Export all configuration tables: Tables A through F, plus any newly added tables discovered at runtime.
- Export format: JSON, with two mandatory metadata fields embedded in every export file:
| Metadata field | Purpose |
|---|---|
schema_version | Tracks the configuration structure version for restore compatibility checking |
checksum | SHA-256 hash of the file contents, computed at export — used to detect corruption or truncation during transfer |
(Source: Zapier Integration V7.pdf §Flow 18 lines 2102–2108)
Step 2 — Upload to S3
- Upload the JSON export to the dedicated S3 bucket.
- Naming convention:
config_backup_YYMMDD_HHMMSS.json - Shared bucket: Flow 18 uses the same S3 bucket and prefix as Flow 40 (Zapier DR Recovery Snapshot). Both flows share the same security and lifecycle configuration.
The S3 bucket MUST be configured with the following properties:
| Property | Requirement | Source |
|---|---|---|
| SSE-KMS encryption | All files encrypted at rest using AWS KMS with a company-managed key | Zapier V7 §Flow 18 |
| Bucket versioning | Enabled — multiple historical versions retained; prevents overwrite from destroying prior copies | Zapier V7 §Flow 18 |
| Object Lock (WORM) | Mandatory — Compliance Mode. Files cannot be modified or deleted within the retention window by any account, including Admin/root. | Flow 18 spec 2026-10-28 (V7 lists Object Lock as optional — see F18-02) |
| Lifecycle tiering + expiration | See table below — native S3 Lifecycle Rule on the backup prefix | Client sheet 2026-11-04 [BG-010] |
| Cross-region replication | Recommended for DR against a full-region outage | Zapier V7 §Flow 18 — see F18-05 |
Lifecycle rules (Hot / Cold):
| Tier | Object age | Storage class |
|---|---|---|
| Hot | 0–90 days (1 quarter) | S3 Standard |
| Cold | 91 days – 1,856 days | S3 Glacier |
| Expiration | After 1,856 days (5 years + 1 month) | Object deleted automatically |
- No custom weekly/monthly folder-compression scripts — the daily cron only uploads the JSON file; tiering and expiration are handled by the S3 Lifecycle Rule.
- Config backups are restoration points, not audit logs — the RFQ V7 §5.0 "2 years immediately accessible" rule (for trading archives) does not apply.
- ⚠️ The Object Lock retention period must not exceed 1,856 days, otherwise the expiration rule cannot delete the object.
(Source: Zapier Integration V7.pdf §Flow 18 lines 2109–2116; §Flow 40 line 2652; QnA_BACKGROUND_MECHANISMS_CRON.md [BG-010] — client sheet 2026-11-04)
Step 3 — Independent Backup Verification
An independent automated verification runs immediately after upload:
- Download the just-uploaded JSON file from S3.
- Recompute the SHA-256 checksum of the downloaded file and compare it with the
checksumcomputed at export.- Match → file is intact. Continue.
- Mismatch → verification failed (→ Step 4, failure path).
- Test-parse the file content against the expected JSON structure.
- Parse succeeds → verification passed. Flow ends successfully.
- Parse fails → verification failed (→ Step 4, failure path).
(Source: Zapier Integration V7.pdf §Flow 18 lines 2117–2119)
Step 4 — Failure Handling: Retry, then Alert
- If the backup (Steps 1–2) or the verification (Step 3) fails, the job retries automatically up to 3 times with exponential backoff.
- If it still fails after the 3rd retry → send a Slack alert to
#ops-devcontaining the failed step and the specific error (e.g. KMS auth failure, S3 upload timeout, checksum mismatch, JSON parse error).
| Outcome | Alert |
|---|---|
| Success | ✅ Slack confirmation: Backup complete — config_backup_YYMMDD_HHMMSS |
| Failure after 3 retries | 🚨 Slack alert with the failed step and error detail. |
Alert channel: Slack #ops-dev only — per the Slack channel registry (CR-15.2, slack_channel_usage.md): "Config DB Backup success/failure notifications". No Freshdesk ticket is created.
(Source: Zapier Integration V7.pdf §Flow 18 lines 2120–2121; CR-15.2; Flow 18 spec 2026-10-28)
4. Pre-conditions
| ID | Pre-condition |
|---|---|
| P1 | All active Zapier Tables (A–F + newly added tables) are accessible and readable via Zapier's table API. |
| P2 | The dedicated S3 bucket (shared with Flow 40) exists and is configured with SSE-KMS, versioning, Object Lock (Compliance Mode) and the lifecycle rules in Step 2. |
| P3 | AWS KMS key is active and the Zapier/Middleware IAM role has kms:GenerateDataKey and s3:PutObject permissions. |
| P4 | Slack webhook for #ops-dev is active. |
5. Post-conditions
| Outcome | Post-condition |
|---|---|
| Success | config_backup_YYMMDD_HHMMSS.json uploaded to S3 with all security properties applied; checksum and parse verified; Slack ✅ confirmation sent to #ops-dev. |
| Failure — recovered by retry | A retry succeeded; same as Success (Slack ✅ confirmation). No failure alert. |
| Failure — after 3 retries (upload error) | File not saved to S3. Slack failure alert sent with error detail. |
| Failure — after 3 retries (checksum mismatch / parse error) | File on S3 but flagged as not verified. Slack failure alert sent. File must NOT be used for restore. |
6. Exception Flows
Exc-1 — S3 upload failure (network timeout, permission denied, KMS key unavailable):
- Retry up to 3 times with exponential backoff (Step 4).
- All retries fail → backup not saved; Slack failure alert sent with error code.
Exc-2 — Checksum mismatch after upload:
- The file is on S3 but cannot be trusted as a valid restore point.
- Retry up to 3 times (Step 4). If still mismatched → Slack failure alert with "checksum mismatch" detail.
- The file is NOT deleted (Object Lock prevents it) — S3 versioning keeps the prior clean version available.
⚠️ [OPEN — Exc-2] Source does not specify whether the unverified file is tagged in S3 metadata. BA to confirm whether a
corrupt=truetag should be applied to the S3 object.
Exc-3 — JSON parse failure:
- File may be truncated or have encoding issues.
- Same retry and preservation behavior as Exc-2; alert detail "JSON parse error".
Exc-4 — Zapier Table read failure (one or more tables unavailable):
- Partial export may be generated.
- A partial backup could silently create an incomplete restore point.
⚠️ [OPEN — Exc-4] Source does not specify whether a partial export is uploaded or the entire job is aborted when one table fails. BA to confirm: abort-all vs. upload-partial-with-error-flag.
Exc-5 — Slack alert delivery failure:
- Backup outcome is unaffected, but Ops has no visibility.
- No fallback channel — alerts are Slack only. The failed delivery is logged server-side.
7. Business Rules
| Rule ID | Rule | Source |
|---|---|---|
| BR_9.3.1 | Flow 18 backs up Zapier Table configuration data only — it does NOT back up trader transaction data (that is handled by Amazon RDS PostgreSQL Multi-AZ automated backups). | Zapier Integration V7.pdf §Flow 18 |
| BR_9.3.2 | The backup scope is Tables A–F plus any newly added tables, discovered at runtime. | Zapier Integration V7.pdf §Flow 18 line 2102; Flow 18 spec 2026-10-28 |
| BR_9.3.3 | Every JSON export MUST embed schema_version and a SHA-256 checksum field. These are metadata, not payload data. | Zapier Integration V7.pdf §Flow 18 lines 2107–2108 |
| BR_9.3.4 | The S3 bucket MUST have SSE-KMS encryption, bucket versioning and S3 Object Lock in Compliance Mode enabled. Cross-region replication is recommended. | Zapier Integration V7.pdf §Flow 18 lines 2110–2115; Flow 18 spec 2026-10-28 (F18-02, F18-05) |
| BR_9.3.5 | S3 Lifecycle Rule on the backup prefix: S3 Standard for the first 90 days → S3 Glacier after 90 days → deleted after 1,856 days (5 years + 1 month). No custom compression/rotation code. | QnA_BACKGROUND_MECHANISMS_CRON.md [BG-010] — client sheet 2026-11-04 |
| BR_9.3.6 | The independent verification (re-download + checksum compare + JSON test-parse) MUST run immediately after every upload. A backup is successful only when verification passes. | Zapier Integration V7.pdf §Flow 18 lines 2117–2119 |
| BR_9.3.7 | Flow 40 (Zapier DR Recovery Snapshot) shares the same S3 bucket and prefix as Flow 18. The bucket applies one unified security, versioning and lifecycle policy to both flows. | Zapier Integration V7.pdf §Flow 40 line 2652 |
| BR_9.3.8 | File naming MUST follow the convention: config_backup_YYMMDD_HHMMSS.json. | Zapier Integration V7.pdf §Flow 18 line 2111 |
| BR_9.3.9 | If the backup or the verification fails, the job MUST retry up to 3 times with exponential backoff. A Slack failure alert is sent only after the 3rd retry fails. | Flow 18 spec 2026-10-28 |
| BR_9.3.10 | All Flow 18 notifications go to Slack #ops-dev only: a ✅ confirmation on every successful backup and a 🚨 alert after the 3rd failed retry. No Freshdesk ticket is created. | Zapier Integration V7.pdf §Flow 18 line 2121; CR-15.2 (slack_channel_usage.md) |
8. Non-Functional Requirements
| Dimension | Requirement |
|---|---|
| Security | SSE-KMS encryption at rest. IAM least-privilege for S3 write and KMS access. Object Lock (Compliance Mode) prevents deletion within the retention window, including by Admin/root accounts. |
| Compliance | Retention 5 years + 1 month (1,856 days); objects older than 90 days in S3 Glacier; deleted at 1,856 days. |
| Durability | S3 standard durability (99.999999999%). Cross-region replication recommended for DR against a full regional outage. |
| Integrity | SHA-256 checksum embedded in every export file. Independent verification mandatory after every upload. |
| Availability | Runs daily — a single failure does not cause data loss (the prior day's backup remains valid on S3 with versioning). Transient failures are absorbed by 3 automatic retries. |
| Observability | Slack #ops-dev only: ✅ confirmation on every successful backup; 🚨 alert after the 3rd failed retry, including the failed step and the specific error detail. |
9. Acceptance Criteria
| ID | Scenario | Expected Result |
|---|---|---|
| AC-9.3-01 | Scheduled job fires at 02:00 UTC (same UTC time all year, no DST shift) — all tables readable | JSON file exported with schema_version and SHA-256 checksum; uploaded to S3 as config_backup_YYMMDD_HHMMSS.json; SSE-KMS and Object Lock applied; verification passes; Slack ✅ confirmation sent to #ops-dev. |
| AC-9.3-02 | Verification: checksum of the downloaded file matches the export checksum | Verification passes. No failure alert sent. |
| AC-9.3-03 | Verification: checksum mismatch on every attempt | 3 retries with exponential backoff executed; after the 3rd retry fails, Slack 🚨 alert sent to #ops-dev with "checksum mismatch" detail. |
| AC-9.3-04 | Verification: JSON test-parse fails on every attempt | 3 retries executed; Slack 🚨 alert sent to #ops-dev with "JSON parse error" detail. |
| AC-9.3-05 | S3 upload fails (e.g. KMS key unavailable) on every attempt | No file written to S3. 3 retries executed; Slack 🚨 alert sent to #ops-dev with the specific error code. |
| AC-9.3-06 | S3 upload fails on the 1st attempt and succeeds on the 2nd retry | Backup completes and verification passes. Slack ✅ confirmation sent; no failure alert. |
| AC-9.3-07 | A second backup run on the same day produces a new file | S3 versioning retains both files. No overwrite of the prior backup. |
| AC-9.3-08 | An attempt is made to delete or overwrite a backup file within its retention window (including with an Admin/root account) | Rejected by S3 Object Lock (Compliance Mode). |
| AC-9.3-09 | A backup file reaches 91 days old | Lifecycle rule moves it from S3 Standard to S3 Glacier. File still retrievable. |
| AC-9.3-10 | A backup file is 1–90 days old | File remains in S3 Standard (hot). |
| AC-9.3-11 | A backup file reaches 1,857 days old | Lifecycle rule deletes the file automatically. |
| AC-9.3-12 | Flow 40 uploads an artifact to the same S3 bucket | File co-exists with Flow 18 backups under the same prefix. KMS, versioning, Object Lock and lifecycle rules apply to both. |
10. Update History
| Date | Version | Updated Section | Before | After | Reason |
|---|---|---|---|---|---|
| 2026-11-04 | v1.2 → v1.3 | Header; UC Index; §2 Trigger (schedule, rationale, source); §3 Step 2 (lifecycle row, lifecycle table + notes, source); §7 BR_9.3.5; §8 Compliance; §9 AC-9.3-01/09/10/11 | Daily 02:00 AM CST (08:00 AM UTC), DST open (F18-04); HOT/WARM/COLD tiering 0–12 / 13–24 / 25–61 months, delete at 61 months | Daily 02:00 UTC fixed (no DST; all backend crons on fixed UTC); S3 Lifecycle Rule: S3 Standard 90 days → S3 Glacier → delete at 1,856 days; no custom compression scripts | Client sheet Adam/Adrian 2026-11-04 (QnA [BG-010] [BG-011]) |
| 2026-10-28 | v1.1 → v1.2 | §1 3rd Party; §3 Step 4; §4 P4; §5; §6 Exc-5; §7 BR_9.3.10 (new); §8 Observability; §9 AC-9.3-01/03/04/05/06 | Alert channel and Freshdesk fallback open (F18-01); success alert status unclear | Slack #ops-dev only — ✅ on success, 🚨 after the 3rd failed retry; no Freshdesk | Decision 2026-10-28 (F18-01 closed) |
| 2026-10-28 | v1.0 → v1.1 | Header; UC Index; §1; §2; §3 Steps 1–4; §4–§6; §7 BR_9.3.2/4/5/6/7, BR_9.3.9 (new); §8; §9 AC-9.3-01–12 | Object Lock optional; lifecycle "> 25 months → Glacier, delete at 61 months"; no retry (Exc-1 OPEN); Slack alert to #dev_ops on success or failure; SOURCE CONFLICT on table scope (A–F vs A–J) | Object Lock mandatory (Compliance Mode); HOT/WARM/COLD tiering (Instant 0–12 m → Flexible 13–24 m → Deep Archive 25–61 m) + expire at 61 m; retry 3× exponential backoff then Slack alert; channel noted as #ops-dev (CR-15.2); scope conflict closed — Tables A–F + newly added. Open items routed to F18-01 → F18-05. | Flow 18 spec 2026-10-28 |
| 2026-08-21 | v1.0 | Initial creation | — | Full SRS for UC_9.3 (Flow 18) | First authoring pass. Source: Zapier Integration V7.pdf §Flow 18; Prop Tech V7 §CFTC 1.31. |