# Qingtian Bridge — SOP-12: Backup, Restore & Data Integrity

**Status:** Final Draft  
**Version:** v1.0  
**Purpose:** Define how important Qingtian Bridge data, records, configurations, and project information are protected through backup, restoration, and integrity verification.

---

# 1. Objective｜目标

Ensure that important information can be recovered after:

- Hardware failure
- Storage failure
- Accidental deletion
- File corruption
- Incorrect modification
- Failed system changes
- Unexpected shutdown

Core principle:

> A backup is not considered reliable merely because it exists. It must be recoverable and appropriately verified.

---

# 2. Scope｜适用范围

This SOP applies to important Qingtian Bridge information, including:

- Main Instructions
- SOP documents
- Project records
- System configuration records
- Important knowledge files
- Hardware records
- Databases
- Automation configurations
- Other operational data identified as important

Not every temporary or easily reproducible file requires the same backup level.

---

# 3. Data Classification｜资料分类

Important data should be classified by recovery importance.

## Level A — Critical

Loss would seriously affect Qingtian operation, security, or important history.

Examples:

- Core configuration
- Main operational records
- Important databases
- Authorization-related configuration

## Level B — Important

Loss would cause significant inconvenience or require substantial reconstruction.

Examples:

- SOP documents
- Project documentation
- Hardware records

## Level C — Useful

Loss is inconvenient but the information can be recreated.

Examples:

- Temporary working files
- Non-critical exports

Backup effort should be proportional to the importance of the data.

---

# 4. Backup Principle｜备份原则

The minimum objective is:

```text
PRIMARY DATA
     ↓
INDEPENDENT BACKUP
     ↓
VERIFIED RECOVERY PATH
```

A backup should not depend entirely on the same failure point as the original data.

Core principle:

> One copy is not a backup.

---

# 5. Backup Targets｜备份对象

Before creating a backup plan, identify:

- What must be protected
- Where the original data is stored
- Where the backup will be stored
- How often it should be backed up
- How restoration will be performed
- How backup success will be verified

Do not assume that every folder has equal importance.

---

# 6. Backup Method Selection｜备份方式选择

Possible methods include:

- Version-controlled records
- NAS backup
- External storage backup
- Scheduled backup
- Snapshot or version history
- Database backup
- Manual protected archive

The appropriate method depends on:

- Data importance
- Change frequency
- Data size
- Recovery time requirement
- Available storage
- Security requirements

---

# 7. Multiple Recovery Paths｜多重恢复路径

For important information, use more than one recovery path where practical.

Example:

```text
Active Record
      ↓
Primary Storage
      ↓
NAS Backup
      ↓
Additional Independent Backup
```

The exact architecture may change as Qingtian Bridge develops.

The objective is to reduce single points of failure.

---

# 8. Backup Frequency｜备份频率

Backup frequency should reflect how often important information changes.

Examples:

```text
Frequent Changes
→ More frequent backup

Stable Configuration
→ Less frequent backup

Major Change
→ Backup before and/or after the change
```

Important system changes should consider creating a recoverable point before high-risk modification.

---

# 9. Pre-Change Backup｜重大变更前备份

Before meaningful or high-risk changes, determine whether the current state should be protected.

Examples:

- Major configuration changes
- Database migration
- System upgrade
- Security-related changes
- Large record restructuring

The principle is:

> Preserve a known recoverable state before performing a change that may be difficult to reverse.

---

# 10. Backup Verification｜备份验证

Backup success should not be assumed merely because a process reports:

> Completed.

Where practical, verify:

- Expected backup exists
- Expected files or data are present
- Backup size or structure is plausible
- Backup can be accessed
- Important records can be restored or read

For critical data, periodic restoration testing is strongly preferred.

---

# 11. Restore Procedure｜恢复流程

General recovery sequence:

```text
FAILURE OR DATA LOSS
        ↓
STOP FURTHER DAMAGE
        ↓
IDENTIFY REQUIRED RECOVERY POINT
        ↓
CHECK BACKUP AVAILABILITY
        ↓
SELECT SAFEST RESTORE METHOD
        ↓
RESTORE
        ↓
VERIFY DATA INTEGRITY
        ↓
VERIFY FUNCTION
        ↓
REPORT ACTUAL STATUS
```

Do not restore over existing data without understanding the consequence.

---

# 12. Restore Point Selection｜选择恢复点

When multiple versions or backups exist, consider:

- Date and time
- Data completeness
- Known correctness
- Relation to the failure event
- Whether later data would be lost

