数十个网站数据库批量备份从想起来才手跑mysqldump到自动多目的地双备份方案：19个网站每个独立数据库3台服务器上想恢复才发现上次备份在43天前而且只导出过两个库其他六个库从来没备份过也没有校验过

去年年底帮一个做站群的朋友排查数据丢失问题。他在3台服务器上跑了19个网站，每个站一个独立数据库。备份策略是"想起来就登服务器手动mysqldump一下"。结果有次服务器被挂马，6个站的数据全被清空，想恢复才发现——最近一次备份是43天前的，而且只备份了其中2个库，其他4个库从来没导出过。那次之后他开始找批量备份的方案，我跟着他一起踩了一圈坑。

上面四种方案在真实场景里都有人在用，差别在于你手里到底有多少个库、多少台服务器、有没有人盯着看。下面逐个拆开说。

一、Shell脚本 + Cron：20行代码覆盖十几台服务器的几十个库，但三个地方最容易翻车

这是最常见也最灵活的方案。核心思路很简单：写一个bash脚本，循环遍历所有数据库名，逐个mysqldump导出，压缩，按日期命名，删除过期备份。

一台服务器上如果有多个数据库，用一个循环就搞定了：

如果有多台服务器，加一层SSH远程执行就行。核心是在中控机上通过SSH免密登录到每台目标服务器，远程触发本地的备份脚本，然后用scp或rsync把备份文件拉回中控机统一存储。

但Shell脚本方案有三个地方特别容易翻车，基本上每个第一次写的人都踩过：

Shell脚本方案的优点是零成本、完全可控、想怎么改怎么改。缺点也很明显：没有可视化管理界面，备份状态要靠日志或者自己写通知脚本，服务器多了以后维护起来越来越费劲。所以手里超过5台服务器、20个库以上的，一般会考虑第二个方案。

二、开源管理平台：Databasus和DBackup，一个Web界面管几百个库的备份，不用再登服务器

如果你已经受不了在多个终端窗口之间切来切去、手动检查每个备份日志的日子，开源备份管理平台就是为你准备的。这两个工具都是2025~2026年活跃更新的项目，部署一把就能在浏览器里管理所有数据库的备份任务。

简单说，如果你主要用PostgreSQL和MySQL，追求界面好看、上手快，Databasus更合适。它一个Docker命令就能跑起来，Web界面做得相当精致，添加数据库连接、配置备份计划都是点几下鼠标的事。如果你数据库类型多、存储需求复杂（比如要备份到OneDrive或者Cloudflare R2），DBackup覆盖面更广。它支持的数据库和存储后端都比Databasus多，而且GVS（祖父-父-子）保留策略是个加分项——能自动按日/周/月分层保留备份，而不是一刀切删旧文件。

不过要注意，这两个平台都是部署在一台服务器上的Web应用，它们通过远程连接目标数据库来执行备份。如果目标数据库在内网、和平台服务器网络不通，那就需要配合VPN或者SSH隧道来打通连接。

三、桌面客户端批量备份：Navicat的"批处理作业"看着很美，实际用起来发现一个硬伤

很多人习惯用Navicat或DBeaver管理数据库，自然而然想到：能不能用它们做批量备份？答案是能，但有限制，而且Navicat有一个硬伤很多人不知道。

DBeaver的批量备份：免费版就支持。在DBeaver里可以选中多个数据库，右键"工具→转储数据库"，一次性导出多个库。它本质上是并行调用mysqldump或pg_dump，比手动一个一个导快不少。但DBeaver的自动定时备份需要企业版，免费版只能手动触发。

Navicat的批量备份：Navicat Premium支持创建"批处理作业"——可以添加多个数据库的备份动作到一个作业里，然后设置定时执行。听起来完美，但实际用起来有一个问题：

所以桌面客户端方案更适合数据库数量稳定、不会频繁增减的场景。比如你固定有8个站、8个库，很少变，那Navicat或DBeaver企业版设好定时任务就行。但如果是站群场景、经常新建站点和数据库，桌面客户端每次都要手动更新备份配置，反而比Shell脚本更麻烦。

四、自建中控+Agent：50个库以上的公司级方案，Ansible一把梭

当你管理的数据库数量超过50个、分布在多个机房或云区域，前面三种方案就开始吃力了。这时候需要一套集中管控的架构：一台中控服务器负责调度，每台数据库服务器上跑一个轻量Agent或直接用Ansible无Agent模式推送备份任务。

