企业官网建设流程全解析

简介：面向64位Linux（x86_64）用户的RAR命令行压缩工具测试包，版本6.1.b1，适合需要在Ubuntu、Debian、Fedora等环境中处理RAR档案的运维与开发人员。压缩包共11个文件，体积约590KB，内含rar与unrar可执行程序、default.sfx自解压模块、makefile及若干txt说明文档，并附rarfiles.lst、order.htm等辅助文件，便于了解命令用法、授权信息与版本变更。已有200人学习下载。读者可据此获得Linux下RAR压缩解压、分卷、加密与损坏档案修复等能力的工具入口，也可通过readme、whatsnew等文档快速核对参数和使用限制；b1为测试版，适合评估新特性或在受控环境中验证兼容性。

1. rarlinux-x64-6.1.b1.tar.gz 是什么：一份只有两个可执行文件的命令行包

rarlinux-x64-6.1 这个包，拆开看几乎没有“安装”这回事：一个 tar.gz 里躺着 rar 和 unrar 两个 Linux x64 可执行文件，外加一份扩展名掩码列表和几页说明文本，没有图形界面，没有向导，也没有依赖清单。它解决的场景很具体——服务器上没桌面、只能靠 shell 干活，却要处理 .rar 归档：解别人发来的包、给日志和数据目录打固实压缩、按 2G 切分卷、加密码、留恢复记录。适合运维、后端、数据交付这类天天跟归档文件打交道的人；只想双击解压的，这份资源帮不上忙。版本号里的 b1 要记牢，它是测试构建，不是稳定分支。

2. 落地安装：从 tar.gz 到命令行里能跑通

2.1 解包之前先列清单

拿到一个来路清楚的压缩包，我第一件事永远是只读不解，先看结构和权限位。

# -t 只列目录不解压，-v 带权限与大小，-z 走 gzip tar -tzvf rarlinux-x64-6.1.b1.tar.gz

正常输出是顶层一个目录，里面是两个 ELF 可执行文件、一份掩码列表、一个自解压模块和若干说明文本。这一步的价值在于提前发现两件事：一是打包时有没有丢失执行位，二是文件是不是真的只有这些，避免解出一堆没预料到的东西再回头清理。-v那一列权限位里如果 rar 和 unrar 没有x，后面复制时必须靠install -m 0755补回来，直接cp过去再执行会报权限拒绝。

体量上 rar 比 unrar 大，因为压缩端的算法实现更重。解包时如果只想看目录结构不想占空间，把-z换成-t先跑一遍，确认顶层目录名再决定解到哪，别在/tmp里堆一堆重复文件。

2.2 装到哪：/opt 存版本，/usr/local/bin 只放软链

安装位置这件事，取决于你机器上有没有别的 rar。有旧版本的时候，直接覆盖/usr/local/bin是最容易埋雷的做法——某个跑了两年的备份脚本会在某天早上突然换了压缩行为。我一般这么放：

cd /tmp tar -xzf rarlinux-x64-6.1.b1.tar.gz cd rar # 版本化目录，beta 号写进路径里，一眼能看出跑的是哪个构建 install -d /opt/rar-6.1b1/bin # install 一步搞定复制+权限，等价于 cp + chmod 0755 install -m 0755 rar unrar /opt/rar-6.1b1/bin/ # 掩码列表放子目录，别直接铺在 /etc 根下 install -d /etc/rar install -m 0644 rarfiles.lst /etc/rar/rarfiles.lst # 需要全局可见时用带版本后缀的软链，不抢默认命令名 ln -sf /opt/rar-6.1b1/bin/rar /usr/local/bin/rar-6.1b1 ln -sf /opt/rar-6.1b1/bin/unrar /usr/local/bin/unrar-6.1b1

install -m 0755里的0755是属主读写执行、同组和其他人读执行；二进制文件别给0777，多出来的写权限在共享主机上是安全隐患。把可执行文件放/opt/rar-6.1b1/bin而不是直接进/usr/local/bin，好处是回滚只需要删一个软链，脚本里写绝对路径调用时也不会因为 PATH 顺序的玄学跑到别的版本上去。

如果包内附带 makefile，make install会一步把 rar、unrar 装进/usr/local/bin，掩码列表装进/etc。省事，但它会覆盖同名文件，执行前先which -a rar unrar看一眼旧版本在哪，心里有个数。装完记得hash -r清掉 shell 的命令缓存，否则新装的命令可能还要开个新终端才生效。

