結論
実践的には「ダメ絶対」
詳細
個人的にはむしろ「rsyncレベルのバックアップ対象に/var/cacheを含めるべきか」という話で少し興味があった。関連して、ディスク圧迫時に /var/cache/ 下のファイルで大きい物を消してよいか、というのも興味がある人もいるのかもしんない。
まずFilesystem Hierarchy Standardによる、「良い」ことになっている。最新の3.0より引用する
/var/cache is intended for cached data from applications. Such data is locally generated as a result of
time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike
/var/spool, the cached files can be deleted without data loss. The data must remain valid between
invocations of the application and rebooting the system.
Files located under /var/cache may be expired in an application specific manner, by the system
administrator, or both. The application must always be able to recover from manual deletion of these files
(generally because of a disk space shortage). No other requirements are made on the data format of the
cache directories.
おそらくだが、特定の時間がかかる作業の成果に例えばIDを振るなどして/var/cache/your_app/(id) とかで書き込んでおき、次回以降はソフトがそのキャッシュを実際にreadしてみて、存在したら結果をそのまま使い、そうでなければ計算し直す、みたいな用途で使えるディレクトリと考えられる。 /tmp と違ってリブート耐性が期待出来るのもポイントが高いのかもしれない。その用途なら/var/tmpがあるけど。
とはいえ現実にはここに大事なデータを突っ込んじゃうソフトが有るようだ
Can I safely remove /var/cache?
大事なデータを突っ込んでしまうアプリケーションとしてまずDNS等で使われるbindが挙げられている。
また、一部のパッケージマネージャ(例えば Debian/Ubuntu系のapt、 RHEL/CentOSのyum, Arch Linuxのpacman等)がこのディレクトリを使うらしく、パッケージマネージャ側の流儀 (apt-get clean, yum clean, pacman -Sc) に従わずに/var/cache 配下の関連ディレクトリに手を入れる (ファイルが大きいからという理由で消したりする) と、ソフトウェア側でまずい挙動を示す可能性があるようだ。FHSの説明に反してはいるが、(文句を垂れるとか必要なら公式にIssue登録した上で)運用者は実際のソフトの挙動に合わせるしかない。
異なる視点で見てみると、/var/cacheのLinuxでのパーミッションはroot/rootに対してdrwxr-xr-x、non-rootアプリに自由に使わせるつもりはないようだ。まぁこれは当たり前といえばそうかもしれないが、FHSの説明通りにキャッシュを保存したいnon-rootアプリはやっぱり/var/tmpに目を向けるしかない気がする。
rsyncの対象に含めるべきか？ 原則含める方向で調整し、消して問題がなく、容量が大きいとか、素性が良くないアプリ(サブディレクトリ)を--excludeで外していくのが良さそうだ。