Ansible是这个场景下最轻量的选择。不需要在目标服务器上装任何额外软件（只需要SSH和Python），在中控机上写一个playbook，定义好所有数据库服务器和要备份的库列表，一条命令就能在所有服务器上并行执行备份：

一条ansible-playbook backup_all_mysql.yml命令下去，所有服务器上的所有数据库同时开始备份，执行结果汇总到中控机终端。比逐台SSH登上去跑脚本的效率高了一个数量级。

Ansible方案的升级版是自己写一个备份管理系统：中控机跑一个调度服务（Python/Go），每台数据库服务器上部署一个小Agent接收任务、执行备份、上报状态。这种方案前期开发成本高，但灵活性最强——可以做备份校验、自动恢复演练、异地多活存储等高级功能。一般只有数据库规模超过100个库、对恢复时间有SLA要求的公司才会走这条路。

五、不同数据库类型的批量备份，工具选错了效率差10倍

前面说的主要是MySQL场景。但现实中很多人不只跑MySQL——PostgreSQL、MongoDB、SQLite、Redis各来一点。不同数据库的批量备份最佳工具完全不一样，用错工具效率能差出10倍。

特别说一下mydumper vs mysqldump的选择。如果你的MySQL数据库单个超过10GB，mysqldump单线程导出的速度会让你等到怀疑人生。mydumper支持多线程并行导出，备份速度比mysqldump快5~10倍，而且可以按表或按行数分片，恢复的时候也能并行导入。批量备份几十个大库的场景，mydumper是刚需。

PostgreSQL这边，pg_dumpall是个被低估的批量备份命令。一条命令就能把整个PostgreSQL实例的所有数据库全部导出到一个文件，不需要写循环脚本。恢复的时候直接psql -f all_databases.sql就全部还原。适合中小型PG实例的快速全量备份。

六、批量备份的存储和保留策略，比备份本身更容易出问题

批量备份几十个库以后，存储和清理变成新问题。一个中型电商站，单库备份压缩后大约200MB，20个库就是4GB/天，一个月120GB，一年1.4TB。如果不做保留策略，硬盘迟早撑爆。

DBackup原生支持GVS策略，在备份任务里直接配置就行。用Shell脚本的话，需要自己写日期判断逻辑，或者用类似find -mtime的分层清理脚本。

七、不同场景的批量备份方案怎么选，四种情况直接抄答案

说了这么多工具和方案，落到具体场景里到底怎么选？下面是四种最常见的批量备份场景，每个场景给一个直接可用的推荐方案。

八、批量备份上线前必须做的一步：恢复演练，90%的人跳过了

备份的意义不在于"备份了"，而在于"能恢复"。批量备份尤其容易出这个问题——你看到50个库的备份文件都在目录里，大小也正常，就以为万事大吉。但其中可能有几个库的备份是损坏的、不完整的、或者缺少关键表结构。

批量备份的恢复演练不需要逐个库完整恢复，太费时间。一个折中方案是：随机抽检。每次备份完成后，从所有备份文件中随机抽3~5个，恢复到临时数据库，检查表数量和行数是否与源库一致。

这套恢复演练流程可以写成脚本自动执行。如果用的是Databasus或DBackup，它们自带备份校验功能，可以设置自动验证。

九、五个容易被忽略的批量备份细节，每一个都可能让你白干

批量备份涉及的服务器和数据库多了以后，很多单库备份不是问题的地方，批量场景下会放大成严重问题。

十、费用估算：四种方案花多少钱，从零元到月投入几百块

大多数中小团队的实际情况是：Shell脚本方案先跑着，等数据库数量超过20个、维护开始吃力了，切到Databasus或DBackup。这是成本最低、风险最小的渐进路线。

批量备份这件事，核心不在于工具多高级，而在于三件事：自动化（不需要人记着去跑）、可验证（备份完知道文件是完整的）、可追溯（三个月前的备份能找到且能恢复）。不管选哪种方案，把这三条做到位了，数据安全这件事就稳了。

另外，备份文件至少存两个不同的物理位置。本地服务器存一份，云存储（S3/OSS/COS）或另一台异机房的服务器存一份。如果所有备份都在同一台服务器上，这台服务器坏了就是全部数据都没了，备份等于白做。