The newest backup is not automatically the best recovery point.

---

# 13. Data Integrity Verification｜资料完整性验证

After restoring important data, verify more than file existence when appropriate.

Possible verification levels:

### Level 1 — Presence
The expected file or backup exists.

### Level 2 — Readability
The data can be opened or accessed.

### Level 3 — Content Integrity
Important content appears complete and correct.

### Level 4 — Functional Integrity
The restored system or record actually performs its required function.

Do not declare recovery complete based only on Level 1 when higher verification is necessary.

---

# 14. Failed Backup｜备份失败

If a backup fails:

1. Do not assume an earlier backup covers the current data.
2. Identify the last confirmed successful backup.
3. Determine what data may be unprotected.
4. Avoid making the situation worse.
5. Attempt safe recovery or an alternative backup path.
6. Report the actual protection status.

Correct:

> “Latest backup not confirmed. Last verified backup: [known point].”

Incorrect:

> “Data is protected.”

when the latest protection state is unknown.

---

# 15. Backup Retention｜备份保留

Retention should preserve useful recovery history without unnecessary duplication.

Consider keeping:

- Recent recovery points
- A stable older recovery point
- Important milestone versions
- Versions before major system changes

Do not delete the only verified recovery point without ensuring another suitable recovery path exists.

---

# 16. Backup Security｜备份安全

Backups may contain sensitive information.

Therefore:

- Apply appropriate access control
- Avoid unnecessary external exposure
- Protect credentials
- Follow sensitive-data authorization rules
- Do not assume backups are less sensitive than primary data

A backup can contain the same private information as the original.

---

# 17. Backup Status Reporting｜备份状态报告

For meaningful backup operations, report:

```text
Data:
What was protected

Backup Target:
Where the backup was created

Result:
Success / Failed / Partial / Unverified

Verification:
What was checked

Recovery Status:
Verified / Not Yet Tested / Unknown
```

Do not claim that a backup is restorable unless that level of verification has actually been performed.

---

# 18. Restore Status Reporting｜恢复状态报告

For meaningful recovery:

```text
Incident:
What required recovery

Recovery Point:
Selected backup or version

Restore Action:
What was performed

Verification:
What was checked

Final Status:
Recovered / Partially Recovered / Failed / Unverified

Next Step:
Required follow-up
```

---

# 19. Backup and Restore Flow｜备份与恢复流程

```text
IMPORTANT DATA
      ↓
CLASSIFY IMPORTANCE
      ↓
SELECT BACKUP METHOD
      ↓
CREATE BACKUP
      ↓
VERIFY BACKUP
      ↓
RETAIN APPROPRIATE RECOVERY HISTORY
      ↓
       [IF FAILURE]
      ↓
PROTECT CURRENT STATE
      ↓
SELECT RECOVERY POINT
      ↓
RESTORE SAFELY
      ↓
VERIFY INTEGRITY
      ↓
VERIFY FUNCTION
      ↓
REPORT ACTUAL RESULT
```

---

# 20. Core SOP Rules｜核心 SOP 规则

Qingtian must:

1. Identify important data requiring protection.
2. Match backup effort to data importance.
3. Avoid single-point backup dependency for important information where practical.
4. Preserve a recoverable state before meaningful high-risk changes when appropriate.
5. Verify important backups.
6. Treat backup process success as separate from verified recoverability.
7. Select recovery points carefully.
8. Avoid destructive restoration without understanding consequences.
9. Verify restored data at an appropriate level.
10. Protect backup privacy and authorization boundaries.
11. Keep meaningful recovery history.
12. Report the actual backup and recovery status honestly.

---

# Document Relationship

```text
Qingtian Main Instruction
        ↓
Defines overall operating principles
        ↓
SOP-12 Backup, Restore & Data Integrity
        ↓
Protects important Qingtian records and system state
        ↓
NAS / External Backup / Version History / Database Backup
        ↓
SOP-07 Failure Handling
        ↓
Recovery and Verification
```

---

# Document Status

**Document:** SOP-12 — Backup, Restore & Data Integrity  
**Version:** v1.0  
**Status:** Final Draft  
**Related Core Documents:**

- SOP-03 Sensitive Data & Authorization
- SOP-05 Action & Result Verification
- SOP-06 Record Update & Version Management
- SOP-07 System Recovery, Failure Handling & Safe Fallback
- SOP-10 Daily Operation, Startup & Safe Shutdown

**Next recommended SOP:**

> SOP-13 — Operational Logging & Audit