企业官网建设流程全解析

Krawl 是一款轻量级、云原生的 Web 欺骗服务器（Honeypot）与反爬虫工具。本文将从零讲清三件运维必会的事：Krawl 数据备份怎么开、数据保留策略如何工作，以及如何在需要扩容时把Standalone（SQLite）模式平滑迁移到 Scalable（PostgreSQL）模式，全程附带配置项说明与操作步骤，适合新手直接照做。

为什么蜜罐数据值得认真对待

Krawl 的核心价值在于持续捕获攻击者的访问日志、凭据窃取尝试和攻击指纹。一旦数据库丢失：

• 已积累的IP 信誉与攻击者画像全部清零；
• 封禁列表（banlist）导出的依据消失，防火墙联动失效；
• 历史攻击回溯与取证能力归零。

因此，备份 + 保留策略是 Krawl 生产部署的两个"保底"机制，而 Standalone → Scalable 迁移则是流量增长后的"升级路径"。

📖 官方文档入口：docs/backups.md、docs/deployment-modes.md

一键开启 Krawl 数据库自动备份

Krawl 内置了定时备份任务dump-krawl-data，默认是关闭的，需要在配置中手动打开。

备份配置方法（config.yaml）

编辑项目根目录的 config.yaml，修改backups段：

backups: path: "backups" # 备份文件保存目录 cron: "*/30 * * * *" # 备份频率，默认每 30 分钟一次 enabled: true # 必须改为 true 才启用

对应的环境变量为KRAWL_BACKUPS_PATH、KRAWL_BACKUPS_CRON、KRAWL_BACKUPS_ENABLED，适合 Docker / K8s 部署时注入。

两种模式下的备份原理

备份方式随部署模式自动切换，无需手动区分（源码：src/tasks/db_dump.py）：

恢复方法也很简单：

# Standalone：先停 Krawl，再覆盖数据库文件 cp backups/krawl_backup.db data/krawl.db # Scalable：导入 SQL 转储 psql -h localhost -U krawl -d krawl < backups/db_dump.sql

如何验证备份任务真的在跑

ls -la backups/ # 文件存在且时间戳是最新的 docker logs krawl-server | grep "dump-krawl-data" # 查看任务日志（K8s 用 kubectl logs）

Krawl 配套的 Grafana 监控面板，可用于观察备份任务与整体运行状态

⚠️ 注意：备份文件每次运行都会覆盖上一次，建议定期把backups/目录同步到对象存储或异地，才能抵御硬件级故障。

数据保留策略：Krawl 保留什么、删除什么

备份解决"意外丢失"，保留策略（data retention）解决"数据库无限膨胀"。Krawl 每天自动清理过期数据，由database.retention_days控制（默认30 天）：

# config.yaml database: path: "data/krawl.db" retention_days: 30

永远保留的数据（不受保留期影响）

• ✅所有凭据捕获记录（credential capture attempts）
• ✅ 所有可疑访问日志与蜜罐触发记录
• ✅ 有可疑历史记录的IP 及其分类历史

自动清理的数据

• 🗑️ 超过保留期的非可疑访问日志
• 🗑️ 无攻击历史的过期 IP 条目
• 🗑️ 孤儿攻击检测记录与孤儿载荷/聚类（"有统计无成员"的幽灵数据）

清理任务 src/tasks/db_retention.py 按1 万行/批分批删除，避免长时间锁表和 WAL 暴涨；删除完成后还会自动修正累计计数器并刷新表统计信息，保证仪表盘数字不失真。

每日清理的时间线

在 Scalable 多副本模式下，这两个任务都标记了single_pod: True，由 Redis 租约保证同一时刻只在一个 Pod 上执行，避免重复删除。

Krawl 仪表盘的数据总览表：保留策略正是围绕这些攻击数据表做精细化清理

Standalone vs Scalable：一张表看懂两种模式

迁移前先确认你是否"真的需要"扩容。两种模式差异如下（详见 docs/deployment-modes.md）：

Krawl 攻击者排行榜数据在迁移后应完整保留，这是迁移成功的关键验证点

Standalone 到 Scalable 迁移：分步教程

迁移脚本 scripts/migrate_sqlite_to_postgres.py 会读取 SQLite 全部表 → 在 PostgreSQL 建表 → 分批（默认 1000 行/批，失败自动退化为逐行插入）→ 最后打印源/目标行数比对摘要。

迁移前置检查清单（重要）

• 先备份：cp data/krawl.db data/krawl.db.backup
• 彻底停止 Krawl：迁移期间绝不能有实例连着 SQLite，否则会出现写锁与数据不一致
• PostgreSQL 已启动且可访问，目标数据库已存在
• PostgreSQL 主机有足够磁盘空间

Docker Compose 环境的迁移步骤

# 1. 停掉 Standalone 栈 docker compose down # 2. 只启动 Scalable 栈中的 PostgreSQL 和 Redis docker compose -f docker/docker-compose.scalable.yaml up -d postgres redis # 3. 等待 PostgreSQL 就绪 docker compose -f docker/docker-compose.scalable.yaml exec postgres pg_isready -U krawl -d krawl # 4. 执行迁移（核对输出的行数比对是否一致！） python scripts/migrate_sqlite_to_postgres.py \ --sqlite-path data/krawl.db \ --postgres-host localhost \ --postgres-user krawl \ --postgres-password krawl \ --postgres-database krawl # 5. 启动完整 Scalable 栈 docker compose -f docker/docker-compose.scalable.yaml up -d

常用参数还有--batch-size（批大小）、--drop-existing（迁移前清空目标表）。也可以借助 docker/docker-compose.scalable.yaml 挂载./data卷在容器内执行迁移。

Kubernetes（Helm）环境的迁移

K8s 场景下 SQLite 数据放在 PVC 里，Helm chart 自带一次性迁移 Job（模板见 helm/templates/migration-job.yaml）：

1. 先把 Krawl 缩容到 0 副本（--set replicaCount=0），释放 PVC 文件锁，同时开启--set migration.enabled=true并启用 PostgreSQL/Redis；
2. 等待 Job 完成：kubectl wait --for=condition=complete job/<release>-krawl-migrate --timeout=600s；
3. kubectl logs job/<release>-krawl-migrate核对行数比对；
4. 再执行helm upgrade切换--set mode=scalable、--set migration.enabled=false、--set replicaCount=2。

迁移后必做三件事

1. 登录仪表盘，核对 IP、攻击日志、统计图表与迁移前一致；
2. SQLite 备份至少保留几天，确认无误再删；
3. 清理旧资源：K8s 中旧 PVC不会随模式切换自动删除，确认后可手动回收；Docker 环境则删除data/krawl.db释放空间。

💡 迁移失败怎么办？把krawl.db.backup恢复回data/krawl.db，以 Standalone 模式重新拉起即可回滚。

新手常见坑位速查

相关文档与源码路径

• 备份文档：docs/backups.md
• 部署模式与迁移完整指南：docs/deployment-modes.md
• 备份任务源码：src/tasks/db_dump.py
• 保留策略任务：src/tasks/db_retention.py、src/tasks/pre_retention_cleanup.py
• 迁移脚本：scripts/migrate_sqlite_to_postgres.py
• Scalable 部署清单：docker/docker-compose.scalable.yaml
• 配置文件示例：config.yaml