サーバー運用実績話 2022秋
何が起こったか
ローカルでTwitterのツイートをJsonで保持するものを使っている
もう数年も使っているので、Jsonファイルが1ディレクトリに100万件を超えて保持されている
基本的にデータファイルはそのままコピーしてバックアップを処理していた
rsync を用いた差分なので不自由は特になかった
なお、バックアップ先は外付けのストレージとなる
最近、そのストレージを交換することになった
エラーがあったわけではなく、なんとなく「もう古いしなあ」という程度
後でSMARTを見たら 5万時間 の稼働だった、5年以上、長い
交換の際、もう一台のストレージに、既存ストレージの中身を移動させようとしたが、
上記Jsonファイルなど様々な要因で移動が長期化して、あるいは終了の目処が立たなくなった
そこでどのようにすべきか考えることにした
最終的な案
Jsonファイルをバックアップ元のサーバーにて tar で圧縮し、転送するようにした
バックアップジョブ中にこれを処理に加えた
圧縮する時間はかかるが、生のままコピーやrsyncよりは早いことが検証できたため
ファイル数が多くても、圧縮する時間は10分程度のため許容できる
したがって、元のストレージにある大量のJsonファイルは削除し、
今後のバックアップにて転送されてくる tarファイルを新たなバックアップとした
検討するための内容
まず、大量ファイルの扱いはWindowsもLinuxも苦手である
可能な限り少数にまとめて1ファイルにしたほうが効率が良い、これが前提となる
大量に至らない場合は、個別に扱ったほうが有利である
先述の通り rsync を使えば差分のみ転送するので、効率的になる
圧縮の場合、常に完全に取得することになる
差分で数秒済むところ、圧縮⇒転送⇒削除(保持しない場合) が必要となり、時間がかかる
更に一時的に容量を使用する
しかし、検証したところ、Linuxの場合は 個別に mvやrsync するよりも、tar cz をしてmv のほうが効率が良くなった
上記から、もしこの記事を参考にされるとして、
どちらを採用するかは状況による、ということになる
新規構築で将来的にどのようになるのか検討つかない場合は、
rsync によるバックアップ ⇒ 大きくなってきたならば 圧縮ファイルによる転送へ切り替え
最初から大規模が想定される場合は、圧縮に使う領域も構成に組み込んでの圧縮転送
なお、余談だが Windows は少数ファイルも扱いが下手である・・・改善して?
FastCopy32 を利用することで、この問題は大きく解決する
FastCopy
関係コマンドあれこれ
・ファイル数を調べる⇒ ls -l | wc -l で出た値 -1 (CentOS, Alma Linuxの場合)
・圧縮 tar cz *.tar.gz 対象ファイル
・プロセス監視 ⇒ while [ 1 ] ; do clear; ps aux | grep 対象プロセス; sleep 1 ; done; とか
・同期、マージに rsync
ストレージ交換を思い立ってやり始めたらいつの間にか週末だし、
やっぱり自宅サーバーを廃止したいよなあ
