Jirajine

磁带机比较适合这种数据归档的场景，而且可靠性很高。
低成本的可以买一堆 512G 的库存机械硬盘，价格非常便宜。因为盘位和功耗不适合用于存储服务器，但冷备份还是适用的。

@realpg #31 你不如干脆说只要记录审计加重罚让人小心操作就解决了。
你提供的推荐方式是错误的，只要目录的权限和当前 umask 不同、或所有用户/组与当前登录用户不同，从上级删除并重建就一定会把权限搞乱套。更不用说 xattr 等扩展属性、或者删掉了一个 btrfs subvolume 然后重建了一个普通的目录这种会为以后埋坑的现象。除非你的服务器是单用户的不然这种情况绝对不是“很少”而是很常见。
不要把你在特定场景的施行那一套“运维体操”当作一般建议。

@realpg
因为你这种规范要求就和这个帖子 https://www.v2ex.com/t/816040 不准用 http put 一样没什么实际意义纯粹给人制造麻烦，GNU rm 已经内置了-i 和-I 的保护措施不用。顺便-f 根本是不必要的，很多人习惯 rm -rf 的原因是有些系统会默认 alias rm='rm -i'，会导致批量删除时不加-f 会让每个文件都提示从而无法正常使用。

@realpg #14 如果 a 是一个含有空格的目录名，仍然可能会导致误删除。而且切了工作目录忘切回去怎么办？要不规范再加一条切到上级不许用 cd ，必须用 pushd 和 popd 。

其实如果 rm 是 GNU coreutils 提供的，直接要求使用或 alias 一个 -I 就可以了，该选项会在删除多个文件是提醒用户确认一次。

@yfwo #10 混淆概念，你在 Windows 装 vs 那一套开发环境 sdk 看看要多少空间，3gb 和 Linux 下装个 base-devel 也差不多少，就是标准的开发工具链的占用。
工具链里自带 git 和 git 依赖工具链是两回事。

@realpg #4 非常糟糕的规则，这样做麻烦不说，如果目录 a 有特殊的权限或其他 attribute 都会无法保留。
rm -rf * 要么执行前按 tab 通过 glob expansion 把*替换成实际要删除的文件名，要么 alias rm='rm -I' 或者其他 trash cli 提供二次确认。
不过这些都不能解决之前那个帖子容器环境下默认 shell 补全和配置都很受限的情况。

这都能洗的啊，好友验证一直不都是微信第一大喷点，是微信绑架你强制使用最直接的体现。