大容量のNFSの増分バックアップ方法について

Question

いつもお世話になっています。

とあるWebアプリケーションのシステム上に数十TBのファイルをホストしているNFSサーバー（Linux）があり、近々別のNFSサーバーにデータ移行することを予定しています。

今の予定ではNFSサーバー側で全量バックアップを一度取ってから、バックアップ中に新規に作成されたファイル（アプリケーションのユーザーがアップロードした画像ファイルなど）を増分バックアップしようと計画しています。

増分バックアップの実現方法としてrsyncかinotify-toolsを利用するか迷っています。

私の現在の認識ですと、rsyncは実ファイルを一覧化して差分を検出する、inotifyはカーネルからファイルシステムイベントをキャッチするという認識です。

なので個人的には数十TBのストレージにおけるファイルの増分を検出する際には、inotifyが適していると考えているのですがこの見解はあっているのでしょうか...。

ご回答のほど、どうぞ宜しくお願い致します。

Answer 1

NFSだとinotifyが使えないので❨私が知らないだけで使える実装があったらごめんなさい❩、
inotify-tools
は使えないように思います

↑サーバ側でのバックアップを想定ということなので、前提が異なるため削除します

Comments

[nobodytolove123]

ご回答頂きありがとうございます。

懸念されていることは私も気になるところではありました、NFSはあくまでネットワークストレージなので、少なくともNFSのクライエント側からはinotifyは使えないはずです。

NFSのサーバー側でもイベントを検知できないかどうかは調査してみます、ありがとうございます。

それともNFSのサーバー側でもNFSを利用している影響でinotifyは使えないものなのでしょうか...?

[tanat]

あ、サーバ側での話なんですね。
すみません、質問の主旨を誤解していました。

であれば回答の懸念は関係の無い話ですね。

どちらの場合でも検証環境を作っての検証が必要な要件に思えるので、実際に試してみるのがベストかと思います。

[nobodytolove123]

はい、理想はいわゆる本番環境と同様の何十TBのディスクを持ったサーバーを用意して検証するのが然るべきなのですが、如何せん時間やコストがかかるので、検証前にrsyncとinotifyのどちらが適しているかを情報ベースでいいので収集しようと思っているという感じですね。

[tanat]

私の認識では
inotify-toolは単体で差分バックアップを取るというよりは、inotifywaitで差分発生時に該当ディレクトリを(Rsyncやシェルスクリプトで)バックアップを取るという認識です。

ファイル更新が頻繁にあるのであれば、inotify-toolsで更新があるたびに差分バックアップをするのは負荷が高くなりすぎる可能性があり、使用するディスク容量も大きくなるはずなので、ファイル更新頻度の想定要件とバックアップ頻度/世代/使用ディスクに関する要件をどうするか次第かなと思いますよ。

[nobodytolove123]

なるほどですね、ありがとうございます。

もしもですが、例えば数秒間に何百というファイルの更新があるのであれば、恐らくrsyncを実行した時のオーバーヘッドよりファイルの更新イベントごとに例えばcpコマンドを実行するオーバーヘッドの方が高くなりそうですもんね。

お話を聞いてファイル更新イベントが少ない場合は、inotifyによる単体バックアップが適していて、ファイル更新イベントが大量に発生する場合は、例えばcronなどでrsyncを実行するなどの方が適していると解釈したのですが認識あっていますでしょうか。

またバックアップ頻度/世代の要件も確かにありますね、ただ余程厳しい要件でなければバックアップ方針がinotify/rsyncでも大きな影響はないかなと判断してます。（うちのシステムではそこまで厳しい要件ではないですね）

使用ディスクは容量の観点で今の所判断してますが、こちらもinotify/rsyncでバックアップしても大きな問題が発生するとは考えていません。

[tanat]

個人的には概ね同じ考えですが、その辺はサーバの性能、ストレージ容量、必要なバックアップの世代/頻度次第だと思いますよ。

双方で実現できることが違うので、まずは何を実現する必要があるのか（=バックアップ要件は何か)を明確にしないといけません。

例えば問題発生時に、
その日の業務開始時点まで復旧できればそれで良いとするなら、深夜にRsyncでバックアップを取るのが適しているでしょうし、個別ファイルを可能な限り直近の変更まで復旧させる必要があるなら、変更がある度にバックアップを取る必要があるはず。といった感じで、要件をどう置くかという観点からも考えてみることをお勧めします。

(要件の中でも優先順位があるはずなので、まずは、必ず実現しないといけないことを整理されるのが良いかと思います。)

[nobodytolove123]

ありがとうございます、仰る通りですね。

> (要件の中でも優先順位があるはずなので、まずは、必ず実現しないといけないことを整理されるのが良いかと思います。)
ただ個人的に経験がないこともあって、数十TBのストレージの差分バックアップにrsyncが使えるのか？inotifyとcpコマンド等で差分バックアップしてて本当に大丈夫か？
というそもそも差分バックアップができるかどうかという最もクリティカルな問題を技術的に解決できるか？という点が気になっていました。

私の言葉足らずで伝わらなかったと思いますが、質問の背景には既存のNFSサーバーの容量が足りなくなったので、新規に増設した大容量のNFSサーバーに移行するという計画がありまして
そこで既存のNFSでホストしていた既存データを全て新規に増設したNFSサーバーに移行しなければならないという最優先の要件があります。

ただ助言を頂いた中で、そもそもファイル更新が大量の場合はinotifywaitを使おうがオーバヘッドが高くなるだけという観点を頂き
inotifywait、rsyncを使った時のメリット/デメリットや適しているパターンなどが把握できましたので調査を進め、他の要件も加味して方針を決めたいと思います。

とても長くなってしまって申し訳なりませんでした、またとても大変参考になりました。
相談に乗って頂き誠にありがとうございました。

[tanat]

参考になったようで良かったです。

最初のサーバ間のデータ移行は(物理サーバなら)外付けor内蔵HDDを接続してコピー&移送(or旧サーバのHDDを取り外して新サーバに接続してコピー)が一番早いケースも多いので、その辺も候補に入れると良いかもしれませんね。

[nobodytolove123]

助言頂きありがとうございます...!
そうですよね、それが一番早そうですよね。

ただ今回はクラウド上でホストしているシステムでして、一応別のチームの方でクラウドベンダーのデータセンターに入らせてもらってデータコピーできるか確認していますが、難しい予感がしてます...。

[tanat]

ああ、ではHDDで移送は難しそうですね。

AWSや他のメジャーなクラウドサービスみたいに、ブロックデバイス単位でイメージが取れる&他のインスタンスにアタッチ出来るならとても簡単かつ早いので、ホストしているベンダーサポートにそういう事が可能か問い合わせてみると幸せになれるかもしれませんね

[nobodytolove123]

なるほど、ありがとうございます...!
確かにイメージのアーカイブ的なものもありますよね。

今回の課題がそれで解決できるか、合わせて検討してみます！