2.3 三条命令验证装对了没有

装完不验证等于没装。我固定跑三条：

# 1. 看解析到的是哪个文件，多个版本时能立刻发现冲突 command -v rar unrar which -a rar unrar # 2. 动态库一票否决：有 not found 就别往下走了 ldd /opt/rar-6.1b1/bin/rar | grep -i "not found" && echo "缺库" || echo "依赖 OK" # 3. 不带参数跑一下，能打印 banner 和用法说明链接过了 /opt/rar-6.1b1/bin/rar 2>&1 | head -n 3 /opt/rar-6.1b1/bin/unrar 2>&1 | head -n 3

ldd那一步是最值得养成习惯的，它把“文件在执行但内核找不到解释器”这类问题提前暴露出来，比等到生产环境报一句含混的错误强得多。版本串里带着 b1 就是测试构建，把它写进部署记录，方便下次出问题回溯。

再加一条端到端的小验证，比看 banner 更实在：

mkdir -p /tmp/rt && cd /tmp/rt dd if=/dev/urandom of=blob.bin bs=1M count=8 # 造 8MB 随机数据，不可压缩 /opt/rar-6.1b1/bin/rar a -ma5 t.rar blob.bin # 打一个 RAR5 包 /opt/rar-6.1b1/bin/unrar t -inul t.rar; echo "exit=$?" # 只测不落盘

随机数据不可压缩，所以打出来的包应该比原文件略大——这是正常的，说明压缩路径确实走了而没有被什么开关短路。exit=0才算通过，非 0 要分清楚是参数写错还是包有问题，别一句|| true糊过去。

3. 压缩参数怎么搭：-m、-md、-s、-v 的组合边界

3.1 -m 与 -md：先算内存，再谈压缩率

压缩级别和字典大小是两个独立维度，很多人只调前者，结果发现从-m3到-m5体积几乎没降——因为瓶颈在字典，不在算法档位。

# 冷备：大字典 + 最高档，用 CPU 换体积 rar a -ma5 -m5 -md256m -mt4 backup-2024.rar ./data/ # 交付：中档压缩，几分钟内出包 rar a -ma5 -m3 -md32m handoff.rar ./dist/

-ma5指定 RAR5 归档格式，只有这个格式才吃得下 1G 级别的字典和 BLAKE2 系列的校验；-md256m把字典设成 256MB，必须是 2 的幂，压缩端内存占用大致就按这个量级往上走，容器里跑之前先看 memory limit，不然会被 OOM Killer 直接带走。-mt4开 4 个压缩线程，压缩是纯 CPU 密集活，线程数超过核数只会互相抢，没有收益。

解压端的内存要求明显低于压缩端，但依然和字典大小相关。做长期归档时我的取舍是：字典设到 128M～256M 就够了，再往上压缩率的边际收益很小，而一旦哪天要在小内存机器上解，反而给自己挖坑。

3.2 -s 与 -v：固实压缩和分卷的代价

rar a -ma5 -m5 -s -md128m -v2g -vn -rr3% -rv2 bigdata.rar ./dataset/

-s是固实压缩，把一堆小文件当成一条连续数据流来压，同构的小文件（大量相似文本、切片的图片、源码树）压缩率提升非常明显。代价有两个：解压单个文件时得从头扫到它所在的位置，越靠后越慢；包一旦固实就不适合增量更新，往固实包里加文件等于重压。所以“每天往里塞文件”的归档不要开-s，用-s-或者干脆每次打新包。

-v2g按 2G 切分卷，单位可以是 k、b、m、g。不加-vn时 RAR5 用.part1.rar、.part2.rar这种新命名；加了-vn走旧的.rar/.r00/.r01命名。选哪种只看接收方——老工具链认旧命名，新脚本用新命名更直观，混着来最容易出错。

-rr3%写 3% 的恢复记录，-rv2额外生成 2 个恢复卷。恢复记录是按卷写入的，能救的是 CRC 级别的局部损坏；如果一整卷丢失、磁盘块级损坏超过记录比例，它救不回来。所以百分比要按“单卷最坏情况”估，不是按整个包的大小估，这一点在血泪经验里排得很靠前。

