見出し画像

ZFS とrsync

サーバーのリプレイスが完了したのでバックアップしてあったデータを戻す作業などをしていました。

作業といってもデータ量が多いのでコマンド一回叩いてあとは、バックグラウンドで終了待ちなんですけど

ここZFSファイルシステム採用の領域に大きめのデータをコピーする時に気をつけた方がいい事について今日は、書きたいと思います。

ZFS > HDD(逆も然り?)

ZFSのデータセットから別のファイルシステムにデータを移動する場合、cpコマンドで移動するとZFSの構成ディスクが多い場合、HDDが不意に外れます。

ん?

って思うかもしれませんが、実際に私がサーバーリプレイス前にデータをHDD5台のRAID-Z2構成のZFSから「/mnt」にマウントしたHDDにcpコマンドでコピーした際に、ZFSを構成しているHDD達がOS上から忽然と姿を消しました。

※ちなみにコピーしたデータは、81GBの1ファイルのデータです

/dev/disk/by-idをlsコマンドで確認してコピー開始する前までいた連中の姿がありませんでした。

「うーん・・・」っと困ってしまい仕方がないので再起動を実施

再起動が完了して当該のZFSを確認すると姿を暗ましたHDD達が戻ってきておりZFSが正常稼働に戻っていました

/dev/disk/by-idをlsコマンドで確認してみるとやはり全員揃っていました。

しかし、原因がわからずどうしたものかと思いました。

そこで同じデータをコピーするコマンドとして「rsync」コマンドがあるので一縷の望みをかけて、同じデータを同じ場所にコピーを行ってみました。

はて?なぜに?

結果は、きちんと最後までコピーされました。

さて!しかし、原因がわからずじまいです。

今後同じように重要なデータをバックアップする際にこのまま原因不明では心許ないと思いました。

原因究明のために根本的なことを調べる事にしました。

そもそもcpコマンドとrsyncコマンドの違いです。

やっている事は、似ている・・・けどコマンドが分かれているという事は、何かが違うという事!

LinuxなどCLIが主流のシステムは、無駄を嫌います。

全く同じ事をしているのであればより優れているものだけが残るはずです。

負担を強いられるものの違い

ググってみると個人的に納得のいく答えはすぐ見つかりました。

cpコマンドは、データをコピーする際にそのコピーにかかる負担をHDD(SSDも含むディスク)に強いるようです。

rsyncコマンドは、CPUに負担がかかるようになっているそうです。

実施に上記のサイトの方がvmstatコマンドで負荷を計測してくれています。

現在のサーバーのデータ保管用のZFSの構成HDDは、PCI-Eに接続してある玄人志向のキワモノの10スロットのSATA3が付いた拡張カードに接続してあります。

https://www.kuroutoshikou.com/product/interface/ata_sata/sata3i10-pcie/

おそらくcpコマンドでデータをコピーした際は、こいつに接続されたHDD全員に対して最大負荷でデータを引き出しを要求した所為で、HDDのI/Oとこの拡張カード自体の処理の許容範囲を超えたため、ZFSの構成HDDが正常稼働を行える台数以下になるまで順次落ちていったと思われます。

rsyncコマンドの場合は、HDDへの負荷が低いため落ちずに最後もまでコピーできたのだと思います。

厳密に試験したわけでは、ないので正確ではないですが、みなさんもZFSから大きめのデータをコピーする際にHDDが落ちてしま様でしたら、rsyncコマンドを使用してみてください。


ちょこっと興味を惹かれたらスキをお願いします。

エンジニアでも、そうでない方でも記事の内容で指摘がありましたらご意見をいただきたいです。


以上、また明日

この記事が気に入ったらサポートをしてみませんか?