容器销毁后日志完整保留的关键在于将日志路径从容器生命周期中剥离，即先挂载持久化卷（如Docker Volume或宿主机绑定路径），再对日志卷执行定时快照（如Restic或云存储快照），并配合logrotate控制体积。
容器销毁后日志完整保留，关键不是“等销毁后再抢救”，而是把日志生命周期从容器里剥离出来——快照只是其中一环，真正起作用的是日志存储路径的独立性和备份触发机制。
一、先确保日志写在持久化卷上，快照才有对象
如果日志还写在容器内部（比如 /var/log/app.log 且没挂载外部存储），容器一删，文件系统层就没了，快照再强也抓不到东西。必须提前把日志目录映射到 Docker Volume 或绑定宿主机路径：
- 用命名卷（推荐）：
docker volume create crm-logs，启动时加-v crm-logs:/app/logs - 或绑定挂载：
-v /data/crm/logs:/app/logs，确保宿主机该路径存在且有写权限 - 应用配置也要同步改：让 CRM 程序把日志输出到
/app/logs，而不是默认的临时路径
二、对日志卷做定时快照，不是对容器快照
快照对象必须是存储日志的卷（Volume），不是容器本身。以 Restic 为例，可配合 cron 每天执行：
- 启动临时容器挂载日志卷，并调用 Restic 备份：
docker run --rm -v crm-logs:/data -v /backups:/repo restic/restic -r /repo backup /data - 首次运行会初始化仓库，后续自动增量备份——只传变化的日志块，节省带宽和空间
- 快照自带时间戳和 SHA-256 指纹，支持按时间点还原，比如恢复“6月10日早8点前的日志”
三、云环境可直接启用存储层快照功能
如果你用的是阿里云 NAS、AWS EBS 或 Azure Disk 这类托管存储，它们原生支持卷级快照：
- 在控制台设置自动快照策略：每天凌晨2点创建快照，保留7份
- 快照是存储卷在某一时刻的完整副本，不依赖容器是否运行
- 万一误删日志卷，可直接从快照新建卷并挂载回新容器，分钟级恢复
四、搭配日志轮转，避免快照体积失控
光靠快照不清理原始日志，磁盘迟早撑爆。建议在宿主机或容器内启用 logrotate：
- 配置每天切割、压缩旧日志、保留90天 —— 快照只备份“当前有效窗口”的数据，更高效
- 例如：
/data/crm/logs/*.log { daily rotate 90 compress missingok } - 这样快照体积稳定，备份耗时短，也符合审计对日志保留期的要求
不复杂但容易忽略：快照本身不能替代日志路径的持久化设计，它只是保险绳。先让日志落盘，再给盘做快照，两步缺一不可。