3.3 -x 与 -n@：排除规则怎么写才生效

# include.lst 一行一个掩码，格式和 rarfiles.lst 相同 cat > include.lst <<'EOF' *.conf *.yaml *.sql EOF rar a -ma5 -m5 -ep1 \ -x'*.log' -x'*/node_modules/*' -x'*/cache/*' \ -n@include.lst \ app-config.rar ./app/

掩码务必用单引号包住。不包的话 shell 会先把*.log展开成当前目录下真实存在的文件名，传给 rar 的规则就变成了几个具体路径，看着像“排除了却没生效”，实际上是规则根本没送进去。

-ep1去掉命令行里给出的基础目录，解压时不会凭空多出一层app/。-n@从文件读包含列表，好处是规则可以进仓库跟版本走，不用把一长串-x塞在 crontab 里。注意-x的优先级高于-n，两者同时命中时以排除为准；掩码的匹配基准是你传给命令的路径，不是当前工作目录，写-x'*/cache/*'这种带前导通配的形式最稳。

规则写完别直接跑全量，先rar lt或rar l看一眼条目数和总大小对不对，这一步花十秒，能省掉一次重打。

3.4 -p 与 -hp：加密强度的分界线

# 只加密数据，文件名仍可列出 rar a -p -ma5 secret-data.rar ./docs/ # 连文件头一起加密，文件名也看不到 rar a -hp -ma5 secret-all.rar ./docs/

-p后面不跟值就是交互式提示输入，这是推荐姿势。写成-pMyPass会同时留在 shell history 和ps的命令行里，等于把密码贴在墙上。-hp加密文件头，没有密码连包里有几个文件、叫什么名字都看不到，安全性高，但找回能力为零——密码丢了就是真丢了，没有后悔药。

解压端对应关系是：-hp打的包，unrar l就需要密码；-p打的包可以列目录，但取文件要密码。批量解无密码包时用-p-强制关掉密码提示，避免脚本卡在交互上。

4. 解压、校验与修复：unrar 的动作选择

4.1 x / e / t / l / p 五个动作的差别

unrar l big.rar | head -n 20 # 先看条目数和总大小，再决定解到哪 unrar x -o+ -ad big.rar ./restore/ # 带路径解压，同名覆盖，自动建同名子目录 unrar t -inul big.rar; echo "exit=$?" # 只校验，不落盘 unrar p big.rar conf/app.yaml # 单个小文件直接打印，不落地

-o+覆盖同名文件、-o-跳过、-or自动改名。-ad这个开关在批量解压时非常关键：它让每个包解到各自同名的子目录里，不加的话几个包的文件会糊在同一层，事后清理比重解还麻烦。-inul关掉进度输出适合脚本，但错误信息也一起被压掉了，所以必须配退出码判断——返回 0 才算通过，CRC 类错误和参数类错误的返回值不一样，脚本里要分开处理。

4.2 分卷包：只给第一个卷

unrar x -o+ pack.part1.rar ./out/ # RAR5 新命名，只给 part1 unrar x -o+ pack.rar ./out/ # 旧命名，只给主卷

unrar 会按前缀自动找后面的卷，前提是所有卷在同一目录、前缀一致、编号连续。缺卷时它会明确报找不到某个卷，这时候不要去试-kb，那是给损坏文件抢救用的开关，会让它把半截文件也写出来，看上去解压成功了，实际数据是残的。

批量恢复时我习惯先把所有分卷sha256sum存一份清单，解压前先sha256sum -c过一遍，确认传输环节没出问题，再让 unrar 干活。顺序反了的话，出了错不知道是文件坏了还是包坏了。

4.3 恢复记录与修复流程

有-rr的包才有修复空间，没恢复记录的包一旦 CRC 损坏，基本只能回退到备份。流程固定三步：

# 1. 先测，拿到具体是哪个文件、哪一卷出问题 unrar t -inul archive.rar; echo "exit=$?" # 2. 有恢复记录时尝试修复，修复结果另存副本，不动原件 rar r archive.rar # 3. 对修复产物再测一遍，通过才算救回来 unrar t -inul fixed.archive.rar; echo "exit=$?"

