backup-retention-erasure

备份保留与删除管理

概述

备份和归档系统在数据保留和删除合规方面面临独特挑战。与可以选择性删除单条记录的主系统不同，备份介质通常以整体数据集的形式存储数据，若不先恢复数据，就无法精确修改。当数据主体依据 GDPR 第 17 条行使删除权，或保留期限届满时，组织必须处理存储在备份中的个人数据。虽然从备份中进行精细化删除在技术上不可行是公认的局限，但这并不免除组织的义务——组织必须记录临时措施，并最终通过备份轮换或恢复后删除的流程完成删除。本技能提供了在保留和删除义务下管理备份数据的操作框架。

法律背景

GDPR 序言第 66 条——在线环境中的删除

删除权应适用于控制者已公开个人数据的情形——控制者应采取合理措施，通知其他处理该数据的控制者。在备份情境中，这一原则要求删除义务同样适用于备份副本，即使技术上无法立即删除。

GDPR 第 17(1) 条——删除权

控制者应「不得无故拖延」删除个人数据。欧洲数据保护委员会（EDPB）和各国数据保护机构（DPA）承认，备份系统可能需要更长时间，但并未给予无限期豁免。预期是应在下一个备份轮换周期内删除备份。

ICO 关于备份删除的指南

英国 ICO 表示，如果无法在技术上立即从备份系统中删除数据，组织应：

1. 将备份数据置于「不可使用」状态——确保其无法因任何目的被访问或使用。
2. 确保在下次覆盖或轮换备份时删除数据。
3. 记录处理方式和时间安排。
4. 告知数据主体备份删除时间安排。

EDPB 立场

欧洲数据保护委员会在多项指南中承认，备份系统可能给删除带来技术挑战。其总体立场是：

• 预期应立即从在线／主系统中删除数据。
• 应在合理期限内删除备份数据，期限应与备份轮换周期相符。
• 在此期间，备份中的数据必须处于「不可使用」状态，不得因任何目的被访问。

备份系统类型与删除方式

按备份类型划分的擦除策略

备份类型	说明	是否可以精细删除？	擦除方式	典型周期
全量备份（基于磁盘）	将所有数据完整复制到磁盘存储	通常不可以（可以还原完整备份并选择性删除，但资源消耗较大）	等待轮换周期；对于紧急请求，执行还原并删除	每周至每月
增量备份（基于磁盘）	仅包含自上次备份以来的变更	不可以	等待轮换周期	每日
差异备份（基于磁盘）	包含自上次全量备份以来的变更	不可以	等待轮换周期	每日
磁带备份（LTO）	按顺序将数据写入磁带	不可以（磁带是顺序存储；除非完整重写，否则无法选择性删除）	等待磁带轮换周期；对于保留期限较长的磁带，可考虑还原并删除	每月至每年
云备份（托管）	基于云的备份服务（例如 AWS Backup、Azure Backup、Veeam Cloud Connect）	取决于供应商 — 部分供应商支持项目级恢复和删除	检查供应商的能力；如果不支持精细删除，则等待保留策略到期	按配置的策略执行
基于快照的备份	存储卷在特定时间点的副本	不可以（快照不可变）	等待快照保留策略到期；确保策略与保留计划一致	每日至每周
数据库备份（逻辑备份）	SQL 转储文件、导出文件	不可以（转储文件是单个文件）	等待轮换；或还原到临时环境、删除数据并重新导出	每日至每周
归档（冷存储）	长期归档到冷存储／离线存储（例如 AWS Glacier、Azure Archive、磁带库）	不可以	对于擦除请求，执行还原并删除；或等待归档保留策略到期	每年至多年

备份保留期限对齐

使备份周期与保留计划一致

备份保留期限不得超过适用的数据保留期限中的最长值。如果备份保留数据的时间超过保留计划，组织持有数据的做法将违反存储限制原则。

Orion Data Vault Corp 的备份保留配置

备份级别	保留期限	轮换周期	与保留计划的一致性
每日增量备份	30 天	30 天后删除最早的每日备份	短于所有数据类别的保留期限 — 符合要求
每周全量备份	90 天	90 天后删除最早的每周备份	短于所有数据类别的保留期限 — 符合要求
每月全量备份	12 个月	12 个月后删除最早的每月备份	短于大多数保留期限；可能需要将 CCTV（30 天）和未成功申请者的数据（6 个月）单独排除
每季度归档	24 个月	24 个月后删除最早的季度归档	涵盖营销数据（2 年）；需要确认未不必要地纳入保留期限较短的数据类别
每年归档	7 年	7 年后删除最早的年度归档	与最长的法定保留期限一致（财务记录：6-7 年）

差距分析

[For each data category in the retention schedule]
         │
         ▼
[What is the retention period?]
         │
         ▼
[Is this data included in backup sets that are retained longer than the retention period?]
   │
   ├── No ──► Compliant — backup rotation will delete data before or at retention expiry
   │
   └── Yes ──► COMPLIANCE GAP
               │
               ├── Option A: Exclude this data category from long-retention backup sets
               │     (segregate data by retention tier; back up separately)
               │
               ├── Option B: Reduce backup retention to match the shortest data category
               │     (may conflict with business continuity requirements)
               │
               └── Option C: Accept interim retention in backups with protective measures
                     (document "beyond use" controls; delete at next rotation)
                     MAXIMUM acceptable overshoot: 90 days beyond retention period

还原并删除流程

在无法等待轮换周期删除备份的情况下（例如紧急的 Art. 17 请求、DPA 执法）：

