linux服务器数据库怎么备份,备份命令有哪些？

备份Linux服务器上的数据库，最稳妥的答案是：根据数据量和业务容忍度，组合使用逻辑备份（如mysqldump）与物理备份（如XtraBackup），并通过定时任务和异地存储形成闭环。单靠一条命令解决不了所有问题，真正可靠的备份方案，需要把备份、校验、恢复演练三个环节串起来。

先搞清楚你的数据库属于哪种类型

不同数据库的备份工具和策略差异很大,动手之前先确认自己用的是哪一类，Linux服务器上最常见的是MySQL/MariaDB和PostgreSQL，其次是MongoDB、Redis这类NoSQL，普通企业场景中，MySQL系占了相当大的比例，所以下文以MySQL为主展开，同时给出PostgreSQL的关键命令。

加载中

21.Linux任务计划实现mysqldump自动备份数据库

特健全的教授

167523-

原视频地址

MySQL的备份方式可以粗分为两类：

• 逻辑备份：用mysqldump导出SQL语句，生成可读的文本文件，优点是简单、跨版本兼容性好，缺点是数据量大时备份和恢复都慢。
• 物理备份：直接复制数据文件目录，配合工具保证一致性，备份速度快，恢复也快，但要求数据库版本和操作系统基本一致。

行业共识认为,生产环境应该物理备份与逻辑备份搭配使用，逻辑备份用于小规模数据或误删单表后的快速恢复，物理备份用于大规模数据的完整恢复场景。

选择备份策略：没有万能方案，只有合适组合

备份策略的核心指标是RPO（恢复点目标）和RTO（恢复时间目标），RPO决定你最多能丢多少数据，RTO决定你多久能恢复业务，下面这个对比可以帮你快速定位需求：

小数据量场景（50GB以下）

直接用mysqldump做每日全量备份,保留最近7天或15天的备份文件，命令如下：

mysqldump -u备份账号 -p --single-transaction --quick --routines --triggers --events mydatabase > /backup/mydatabase_$(date +%Y%m%d).sql

--single-transaction参数很关键，它利用InnoDB的事务特性，在不锁表的情况下获得一致性快照，备份完成后记得用gzip压缩，SQL文件压缩后体积能缩小到原来的五分之一左右，节省磁盘空间。

大数据量场景（100GB以上）

mysqldump在这种规模下表现很差,导出耗时数小时，恢复更慢，业内专家指出，百GB以上规模的MySQL实例，优选使用Percona XtraBackup做物理备份。

xtrabackup --backup --target-dir=/backup/full_$(date +%Y%m%d) --user=备份账号 --password=

这个命令直接复制InnoDB数据文件,备份速度比mysqldump快一个数量级，恢复时先应用日志，再还原目录，步骤为：

xtrabackup --prepare --target-dir=/backup/full_20260101
xtrabackup --copy-back --target-dir=/backup/full_20260101

对数据丢失零容忍的场景

物理备份加上binlog增量日志,binlog记录了所有写操作，配合全量备份，可以将数据库恢复到任意时间点，恢复流程是：先恢复最近一次全量备份，再重放全量备份之后的binlog，直到故障发生前的那一刻，这个方案RPO理论上是零，代价是需要额外开启log_bin并妥善管理binlog文件。

linux服务器mysql数据库备份命令怎么写才规范

很多教程直接让你用root账号执行备份,这是典型的错误示范，用root做备份存在两个隐患：一是密码暴露风险大，二是误操作概率高，正确做法是创建专用备份账号，只授予备份所需的最小权限：

CREATE USER 'backup_user'@'localhost' IDENTIFIED BY '强密码';
GRANT SELECT, SHOW VIEW, RELOAD, REPLICATION CLIENT, EVENT, TRIGGER ON . TO 'backup_user'@'localhost';

权限说明：SELECT和SHOW VIEW用于读取数据，RELOAD用于--single-transaction的全局锁，REPLICATION CLIENT用于读取binlog位置，EVENT和TRIGGER确保导出存储过程和触发器。

核心安全配置清单

备份账号建好后,还应在MySQL配置文件中调整两个参数：

• max_allowed_packet：调整为64M或更大，防止大字段导致备份失败
• innodb_strict_mode：保持默认开启即可

linux数据库自动备份脚本怎么写的完整过程

手动执行备份只是起点,生产环境必须做自动化，写一个健壮的备份脚本，无非是以下几个步骤，但不建议直接复制网上的脚本，你需要理解每段逻辑。

第一步：定义变量和目录结构

