# Backup & Recovery Policy

| Field | Value |
|-------|-------|
| **Document ID** | POL-004 |
| **Version** | 1.0 |
| **Status** | Draft — Pending approval |
| **Owner** | DevOps Lead |
| **Maintained By** | DevOps Lead |
| **Effective Date** | _Pending approval_ |
| **Review Cycle** | Annual |
| **ISO 27001 Reference** | A.8.13 — Information backup |

Related: [Information Security Policy](./information-security-policy.md) | [Incident Response Plan](./incident-response-plan.md)

---

## 1. Purpose

This policy defines backup requirements, retention periods, and recovery objectives for Tender Management System data to ensure business continuity and data protection.

---

## 2. Scope

Covers backup and recovery for:

| Asset | ID | Backup Method |
|-------|-----|---------------|
| MongoDB (`tm` database) | A-001 | Automated snapshots / mongodump |
| MinIO object storage | A-003 | Bucket replication or periodic sync |
| Redis | A-002 | RDB snapshots (cache — lower priority) |
| Application configuration | A-010 | Version-controlled templates; secrets in vault |
| Application logs | A-011 | Log aggregator retention |

---

## 3. Recovery Objectives

| Metric | Definition | Target |
|--------|------------|--------|
| **RTO** (Recovery Time Objective) | Maximum acceptable downtime | **4 hours** (production API) |
| **RPO** (Recovery Point Objective) | Maximum acceptable data loss | **1 hour** (MongoDB); **24 hours** (MinIO documents) |

RTO/RPO are reviewed annually and after major architecture changes.

---

## 4. Backup Requirements

### 4.1 MongoDB

| Parameter | Requirement |
|-----------|-------------|
| Frequency | Continuous oplog / hourly snapshots (production) |
| Retention | Daily: 30 days; Weekly: 12 weeks; Monthly: 12 months |
| Storage | Separate region/account from production |
| Encryption | Encrypted at rest (AES-256 or provider equivalent) |
| Access | DevOps Lead + break-glass only |

**Collections in scope:** `companies`, `customers`, `users`, `tenders`, `notices`, `feedback`, `notifications`, and all domain collections.

### 4.2 MinIO

| Parameter | Requirement |
|-----------|-------------|
| Frequency | Daily incremental; weekly full sync |
| Retention | 30 days rolling |
| Scope | `files` and `documents` buckets (company docs, tender JSON, translations) |
| Encryption | Server-side encryption enabled |
| Versioning | Bucket versioning enabled where supported |

### 4.3 Redis

| Parameter | Requirement |
|-----------|-------------|
| Frequency | Daily RDB snapshot |
| Retention | 7 days |
| Note | Redis holds ephemeral cache/session data; rebuild acceptable within RTO |

### 4.4 Configuration & Secrets

- Infrastructure-as-code and config templates in Git
- Production secrets in secret manager (not backed up in plaintext)
- Secret manager backup per provider documentation

---

## 5. Backup Security

1. Backups classified **C3 Confidential** — same protection as source data
2. Backup storage not publicly accessible
3. Backup access logged and restricted to authorized DevOps personnel
4. Backup encryption keys managed separately from backup data
5. No backup data transferred to unauthorized regions (GDPR data residency compliance)

---

## 6. Recovery Procedures

### 6.1 MongoDB Full Restore

1. Identify target recovery point (timestamp before incident)
2. Provision clean MongoDB instance or restore to staging first
3. Restore from snapshot / mongodump
4. Verify document counts and sample integrity checks
5. Update application connection string
6. Run application smoke tests (auth, tender list, company profile)
7. Monitor for 24 hours post-restore

### 6.2 MinIO Restore

1. Identify affected buckets/prefixes
2. Restore from backup or cross-region replica
3. Verify file accessibility via file store service
4. Re-run worker jobs for any missing derived data (translations)

### 6.3 Partial Restore (Single Collection / Document)

- Use point-in-time recovery or selective mongorestore
- Requires IC approval for production partial restores
- Audit log entry required

---

## 7. Backup Testing

| Test | Frequency | Success Criteria |
|------|-----------|------------------|
| MongoDB restore to staging | **Monthly** | Data integrity verified; app connects successfully |
| MinIO file restore (sample) | **Quarterly** | Random files readable and checksum-valid |
| Full DR simulation | **Annual** | RTO/RPO met in tabletop or live test |
| Backup job monitoring | **Daily** | All scheduled backups complete without error |

Test results documented with date, tester, outcome, and remediation items.

---

## 8. Responsibilities

| Role | Responsibility |
|------|----------------|
| DevOps Lead | Implement and monitor backups; conduct restore tests |
| ISO | Verify policy compliance; include backup status in management review |
| Engineering Lead | Validate application behavior post-restore |
| IC (during incident) | Authorize production restore; communicate status |

---

## 9. Failure Handling

If a scheduled backup fails:

1. Automated alert to DevOps on-call
2. Investigate and re-run within **4 hours**
3. If unrecoverable, escalate to P2 incident if production data at risk
4. Document failure and resolution in backup log

---

## 10. Document Control

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial policy |

**Approval**

| Role | Name | Signature | Date |
|------|------|-----------|------|
| DevOps Lead | _Pending_ | | |
| ISO | _Pending_ | | |
