安全扫描报告里有一行高危：/backup/db-20261001.sql.gz可以匿名下载，响应200，文件大小一点二个G。这个路径在网站根目录下，浏览器直接输入就能存到本地。库里存着三十七万条用户记录和全部订单。
备份脚本当初为了省事，mysqldump的输出直接落在网站目录里的backup文件夹，理由是面板里能点着下载，不用再开FTP。目录列表是关着的，访问/backup/返回403。问题在于关掉列表只挡住了浏览，挡不住按名字直接取。
文件名有规律是最要命的一处，db-加日期加.gz，看一次就知道下一次叫什么。路径还会从别的地方漏出去，页面报错时打印的绝对路径、前端打包残留的sourcemap、代码仓库的历史提交、服务器上别人的账号，任一处露出来就等于把地址送出去。这类文件一旦被抓到，通常不会立刻被用，而是先进别人的数据集，过几个月才出现在撞库名单里。压缩包里的内容比想象中全，用户表的手机号、邮箱、密码哈希、注册IP，订单表的收货地址，后台账号也在同一份dump里。密码如果还是老式哈希，跑一遍字典就能还原一部分。
你先确认有人拿走过没有。翻access日志，筛出对.sql、.gz、.zip、.tar的请求，看状态码和字节数。状态200且字节数接近文件大小的，就是完整下载过一次。日志按天切过、只留了七天的，翻不到更早的，只能按最坏情况算。
处置顺序是先把入口堵上，再挪文件，最后处理已经泄露的数据。nginx里加一条location ~* \.(sql|gz|zip|tar)$直接return 404，比删文件快，也不会因为漏了某个目录又露出来。文件挪到web根目录之外，比如/data/backup，属主给一个不能登shell的账号，权限700。后台如果还要下载备份，走一段鉴权脚本读文件再输出，不要靠猜路径。
目录权限这块，网站根目录本身不该有写权限给运行用户。备份能写进去，说明这一层本来就是开的，顺手一起收掉。上传目录必须可写的单独放行，别整个根目录放开。
正确的备份位置在站点目录之外，最好在另一块盘或另一台机器。保留策略按天滚动，本地留七份，异地留四份周备份。备份脚本写完文件顺手算一次校验和，恢复的时候先比校验和，能避免拿到半截文件还以为备份成功。异地那份建议加密，密钥不要跟备份放在同一个地方，否则等于没加密。
已经泄露的那份按最坏情况处理，后台密码全部重置，用户侧发一次强制改密，支付和短信接口的密钥轮换一遍。日志里能查到下载的源IP，数量不多的话可以按IP段封掉，但别指望这能挽回什么。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
