备份

一句话

系统每天凌晨自动备份数据库，保留 30 天。但备份只在同一台服务器上 —— 你必须自己再同步一份到别处。

自动做了什么

装好之后（python deploy.py backup --cron），服务器每天会自己备份一次：

项	值
时间	每天 03:20（服务器时间，UTC）
内容	整个数据库（商品、订单、会员、配置，全在里面）
存在哪	服务器的 /opt/mall/backup/
文件名	mall-20260822-032001.sql.gz
保留	30 天，更早的自动删
日志	/opt/mall/logs/backup.log

没装过 cron 的话现在装一下

python deploy.py backup --cron

这条命令会立刻备份一次，并且从此每天 03:20 自动备。

⭐ 怎么把备份下载到自己电脑

一条命令，在放着 deploy.py 的那个文件夹里跑：

python deploy.py backup

它做三件事：

1. 在服务器上现做一份新备份（不是拿旧的）
2. 下载到你电脑，放在 deploy.py 旁边的 backups/ 文件夹
3. 顺手把 .secrets.json 也复制一份进去

跑完会打印实际路径，长这样：

== 备份 ==
     [stderr] mysqldump: [Warning] Using a password on the command line interface can be insecure.
  [OK] 远端 /opt/mall/backup/mall-20260822-215812.sql.gz  (104K)
  [OK] 已下载到 D:\Mallackups\mall-20260822-215812.sql.gz
  [OK] 密钥已复制到 backups/secrets-20260822-215812.json  <- 请离线单独保存

那条 Using a password ... can be insecure 是正常的

MySQL 对"在命令行里带密码"一律会提醒一句。备份是在你自己的服务器上跑的， 没有别人能看到那条命令，不用管它。看到三行 [OK] 就是成功了。

就是这么简单，不用 SSH、不用 FTP

你不需要登服务器，也不需要装任何工具。这条命令用的就是部署时那套连接。

backups/ 里的东西比你想的敏感

• mall-*.sql.gz 里有全部买家的邮箱、电话、收货地址
• secrets-*.json 里有服务器密码和支付密钥的加密主密钥

别放到公共网盘的分享文件夹，别发微信给别人。

每天下载太麻烦？

不用每天。按你亏得起多少数据来定：

你的情况	建议频率
刚上线，每天几单	每周一次
每天几十单	每 2~3 天
每天上百单	每天，或做成自动的（见下）

想做成全自动

Windows 用任务计划程序、macOS/Linux 用 crontab， 定时跑一次 python deploy.py backup 就行 —— 它本来就是无人值守的（不会问任何问题）。

⭐ 为什么服务器上的备份不算数

服务器挂了，那 30 份备份跟着一起没

硬盘坏、服务商跑路、账号被封、误删整台机器 —— 这几种情况下，/opt/mall/backup/ 和数据库一起消失。

备份必须在另一个地方还有一份。 这是唯一一条能救命的规则， 而 python deploy.py backup 就是把它拿到"另一个地方"最省事的方式。

最低标准：每周至少跑一次那条命令。 做不到就设个日历提醒。

怎么确认备份是好的

看服务器上最近备份对不对

python deploy.py check

会报「每日备份 cron 已安装」和「有近期备份产物」两条。

看看下载下来的文件

backups/ 里那个 .sql.gz，大小合理就基本没问题（几百 KB 到几十 MB， 取决于你有多少订单）。突然变成几十字节就是出问题了。

系统已经防了一种最坑的情况

备份脚本是先校验产物、再删旧的。

因为反过来的话，某天 mysqldump 失败留下一个空文件， "先删后验"一次就能把 30 天的备份全部换成空文件 —— 而且没人会发现。

真的演练一次恢复

没恢复过的备份不算备份

最常见的事故不是"没备份"，是"备份了三年，出事那天发现全是空文件"。

怎么恢复

恢复会覆盖现有数据，做之前先备份当前状态

python deploy.py backup

目前没有一键恢复命令，需要在服务器上手工执行。步骤：

1. SSH 登上服务器（用 .secrets.json 里那套 host / ssh_user / ssh_password）

ssh root@你的服务器IP

2. 挑一份备份

服务器上本来就存着最近 30 天的，看一眼有哪些：

ls -lh /opt/mall/backup/

要用你电脑上那份的话，先传上去（在本机跑）：

scp backups/mall-20260822-213045.sql.gz root@你的服务器IP:/opt/mall/backup/

3. 停服务 → 恢复 → 起服务（在服务器上）

systemctl stop mall-backend
zcat /opt/mall/backup/mall-20260822-032001.sql.gz | mysql mall
systemctl start mall-backend

中间那条要停了后端再跑

不停的话应用还在往库里写，恢复出来的数据是半新半旧的混合体， 比"数据丢了"更难查。

4. 打开网站确认数据回来了

恢复的是「那一刻」的数据

备份之后产生的订单、会员、评价全部丢失。 所以出事时第一件事是停掉服务，别让新数据继续进来 —— 新数据越多，恢复的代价越大。

不确定怎么操作就先别动

恢复是不可逆的。慌的时候做破坏性操作只会让事情更糟。 先把当前状态备份下来（python deploy.py backup），再慢慢弄。

除了数据库还要备什么

东西	要不要备	说明
数据库	✅ 自动	订单、商品、会员全在这
上传的图片	⚠️ 要自己备	对象存储里，不在数据库备份里
代码	❌	重新部署即可
配置文件	✅ 自动	.secrets.json —— deploy.py backup 每次都会复制一份到 backups/

图片没备份的后果

数据库恢复了，商品都在，但每张图都是裂的。 如果你用的是 MinIO 装在本机，图片和数据库一起没。

用云对象存储（R2/S3/OSS）的话它们自己有多副本，这一条可以放心一些。

常见问题

怎么确认昨晚备份成功了

python deploy.py check

里面有「有近期备份产物」一条。想看细节就 SSH 上去看 /opt/mall/logs/backup.log，每次备份都会记一行。

想立刻备份一次

python deploy.py backup

上线前、做大改动前、批量改数据前，都建议先跑一次。

备份文件放在我电脑哪里了

deploy.py 旁边的 backups/ 文件夹。命令跑完会打印完整路径。

数据被误删了想恢复

第一件事是停掉服务（systemctl stop mall-backend），别让新数据继续写进去 —— 新数据越多，恢复的代价越大。

然后按上面「怎么恢复」那一节走。恢复之前先 python deploy.py backup 把当前状态留一份底。

服务器磁盘满了

30 天的备份可能占不少空间。看一眼：

du -sh /opt/mall/backup/

太大的话可以把保留天数改短 —— 前提是你已经在本机存了一份。