金融科技后端前端【免费下载链接】binance-trading-botAutomated Binance trading bot with pluggable strategies, historical backtesting, and a live dashboard项目地址https://gitcode.com/gh_mirrors/bi/binance-trading-bot点击查看免费下载本文以 docs/user-guide/system/backup-restore.md 为骨架结合 worker cron、API 路由与前端面板的源码实现展开。读完你将掌握如何在 Web UI 中配置周期备份的开关、间隔与保留份数db-backupcron 如何每 5 分钟自轮询并在到期时生成pg_dump归档GET /backup、POST /restore、GET/PUT /backup/config四类接口的用法与边界以及备份文件中明文密钥的威胁模型与补偿控制手段。binance-trading-bot 的数据备份体系由两条路径组成一条是在应用内配置的周期自动转储由 worker 的db-backupcron 驱动另一条是通过 API 的按需下载与恢复GET /backup与POST /restore。两条路径最终都产出同一种自定义格式custom format归档文件该格式可直接被pg_restore读取因此无论备份来自定时任务还是手动下载恢复流程都是统一的。两条备份路径统一归档格式两种触发方式系统在BACKUP_DIR目录中存放所有备份文件。两种路径各自独立触发但写盘方式保持一致周期转储由 worker 常驻的db-backupcron 按数据库中的配置行自动触发适合无人值守的定期快照按需下载/恢复由操作员通过 API或 Web 面板上的按钮触发适合迁移前手动导出一份 / 故障后立即还原。归档参数在 packages/core/src/backup/index.ts 中被定义为共享常量PG_DUMP_ARGS [--formatcustom, --no-owner, --no-acl]cron 与按需下载都复用这一组参数保证两种路径产出的归档字节级兼容、可被同一条pg_restore流程还原--formatcustomPostgreSQL 自定义压缩格式体积小、且支持选择性恢复pg_restore -l/-t等--no-owner、--no-acl丢弃 role 与 grant 语句避免在全新目标库上重放时报角色不存在。周期备份在 Web UI 中配置的自动调度周期备份的调度不在环境变量里而在 Web UI 的 Account → Backup 页面中维护。操作员可配置三个参数它们写入数据库的backup_config单例行singleton row由 worker cron 每次轮询时读取配置项含义取值约束前后端双重校验Enable周期备份总开关true/false切换后无需重启 worker下一个 cron 轮询即生效Interval (hours)两次转储的间隔单位为小时整数18760上限即一年Retention (count)磁盘上保留的转储份数整数1365每次成功转储后超出份数的旧归档被裁剪取值范围在 packages/contracts/src/backup-config.ts 的BackupConfigPut中定义intervalHours上限 8760h、retentionCount上限 365并在 apps/web/src/features/account/components/backup-settings-card.tsx 中镜像同样的INTERVAL_MIN/MAX、RETENTION_MIN/MAX前端先拦截手误输入服务端422 VALIDATION_FAILED兜底。db-backup cron 的执行流程worker 注册了名为db-backup的 cron见 apps/worker/src/crons/register-crons.ts 与 apps/worker/src/crons/db-backup.cron.ts。其核心 handlerdbBackupHandler每轮依次完成读取配置 → 判断开关 → 判断是否到期 → 转储 → 记录成功时间 → 裁剪旧档 → 清扫残留临时文件各步骤在源码中的落点如下开关自门控if (!cfg.enabled)直接跳过本轮db-backup.cron.ts。cron 始终注册、每轮从数据库读配置因此 UI 上的开关不需要重启 worker到期判断以lastBackupAt intervalHours为下一次到期时间未到期则跳过db-backup.cron.ts。5 分钟轮询只是检查粒度不是备份节奏——真正决定备份节奏的是intervalHours原子转储调用pgDumpToFile将pg_dump流写入BACKUP_DIR/backup-epochms.dump文件名的时间戳由注入的时钟决定测试中可固定先记录成功再裁剪touchLastBackup(now)在裁剪之前执行裁剪失败不会回滚已备份信号避免下次轮询重复转储db-backup.cron.ts保留份数裁剪keep Math.max(1, retentionCount)——0 或负值绝不会在刚写完一份后把所有备份全删掉然后由纯函数selectBackupsToPrune按文件名内嵌时间戳排序、只删最旧的超量部分apps/worker/src/crons/retention-select.ts残留清扫任何剩余的*.dump.partial都被视为此前崩溃转储的残留或清理失败的产物统一删除避免堆积db-backup.cron.ts。为什么转储要先写 .partial 再重命名pgDumpToFilepackages/core/src/backup/index.ts实现了原子写pg_dump的输出先流向name.dump.partial临时文件只有pg_dump退出码为 0且输出流完全 flush 之后才通过rename换成正式名。这意味着backup-ts.dump永远不会以半成品形式存在——被 kill 的转储最多留下.partial不会被保留逻辑误统计为一份有效备份临时文件在 spawnpg_dump之前就已创建写不进去就直接报错绝不会出现转储失败但留下了残缺文件失败路径做确定性清理kill 子进程、销毁写流、删除临时文件若清理本身也失败错误信息会同时携带两个原因源码注释将 dump 错误作为cause保留。自重新调度慢转储延后而非重叠db-backupcron 使用selfReschedulePeriodMs: 300_0005 分钟而非固定 cron pattern。按 apps/worker/src/crons/define.ts 的说明当 handler 的最坏运行时长可能接近或超过调度周期时一次全库pg_dump可能持续数分钟固定节奏调度器会在上一轮未结束时又发新任务导致重叠堆积而自重新调度只在当前运行进入终态后 enqueue 下一轮下一次延迟为max(0, period - runtime)——运行快则保持 5 分钟节奏运行慢则自动坍缩为背靠背永远不会重叠。旧 sidecar 机制已移除文档明确旧的backupcompose sidecar独立postgres容器跑 shell 循环已被移除现在只有 worker cron 这一个机制写./backups。对应的BACKUP_INTERVAL_SECONDS/BACKUP_RETENTION_DAYS环境变量也已删除请改在 UI 中配置调度。从 deploy/compose/docker-compose.yml 可以看到BACKUP_DIR默认/backups由 compose bind-mount 到仓库根目录的./backupsworker 与 API 共享同一目录cron 在 worker 容器内写 dumpGET /backup/config在 API 容器内列同一批文件。按需下载与恢复四个 API 端点按需操作通过四个受认证保护的端点完成实现见 apps/api/src/routes/backup.ts前端页面挂载在/settings/backup-restoreapps/web/src/features/account/routes/settings.backup-restore.tsx端点方法作用/backupGET实时流式生成一份全新全库转储供下载/restorePOST上传先前取得的归档并还原数据库/backup/configGET读取已保存的调度开关/间隔/保留 磁盘上最近的转储列表/backup/configPUT更新调度下一个 cron 轮询即生效所有端点都需要已认证的操作员会话requireUser()且因转储/恢复携带全部密钥、恢复具有破坏性路由还叠加了requireNotDemo()演示环境demo中这三个路径一律关闭backup.ts。PUT /backup/config无需向 worker 同步——cron 每轮自己读backup_config行保存后自然生效backup.ts。GET /backup流式下载全新转储pg_dump的自定义归档直接写向 stdoutAPI 通过 Hono 的stream把子进程输出原样 pipe 到 HTTP 响应不经过内存缓冲backup.ts响应头content-type: application/octet-stream、content-disposition: attachment; filenamebackup-Date.now().dump每次请求都会实时生成一份新 dump而非复用磁盘旧档API 容器内置postgresql17-client保证pg_dump可用前端Download backup按钮直接用window.location.href .../backup触发浏览器保存避免把整份归档读进 JS 内存settings.backup-restore.tsx。POST /restore上传式还原 恢复前重新认证POST /restore只接受上传以multipart/form-data提交archive文件还包含reauthentication字段服务端把文件写入临时目录后执行pg_restore。需要特别留意的三个设计点恢复前重新认证恢复会替换密码哈希、单点登录身份与安全设置若被盗会话能擅自恢复并植入自己的密码操作员将被锁在门外。因此请求必须携带密码或新的单点登录证明reauthenticateOperator校验前端以 Confirm its you 面板收集backup.ts--single-transaction事务化pg_restore参数中明确带有--single-transaction --clean --if-exists --no-owner --no-aclbackup.ts。若不加该参数pg_restore遇到错误会继续执行失败恢复会留下 dump 里的会话和旧安全纪元随后的登出逻辑可能不执行加了它失败即整体回滚、什么都不改恢复后全员登出signOutEverythingAfterRestore会提升安全纪元必须超过恢复前的在线纪元而不仅仅是 dump 内的、删除该操作员全部会话、撤销 Agent 访问权限并发布会话吊销事件backup.ts——因为 dump 自带的会话与安全纪元可能早于dump 之后才吊销的会话若不清理被吊销的设备会借 dump 复活。若登出失败API 会提示操作员先运行 reset-password 命令再继续使用。从磁盘归档恢复pg_restore CLI 流程POST /restore只能处理你上传的归档。若要从磁盘上已存在的周期转储backup-ts.dump恢复文档指定的路径是走 deploy/README.md 中的 Restore 流程核心命令如下摘自该文件# ./backups 已 bind-mount 进 postgres 容器挂载点为 /backups # 把要恢复的 dump 放入仓库根目录的 ./backups 后直接 exec无需 docker cp REPO_ROOT$(git rev-parse --show-toplevel) cp /path/to/dump.dump $REPO_ROOT/backups/restore.dump docker compose -f deploy/compose/docker-compose.yml -f deploy/compose/docker-compose.prod.yml --env-file .env \ exec -T postgres pg_restore \ -U postgres -d binance_trading_bot /backups/restore.dumpdeploy/README.md还给出了离机备份off-host backup配方用 restic 将./backups每日推送到 S3/B2/Storj并配合restic forget --keep-daily 14 --keep-weekly 8 --keep-monthly 12 --prune做离机保留策略恢复时restic restore到临时目录再挑选时间戳命名的 dump。GET /backup/config调度 磁盘状态一目了然GET /backup/config返回BackupConfigResponsepackages/contracts/src/backup-config.tsenabled/intervalHours/retentionCount当前调度lastBackupAt最近一次成功转储时间可为 null表示从未转储nextDueAtlastBackupAt intervalHours推算的下次到期时间禁用或首次运行前为 nullUI 显示 pending first backuprecentBackups磁盘上按时间戳倒序的最新 20 份归档每项含name、sizeBytes、modifiedAt。前端面板backup-settings-card.tsx把lastBackupAt/nextDueAt翻译成 Last backup 5m ago、Next backup in about 3h、any moment now 等自然语言状态行并在 Recent backups 列表中按修改时间倒序展示最近的 10 份带 KB/MB 格式化体积。实现上对BACKUP_DIR缺失ENOENT视为正常冷启动态、返回空列表而非 500若读取与 stat 之间文件恰好被 cron 裁剪也容忍为 null 而非中断整个列表backup.ts。安全注意事项dump 即明文密钥库文档的威胁模型强调worker 现在持有写整个数据库到本地备份目录的路径而 dump 是可恢复的明文副本——其中包含的 Binance API 密钥与通知器notifier密钥同样以明文存储因此一份泄露的 dump 等于泄露实时凭据。相应的补偿控制包括Binance IP 白名单在 Binance 控制台为密钥配置 IP 白名单限制泄露密钥的可执行范围备份目录文件权限deploy/README.md要求首次运行后执行chmod 700 ./backups deploy/secrets确保 dump 永不被 Web 服务暴露、不对外部可读放置原则BACKUP_DIR必须放在任何被服务的路径之外并仅授予 worker 用户访问权限离机 restic 仓库的密码必须离线保管如密码管理器不能与主机同盘否则主机失陷会让离机备份一并失陷。Web 端的恢复页面同样以醒目告警提醒 The backup file contains your Binance API keys in plaintextsettings.backup-restore.tsx且要求输入RESTORE确认词后才能提交防止误触不可逆操作。测试与验证行为即契约仓库为这套机制提供了充分的行为测试可作为理解与回归验证的依据worker cron 契约测试apps/worker/tests/crons/db-backup.cron.test.ts注入固定时钟与纯端口依赖断言禁用时完全不触碰文件系统、未到期时跳过、到期时生成确定性的/backups/backup-ts.dump并记录成功时间、转储失败时不记录成功也不裁剪、裁剪只删最旧、保留最新retentionCount份API 路由测试apps/api/tests/routes/backup-config.route.test.ts断言新库默认值禁用、无备份、PUT 持久化后 GET 回读一致、nextDueAt lastBackupAt interval的推算、越界值返回 422 且配置不变、无会话访问返回 401、目录列表只匹配backup-ts.dump且最新优先cron 状态脱敏测试apps/worker/tests/crons/cron-status.test.tsdb-backup的错误记录会抹去绝对路径与 PostgreSQL 连接串凭据避免 cron 状态面板泄露环境信息。小结binance-trading-bot 的备份/恢复体系可以概括为一条统一归档格式custom format、两条触发路径cron 周期转储 API 按需操作、四类端点下载/恢复/读配置/写配置、一套明文密钥威胁模型。日常运维只需记住调度在 UI 里配置而不是环境变量、5 分钟轮询不等于备份间隔、恢复是全库不可逆操作且会全员登出、dump 要按密钥同等对待。生产环境建议叠加deploy/README.md中的 restic 离机副本让本地周期转储与离机快照互为冗余。赞分享金融科技后端前端【免费下载链接】binance-trading-botAutomated Binance trading bot with pluggable strategies, historical backtesting, and a live dashboard项目地址https://gitcode.com/gh_mirrors/bi/binance-trading-bot点击查看免费下载相关推荐PostgreSQL 数据库备份与恢复实战pg_dump 自定义格式与 pg_restore 完整指南PostgreSQL 数据库备份与恢复实战pg_dump 自定义格式与 pg_restore 完整指南 PostgreSQL 自带两套命令行工具用于数据库的导文档教程知识库AXWebViewController扩展开发如何实现自定义工具栏与交互事件AXWebViewController扩展开发如何实现自定义工具栏与交互事件 AXWebViewController是一款轻量级iOS平台网页浏览控制器基于如何备份与恢复DLSSG到FSR3帧生成安装前后的注意事项如何备份与恢复DLSSG到FSR3帧生成安装前后的注意事项 想要在游戏中体验更流畅的帧率吗DLSSG到FSR3帧生成技术能让你在NVIDIA显卡上也能享受到图形学游戏开发创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考