ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

Linux服务器RAR工具部署与命令行实战指南

Linux服务器RAR工具部署与命令行实战指南 简介这是一款面向Linux 64位x86_64系统的RAR压缩工具测试版对应版本6.1.b1主要解决在纯命令行环境中创建、解压、修复RAR档案的需求适合系统管理员、运维工程师以及经常处理跨平台压缩包的开发者。包内共11个文件体积仅590KB以rar与unrar两个可执行文件为核心另有txt说明文档、htm离线帮助、makefile构建脚本、sfx自解压模板及lst列表文件结构完整解压后即可直接使用。已有197人学习浏览。除了常规压缩解压该工具还支持多卷分割、自解压包生成、损坏档案修复和AES-128/AES-256加密可在Shell脚本中批量调用完成日志归档、备份文件加密、分包传输等任务由于是测试版核心功能完整但个别边界情况仍需留意。与图形界面工具相比这款命令行版本更轻量便于在无桌面环境的服务器上集成到自动化运维流程中。1. rarlinux-x64-6.1.b1Linux 服务器处理 RAR 交付物的兜底方案rarlinux-x64-6.1.b1 这个包是我在 x64 Linux 服务器上处理 .rar 交付物时的兜底选项。Windows 那边发过来的压缩包拿到服务器上一敲 tar 就报错gzip 也解不动——这不是命令写错而是 RAR 格式必须由 RAR 自己的程序来解。系统仓库里的 unrar-free 勉强能解却不支持压缩和加密回传折腾 7z 又要在每个环境里陪跑依赖。rarlinux-x64-6.1 的 b1 是 beta 1虽是测试版本命令行功能一个不少解压、打包、加密、多卷拆分都有。适合定期处理 Windows 交付物的运维、需要在服务器上归档日志与数据库备份的工程师、经常在 Linux 下打开网盘数据的分析岗。这套包使用门槛不高但部署位置、参数细节和边界条件值得一步步理清楚。2. 安装与部署tar.gz 解压、二进制落位与 PATH 配置2.1 为什么不用系统自带的 unrar选型与架构确认先回答一个常见疑问为什么不直接用 yum install unrar 或 apt install unrar原因是大多数发行版仓库里的 unrar 是 unrar-free它是一个裁剪过的读取器能解压一部分 RAR但缺少压缩、加密、分卷等写入类子命令p7zip 对 RAR 的支持也到不了官方实现的完整度某些新版本格式会落后一拍。而这个包是 RAR 官方发布的 Linux 版本把 rar 和 unrar 两个程序都带上了rar 负责压缩unrar 专注解压功能闭环。选型定下来之后再谈架构。别急着解压。先跑 uname -m 确认架构是 x86_64。我见过有人在 ARM 服务器上硬解 x64 包最终报 Exec format error白白折腾半小时。如果你确实在 ARM 环境需要找对应的 arm 版本安装步骤一样只是二进制架构不通用。确认无误后再解开包uname -m # 输出 x86_64 就对了然后解包 tar -xzvf rarlinux-x64-6.1.b1.tar.gz ls -la rar/tar 的参数拆开讲-x 是解压动作-z 表示处理的是 gzip 压缩的包-v 把解压过程打印到终端-f 后面跟文件名这四个字母在实际运维里几乎绑定出现。解开后目录名通常不是 rarlinux-x64-6.1.b1而是 rar/这一点经常被脚本里的路径踩到稍后配置时要注意。2.2 二进制落位复制法还是软链接法把二进制放哪里直接决定后续升级和卸载的体验。我见过有人把解压目录留在 /root然后用绝对路径到处写结果清理磁盘时误删整个服务器再也找不到 rar 命令。常用做法是二选一把可执行文件复制到 /usr/local/bin或把整个 rar 目录放到 /opt再用软链接暴露命令。# 方案一把两个可执行文件复制到 /usr/local/bin sudo cp -a rar/rar rar/unrar /usr/local/bin/ sudo chmod x /usr/local/bin/rar /usr/local/bin/unrar # 方案二把 rar 目录整体放到 /opt软链接到命令目录 sudo cp -a rar /opt/rar sudo ln -sf /opt/rar/rar /usr/local/bin/rar sudo ln -sf /opt/rar/unrar /usr/local/bin/unrar两种做法都可以但我倾向方案二。理由和踩过的坑相关rar 运行时需要依赖同目录下的辅助文件单独把 rar 二进制复制出去一旦运行时要读取这些文件却找不到就会表现出一些反常行为比如某些参数不生效或命令直接退出。整个目录保留在 /opt升级时只需要替换 /opt/rar 里面的内容软链接不用动。方案一适合临时机几分钟内启用的场景没问题方案二适合长期使用的生产机卸载时删掉 /opt/rar 和两条软链接干净利落。2.3 全局 PATHprofile、bashrc 与定时任务的差异命令放好后核心问题就是 PATH。用户的 .bashrc 只在交互式登录时加载cron、systemd、CGI 类程序一概不读它。把 rar 目录写进全局 profile比写入某个用户的 bashrc 更可靠echo export PATH/opt/rar:$PATH /etc/profile.d/rar.sh source /etc/profile.d/rar.sh which rar # 输出 /opt/rar/rar 才算成功用 /etc/profile.d/rar.sh 而不是直接改 /etc/profile好处是职责单一卸载时删除这个小文件即可。加进 PATH 后root 和普通用户登录时都能找到 rar。但要注意一个边界Web 面板定时任务、CI 流水线这类脚本通常在非登录非交互 shell 下执行profile 也不一定被读取。所以到了脚本内部我一般不会靠 PATH而是直接在脚本顶部声明RAR/usr/local/bin/rar # 或者 RAR/opt/rar/rar $RAR t /data/backup/weekly.rar这种做法相当于给命令上了双保险交互终端靠 PATH 用脚本用显式变量用。前面说过的 command not found 问题绝大多数是这一步没做到位。2.4 权限与挂载选项普通用户调用的隐藏门槛权限问题比 PATH 更隐蔽。软链接指向 /opt/rar 后root 能跑nginx 或 www 用户跑却报权限错误。原因有两类一是 /opt/rar/rar 的可执行位在复制过程中丢失二是目录和文件本身的访问权限不足。先按下面顺序补权限sudo chmod 755 /opt/rar sudo chmod 755 /opt/rar/rar sudo chmod 755 /opt/rar/unrar ls -l /opt/rar/rar # 确认输出 -rwxr-xr-xrarlinux 包解出来通常自带执行权限但从 Windows 转过来的文件或某些压缩传输工具会把这些权限抹掉。另一个容易忽略的点是挂载选项如果 /tmp 或 /opt 所在分区用 noexec 挂载就算文件有执行位内核也会直接拒绝运行报错往往是 Permission denied。排查时先 df -h /opt 看挂载点再用 mount -o remount,exec /opt 临时放行长期方案是把 rar 放到非 noexec 的分区。这两条加起来能避免许多「明明按教程装了却跑不起来」的玄学困扰。3. 高频命令实战解压、压缩、加密与多卷拆分3.1 解压命令 x 与 e保留目录 vs 全部拍平RAR 命令行最常用的是 x 和 e 两个子命令。x 解压时保留压缩包里的目录结构e 则把全部文件平铺到目标目录。二者的区别不只是目录结构大量同名文件在 e 方式下会互相覆盖这才是真正的翻车点。# x按原目录结构解压到 /data/restore rar x /data/backup/backup.rar /data/restore/ # e舍弃目录结构把文件全部摊平 rar e /data/backup/backup.rar /data/restore/x 适合迁移和完整还原它能保留原打包者在 Windows 下建的路径e 适合从包里捞一个文件、或者包内只有一层结构的场景。目标目录不存在时 rar 会自动创建省去 mkdir 一步。自动化脚本里我几乎必加两个参数-o 表示覆盖已存在文件-y 跳过所有确认提示。不加 -y 时批量解压遇到同名文件会停下来问你脚本就此挂住——这个细节最容易忽视也是 cron 任务卡死的一大来源。补充一个习惯解压前先 rar l 或 rar t 预览一遍。x 在遇到包内路径名带危险层级时可能给你解出一堆意想不到的目录结构先看内容再解压是我处理未知压缩包的铁律。3.2 压缩命令 a常用参数与压缩级别创建 RAR 用 a 子命令追加文件到已有包也是 a。压缩时最常用的开关是压缩级别 -m、固实模式 -s、递归 -r 和排除基础路径 -ep1。# 把 /var/log/app 递归压缩最大压缩级、固实模式、去掉根路径 rar a -r -m5 -s -ep1 /data/backup/app_$(date %F).rar /var/log/app参数逐个拆解-r 递归进子目录压缩目录时建议带上避免有的版本只把目录本身加进去-m5 是最大压缩级别压缩时间最长但体积最小-m0 只打包不压缩速度最快-m1 到 -m3 是日常档位-s 开启固实模式把包内文件作为一个整体数据流压缩压缩率更高代价是损坏后恢复难度和随机读取成本增加-ep1 表示排除命令行传入的根目录路径解压出来直接是 app 下的相对路径而不是 /var/log/app/xxx 一层套一层。备份日志这类重复内容时用 -m5 -s 能压掉大部分重复字节如果备份的是已经压缩过的视频、图片、数据库导出文件-m0 反而更合理能省掉大量 CPU 时间。表格化的选择逻辑大概是-m0 存储级适合已压缩内容-m1 快速档适合临时打包-m3 标准档日常均衡-m5 最大压缩适合日志和文本类。整体没有绝对正确答案按内容类型决定就好。3.3 加密与多卷拆分-p、-hp 与 -vRAR 的加密分两个层级很多人压完发给对方对方还是能在压缩包里看到文件名列表原因就是只用了 -p 没加 -hp。单独 -p 只对文件内容加密文件名和目录结构仍然可见-hp 加密文件头把文件名列表一起藏住。交付敏感资料时我用的是文件头加密# -hp 同时加密数据与文件头文件名列表不会暴露 rar a -hpPssw0rd2024 secret.rar /data/secret/ # 每 100M 拆一个分卷 rar a -v100M /data/backup/large_$(date %F).rar /data/backup/dump/密码直接写在命令行里会留在 shell 历史中生产脚本里建议用环境变量传入密码或者运行时交互式输入演示写法只是为了让你看清参数结构。多卷参数 -v 支持 k、m、g 单位-v100M 就是每卷 100MB。拆分后文件名会自动带 part01、part02 后缀。解压多卷包时只要指定第一个分卷rar 会自动找后续分卷前提是它们都在同一个目录且命名没被改动。如果有人单独下载了 part02 想解压rar 会提示缺少第一个分卷这不是命令写错是分卷规则如此。3.4 查看与校验l、t 子命令的排错价值l 列出压缩包内容t 测试压缩包完整性。这两个子命令在排错场景里使用频率最高。接别人压缩包的第一件事我会先 rar l 把文件路径、大小、日期看一遍确认里面没有诡异路径再解压。rar l backup.rar rar t backup.rar echo $?l 的输出包含原始路径、体积、压缩率和日期能快速判断文件名编码是否正常、体积是否合理也会提前暴露包内是否有危险路径。t 会把整个包在内部解压并比对 CRC 校验值完整无误才返回 0。在脚本里rar t 是承接下一步解压的可靠闸门只有 t 通过才允许 rar x 落地。对多卷包执行 t 同样只需指定第一个分卷rar 会自动遍历其余分卷。我还会在 t 之后顺手看一遍 $?因为有的脚本环境会把 rar 的非 0 退出码吞掉显式 echo 一下更稳。4. 进阶用法日志归档、Web 面板集成与自动清理4.1 把日志目录写成按期归档的备份脚本「压缩完马上校验」是我写备份脚本时的固定动作。把日志目录递归打包、做最大压缩、去掉根路径再立刻跑一趟 rar t两步串联保证落到磁盘的备份文件一定是完整可用的。脚本模板如下#!/usr/bin/env bash set -euo pipefail RAR/usr/local/bin/rar LOG_DIR/var/log/app BACKUP_DIR/data/backup DATE$(date %Y%m%d_%H%M%S) TARGET${BACKUP_DIR}/app_${DATE}.rar mkdir -p $BACKUP_DIR $RAR a -r -m5 -s -ep1 $TARGET $LOG_DIR $RAR t $TARGET || exit 1 echo backup finished: $TARGETset -euo pipefail 三个开关各司其职遇到错误立即退出、变量未定义报错、管道中间环节失败也退出$RAR 指向 rar 绝对路径避开了 cron 环境没有 PATH 的坑带时间戳的文件名让同名文件不会互相覆盖。t 校验失败时 exit 1脚本调用方可以通过退出码知道备份没成功。我还会把清理动作从压缩脚本里拆出去不推荐在压缩脚本里顺手删老包避免脚本中途失败连带把文件删了。4.2 在 Web 面板与 CI 脚本中调用 rar宝塔、AMH、GitLab CI 这类环境定时任务默认用的可能是 sh 而不是 bash环境变量极简。面板里填 rar 开头大概率 command not found根源不是 rar 没装而是执行环境不读 /etc/profile。处理办法只有两条路脚本里显式写绝对路径或者开头先把 PATH 铺好。#!/usr/bin/env bash PATH/usr/local/bin:/usr/bin:/bin export PATH # 面板任务里填这个脚本路径用 bash 执行 if /usr/local/bin/rar t /data/backup/weekly.rar; then rm -f /data/backup/tmp_*.rar fi这里有一个甄别技巧面板默认用哪个 shell 解析脚本决定了 $(date %F) 这类语法能不能用。dash 对某些 bash 扩展语法支持有限最好在面板的任务设置里显式写 bash /path/script.sh或者让任务调用一个以 #!/usr/bin/env bash 开头的脚本文件。另一个隐藏问题是执行用户很多面板用 www 用户跑任务备份目录的写权限、rar 可执行文件的读权限都要提前放好。我遇到过脚本在 root 终端正常、面板定时任务一直报 Permission denied最后发现是 www 用户对 /data/backup 没有写权限chown 给 www 之后立刻恢复。4.3 与 find、crontab 组合保留最近 N 份备份归档文件越积越多手动清理不现实。把 crontab 与 find 组合起来保留最近 30 天更早的自动删除。我的习惯是把删除动作和备份动作分开两个定时任务之间留出足够间隔避免备份还没生成完就被清掉。# 每天 2 点执行备份脚本凌晨 4 点半清理过期文件 0 2 * * * /usr/local/scripts/backup_app.sh 30 4 * * * find /data/backup -maxdepth 1 -name app_*.rar -mtime 30 -deletefind 的 -maxdepth 1 防止递归扫描子目录-mtime 30 按修改时间过滤超过 30 天的文件才会被删除。如果你不想让清理行为不可逆把 -delete 换成 mv 到 /data/backup/archive 再定期处理相当于多留一道后悔药。结合前面的 rar t 校验可以认为磁盘上的每个备份包都是经过验证的清理流程才敢放心跑。顺序记住一句话先压缩、再校验、后清理任何一步失败都停住不自动进入下一步。5. 避坑复盘Linux 下 RAR 工具的四个典型翻车现场这一章把我在不同服务器上实际遇到过的坑逐一拆开每条按现象、原因、解决的顺序写方便对照排查。四个问题相互独立但都容易和上面的部署步骤混在一起出现。5.1 command not foundPATH 没刷进去现象装完执行 rar 提示 rar: command not found但切到 /opt/rar 目录用 ./rar 又能跑。原因二进制可能不在 PATH 覆盖的目录里也可能是当前 shell 的 PATH 缓存还没刷新。cron 和 Web 面板里出现这个提示则几乎一定是执行环境没有加载 profile 或 bashrc而不是路径本身没设好。解决先用 which rar 或 ls /usr/local/bin/rar 确认文件在不在。文件存在但命令找不到说明是 PATH 没生效改用绝对路径调用最省心。我把 /usr/local/bin 和 /opt/rar 都写进 /etc/profile.d/再在脚本里用 $RAR 变量双保险之后 command not found 就很少出现了。5.2 Exec format errorx64 包装到了 ARM 服务器现象执行 rar 时提示 bash: /usr/local/bin/rar: cannot execute binary file: Exec format error文件明明存在权限也是 755。原因标题里写着 x64对应的是 x86_64 指令集。ARM 服务器、苹果 M 系列云主机上跑 x64 二进制内核直接拒绝加载跟文件权限无关。解决先 uname -m 确认架构再下载匹配的版本。用 file 命令验证一下是最稳的file /usr/local/bin/rar # 期望输出 ELF 64-bit LSB executable, x86-64 ...我在一台 ARM 云主机上硬装过 x64 包折腾半小时才发现方向错了。从那以后拿到任何二进制我都会先跑 file 确认格式再考虑怎么部署。5.3 中文文件名乱码先看 l 的输出再决定怎么解现象rar x 解压后目录和文件名变成乱码或者是一串问号用 ls 看完全认不出。原因压缩包在 Windows 上生成时文件名用的是本地编码比如 GBKLinux 侧按 UTF-8 解码就错位。RAR 6.x 版本对编码的兼容性好了一些但老包、第三方工具打的包仍然很容易踩。解决解压前先 rar l 看看包内文件名在终端是否正常。如果 l 阶段就乱码说明是源包编码问题解压后用 convmv 转码文件名# 发行版先安装 convmv再对解压后的目录做文件名转码 convmv -f gbk -t utf8 --notest /data/restore/注意是转文件名不是转文件内容千万别对文件内容做同样操作。乱码目录里文件多了之后手工 mv 会非常累convmv 一条命令就能把整个目录树的文件名重写掉。这个经验帮我处理过好几份 Windows 交付物价值很高。5.4 unrar-free 冒充 unrar只能解不能压现象执行 unrar a archive.rar dir 时报 unknown option或者说不支持该操作但解压却能正常用。原因系统发行版自带的 unrar-free 只是 RAR 读取器功能被裁剪到只能解压不支持 a、c 这类写入子命令。命令名字一样能力完全是两个东西。解决在服务器上同时存在两套 unrar 时我一般不会去卸载系统包而是统一用 rar 前缀调用完整版。脚本里写 /usr/local/bin/rar a从不用 unrar 去压缩这样系统里的 unrar-free 是什么版本都不会被误用。如果你确认 unrar 指向的是本包拷过去的二进制那它也是完整版但为了消除歧义全路径 rar 是最省心的写法也方便团队其他成员接手时一眼看懂。6. 验证与排错陌生 RAR 也值得先过一遍 rar t 再解压收到一份几十 GB 的交付 RAR第一反应直接 x 解压很容易在十分钟后才发现有文件损坏。压缩包损坏不会在解压一开始就全部暴露而是解到某个文件时才报 CRC 错误前面花的时间全部白费。我的固定流程是三步先 l 看内容、再 t 验完整性、最后 x 解压。脚本化之后大概是这样的#!/usr/bin/env bash set -euo pipefail ARCHIVE/data/delivery/xxx.part01.rar OUTDIR/data/extracted /usr/local/bin/rar l $ARCHIVE if /usr/local/bin/rar t $ARCHIVE; then /usr/local/bin/rar x -o- -y $ARCHIVE $OUTDIR else echo integrity check failed: $ARCHIVE exit 1 firar l 先输出包内文件清单看看路径和数据量是否符合预期rar t 校验整个包失败立即停住任何文件都不落地rar x 用 -o- 跳过已有文件避免覆盖服务器上的同名文件-y 自动应答所有确认提示。多卷包同样适用把 part01 传给 l、t、x 即可后续分卷会按序号自动续上。这套流程还能顺便排查三类问题密码错误时 t 阶段就会停下分卷缺失时 t 阶段会报缺卷文件名编码问题在 l 阶段就能发现。相比直接解压多花的时间只是先跑一遍 CRC对几十 GB 的包也就几分钟。我在处理数据库逻辑备份、外部交付包时几乎每份都强制走这个流程。解压完成后我会再抽查两个关键文件的 md5和交付方发来的校验值比对一下确认磁盘层面没有静默损坏。这一步是强迫自己在交付前做的毕竟服务器上出了错最后背锅的还是自己。从那以后我不管处理谁的 RAR 压缩包都强制先走 rar l、rar t、rar x 这个顺序已经养成肌肉记忆几乎没再因为解压翻过车。希望帮到你。本文还有配套的精品资源点击获取
返回列表