做了这么多年Linux运维我对Linux数据备份与还原这件事的态度经历了三个阶段第一次数据丢失时的手忙脚乱中间几年对备份脚本的盲目自信以及一次真实事故之后的彻底重构。去年一台业务服务器磁盘报错文件系统变成只读我安慰自己没事有备份翻出来一看才发现最近一次全量备份是一个月前的按周做的增量因为脚本里一个路径写错连续三周空跑。最后靠数据库binlog恢复到故障前两小时那两小时的数据终究还是丢了。那次之后我把备份和还原当成两件事来对待重新设计了一整套方案。这篇实战指南就是那套方案的完整记录覆盖了备份策略设计、文件级备份tar/rsync、镜像级备份dd/LVM快照/再生龙Clonezilla、数据库备份还原MySQL/PostgreSQL最后还会专门讲还原演练和那些只有真正出过事才懂的坑。不管你是刚接手Linux服务器的新手运维还是写了好几年备份脚本的老手希望能帮你少走一些我走过的弯路。1. 备份前先想清楚你要从哪类事故里活过来备份方案不是一个工具选型问题而是一个风险决策问题。你花多少成本做备份应该取决于你愿意为数据丢失这件事承担多大代价。在我接触过的服务器环境里导致数据丢失的原因通常就这几类误删文件或误执行命令、磁盘或硬件故障、勒索病毒或入侵者破坏、机房级别的事故断电、火灾、水淹以及最容易被忽视的——备份机制本身失效。1.1 给数据分个类别一把抓我习惯把服务器上的数据分成三类每一类的备份策略完全不同配置类数据/etc下的各种配置文件、systemd服务单元、Nginx和Apache的站点配置、网络配置、定时任务、SSH密钥。特点是体量小、变化不频繁、但影响面大丢一个配置文件可能导致整个服务起不来。应用数据数据库文件、用户上传的文件、代码仓库、日志。特点是大、持续在写、丢失后重建成本极高。系统数据操作系统本身、已安装的软件包、内核和引导配置。特点是重装成本高但可以用镜像方案快速恢复。针对这三类数据我的默认方案是配置类用tar定期打包保留多个历史版本应用数据用rsync同步加数据库专用备份工具系统数据用镜像级备份Clonezilla或者LVM快照做兜底。分类的另外一个好处是你知道每种数据的恢复手段是什么不会出现明明只是配置文件坏了却要整个重装系统的尴尬。1.2 3-2-1备份原则怎么落地3-2-1原则很简单至少3份副本2种不同介质1份异地存放。这个原则本身没问题但初次落地时容易理解偏。我重点说几个实际执行中的理解首先生产机上正在使用的数据不能算作一份可靠的副本。磁盘物理损坏、误删、勒索病毒加密这三种情况都会把本机数据一起带走。真正算数的副本是独立于在线数据之外的拷贝。其次两种介质指的是不同类型的存储不一定是磁带和磁盘才算。我现在的常用组合是本机一块独立数据盘和系统盘分开内网另一台备份服务器加上远端的对象存储。三份副本分别落在三个不同的存储位置这样即使某一层出了问题至少还有另外两层兜底。第三异地这份要解决的是整个机房都完蛋的场景。如果公司没有跨机房或云端预算退而求其次至少把备份放到不同物理位置的另一台机器上。我会用rclone或restic把备份加密后推到对象存储既解决了异地问题也顺便解决了备份文件被拖走就能读的隐患。容量规划我给一个参考算法假设要备份的数据总量是500GB每日增量大约10GB计划本地保留最近7天增量、备份服务器保留最近30天、远端对象存储保留90天。那么本地需要约570GB备份服务器约800GB远端约1.2TB实际购买时再留30%的余量因为数据库备份临时文件、日志产生的额外消耗经常被低估。1.3 备份窗口、一致性和RTO/RPO备份不是任何时候都能做的这里有两个概念要先理清备份窗口和一致性。备份窗口指的是可以安全执行备份的那段时间。数据库在业务高峰不停写入的时候直接去备份数据文件拿到的东西很可能是崩溃状态的恢复时表损坏、数据对不上都是常事。所以绝大多数生产环境会把备份任务放在凌晨2点到4点这种低峰期再配合数据库本身的一致性机制MySQL的FLUSH TABLES WITH READ LOCK、PostgreSQL的pg_start_backup或者直接依赖InnoDB的MVCC做逻辑备份。一致性有个容易被忽略的细节你备份的多个文件之间必须属于同一个时间点。最典型的就是数据库数据文件、binlog和配置文件必须来自同一个备份时刻否则恢复出来数据逻辑是错乱的。这也是为什么我强烈建议数据库备份用专门工具而不是直接tar数据库目录。RPO和RTO是两个必须写进方案的数字。RPO恢复点目标是你能接受最多丢多少数据它决定备份频率和要不要做日志归档RTO恢复时间目标是业务最多能停多久它决定你用什么样的恢复手段。这两个数字不是拍脑袋定的要跟业务方确认。如果RPO是1小时每天一次全量备份完全不够必须配合binlog或WAL归档才能满足。2. 文件级备份实战tar和rsync的正确姿势文件级备份是最基础的一层适合配置类数据和中小体量的应用数据。这一层用两个工具就够了tar做打包归档rsync做同步和增量。工具都很老但用好的没几个人。2.1 tar打包备份命令很简单细节很坑tar是全量打包每次都会把所有文件读一遍。它的优势是简单、可靠、适合分发归档劣势是数据量大时又慢又占空间。备份配置文件这种小体量数据tar足够了。最基本的用法tar -czpf /backup/etc_backup_$(date %F).tar.gz /etc这里有三个细节新手最容易翻车。第一加-p是为了保留权限和属主信息不加的话恢复出来文件属主可能变成当前用户。第二恢复时必须用--same-owner和--preserve-permissions才能把权限完整还原光靠存档时加-p不够。第三$(date %F)是为了生成带日期的文件名这个习惯很重要没有日期你根本不知道这份备份是什么时候的。备份Web目录并排除缓存tar -czpf /backup/www_$(date %F).tar.gz --exclude/var/www/cache --exclude/var/www/tmp /var/www排除目录时要注意--exclude的位置放在源路径前面路径要写绝对路径否则匹配不到。另外如果目录里有正在写入的日志文件tar会给出file changed as we read it的警告这说明备份出来的文件可能不在同一个时间点后面我会专门讲这一类一致性问题的处理。恢复时的黄金习惯是永远先恢复到临时目录检查无误后再覆盖原路径。mkdir -p /tmp/restore tar -xzpvf /backup/etc_backup_2025-01-01.tar.gz -C /tmp/restore diff -r /tmp/restore/etc /etc我见过太多人直接解压覆盖结果备份文件本身有问题线上环境被弄得更糟。先恢复到临时目录的成本很低但能避免最糟糕的二次事故。2.2 rsync增量同步与硬链接快照rsync是同步工具不是归档工具。它的核心特点是增量传输只把源端变化的部分传过去支持断点续传还能通过SSH加密传输。用来做日常同步和远程备份非常合适。基础用法rsync -avz --delete /var/www/ backup-server:/backup/www/-a是归档模式保留权限、属主、时间戳和软链接-v是verbose-z是压缩传输--delete表示把目标端存在但源端已经删除的文件一并删除这样目标端始终是源端的镜像。先说一个很多人踩过的坑源路径末尾的斜杠。rsync /var/www和rsync /var/www/的行为完全不一样前者把www这个目录本身同步过去结果是目标端变成/backup/www后者只同步www里面的内容结果是/backup目录下直接就是www的内容。写脚本前务必确认你要的是哪一种。增量备份怎么做rsync本身每次都同步全量文件内容但可以通过硬链接实现每天一个全量目录实际空间只占一份的效果rsync -av --link-dest/backup/www/$(date -d yesterday %F) /var/www/ /backup/www/$(date %F)/--link-dest的意思是如果目标文件内容和link-dest指向的目录里的同名文件一致就不重新存储而是建立硬链接。这样每天生成一个完整的目录结构未变化的文件通过硬链接共享同一个inode既保留了任意一天都能直接找到完整文件的方便又让空间消耗接近增量备份。恢复时只要按日期目录取文件就行不需要先还原全量再叠增量容错性比传统增量备份高很多。2.3 备份脚本与定时任务的正确写法文件级备份最终要落到脚本和定时任务里。下面是我常用的一个带轮转清理的rsync备份脚本#!/bin/bash # /usr/local/bin/backup_www.sh export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin BACKUP_ROOT/backup/www DATE$(date %F) YESTERDAY$(date -d 1 day ago %F) KEEP_DAYS30 mkdir -p $BACKUP_ROOT rsync -av --link-dest$BACKUP_ROOT/$YESTERDAY \ /var/www/ $BACKUP_ROOT/$DATE/ find $BACKUP_ROOT -maxdepth 1 -type d -mtime $KEEP_DAYS -exec rm -rf {} \;配合crontab30 2 * * * /usr/local/bin/backup_www.sh /var/log/backup_www.log 21定时任务里有两个问题很隐蔽。第一cron执行时的环境变量和登录shell不一样PATH很精简脚本里如果不写绝对路径或没在开头export PATH经常出现手动执行正常定时任务里找不到命令的诡异现象。第二cron的输出默认会发给root的邮箱不重定向的话邮箱会被塞爆务必把标准输出和标准错误都写到日志文件。另外我建议在脚本最后加一个成功率检查。比如rsync结束后用$?判断退出码非零就发告警再检查生成的文件大小如果明显小于预期阈值就说明同步可能出了问题。备份的失败通常不是一次性的是这种小问题日积月累等真的需要恢复时才发现已经坏了好几周。3. 镜像级备份dd、LVM快照和再生龙组合拳文件级备份解决的是某个目录坏了的问题解决不了整个系统起不来的问题。系统盘损坏、引导分区丢失、机器被入侵后系统文件被篡改这些场景需要镜像级的备份方案。这一层的工具从原始到现代都有我按使用场景讲。3.1 dd整盘克隆什么场合用什么场合别用dd是块级别的复制工具它不管文件系统直接把整个块设备的内容逐块拷贝。基础用法dd if/dev/sda of/backup/sda.img bs64M statusprogressbs64M是块大小。很多人用默认512字节那速度简直灾难。我实测过对普通SATA机械盘64M块大小比默认快几十倍对SSD效果也更明显。这里有个常识dd读的是整块盘包括空闲空间即使盘里只有20GB数据1TB的盘也会读出1TB的镜像。dd的缺陷很明显镜像体积等于磁盘容量、无法做增量、恢复时要求目标盘容量不小于源盘、备份过程要求文件系统处于静止状态否则镜像可能不一致。所以dd不适合做例行备份它更合适的场景是系统迁移前做一次整盘安全快照、把一块盘完整克隆到另一块同容量盘、或者是取证场景下做只读镜像。也就是说日常的每日备份交给rsync和数据库工具dd只用于大事件之前的保险。3.2 LVM快照在线备份的一致性好帮手如果服务器用了LVM管理磁盘LVM快照是做一致性备份的利器。原理上LVM快照是COW写时复制创建快照后原始卷上的数据没有变化的部分继续读原始卷将要被修改的块在修改前先复制到快照空间。这就意味着快照创建那一刻的数据状态被冻结住了后续对数据的修改不会影响快照内容。用LVM快照做备份的标准流程# 创建快照大小一般给原始卷的10%-20% lvcreate -L 50G -s -n snap /dev/vg0/lv-data # 挂载快照 mkdir -p /mnt/snap mount /dev/vg0/snap /mnt/snap # 从快照目录做tar或rsync此时业务还在正常写 tar -czpf /backup/data_$(date %F).tar.gz /mnt/snap/ # 完成后卸载并删除快照 umount /mnt/snap lvremove /dev/vg0/snap有几个细节要记住。快照大小要根据备份耗时和数据变化速率来规划如果备份过程太慢数据变化超过了快照空间快照会自动失效备份就废了。所以务必要监控快照的使用率别等到满了才发现。另外快照里的文件属于某一次写操作之前的旧状态应用层的一致性还是要靠业务自己保证比如数据库目录里的文件如果数据库不是用安全模式停过再备份快照也拿不到逻辑一致的数据库状态。3.3 再生龙备份与还原Linux服务器的完整流程再生龙Clonezilla是开源社区里做整机备份最成熟的工具之一基于Parted Magic运行支持ext4、xfs、btrfs等多种文件系统。我用它来做系统盘的定期整机镜像。备份的完整流程是这样的下载Clonezilla Live的ISO用dd写入U盘或者用balenaEtcher这类工具刻录。目标服务器从U盘启动进入引导菜单选择第一项Clonezilla Live。选择语言、键盘布局然后进入核心界面选择device-image设备映像模式。备份时选保存磁盘为镜像还原时选从镜像恢复磁盘。选择要备份的磁盘或分区再选择镜像文件的存放位置可以是本地磁盘、移动硬盘也可以通过网络访问Samba/NFS服务器。按照提示设置压缩级别和分片大小开始备份。还原时Clonezilla会重建分区表和引导记录。这个特性是双刃剑好处是还原完成后不需要额外处理引导坏处是如果目标机器和源机器硬件差异很大比如RAID卡型号不同、磁盘控制器驱动不一致还原后很可能起不来。遇到这种情况恢复后需要在救援模式下重建initramfs把正确的磁盘驱动打进去。我的建议是用Clonezilla做的系统镜像主要用于同型号硬件或者虚拟机模板这种场景。物理机跨硬件迁移时老老实实按新硬件重装系统再把应用数据还原上去比寄希望于镜像万能可靠得多。3.4 不同层级的备份方案怎么组合镜像备份、文件备份、数据库备份不是互斥的而是层层兜底的关系。以一台典型的Web应用服务器为例我的方案是系统盘整机镜像每半个月用Clonezilla做一次存放在内网共享存储解决系统崩溃后快速恢复的问题。/etc配置目录和Web目录每天用rsync同步到备份服务器解决日常误改、误删的问题。MySQL数据库每天定时mysqldump逻辑备份每周一次XtraBackup物理备份binlog实时归档既能快速恢复当日数据又能做时间点恢复。优先级从高到低是数据库、应用数据、配置文件、系统镜像。原因很简单系统盘坏了重装一个系统加配置顶多半天数据库如果丢了好几年的业务数据就真的回不来了。备份方案设计的第一步永远是把最贵的数据保护等级提上去。4. 数据库备份与还原逻辑备份和物理备份的取舍文件级备份里特意没有把数据库目录算进去因为数据库的备份有独立的工具和独立的一致性要求。这一节把最常用的MySQL和PostgreSQL讲清楚。4.1 MySQL的mysqldump逻辑备份mysqldump是逻辑备份工具导出的是一堆SQL语句。InnoDB引擎下最标准的全库备份mysqldump --single-transaction -u backup_user -p --databases mydb /backup/mydb_$(date %F).sql--single-transaction是关键它基于InnoDB的MVCC机制在不锁表的情况下拿到一个一致性的快照。如果你的表里有MyISAMMVCC对它无效必须加--lock-tables或者干脆把MyISAM表先转成InnoDB。生产环境已经2025年了还在用MyISAM的表尽量迁移到InnoDB吧这不只是备份的问题。恢复就是导入SQLmysql -u root -p /backup/mydb_2025-01-01.sql导入时有一个需要注意的细节。如果当时用--databases导出文件里包含CREATE DATABASE和USE语句直接导入没问题如果当时用了--no-create-db或者只导出了单表就要提前自己创建数据库并指定库名导入mysql -u root -p mydb /backup/mydb_table_2025-01-01.sql逻辑备份的优势是文本格式、跨版本兼容性好、可以单独恢复某张表或者某条数据劣势是大数据量时导出导入都慢而且恢复时间不可控。几百MB的小库用mysqldump完全够几个TB的大库还是得靠物理备份。4.2 MySQL的XtraBackup物理备份Percona XtraBackup是物理备份工具直接拷贝InnoDB数据文件同时通过redo log保证一致性。备份命令xtrabackup --backup --target-dir/backup/xtra/20250101 --userbackup_user这里的--backup只是拷贝数据文件恢复前必须执行prepare把事务日志应用进去让文件达到一致状态xtrabackup --prepare --target-dir/backup/xtra/20250101然后copy-back到数据目录xtrabackup --copy-back --target-dir/backup/xtra/20250101 chown -R mysql:mysql /var/lib/mysqlchown那步很容易漏数据文件属主不对MySQL服务起来就会因权限问题报错或拒绝启动。物理备份的优势是恢复速度快特别适合上TB级的大库劣势是工具依赖Percona分支备份格式和MySQL版本强相关跨大版本恢复会有麻烦。4.3 PostgreSQL的pg_dump与WAL时间点恢复PostgreSQL的逻辑备份工具是pg_dump。自定义格式的全库导出pg_dump -h localhost -U postgres -Fc mydb /backup/mydb_$(date %F).dump-Fc生成的是自定义格式支持用pg_restore选择性地导入部分对象比纯SQL灵活。恢复pg_restore -d mydb /backup/mydb_2025-01-01.dump如果目标是空库也可以直接createdb mydb pg_restore -d mydb。pg_dump做的是逻辑备份适合中小库大数据量的PostgreSQL一般用pg_basebackup做物理备份。PostgreSQL真正强大的地方是WAL归档加PITR时间点恢复。配置思路是开启wal_levelreplica或logical设置archive_modeon把archive_command指向一个脚本让WAL文件持续归档到共享存储或远程服务器。恢复时先从全量备份恢复基础数据然后配置recovery_target_time指向误操作之前的时间点PostgreSQL会把归档的WAL从全量备份位置重放到目标时间。这套机制的威力在于你可以把数据库恢复到过去任意一个时间点而不是只恢复到最后一次备份。代价是配置复杂度高、归档文件要持续维护、恢复流程也要演练。如果是核心交易系统这个成本是值得的。如果是一个内容站每天pg_dump一次也够了。4.4 数据库备份的保留策略与校验数据库备份文件比普通文件更值钱保留策略要单独定。我的默认配置每日逻辑备份保留14天每周物理备份保留8周月度备份保留12个月归档日志binlog/WAL保留30天核心库可以延长到90天每条备份必须有校验信息。mysqldump之后顺手生成md5md5sum /backup/mydb_$(date %F).sql /backup/mydb_$(date %F).sql.md5恢复前先校验避免备份文件在传输中损坏导致恢复失败。我遇到过几次恢复出来表结构都在但数据缺了一片的情况最后排查就是备份文件在拷贝到远端时出了问题而校验能第一时间发现。binlog和WAL归档的本质是增量日志。很多人只做全量备份不做日志归档一旦需要恢复到今天中午12点这种时间点就无能为力。RPO要求是1小时以内的系统日志归档不是可选项是刚需。5. 还原演练灾难恢复计划不是文档是流程备份做得再勤如果没验证过能还原那只是一堆躺在存储里的数据。我见过太多公司灾难恢复计划写得漂漂亮亮真出事时照着文档走每一步都卡壳。所以我一直强调灾难恢复计划的价值不在文档本身在还原演练。5.1 季度还原演练清单我的习惯是每季度在测试环境做一次全流程还原演练直接模拟生产机的故障。清单是这样的从最近的备份中取回全量备份和最后一次增量。准备一台同版本操作系统的干净机器先不要装任何业务软件。按文档顺序执行还原系统镜像或分区还原、配置文件还原、应用数据还原、数据库还原。启动所有服务逐项检查业务功能是否正常比如页面是否打开、数据库能否读写、日志有没有报错。记录每一步实际耗时对照RTO看是否达标。演练过程中最容易发现的问题有几个还原文档里写的命令和服务器的实际环境对不上备份文件存储在NFS但演练环境访问不了NFS数据库还原之后忘了改权限导致服务起不来。这些问题每一个都真实发生过而它们的最佳发现时机是在演练环境不是在故障现场。演练的频率和范围要量力而行。实在做不到每季度至少每半年做一次核心数据库的还原演练。我个人的经验是数据库的还原演练价值最高因为数据库恢复步骤最复杂、最容易出错而它又恰恰是最不能丢的数据。5.2 备份有效性的验证方法除了大演练日常对备份有效性的抽查也要做。文件级备份可以这样快速验证tar -tzf /backup/etc_2025-01-01.tar.gz | head -50这条命令列出备份包里的内容确认结构完整。更严格的验证是解压到临时目录后和源文件做对比tar -xzf /backup/www_2025-01-01.tar.gz -C /tmp/restore diff -r /tmp/restore/www /var/www数据库备份的验证更直接把dump文件导入一个临时的空库然后执行CHECK TABLE或SELECT count(*)对比关键表。这一步成本很低但能提前发现备份里藏着的问题比如mysqldump导出过程中遇到锁超时导致数据不完整。备份脚本自身也要有自检机制。我习惯在脚本里加这几行rsync -av --delete /var/www/ backup-server:/backup/www/ || { echo rsync failed; exit 1; } [ $(stat -c%s /backup/latest.sql) -ge 104857600 ] || echo backup file too small如果退出码非零直接告警如果文件大小低于预期阈值也告警。自动化自检比人工巡检可靠得多人工巡检总会有漏掉的那一天。5.3 灾难恢复计划模板里的必备章节网上随手能搜到很多数据备份灾难恢复计划模板我参考过不少真正落到自己环境时必须补充进这些内容模板才不会变成废纸备份资产清单每种数据在哪个目录、用什么工具、什么周期备份、备份存储在哪里。每个环节的责任人谁来执行备份、谁来执行还原、谁有权审批恢复操作。没有责任人紧急情况下没人敢动手。关键机器的硬件信息磁盘控制器型号、引导方式BIOS还是UEFI、文件系统类型、磁盘分区布局。恢复时这些信息直接决定操作方向。还原步骤的细粒度命令不要写恢复数据库这种模糊句子要写到具体命令和参数。每类数据的目标RPO和RTO要让所有人知道这个备份方案在什么区间内是有效的超出区间比如RPO是1小时却只有每日备份就必须提前预警。模板是工具不是目标。我见过太多团队的灾难恢复计划文档写得像获奖论文一年都没翻过一次。真正有效的办法是写完文档后拿它做一次还原演练演练暴露的问题就是文档下一版要补的内容。迭代几轮之后这份文档才是真正可用的。6. 我在备份还原实战中踩过的坑最后这一节都是我在真实故障排查中一步步趟出来的经验。有些坑很小但时机不对就会造成大事故。6.1 文件权限和属主是最容易翻车的地方tar恢复时最常见的问题就是权限和属主错乱。如果当初打包时没有保留权限信息或者恢复时用的是普通用户还原出来的文件属主可能变成执行恢复的用户。对SSH密钥、Nginx配置这类权限敏感的文件来说属主不对等于服务起不来、远程登录被拒。我的习惯是恢复完成后不要立刻启动服务先检查关键文件的属主和权限。可以用一条命令批量检查find /etc -name *.conf -o -name *.key | xargs ls -l更稳妥的做法是尽量用rsync -a从备份目录同步回原路径因为rsync的-a参数会把权限、属主、时间戳一起恢复比tar解压靠谱得多。6.2 file changed as we read it背后的不一致风险运行中的服务目录做tar打包经常会出现这个警告。它的意思是tar读取文件的过程中文件内容被其他进程修改了。这个警告不能忽略它意味着备份包里的某些文件可能来自不同时间点——这对配置文件影响不大但对数据库文件和日志文件就是致命的。处理办法分情况如果是配置类目录警告可以容忍但要在文档里记录如果是数据库目录必须停下来改用数据库工具或者LVM快照方案如果是日志文件这种写频繁的目录要么先做日志轮转再备份要么用rsync同步并在脚本里接受最后一个日志文件可能不完整这个事实。6.3 磁盘空间判断失误导致备份中断备份脚本最常见的故障之一就是目标磁盘写满。tar或rsync在磁盘满时会直接退出留下一个半截文件而这个半截文件看起来和完整文件没什么区别散落在备份目录里。等真正恢复时才发现文件不完整那真是最绝望的时刻。处理办法有两个一是把备份目录放在独立文件系统上不要和根分区共用这样备份占满磁盘不会拖垮系统二是在脚本里提前检查磁盘剩余空间不够就告警退出REQUIRED8388608 # 至少需要8GB空间KB AVAILABLE$(df -P /backup | awk NR2{print $4}) if [ $AVAILABLE -lt $REQUIRED ]; then echo backup disk space insufficient: $AVAILABLE KB 2 exit 1 fi6.4 恢复顺序错了后面的步骤全白做还原服务时的通用顺序是先恢复系统层的分区和引导再恢复配置再恢复应用数据最后启动服务。顺序一旦乱了可能造成二次破坏。最典型的例子是先启动了数据库服务MySQL在数据目录为空时自动初始化出一个全新数据目录之后你再把备份的数据文件copy回去很可能因为版本状态对不上直接启动失败或者更糟新初始化的文件覆盖了备份文件。数据库恢复后还必须确认数据目录的属主。MySQL数据目录要求属主是mysql用户PostgreSQL数据目录要求属主是postgres用户rsync或tar恢复后经常把这些目录的属主变成root结果服务起不来。恢复完先chown再启动服务这是铁律。6.5 备份文件自身的安全与防篡改备份数据是攻击者的重点目标。如果备份文件和在线数据放在一起勒索病毒扫到直接一起加密如果备份服务器权限松散攻击者拿到后还会顺手把备份删掉让你连恢复的机会都没有。我的做法是备份服务器的SSH只允许密钥登录备份目录权限收紧到0700本地保存的备份定期用restic或rclone加密后再推到对象存储加密密钥单独存放备份网络和生产网络做访问控制备份服务器不能随意访问生产机。另外重要备份要在几种介质上各留一份并且定期做恢复测试——备份是否真的有效只有完全还原出来验证过才算数。做了这么多年备份方案我的体会可以用一句话概括备份是为了还原还原演练才是备份方案的照妖镜。你觉得方案天衣无缝演练一次就会知道哪里断了你觉得工具老旧不好用真正出事时往往是那个被你嫌弃的tar脚本救了场。希望这篇Linux数据备份与还原实战指南能帮你把方案的每一环都跑通而不是等到数据丢了才后悔。 Linux数据备份与还原实战指南：从tar、rsync到数据库恢复
做了这么多年Linux运维我对Linux数据备份与还原这件事的态度经历了三个阶段第一次数据丢失时的手忙脚乱中间几年对备份脚本的盲目自信以及一次真实事故之后的彻底重构。去年一台业务服务器磁盘报错文件系统变成只读我安慰自己没事有备份翻出来一看才发现最近一次全量备份是一个月前的按周做的增量因为脚本里一个路径写错连续三周空跑。最后靠数据库binlog恢复到故障前两小时那两小时的数据终究还是丢了。那次之后我把备份和还原当成两件事来对待重新设计了一整套方案。这篇实战指南就是那套方案的完整记录覆盖了备份策略设计、文件级备份tar/rsync、镜像级备份dd/LVM快照/再生龙Clonezilla、数据库备份还原MySQL/PostgreSQL最后还会专门讲还原演练和那些只有真正出过事才懂的坑。不管你是刚接手Linux服务器的新手运维还是写了好几年备份脚本的老手希望能帮你少走一些我走过的弯路。1. 备份前先想清楚你要从哪类事故里活过来备份方案不是一个工具选型问题而是一个风险决策问题。你花多少成本做备份应该取决于你愿意为数据丢失这件事承担多大代价。在我接触过的服务器环境里导致数据丢失的原因通常就这几类误删文件或误执行命令、磁盘或硬件故障、勒索病毒或入侵者破坏、机房级别的事故断电、火灾、水淹以及最容易被忽视的——备份机制本身失效。1.1 给数据分个类别一把抓我习惯把服务器上的数据分成三类每一类的备份策略完全不同配置类数据/etc下的各种配置文件、systemd服务单元、Nginx和Apache的站点配置、网络配置、定时任务、SSH密钥。特点是体量小、变化不频繁、但影响面大丢一个配置文件可能导致整个服务起不来。应用数据数据库文件、用户上传的文件、代码仓库、日志。特点是大、持续在写、丢失后重建成本极高。系统数据操作系统本身、已安装的软件包、内核和引导配置。特点是重装成本高但可以用镜像方案快速恢复。针对这三类数据我的默认方案是配置类用tar定期打包保留多个历史版本应用数据用rsync同步加数据库专用备份工具系统数据用镜像级备份Clonezilla或者LVM快照做兜底。分类的另外一个好处是你知道每种数据的恢复手段是什么不会出现明明只是配置文件坏了却要整个重装系统的尴尬。1.2 3-2-1备份原则怎么落地3-2-1原则很简单至少3份副本2种不同介质1份异地存放。这个原则本身没问题但初次落地时容易理解偏。我重点说几个实际执行中的理解首先生产机上正在使用的数据不能算作一份可靠的副本。磁盘物理损坏、误删、勒索病毒加密这三种情况都会把本机数据一起带走。真正算数的副本是独立于在线数据之外的拷贝。其次两种介质指的是不同类型的存储不一定是磁带和磁盘才算。我现在的常用组合是本机一块独立数据盘和系统盘分开内网另一台备份服务器加上远端的对象存储。三份副本分别落在三个不同的存储位置这样即使某一层出了问题至少还有另外两层兜底。第三异地这份要解决的是整个机房都完蛋的场景。如果公司没有跨机房或云端预算退而求其次至少把备份放到不同物理位置的另一台机器上。我会用rclone或restic把备份加密后推到对象存储既解决了异地问题也顺便解决了备份文件被拖走就能读的隐患。容量规划我给一个参考算法假设要备份的数据总量是500GB每日增量大约10GB计划本地保留最近7天增量、备份服务器保留最近30天、远端对象存储保留90天。那么本地需要约570GB备份服务器约800GB远端约1.2TB实际购买时再留30%的余量因为数据库备份临时文件、日志产生的额外消耗经常被低估。1.3 备份窗口、一致性和RTO/RPO备份不是任何时候都能做的这里有两个概念要先理清备份窗口和一致性。备份窗口指的是可以安全执行备份的那段时间。数据库在业务高峰不停写入的时候直接去备份数据文件拿到的东西很可能是崩溃状态的恢复时表损坏、数据对不上都是常事。所以绝大多数生产环境会把备份任务放在凌晨2点到4点这种低峰期再配合数据库本身的一致性机制MySQL的FLUSH TABLES WITH READ LOCK、PostgreSQL的pg_start_backup或者直接依赖InnoDB的MVCC做逻辑备份。一致性有个容易被忽略的细节你备份的多个文件之间必须属于同一个时间点。最典型的就是数据库数据文件、binlog和配置文件必须来自同一个备份时刻否则恢复出来数据逻辑是错乱的。这也是为什么我强烈建议数据库备份用专门工具而不是直接tar数据库目录。RPO和RTO是两个必须写进方案的数字。RPO恢复点目标是你能接受最多丢多少数据它决定备份频率和要不要做日志归档RTO恢复时间目标是业务最多能停多久它决定你用什么样的恢复手段。这两个数字不是拍脑袋定的要跟业务方确认。如果RPO是1小时每天一次全量备份完全不够必须配合binlog或WAL归档才能满足。2. 文件级备份实战tar和rsync的正确姿势文件级备份是最基础的一层适合配置类数据和中小体量的应用数据。这一层用两个工具就够了tar做打包归档rsync做同步和增量。工具都很老但用好的没几个人。2.1 tar打包备份命令很简单细节很坑tar是全量打包每次都会把所有文件读一遍。它的优势是简单、可靠、适合分发归档劣势是数据量大时又慢又占空间。备份配置文件这种小体量数据tar足够了。最基本的用法tar -czpf /backup/etc_backup_$(date %F).tar.gz /etc这里有三个细节新手最容易翻车。第一加-p是为了保留权限和属主信息不加的话恢复出来文件属主可能变成当前用户。第二恢复时必须用--same-owner和--preserve-permissions才能把权限完整还原光靠存档时加-p不够。第三$(date %F)是为了生成带日期的文件名这个习惯很重要没有日期你根本不知道这份备份是什么时候的。备份Web目录并排除缓存tar -czpf /backup/www_$(date %F).tar.gz --exclude/var/www/cache --exclude/var/www/tmp /var/www排除目录时要注意--exclude的位置放在源路径前面路径要写绝对路径否则匹配不到。另外如果目录里有正在写入的日志文件tar会给出file changed as we read it的警告这说明备份出来的文件可能不在同一个时间点后面我会专门讲这一类一致性问题的处理。恢复时的黄金习惯是永远先恢复到临时目录检查无误后再覆盖原路径。mkdir -p /tmp/restore tar -xzpvf /backup/etc_backup_2025-01-01.tar.gz -C /tmp/restore diff -r /tmp/restore/etc /etc我见过太多人直接解压覆盖结果备份文件本身有问题线上环境被弄得更糟。先恢复到临时目录的成本很低但能避免最糟糕的二次事故。2.2 rsync增量同步与硬链接快照rsync是同步工具不是归档工具。它的核心特点是增量传输只把源端变化的部分传过去支持断点续传还能通过SSH加密传输。用来做日常同步和远程备份非常合适。基础用法rsync -avz --delete /var/www/ backup-server:/backup/www/-a是归档模式保留权限、属主、时间戳和软链接-v是verbose-z是压缩传输--delete表示把目标端存在但源端已经删除的文件一并删除这样目标端始终是源端的镜像。先说一个很多人踩过的坑源路径末尾的斜杠。rsync /var/www和rsync /var/www/的行为完全不一样前者把www这个目录本身同步过去结果是目标端变成/backup/www后者只同步www里面的内容结果是/backup目录下直接就是www的内容。写脚本前务必确认你要的是哪一种。增量备份怎么做rsync本身每次都同步全量文件内容但可以通过硬链接实现每天一个全量目录实际空间只占一份的效果rsync -av --link-dest/backup/www/$(date -d yesterday %F) /var/www/ /backup/www/$(date %F)/--link-dest的意思是如果目标文件内容和link-dest指向的目录里的同名文件一致就不重新存储而是建立硬链接。这样每天生成一个完整的目录结构未变化的文件通过硬链接共享同一个inode既保留了任意一天都能直接找到完整文件的方便又让空间消耗接近增量备份。恢复时只要按日期目录取文件就行不需要先还原全量再叠增量容错性比传统增量备份高很多。2.3 备份脚本与定时任务的正确写法文件级备份最终要落到脚本和定时任务里。下面是我常用的一个带轮转清理的rsync备份脚本#!/bin/bash # /usr/local/bin/backup_www.sh export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin BACKUP_ROOT/backup/www DATE$(date %F) YESTERDAY$(date -d 1 day ago %F) KEEP_DAYS30 mkdir -p $BACKUP_ROOT rsync -av --link-dest$BACKUP_ROOT/$YESTERDAY \ /var/www/ $BACKUP_ROOT/$DATE/ find $BACKUP_ROOT -maxdepth 1 -type d -mtime $KEEP_DAYS -exec rm -rf {} \;配合crontab30 2 * * * /usr/local/bin/backup_www.sh /var/log/backup_www.log 21定时任务里有两个问题很隐蔽。第一cron执行时的环境变量和登录shell不一样PATH很精简脚本里如果不写绝对路径或没在开头export PATH经常出现手动执行正常定时任务里找不到命令的诡异现象。第二cron的输出默认会发给root的邮箱不重定向的话邮箱会被塞爆务必把标准输出和标准错误都写到日志文件。另外我建议在脚本最后加一个成功率检查。比如rsync结束后用$?判断退出码非零就发告警再检查生成的文件大小如果明显小于预期阈值就说明同步可能出了问题。备份的失败通常不是一次性的是这种小问题日积月累等真的需要恢复时才发现已经坏了好几周。3. 镜像级备份dd、LVM快照和再生龙组合拳文件级备份解决的是某个目录坏了的问题解决不了整个系统起不来的问题。系统盘损坏、引导分区丢失、机器被入侵后系统文件被篡改这些场景需要镜像级的备份方案。这一层的工具从原始到现代都有我按使用场景讲。3.1 dd整盘克隆什么场合用什么场合别用dd是块级别的复制工具它不管文件系统直接把整个块设备的内容逐块拷贝。基础用法dd if/dev/sda of/backup/sda.img bs64M statusprogressbs64M是块大小。很多人用默认512字节那速度简直灾难。我实测过对普通SATA机械盘64M块大小比默认快几十倍对SSD效果也更明显。这里有个常识dd读的是整块盘包括空闲空间即使盘里只有20GB数据1TB的盘也会读出1TB的镜像。dd的缺陷很明显镜像体积等于磁盘容量、无法做增量、恢复时要求目标盘容量不小于源盘、备份过程要求文件系统处于静止状态否则镜像可能不一致。所以dd不适合做例行备份它更合适的场景是系统迁移前做一次整盘安全快照、把一块盘完整克隆到另一块同容量盘、或者是取证场景下做只读镜像。也就是说日常的每日备份交给rsync和数据库工具dd只用于大事件之前的保险。3.2 LVM快照在线备份的一致性好帮手如果服务器用了LVM管理磁盘LVM快照是做一致性备份的利器。原理上LVM快照是COW写时复制创建快照后原始卷上的数据没有变化的部分继续读原始卷将要被修改的块在修改前先复制到快照空间。这就意味着快照创建那一刻的数据状态被冻结住了后续对数据的修改不会影响快照内容。用LVM快照做备份的标准流程# 创建快照大小一般给原始卷的10%-20% lvcreate -L 50G -s -n snap /dev/vg0/lv-data # 挂载快照 mkdir -p /mnt/snap mount /dev/vg0/snap /mnt/snap # 从快照目录做tar或rsync此时业务还在正常写 tar -czpf /backup/data_$(date %F).tar.gz /mnt/snap/ # 完成后卸载并删除快照 umount /mnt/snap lvremove /dev/vg0/snap有几个细节要记住。快照大小要根据备份耗时和数据变化速率来规划如果备份过程太慢数据变化超过了快照空间快照会自动失效备份就废了。所以务必要监控快照的使用率别等到满了才发现。另外快照里的文件属于某一次写操作之前的旧状态应用层的一致性还是要靠业务自己保证比如数据库目录里的文件如果数据库不是用安全模式停过再备份快照也拿不到逻辑一致的数据库状态。3.3 再生龙备份与还原Linux服务器的完整流程再生龙Clonezilla是开源社区里做整机备份最成熟的工具之一基于Parted Magic运行支持ext4、xfs、btrfs等多种文件系统。我用它来做系统盘的定期整机镜像。备份的完整流程是这样的下载Clonezilla Live的ISO用dd写入U盘或者用balenaEtcher这类工具刻录。目标服务器从U盘启动进入引导菜单选择第一项Clonezilla Live。选择语言、键盘布局然后进入核心界面选择device-image设备映像模式。备份时选保存磁盘为镜像还原时选从镜像恢复磁盘。选择要备份的磁盘或分区再选择镜像文件的存放位置可以是本地磁盘、移动硬盘也可以通过网络访问Samba/NFS服务器。按照提示设置压缩级别和分片大小开始备份。还原时Clonezilla会重建分区表和引导记录。这个特性是双刃剑好处是还原完成后不需要额外处理引导坏处是如果目标机器和源机器硬件差异很大比如RAID卡型号不同、磁盘控制器驱动不一致还原后很可能起不来。遇到这种情况恢复后需要在救援模式下重建initramfs把正确的磁盘驱动打进去。我的建议是用Clonezilla做的系统镜像主要用于同型号硬件或者虚拟机模板这种场景。物理机跨硬件迁移时老老实实按新硬件重装系统再把应用数据还原上去比寄希望于镜像万能可靠得多。3.4 不同层级的备份方案怎么组合镜像备份、文件备份、数据库备份不是互斥的而是层层兜底的关系。以一台典型的Web应用服务器为例我的方案是系统盘整机镜像每半个月用Clonezilla做一次存放在内网共享存储解决系统崩溃后快速恢复的问题。/etc配置目录和Web目录每天用rsync同步到备份服务器解决日常误改、误删的问题。MySQL数据库每天定时mysqldump逻辑备份每周一次XtraBackup物理备份binlog实时归档既能快速恢复当日数据又能做时间点恢复。优先级从高到低是数据库、应用数据、配置文件、系统镜像。原因很简单系统盘坏了重装一个系统加配置顶多半天数据库如果丢了好几年的业务数据就真的回不来了。备份方案设计的第一步永远是把最贵的数据保护等级提上去。4. 数据库备份与还原逻辑备份和物理备份的取舍文件级备份里特意没有把数据库目录算进去因为数据库的备份有独立的工具和独立的一致性要求。这一节把最常用的MySQL和PostgreSQL讲清楚。4.1 MySQL的mysqldump逻辑备份mysqldump是逻辑备份工具导出的是一堆SQL语句。InnoDB引擎下最标准的全库备份mysqldump --single-transaction -u backup_user -p --databases mydb /backup/mydb_$(date %F).sql--single-transaction是关键它基于InnoDB的MVCC机制在不锁表的情况下拿到一个一致性的快照。如果你的表里有MyISAMMVCC对它无效必须加--lock-tables或者干脆把MyISAM表先转成InnoDB。生产环境已经2025年了还在用MyISAM的表尽量迁移到InnoDB吧这不只是备份的问题。恢复就是导入SQLmysql -u root -p /backup/mydb_2025-01-01.sql导入时有一个需要注意的细节。如果当时用--databases导出文件里包含CREATE DATABASE和USE语句直接导入没问题如果当时用了--no-create-db或者只导出了单表就要提前自己创建数据库并指定库名导入mysql -u root -p mydb /backup/mydb_table_2025-01-01.sql逻辑备份的优势是文本格式、跨版本兼容性好、可以单独恢复某张表或者某条数据劣势是大数据量时导出导入都慢而且恢复时间不可控。几百MB的小库用mysqldump完全够几个TB的大库还是得靠物理备份。4.2 MySQL的XtraBackup物理备份Percona XtraBackup是物理备份工具直接拷贝InnoDB数据文件同时通过redo log保证一致性。备份命令xtrabackup --backup --target-dir/backup/xtra/20250101 --userbackup_user这里的--backup只是拷贝数据文件恢复前必须执行prepare把事务日志应用进去让文件达到一致状态xtrabackup --prepare --target-dir/backup/xtra/20250101然后copy-back到数据目录xtrabackup --copy-back --target-dir/backup/xtra/20250101 chown -R mysql:mysql /var/lib/mysqlchown那步很容易漏数据文件属主不对MySQL服务起来就会因权限问题报错或拒绝启动。物理备份的优势是恢复速度快特别适合上TB级的大库劣势是工具依赖Percona分支备份格式和MySQL版本强相关跨大版本恢复会有麻烦。4.3 PostgreSQL的pg_dump与WAL时间点恢复PostgreSQL的逻辑备份工具是pg_dump。自定义格式的全库导出pg_dump -h localhost -U postgres -Fc mydb /backup/mydb_$(date %F).dump-Fc生成的是自定义格式支持用pg_restore选择性地导入部分对象比纯SQL灵活。恢复pg_restore -d mydb /backup/mydb_2025-01-01.dump如果目标是空库也可以直接createdb mydb pg_restore -d mydb。pg_dump做的是逻辑备份适合中小库大数据量的PostgreSQL一般用pg_basebackup做物理备份。PostgreSQL真正强大的地方是WAL归档加PITR时间点恢复。配置思路是开启wal_levelreplica或logical设置archive_modeon把archive_command指向一个脚本让WAL文件持续归档到共享存储或远程服务器。恢复时先从全量备份恢复基础数据然后配置recovery_target_time指向误操作之前的时间点PostgreSQL会把归档的WAL从全量备份位置重放到目标时间。这套机制的威力在于你可以把数据库恢复到过去任意一个时间点而不是只恢复到最后一次备份。代价是配置复杂度高、归档文件要持续维护、恢复流程也要演练。如果是核心交易系统这个成本是值得的。如果是一个内容站每天pg_dump一次也够了。4.4 数据库备份的保留策略与校验数据库备份文件比普通文件更值钱保留策略要单独定。我的默认配置每日逻辑备份保留14天每周物理备份保留8周月度备份保留12个月归档日志binlog/WAL保留30天核心库可以延长到90天每条备份必须有校验信息。mysqldump之后顺手生成md5md5sum /backup/mydb_$(date %F).sql /backup/mydb_$(date %F).sql.md5恢复前先校验避免备份文件在传输中损坏导致恢复失败。我遇到过几次恢复出来表结构都在但数据缺了一片的情况最后排查就是备份文件在拷贝到远端时出了问题而校验能第一时间发现。binlog和WAL归档的本质是增量日志。很多人只做全量备份不做日志归档一旦需要恢复到今天中午12点这种时间点就无能为力。RPO要求是1小时以内的系统日志归档不是可选项是刚需。5. 还原演练灾难恢复计划不是文档是流程备份做得再勤如果没验证过能还原那只是一堆躺在存储里的数据。我见过太多公司灾难恢复计划写得漂漂亮亮真出事时照着文档走每一步都卡壳。所以我一直强调灾难恢复计划的价值不在文档本身在还原演练。5.1 季度还原演练清单我的习惯是每季度在测试环境做一次全流程还原演练直接模拟生产机的故障。清单是这样的从最近的备份中取回全量备份和最后一次增量。准备一台同版本操作系统的干净机器先不要装任何业务软件。按文档顺序执行还原系统镜像或分区还原、配置文件还原、应用数据还原、数据库还原。启动所有服务逐项检查业务功能是否正常比如页面是否打开、数据库能否读写、日志有没有报错。记录每一步实际耗时对照RTO看是否达标。演练过程中最容易发现的问题有几个还原文档里写的命令和服务器的实际环境对不上备份文件存储在NFS但演练环境访问不了NFS数据库还原之后忘了改权限导致服务起不来。这些问题每一个都真实发生过而它们的最佳发现时机是在演练环境不是在故障现场。演练的频率和范围要量力而行。实在做不到每季度至少每半年做一次核心数据库的还原演练。我个人的经验是数据库的还原演练价值最高因为数据库恢复步骤最复杂、最容易出错而它又恰恰是最不能丢的数据。5.2 备份有效性的验证方法除了大演练日常对备份有效性的抽查也要做。文件级备份可以这样快速验证tar -tzf /backup/etc_2025-01-01.tar.gz | head -50这条命令列出备份包里的内容确认结构完整。更严格的验证是解压到临时目录后和源文件做对比tar -xzf /backup/www_2025-01-01.tar.gz -C /tmp/restore diff -r /tmp/restore/www /var/www数据库备份的验证更直接把dump文件导入一个临时的空库然后执行CHECK TABLE或SELECT count(*)对比关键表。这一步成本很低但能提前发现备份里藏着的问题比如mysqldump导出过程中遇到锁超时导致数据不完整。备份脚本自身也要有自检机制。我习惯在脚本里加这几行rsync -av --delete /var/www/ backup-server:/backup/www/ || { echo rsync failed; exit 1; } [ $(stat -c%s /backup/latest.sql) -ge 104857600 ] || echo backup file too small如果退出码非零直接告警如果文件大小低于预期阈值也告警。自动化自检比人工巡检可靠得多人工巡检总会有漏掉的那一天。5.3 灾难恢复计划模板里的必备章节网上随手能搜到很多数据备份灾难恢复计划模板我参考过不少真正落到自己环境时必须补充进这些内容模板才不会变成废纸备份资产清单每种数据在哪个目录、用什么工具、什么周期备份、备份存储在哪里。每个环节的责任人谁来执行备份、谁来执行还原、谁有权审批恢复操作。没有责任人紧急情况下没人敢动手。关键机器的硬件信息磁盘控制器型号、引导方式BIOS还是UEFI、文件系统类型、磁盘分区布局。恢复时这些信息直接决定操作方向。还原步骤的细粒度命令不要写恢复数据库这种模糊句子要写到具体命令和参数。每类数据的目标RPO和RTO要让所有人知道这个备份方案在什么区间内是有效的超出区间比如RPO是1小时却只有每日备份就必须提前预警。模板是工具不是目标。我见过太多团队的灾难恢复计划文档写得像获奖论文一年都没翻过一次。真正有效的办法是写完文档后拿它做一次还原演练演练暴露的问题就是文档下一版要补的内容。迭代几轮之后这份文档才是真正可用的。6. 我在备份还原实战中踩过的坑最后这一节都是我在真实故障排查中一步步趟出来的经验。有些坑很小但时机不对就会造成大事故。6.1 文件权限和属主是最容易翻车的地方tar恢复时最常见的问题就是权限和属主错乱。如果当初打包时没有保留权限信息或者恢复时用的是普通用户还原出来的文件属主可能变成执行恢复的用户。对SSH密钥、Nginx配置这类权限敏感的文件来说属主不对等于服务起不来、远程登录被拒。我的习惯是恢复完成后不要立刻启动服务先检查关键文件的属主和权限。可以用一条命令批量检查find /etc -name *.conf -o -name *.key | xargs ls -l更稳妥的做法是尽量用rsync -a从备份目录同步回原路径因为rsync的-a参数会把权限、属主、时间戳一起恢复比tar解压靠谱得多。6.2 file changed as we read it背后的不一致风险运行中的服务目录做tar打包经常会出现这个警告。它的意思是tar读取文件的过程中文件内容被其他进程修改了。这个警告不能忽略它意味着备份包里的某些文件可能来自不同时间点——这对配置文件影响不大但对数据库文件和日志文件就是致命的。处理办法分情况如果是配置类目录警告可以容忍但要在文档里记录如果是数据库目录必须停下来改用数据库工具或者LVM快照方案如果是日志文件这种写频繁的目录要么先做日志轮转再备份要么用rsync同步并在脚本里接受最后一个日志文件可能不完整这个事实。6.3 磁盘空间判断失误导致备份中断备份脚本最常见的故障之一就是目标磁盘写满。tar或rsync在磁盘满时会直接退出留下一个半截文件而这个半截文件看起来和完整文件没什么区别散落在备份目录里。等真正恢复时才发现文件不完整那真是最绝望的时刻。处理办法有两个一是把备份目录放在独立文件系统上不要和根分区共用这样备份占满磁盘不会拖垮系统二是在脚本里提前检查磁盘剩余空间不够就告警退出REQUIRED8388608 # 至少需要8GB空间KB AVAILABLE$(df -P /backup | awk NR2{print $4}) if [ $AVAILABLE -lt $REQUIRED ]; then echo backup disk space insufficient: $AVAILABLE KB 2 exit 1 fi6.4 恢复顺序错了后面的步骤全白做还原服务时的通用顺序是先恢复系统层的分区和引导再恢复配置再恢复应用数据最后启动服务。顺序一旦乱了可能造成二次破坏。最典型的例子是先启动了数据库服务MySQL在数据目录为空时自动初始化出一个全新数据目录之后你再把备份的数据文件copy回去很可能因为版本状态对不上直接启动失败或者更糟新初始化的文件覆盖了备份文件。数据库恢复后还必须确认数据目录的属主。MySQL数据目录要求属主是mysql用户PostgreSQL数据目录要求属主是postgres用户rsync或tar恢复后经常把这些目录的属主变成root结果服务起不来。恢复完先chown再启动服务这是铁律。6.5 备份文件自身的安全与防篡改备份数据是攻击者的重点目标。如果备份文件和在线数据放在一起勒索病毒扫到直接一起加密如果备份服务器权限松散攻击者拿到后还会顺手把备份删掉让你连恢复的机会都没有。我的做法是备份服务器的SSH只允许密钥登录备份目录权限收紧到0700本地保存的备份定期用restic或rclone加密后再推到对象存储加密密钥单独存放备份网络和生产网络做访问控制备份服务器不能随意访问生产机。另外重要备份要在几种介质上各留一份并且定期做恢复测试——备份是否真的有效只有完全还原出来验证过才算数。做了这么多年备份方案我的体会可以用一句话概括备份是为了还原还原演练才是备份方案的照妖镜。你觉得方案天衣无缝演练一次就会知道哪里断了你觉得工具老旧不好用真正出事时往往是那个被你嫌弃的tar脚本救了场。希望这篇Linux数据备份与还原实战指南能帮你把方案的每一环都跑通而不是等到数据丢了才后悔。