为什么我不再信任自己的备份脚本（并改为构建 SaaS）

Source: Dev.to

“哦，糟了” 的时刻

我们都有过这种经历。你在一台 5 美元的 VPS 上跑着一个副项目。你写了一个简短的 Bash 脚本，在凌晨 3 点执行 pg_dump 或 mysqldump，把它加到 crontab，于是觉得自己既负责又安全。

六个月后，你真的需要这些数据。你打开备份文件夹，看到：

• 文件大小： 0 KB。
• 更糟糕的是： 文件虽然在，但恢复失败，因为你从未测试过恢复命令，版本不匹配导致到处报错。

这正是我开始构建 Oops Backup 的原因。

作为开发者，我们总是执着于备份这件事——“数据保存了吗？”——但很少关注恢复——“如果服务器起火，我能在 5 分钟内把应用恢复上线吗？”

我那堆随意的 Shell 脚本和 cron 任务有三个致命缺陷：

1. 缺乏可视化 – 如果备份悄悄失败（磁盘满、凭证变更），我根本不知道，直到为时已晚。
2. 存储地狱 – 把备份和数据库放在同一台服务器上是灾难的配方。通过脚本搬到 S3 维护起来非常烦人。
3. 恢复焦虑 – 恢复数据库通常意味着 SSH 进去，找到文件，解压，然后祈祷导入命令能成功。

构建解决方案（并学会说“不”）

我决定打造一个把备份 和 恢复都视为一等公民的工具，而不是事后才想起的功能。

• 我非常推崇保持基础设施的简洁。Oops Backup 能干净地运行在 Docker 容器中，由 Portainer 管理，感觉就像是我的技术栈的原生部分。
• 自动调度 – 再也不需要手动编辑 cron。
• 存储 – 原生集成 S3 兼容存储（AWS、Cloudflare R2、Backblaze B2）、Oops Storage 或 SFTP 传输。
• 一键恢复 – 在 UI 中浏览备份，并将其恢复到指定的数据库实例。

功能裁剪

公开开发意味着敢于承认自己的错误。最初我想支持所有数据库：MongoDB、PostgreSQL、MySQL 和 Microsoft SQL Server。上周我正式放弃了对 MSSQL 的支持。

为什么？ 在一个轻量级工具里支持 Windows 为主的 MSSQL 生态会让项目臃肿，并把注意力从核心用户群上转移走。大约 95 % 的独立黑客和我认识的开发者使用 “LAMP” 或 “MERN” 类的栈。去掉 MSSQL 后，我可以把精力加倍投入到让 Postgres、Mongo 和 MySQL 的体验做到极致。有时候必须砍掉功能才能拯救产品。

我目前正在完成并打磨 UI。我的旅程会在 X、Threads 和 Bluesky 上同步分享。

如果你已经厌倦了信任三年前写的 backup.sh，来看看我正在构建的东西：

Oops Backup

我期待最直白的反馈。你当前的备份方案缺少的唯一功能是什么？