简介面向需要实现系统快照、目录打包与数据备份功能的开发人员这里提供一份名为“安安dumptar”的备份工具工程包该包特别契合在三星设备或安卓与 Linux 环境中定制备份方案的技术场景。包体共三十七个文件、约十七点七三兆属于较精简的微软开发环境工程主要文件包括 C 源码、动态链接库与导入库、可执行程序、工程配置文件、调试符号以及构建日志和中间文件等目录结构清晰便于按需检索。目前已有二百三十二人学习下载。借助这份资源开发者可以通读 dumptar 命令的实现源码理解如何将系统级备份与打包压缩逻辑融为一体同时还能看到对 detours 库的调用方式掌握在视窗环境下面向文件系统进行镜像备份、状态导出与恢复的实战技巧进而快速打造适合自身业务的数据保护工具。1. 安安dumptar是什么把备份做成流水线的命令行方案很多人备份数据库到今天还停留在“点一下导出SQL存到桌面”的水平。这种习惯放在单机上问题不大放到服务器上就是定时炸弹——凌晨备份崩了没人看客户早上要数据时才发现归档是坏的。安安dumptar就是在这种场景下冒出来的工具思路把“数据导出(dump)”和“归档打包(tar)”两个动作绑成一个命令跑完就拿到一份带时间戳、带校验、可恢复的备份文件。它解决的是备份黑匣子问题备份到底有没有成功不再是玄学。适合手上有几台生产机器要维护、又不想为备份单独买商业软件的工程师。命令的关键在于把每一步都留下可验证的中间结果。dump负责和数据库交互把数据导成文本tar负责打包压缩把dump的输出变成单一归档文件。两个动作分开执行出错时能定位到底卡在哪一环。下面从最小脚本讲到定时任务再落到恢复演练。按这套走下来你至少能保证下一次要恢复时备份是真正可用的。2. dumptar的数据链路为什么是dump配tar以及备份目录怎么规划2.1 dump负责导出tar负责归档分开才不容易翻车绝大多数数据库备份脚本本质就是两段逻辑先导出再打包。以MySQL为例常见做法是mysqldump把在线库导出成SQL文本然后tar把SQL连同目录信息压缩归档。这两步分开写而不是用管道硬串是很多人吃过亏后的经验之谈。用管道直连时如果dump卡住或连接断开tar那边拿到的可能是一个不完整的读取流。只要tar进程正常退出脚本就认为“成功”但归档里可能连SQL结束符都没有。分开执行的价值在于每一步都有明确的退出码和中间产物失败时能立刻看到是连接问题、授权问题还是磁盘问题。逻辑备份在在线场景下几乎是必选因为它不要求停库。物理备份要保证数据文件一致要么依赖文件系统快照要么得让实例进入只读状态这在生产环境很难接受。mysqldump加上合适的参数后可以在InnoDB事务隔离级别下生成一致性快照虽然不是零开销但至少能在线完成。tar在链路里承担的是“打包压缩”两个职责。它保留Unix文件属性、符号链接能以流式方式把大量小文件处理掉。相比之下zip在Linux上反而常丢权限位跨平台恢复时容易出问题。压缩级别上gzip -6是速度和压缩比的常见平衡点xz压缩比高但恢复时CPU开销大备份场景等不起那个解压时间。所以“安安dumptar”这个名字里dump在前tar在后恰好点出了顺序先拿到正确数据再考虑归档格式。2.2 备份目录规划按日期和主机分层别把归档堆在一起目录设计是备份方案里最容易被忽略、也是最能体现维护水平的地方。见过不少机器备份目录下平铺一堆YYYYMMDD_xxx.sql.gz换台机器恢复时根本分不清哪个对应哪个库。建议按“根目录/主机名/日期”分层文件名里带上数据库名和归档类型。我常用的结构是这样/path/to/backups/ web01/ 20250401/ web01_db1_20250401_030000.sql.tar.gz web01_db1_20250401_030000.sha256 20250402/ ... db02/ 20250401/ db02_db1_20250401_030000.sql.tar.gz这样设计的理由很直接按主机分避免多台机器混跑同一脚本时互相覆盖按日期分清理旧归档时直接按目录删不用在文件名里做正则匹配。文件名里包含库名恢复时不会找错文件。归档与校验文件放同一目录恢复前先把校验跑一遍能拦截大部分传输损坏。按日期分目录还有一个隐形好处可以和保留策略对齐。比如只需要保留30天直接find -maxdepth 1 -type d -mtime 30 -exec rm -rf {} ;比在文件名上做日期解析简单得多。对多实例机器我建议在主机名后再加一层实例端口或实例名避免3306和3307两个实例的备份混在一起。2.3 选型对比tar vs zip vs 直接复制数据目录方式优点缺点适合场景mysqldump tar.gz语法通用、保留权限、可流式、压缩率高恢复速度比物理备份慢常规生产库需要在线备份zip跨平台友好、可分段压缩易丢Unix属性、不适合大量小文件要与Windows交换文件直接cp数据目录恢复快、是物理镜像需要停库或快照占用空间大大库、低峰期停机维护选型没有绝对最优关键看恢复时你愿意等多久。逻辑备份加gzip1GB的库大概几十秒到几分钟。真要恢复几十GB的库可能要考虑物理快照方案。常见做法是在同一台机器上两者并用日常用逻辑备份保底重要版本发布前再做一次物理快照。tar在备份场景还有一个容易被忽视的优势它支持流式读可以一边打包一边读不额外占用一倍的临时磁盘空间。zip和cp如果先落一份原始SQL再压缩临时文件会占掉和线上数据接近的空间对磁盘小的机器很不友好。这也是我在生产环境优先用tar而不是zip的原因。2.4 备份前要确认的三件事权限、磁盘和连接mysqldump需要什么权限很多人是等失败才知道。SELECT、SHOW VIEW、TRIGGER这种对象权限缺失导出会在中途报错tar却已经把半截SQL打进去了。常见做法是专门建一个backup账号而不是用root跑备份既避免权限过大也能在授权错误时快速定位。磁盘和连接是每次备份前必须检查的。磁盘低于阈值直接退出不进入备份流程连接检查可以用mysqladmin ping加超时参数避免数据库假死时脚本挂一晚上。这三件事写成一个check函数放在脚本开头比任何“备份后补救”都省事。3. 用安安dumptar跑通最小脚本mysql示例与参数取舍3.1 最小命令mysqldump接tar先跑通再谈自动化把上一章的设计落到脚本里。下面这段是一个可以直接复制到Linux机器上运行的dumptar最小实现依赖只有bash、mysql客户端和tar不需要额外装任何备份软件。#!/usr/bin/env bash set -euo pipefail BACKUP_ROOT/data/backups HOST$(hostname -s) DATE$(date %Y%m%d_%H%M%S) DB_NAMEapp_db ARCHIVE${BACKUP_ROOT}/${HOST}/${DATE}/${DB_NAME}_${DATE}.sql.tar.gz mkdir -p $(dirname $ARCHIVE) # 1. 先确认数据库能连上连不上就直接退出 mysqladmin ping --silent # 2. 导出逻辑数据到以日期命名的临时SQL文件 mysqldump \ --single-transaction \ --quick \ --skip-lock-tables \ --set-gtid-purgedOFF \ --no-tablespaces \ ${DB_NAME} ${ARCHIVE%.tar.gz}.sql # 3. 打包压缩-C切换到临时文件所在目录避免归档里带上绝对路径 tar -czf $ARCHIVE -C $(dirname $ARCHIVE) ${DB_NAME}_${DATE}.sql # 4. 校验归档完整后再删除临时SQL gzip -t $ARCHIVE rm -f ${ARCHIVE%.tar.gz}.sql这段脚本的思路是“落盘再打包”而不是把mysqldump的输出直接pipe给tar。原因在第2章说过落盘后mysqldump的退出码是可控的tar读取的是一个稳定文件不会出现“文件读到一半大小变了”的错乱。set -euo pipefail让脚本在任一步出错时立即退出而不是带着错误继续跑。变量ARCHIVE同时用于派生临时SQL文件名——${ARCHIVE%.tar.gz}.sql把归档后缀去掉得到SQL路径。这样脚本里只维护一个变量不会出现日期戳不一致的情况。mysqladmin ping --silent是第一条防线数据库没启动或账号连不上时脚本直接停在这里不会产生一个0字节的假归档。3.2 必调参数压缩级别、一致性快照与保留天数mysqldump的参数看起来多真正能影响备份可靠性的就那么几个。列出我常用的参数和建议值。参数建议值说明--single-transaction必须InnoDB下开启一致性快照导出期间不锁表--quick建议逐行读取数据降低客户端内存占用--skip-lock-tables建议避免导出时对所有表加全局锁--set-gtid-purgedOFFMySQL 5.6/8.0恢复时不强制写入GTID位置方便后续操作--no-tablespacesMySQL 8.0避免因缺少PROCESS权限导致导出中断--routines --triggers推荐默认不导出存储过程和触发器丢了你都不知道--hex-blob推荐二进制字段以十六进制导出恢复时更稳--max-allowed-packet64M防止单个大SQL行被客户端截断--single-transaction是这些参数里的核心。它启动一个REPEATABLE READ事务mysqldump在这个事务里读取数据InnoDB通过MVCC保证读到的是一致快照。代价是事务期间undo log不会被清理备份大库时注意binlog和undo空间但这是在线逻辑备份最可靠的姿势。tar这边也有两个细节。-czf里默认gzip压缩级别是6想更快可以改成--use-compress-programpigz用多核压缩。生产环境建议给tar加--acls --xattrs把ACL和扩展属性一起保留恢复后不用手动重设权限。反过来不要加--ignore-failed-read那会让tar在遇到读错误时继续打包正好掩盖问题。保留天数这次先不写进脚本因为清理策略放到定时任务里一起讲更完整。第4章会给按份数的清理方法比按天数可靠。3.3 最小验证列出归档内容并检查数据可达脚本跑完第一件事不是看文件大小而是确认归档本身能解开。这三条命令看到输出才能说“备份这一步完成”。# 校验gzip压缩流完整 gzip -t /data/backups/web01/20250401/web01_db1_20250401_030000.sql.tar.gz # 列出归档内的文件名确认不是空包 tar -tzf /data/backups/web01/20250401/web01_db1_20250401_030000.sql.tar.gz # 生成校验文件留作恢复前比对 sha256sum /data/backups/web01/20250401/web01_db1_20250401_030000.sql.tar.gz /data/backups/web01/20250401/web01_db1_20250401_030000.sql.tar.gz.sha256gzip -t只校验压缩流不校验SQL内容tar -tzf看的是文件列表和大小两者都通过说明归档在文件层面没问题。真正的数据一致性检查必须靠恢复演练第6章会展开。sha256校验文件放在归档同目录恢复时先跑sha256sum -c能拦截跨机器拷贝造成的静默损坏。这一步很多人略过觉得麻烦真到恢复那天就知道它的价值——传输过程丢一个字节MySQL导入到一半报错排查成本远高于生成校验文件的几十毫秒。4. 把dumptar接入定时任务cron与systemd timer的取舍4.1 cron方案PATH、日志与互斥锁备份脚本手动跑通了下一步就是定时执行。cron是最常见的选择但它有两个坑环境PATH极其精简以及任务重入。脚本开头必须显式设置PATH。mysqldump、mysqladmin、tar这些命令不在cron的默认PATH里不设置会出现“cron里跑失败、手动跑成功”的经典翻车。日志必须重定向不然cron任务的所有输出都被系统吞掉失败时连排查方向都没有。# crontab -e 添加以下两行 20 3 * * * export PATH/usr/local/mysql/bin:/usr/bin:/bin:/sbin /usr/local/bin/backup_script.sh /var/log/dumptar.log 21 15 3 * * * export PATH/usr/bin:/bin:/sbin /usr/local/bin/cleanup_old.sh /var/log/backup_clean.log 21时间上避开整点因为系统级任务大多在整点触发数据库备份和系统任务抢IO会影响导出耗时。备份定在3:20清理定在3:15清理先跑释放空间后再做备份减少因磁盘不足导致备份失败的几率。互斥锁不能省。备份脚本一旦因为网络卡顿跑超时下一个调度周期又开始了两个mysqldump同时执行会互相拖慢甚至锁竞争导致死锁。用flock加一个文件锁是最简单的方案。# backup_script.sh 开头加入 exec 9/var/lock/dumptar.lock if ! flock -n 9; then echo $(date %F %T) another backup is running, exit /var/log/dumptar.log exit 1 fiexec 9文件把文件描述符9指向锁文件flock -n 9尝试非阻塞获取锁。拿不到锁说明上一个备份还没结束直接退出并留下日志。注意这里用-n非阻塞而不是默认阻塞——阻塞会让新任务等旧任务等久了又会堆叠。4.2 systemd timer方案适合对依赖有要求的机器cron能解决“定时执行”解决不了“任务依赖”。比如机器重启后MySQL还没起来3:20的备份脚本先跑mysqladmin ping直接失败当天的备份就没了。对这类场景systemd timer比cron更合适。先写服务单元管理备份进程本身# /etc/systemd/system/dumptar.service [Unit] DescriptionRun dumptar backup Aftermysqld.service Requiresmysqld.service [Service] Typeoneshot ExecStart/usr/local/bin/backup_script.sh StandardOutputappend:/var/log/dumptar.log StandardErrorappend:/var/log/dumptar.log再写定时器管理触发时间# /etc/systemd/system/dumptar.timer [Timer] OnCalendar*-*-* 03:20:00 Persistenttrue RandomizedDelaySec300 [Install] WantedBytimers.targetAfter和Requires保证MySQL服务处于运行状态才启动备份这是cron做不到的依赖控制。Persistenttrue是关键——机器在计划时间处于关机或维护状态开机后systemd会立即补跑一次错过的任务cron没有这个概念。RandomizedDelaySec300把启动时间随机延迟最多5分钟多台机器同时跑备份时分散IO压力对数据库集群很有用。启用命令是三条sudo systemctl daemon-reload sudo systemctl enable --now dumptar.timer sudo systemctl list-timers dumptar.timerlist-timers确认timer处于激活状态也能看到下一次触发时间。日志方面StandardOutputappend:直接追加到文件不再需要cron里的重定向写法。排查时用journalctl -u dumptar.service也可以看。4.3 保留策略按份数清理而不是按天数清理旧归档是定时任务里最容易写错的部分。最常见的做法是find -mtime 30 -delete按天数删但这个方案有个漏洞机器停机三天没跑备份第四天跑完时旧归档已经超过了保留天数清理脚本会把本该保留的归档删掉。反过来如果备份频率高按天数清理会留下比预期更多的归档。更可靠的是按份数保留——“只留最近30份”不关心日期漂移#!/usr/bin/env bash # cleanup_old.sh BACKUP_ROOT/data/backups KEEP_COUNT30 find $BACKUP_ROOT -type f -name *.tar.gz -printf %T %p\n \ | sort -n \ | head -n -${KEEP_COUNT} \ | awk {print $2} \ | xargs rm -f这个管道做的事情按修改时间排序归档文件head -n -30取出最旧的那一批总数减30剩下的xargs删掉。注意sort -n是对第一列的纳秒时间戳排序不是文件名字典序。如果归档总数不到30份head -n -30会输出空不会误删任何文件。清理动作放在备份完成并校验通过后执行。务必不要放在备份之前——虽然先清理能释放磁盘空间但万一清理逻辑写错你会连唯一可用的旧归档一起删掉。先备份后清理最坏情况是磁盘多撑一天至少不会丢掉所有后路。5. dumptar避坑清单备份失败最常见的四个坑5.1 备份“成功”恢复却失败现象脚本每次跑完都生成tar.gz日志干净但恢复时gzip -t报unexpected end of file归档体积比预期小很多。原因是备份流程只检查了“命令是否退出”没检查“数据是否完整”。尤其是用管道把mysqldump直接喂给tar时mysqldump中途崩溃管道关闭tar可能正常退出并生成一个不完整的归档脚本只看最后一个命令的退出码误判为成功。解决第一落盘再打包mysqldump的输出先写临时SQL文件单独检查退出码第二打包完成后立即执行gzip -t做完整校验校验通过才删除临时文件。这个操作加进去备份脚本的可靠性能提升一个量级。5.2 cron里跑不报错手动跑却成功现象手动执行备份脚本一切正常cron执行后日志里只留下一句mysqldump: command not found备份目录里没有新文件。明明同一个脚本为什么两种环境行为不同。原因是cron的PATH环境变量被精简成/usr/bin:/binMySQL客户端装在/usr/local/mysql/bin下脚本里的mysqldump根本找不到。另外如果备份账号密码写在~/.my.cnf里cron执行时的HOME目录不同可能读取不到这个配置。解决脚本开头显式设置PATH把/usr/local/mysql/bin加进去mysqldump和mysqladmin用绝对路径调用.my.cnf的权限设为-rw-------并确认执行脚本的用户能读到。排查时先用sudo -u 用户名 crontab -l确认运行身份再手动以该身份执行脚本复现问题。5.3 磁盘塞满归档写一半断掉现象备份快结束时tar报write error归档文件在但明显偏小系统根分区使用率100%。更麻烦的是MySQL实例所在分区和备份分区如果是同一个数据库可能也会出问题。原因是备份前没有检查磁盘空间也没有清理旧归档。压缩写入需要临时空间空间耗尽时gzip写出半截就退出脚本却继续执行清理逻辑把临时SQL文件删了留下一个损坏的tar包。解决脚本开头加磁盘检查备份目录可用空间低于备份预估大小的2倍时直接退出。预估大小可以粗略按“数据库实际大小×1.2”算InnoDB表在dump后的SQL文本通常会膨胀。排在后面的备份顺序是先清理旧归档释放空间再执行备份备份完整校验通过后再次清理。这样即使清理逻辑出错也不会在写新归档时把磁盘撑爆。5.4 恢复后数据比预期少一段现象做恢复演练时发现恢复到临时库的行数比线上少几百条而且少的记录集中在某个表。备份执行时数据库负载并不高mysqldump没有任何报错。原因是--single-transaction只保证InnoDB一组事务的一致性它管不住备份期间执行的DDL。比如备份过程中有人执行了CREATE TABLE或ALTER TABLE这条语句产生的数据变更不会出现在dump快照里恢复出来的库自然就少了那段数据。这是逻辑备份的固有限制不是参数选错。解决备份时记录一致性位点。MySQL 5.6到8.0的早期版本用--master-data28.0高版本推荐--source-data2它会把binlog文件名和position作为注释写入dump头部。发生需要恢复的场景时先恢复到dump位点再重放该位点之后的binlog才能把数据补到最近时刻。位点信息要一并归档保存恢复时翻dump文件头部就能看到。5.5 tar提示“file changed as we read it”现象tar打包过程中输出warning: file changed as we read it脚本退出码为1但归档已经生成。原因mysqldump落盘的SQL文件还在写入时tar就开始读取了文件大小持续增长tar检测到元数据变化就报错。这个问题只出现在“边写边打包”的场景逻辑备份脚本尤其常见。解决mysqldump命令结束并确认退出码为0之后再加一句sync等文件系统把缓冲刷新再启动tar。如果对实时性有要求也可以在mysqldump之后sleep 1到2秒让文件稳定后再打包。这里不建议用tar --warningno-file-changed压掉报错它会掩盖真正需要关注的写入问题。6. 验证dumptar备份真的能恢复给恢复预案留后路6.1 恢复演练脚本临时库导入与行数对比验证备份能不能用只有一个标准真的恢复一次。在目标MySQL实例上建临时库把归档导入进去再统计每个表的行数。下面是可复用的验证脚本。#!/usr/bin/env bash set -euo pipefail ARCHIVE/data/backups/web01/20250401/web01_db1_20250401_030000.sql.tar.gz TMP_DBrestore_check # 建临时库导入归档内容 mysql -e DROP DATABASE IF EXISTS ${TMP_DB}; CREATE DATABASE ${TMP_DB}; tar -xOzf $ARCHIVE | mysql $TMP_DB # 列出所有表并统计行数 mysql -N -e SELECT table_name FROM information_schema.tables WHERE table_schema${TMP_DB} \ | while read table; do count$(mysql -N -e SELECT COUNT(*) FROM ${TMP_DB}.${table}) echo ${table}: ${count} done # 确认后清理临时库 mysql -e DROP DATABASE ${TMP_DB}tar -xOzf把SQL解压输出到stdout直接管道给mysql导入不再经过临时文件。行数统计不能证明数据内容完全一致但能快速暴露空表、缺表、导入中断这些明显问题。验证脚本建议保留成固定文件每次备份完成后跑一遍输出追加到校验日志。6.2 归档校验与checksum留痕恢复演练能发现逻辑问题checksum能发现物理损坏两条线都要留档。备份脚本生成归档后紧接着生成sha256值sha256sum $ARCHIVE $ARCHIVE.sha256下次恢复前先校验cd $(dirname $ARCHIVE) sha256sum -c $(basename $ARCHIVE).sha256-c模式会输出OK或FAILED一眼看出归档是否被改动过。校验文件和归档放同一目录随备份目录一起做异地同步同步工具只认文件大小和mtime时会漏掉内容损坏有checksum就能兜底。6.3 把验证变成习惯先恢复再收工吃过一次恢复失败的亏就会明白备份的真正价值不在生成归档的那一刻而在恢复那一刻能不能站起来。我现在的习惯是每次mysqldump版本升级、MySQL小版本升级、或者应用上线涉及表结构变更都手动跑一次6.1的恢复演练确认新环境下dump和restore链路是通的再把这个版本的备份当作正式基线。安安dumptar这类方案能做的是把导出、打包、校验、清理这些环节用脚本固定下来减少漏步骤的概率。但工具不会替你验证恢复演练这件事没有任何自动化能完全替代。每两三个月挑一台机器做一次真实恢复把校验结果留档哪怕只是行数对比也会比一堆从未打开过的tar.gz值钱得多。这套流程我一直在用希望帮到你。本文还有配套的精品资源点击获取