rar r不会覆盖原文件，它另存出一个修复后的副本，文件名以屏幕输出为准，别凭猜。分卷包损坏时先用rar r对第一分卷做重建，能补回缺失的卷结构再解压；补不回来的，老老实实承认丢失，从备份取。这几步我一般写进一个脚本里，因为着急的时候人容易跳步，跳过测试直接解压，最后拿到一堆打不开的文件还以为恢复了。

5. 避坑与排查：五个真实翻车现场

5.1 轻量容器里报“文件不存在”，但 ls 明明能看到

现象：./rar执行报No such file or directory，ls -l显示文件在、权限也对。

原因：这类精简镜像用的是 musl 运行库，没有 glibc 的动态链接器，内核找不到 ELF 里指定的解释器路径，报错就变成了“文件不存在”这种误导性文案。

解决：ldd ./rar一看就知道，输出里会有not found或直接提示不是动态可执行文件。真要在这类镜像里用，换 glibc 基础镜像，或在阶段划分里把解压动作放到另一个构建阶段，别在生产基础镜像上硬塞兼容层——那种做法短期能跑，长期是维护黑洞。

5.2 昨天还好好的打包脚本，今天产物解不开

现象：同一个脚本，包体积突然变了，或者解压时报格式错误。

原因：全局默认的 rar 被换成了新版本（比如这次装的是 b1 测试构建），脚本里写的是裸命令rar，PATH 一改就换了实现。测试构建的行为和稳定版有差异属于正常，问题出在没人知道换了。

解决：可执行文件放/opt带版本号的目录，脚本里写绝对路径，别依赖 PATH 顺序；升级前which -a rar拍照留档；把版本号打进产物文件名，出问题能立刻对应上。从那以后我所有涉及归档的脚本都这么写，再没遇到过“版本自己变了”这种事。

5.3 密码泄漏在 history 和 ps 里

现象：ps aux能看到完整的密码参数，history里也留着明文。

原因：-pMyPass直接写在命令行上，进程启动参数对同机用户可见，shell 还会把它记进历史文件。

解决：用不带值的-p交互输入；必须自动化时，把凭据放 600 权限文件由受控账号读取，同时设HISTCONTROL=ignorespace、在敏感命令前加空格避免入历史，事后再检查一遍 history。已经泄漏的密码立刻换掉，别抱侥幸。

5.4 排除规则没生效，包比预期大好几倍

现象：明明写了-x'*/node_modules/*'，产物还是把依赖目录全打进去了。

原因：三种可能——引号没加导致通配符被 shell 提前展开；掩码基准路径写错，实际匹配不到；-n包含列表里又把这些文件显式加了回来（-x优先级更高，但如果-n@里的路径绕开了掩码就躲过去了）。

解决：先rar l看条目，确认到底打进去了什么；再把通配符统一加单引号，用带前导*/的形式覆盖任意层级；最后把包含/排除规则放进版本化的列表文件里，别散在命令行长串中。

5.5 解压出来的中文文件名乱码、时间戳全变成当前时刻

现象：从别处发来的包解开后，文件名是一堆问号或乱码，文件修改时间全部变成解压那一刻。

原因：老格式的包按打包端本地代码页存文件名，到 Linux 上按 UTF-8 解释就错位；时间戳丢失一般是打包时没保留、或解压目标文件系统不支持权限与时间属性（比如某些挂载参数下的外部存储）。

解决：能在打包端解决的就在打包端解决——统一用 RAR5 格式、文件名统一 UTF-8；收到老包先解一个小样本验证，别一次性全量解；跨文件系统交付前，先拿两个文件试解、比对 sha256 和 mtime，确认属性保住了再批量跑。

6. 进阶：把 rar 编进备份脚本，用三重校验兜底

我维护过一段无人值守的归档流水线，最怕的不是包没打出来，而是脚本返回 0 之后没人验证它能不能解开。所以脚本里固化了三道校验：打包退出码、全卷解压测试、独立哈希清单。

#!/usr/bin/env bash set -euo pipefail RAR=/opt/rar-6.1b1/bin/rar # 绝对路径，不依赖 PATH UNRAR=/opt/rar-6.1b1/bin/unrar SRC=/srv/data OUT=/backup/$(date +%F) mkdir -p "$OUT" # 1. 打包：固实 + 3% 恢复记录 + 2G 分卷 "$RAR" a -ma5 -m5 -md128m -s -rr3% -v2 <p> <a href="https://download.csdn.net/download/lion1994/33361886" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>