#!/bin/bash
BACKUP_BASE="/data/db_backup"
BACKUP_DAY=$(date +%Y%m%d)
BACKUP_DIR="${BACKUP_BASE}/${BACKUP_DAY}"
MYSQL_USER="backup_user"
MYSQL_PASSWORD="你的密码"
DATABASES="demo_db,order_db"

备份目录按日期划分,方便后面的清理策略按天切分。

第二步：创建目录并执行备份

mkdir -p "${BACKUP_DIR}"
for db in $(echo ${DATABASES} | tr ',' ' '); do
    mysqldump -u${MYSQL_USER} -p${MYSQL_PASSWORD} --single-transaction --quick "${db}" | gzip > "${BACKUP_DIR}/${db}_$(date +%H%M).sql.gz"
done

注意mysqldump管道直接输出到gzip，避免中间产生未压缩的临时文件，这样写入磁盘的同时完成压缩，减少IO开销。

第三步：校验备份文件的完整性

这一步大多数人会忽略,但恰恰最该重视，用gunzip -t检查压缩包是否损坏：

find "${BACKUP_DIR}" -name ".gz" -exec gunzip -t {} ;

也可以查看压缩包中最后一条SQL语句是否为-- Dump completed，来判断导出是正常结束的。

第四步：自动清理过期备份

磁盘被备份文件打满,是运维事故高发原因，保留7天本地备份，多余删除：

find "${BACKUP_BASE}" -type d -name "2026" -mtime +7 -exec rm -rf {} ;

这段逻辑确保备份文件不会无限增长,把磁盘空间耗尽的风险提前消化。

第五步：配置crontab定时任务

crontab -e
# 每天凌晨2点执行备份脚本
0 2    /usr/local/bin/mysql_backup.sh >> /var/log/mysql_backup.log 2>&1

凌晨2点通常是业务低峰期,备份对线上性能的影响最小，日志重定向到独立文件，方便事后排查。

一个更稳妥的送异地方案

本地备份只是第一道防线,服务器硬盘故障、机房断电、勒索病毒都会让本地备份和原数据一起灰飞烟灭，Linux自带的rsync结合免密认证，可以把备份文件推送到另一台服务器或对象存储。

rsync -avz --delete /data/db_backup/ backup@192.168.1.100:/data/backup_repo/

在目标服务器上配置SSH密钥认证,就能实现无人工干预的异地同步，近年来的实践显示，异地备份是应对勒索病毒最有效的手段之一攻击者拿不到远端那份历史备份，你就掌握了恢复的底牌。

Linux服务器数据库备份方案落地还要补两个坑

备份做好只是完成了上半场,下半场要证明备份真的可用。

恢复演练的实操步骤

定期做恢复演练,在测试环境搭一个数据库实例，从最近的备份文件完整恢复一次，重点是验证两个问题：备份文件是否完整、恢复出来的数据是否一致，恢复后抽查几张核心表的数据，对比源库的记录数，如果记录数对不上，备份流程中存在逻辑漏洞，需要排查。

流程用文字表达就是：

1. 准备一台与生产环境同版本的测试服务器
2. 同步最新的备份文件到测试机
3. 解压备份文件,执行恢复导入
4. 检查恢复后的数据库可访问性
5. 对比核心业务表的记录数和关键日期字段

数据库和备份文件都加密的意识

MySQL的数据文件默认不加密,备份出基本等同于数据裸奔，建议用GPG对备份文件加密再传输，或者至少使用openssl enc做对称加密：

openssl enc -aes-256-cbc -salt -in demo_db_20260101.sql.gz -out demo_db_20260101.sql.gz.enc -k 加密口令

解密恢复时用同样的口令反向操作,成本很低，但能让备份数据在泄露场景下依然安全。

Q&A：linux服务器数据库怎么备份数据库常见疑问

问：数据库每天都会更新，增量备份和全量备份怎么配合？

配合策略是：每周日做一次全量备份，周一至周六做每天的增量备份，增量备份通过binlog实现，备份内容是从上次全量备份以来的所有binlog文件，恢复时先还原全量备份，再按顺序重放binlog，即可恢复到增量时间点，这样既控制了备份文件体积，又能把数据丢失窗口压缩到很小。

问：没有专门备份工具的情况下，直接tar打包数据库文件目录行不行？

如果数据是MyISAM引擎且业务处于停写状态,tar打包文件目录可以工作，但对于InnoDB引擎，直接打包数据目录得出的备份文件大概率是不一致的，因为InnoDB的缓冲池中可能还有未落盘的数据，文件系统层面的文件快照无法保证事务一致性，除非你的表都是MyISAM、且能接受停机备份，否则不建议这样做，云服务器厂商提供的磁盘快照功能倒是可以绕过这个问题，但快照一致性依赖于底层存储机制，下单前要和厂商确认是否支持崩溃一致性。