# Backups & Disaster Recovery

## RDS Automated Backups

Enable RDS automated backups for continuous protection:

| Plan     | Retention     | Notes            |
| -------- | ------------- | ---------------- |
| Free     | 7 days        | Basic protection |
| Standard | Up to 35 days | Full protection  |

### Point-in-Time Recovery (PITR)

RDS PITR allows you to restore the database to any point within the retention window. This is your primary disaster recovery mechanism.

**When to use PITR:**

* Hardware failure or data corruption
* Accidental schema changes
* Database-level incidents

**When NOT to use PITR:**

* Reversing business transactions — use compensating journal entries instead
* Undoing a single account's changes — PITR restores the entire database

### Manual Snapshots

You can trigger manual RDS snapshots on demand. These persist until explicitly deleted and are not subject to the retention window.

**Use manual snapshots before:**

* Major schema changes
* Large archive operations
* Maintenance windows

## Backup Strategy

### Daily

* RDS automated backups run continuously (no action needed)
* Verify backup status in the RDS console

### Before Maintenance

1. Create a manual RDS snapshot
2. Perform the maintenance operation
3. Verify system health via `GET /integrity`
4. Delete the snapshot after confirming success (or keep for extra safety)

### Before Archive Operations

1. Run `GET /integrity` to verify current state
2. Optionally create a manual snapshot
3. Execute `POST /ledger/archive`
4. Run `GET /integrity` again to verify post-archive state

## Disaster Recovery Procedures

### Scenario: Server Crash

1. Fargate automatically restarts the container
2. The startup sequence validates the environment and populates recovery records
3. Use `GET /recovery` to identify the last committed batch
4. Reconcile any in-flight transactions using the recovery data
5. Resume normal operations

### Scenario: Database Corruption

1. Identify the point in time before the corruption
2. Restore from PITR to a new RDS instance
3. Update `LEDGER_DB_MASTER_URL` and `LEDGER_DB_REPLICA_URL`
4. Restart the ledger service
5. Run `GET /integrity` to validate the restored state

### Scenario: Accidental Data Modification

1. If the modification was recent, you may still have data in the idempotency window
2. For older modifications, use PITR to restore
3. Run `GET /integrity` to identify any violations

## Data Durability

EntryTarget ensures data durability through:

* **Atomic batch commits** — all journal entries in a batch are committed in a single PostgreSQL transaction
* **Row-level integrity** — cryptographic hashes detect any unauthorized modifications
* **Recovery records** — the last committed batch is always recoverable after a restart
* **RDS replication** — synchronous replication to the read replica provides an additional copy


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://entrytarget.gitbook.io/docs/maintenance/backups.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.