PROCEDURE: RESTORE-AND-DELETE
Organization: Orion Data Vault Corp
Procedure ID: BKP-RAD-001

TRIGGER: Art. 17 erasure request where data exists only in backups
         and backup rotation will not occur within an acceptable timeframe

PREREQUISITES:
- All primary system deletion confirmed complete
- Backup system granular deletion confirmed infeasible
- DPO has approved restore-and-delete approach
- Next backup rotation > 90 days away

PROCEDURE:

Step 1: Identify Relevant Backup Sets
   - Query backup catalog for sets containing data subject's data
   - List all relevant backup sets with dates and storage locations
   - Estimated effort: [hours/days]

Step 2: Provision Isolated Restore Environment
   - Create isolated network segment (no connectivity to production)
   - Provision temporary storage sufficient for backup restoration
   - Apply access controls (authorized personnel only)
   - Enable full audit logging

Step 3: Restore Backup to Isolated Environment
   - Restore the backup set(s) to the isolated environment
   - Verify restoration integrity (checksum validation)

Step 4: Execute Granular Deletion
   - Identify and delete the data subject's records from the restored data
   - Verify deletion (query for data subject's identifiers — zero results expected)

Step 5: Create Replacement Backup
   - Export the cleaned data as a replacement backup set
   - Verify replacement backup integrity
   - Store replacement backup in the same tier as the original

Step 6: Destroy Original Backup
   - Delete or overwrite the original backup set containing the data subject's data
   - If tape: degauss and destroy the original tape
   - If disk: secure overwrite of original backup files
   - Generate destruction confirmation

Step 7: Decommission Restore Environment
   - Securely wipe the isolated restore environment
   - Release temporary storage
   - Disable the isolated network segment

Step 8: Documentation
   - Record all steps in the deletion confirmation record
   - Update the data subject's erasure request file with backup deletion confirmation
   - Log total time and resources consumed (for future planning)

ESTIMATED TIMELINE: 5-15 business days depending on backup size
ESTIMATED COST: [Track for each execution — informs cost-benefit analysis]

临时保护措施（“停止使用”）

在等待轮换或还原并删除期间，只要备份中仍保留个人数据，就必须采取以下临时措施：

“超出使用范围”控制措施

控制措施	实施方式	验证
访问限制	对于已从主系统中删除或已超过保留期限的数据，备份恢复请求必须获得 DPO 批准	每季度审计备份恢复请求
用途限制	备份数据仅可用于灾难恢复或业务连续性，不得用于运营、分析或数据主体请求	已记录相关政策；已对员工进行培训
恢复筛查	如果出于灾难恢复目的必须恢复包含已删除数据的备份，则必须在恢复环境投入生产之前重新删除其中已删除的记录	恢复流程包含删除检查清单
抑制名单	维护一份抑制名单，记录已从主系统中删除数据的数据主体。每次备份恢复时都要与该名单交叉核对，确保重新删除相关数据	每次恢复时检查抑制名单
加密	所有备份介质均已加密（AES-256）。加密密钥单独管理。在极端情况下，销毁加密密钥可使备份数据无法恢复	每年审计密钥管理
日志记录	所有备份访问、恢复和删除事件均记录在不可篡改的审计跟踪中	每月审查审计日志

备份恢复流程（符合删除要求）

因灾难恢复必须恢复备份，且备份中包含已从主系统中删除的数据时：

[Disaster Recovery Event — Backup Restoration Required]
         │
         ▼
[Select Appropriate Backup Set for Restoration]
         │
         ▼
[Check: Does this backup pre-date any completed erasure requests or retention expiry deletions?]
   │
   ├── No ──► [Restore normally — no erasure compliance action needed]
   │
   └── Yes ──► [Retrieve Suppression List]
               │
               ▼
         [Restore backup to production environment]
               │
               ▼
         [IMMEDIATELY execute deletion of all records matching suppression list]
               │
               ├── Automated: Run deletion script against suppression list
               │   (pre-built script must exist — test quarterly)
               │
               └── Manual (if automated script fails): Assign to data team
                   with 24-hour SLA for completion
               │
               ▼
         [Verify deletion — zero records for suppressed data subjects]
               │
               ▼
         [Log re-deletion event in erasure confirmation records]
               │
               ▼
         [Resume normal operations]

合规性监控

每季度备份保留审计

检查项	方法	预期结果
备份保留期限符合保留计划	将备份保留配置与当前保留计划进行比较	任何备份层级保留数据的时间均不超过最长适用保留期限
“超出使用范围”控制措施已启用	审查备份恢复的访问日志；核实所有恢复已删除数据的备份操作均已获得 DPO 批准	未经授权的恢复次数为零
抑制名单时效性	核实抑制名单包含自最早备份集日期以来从主系统中删除的所有数据主体	覆盖率为 100%
轮换合规性	核实最早备份集日期与预期轮换日期一致	与预期轮换日期相差不超过 7 天
加密验证	核实所有备份介质均已加密	加密覆盖率为 100%
恢复并删除的执行情况	对于任何待处理的恢复并删除操作，核实其进度和时间安排	所有操作均在承诺的时间范围内完成

向 DPO 报告的指标

指标	目标	频率
备份保留期限平均超出时长（超过保留计划）	≤ 90 天	每季度
恢复并删除的完成时间	≤ 15 个工作日	每次执行
抑制名单规模（有效条目数）	跟踪趋势	每月
需要重新删除数据的备份恢复事件	跟踪数量	每季度
包含超过保留期限数据的备份集	零（轮换周期结束后）	每月