スナップショットは、自宅コンピューターで単純な仮想マシンを実行している場合でも、常に更新や変更が行われている企業データベースである場合にも重要なものです。 スナップショット、つまり、ある期間でのファイルシステム全体のコピーを持つことは重要です。
人は、どこで何が起こったのか、ファイルが削除され、それがなくなっていることに誰も気づかなかったのか、わからなくなることがよくあります。 数回のバックアップが経過した後、重要なファイルが過去 5 週間のすべての利用可能なバックアップから失われていることに気付きます。 このチュートリアルでは、ZFS スナップショットの使用方法を確認し、リソースの使用率と復元性の両方の観点から最適に機能するさまざまなスナップショット ポリシーに触れます。
ZFS にはファイルとディレクトリの高レベルな概要があり、データがディスクにどのように書き込まれるかを理解します。 データをディスクに物理的に書き込む場合、それは個別のブロックで行われます。 通常、ブロックのサイズは 1 MB まで可能ですが、デフォルトでは通常 128 KB になっています。 コピーオンライト機構は、ブロックが変更されるたびに、ブロックを直接変更するのではなく、新しいブロックに必要な変更を加えたブロックのコピーを作成することを保証するものです。 従来のファイルシステムでこのようなことが起こると、ファイルが破損したり、穴が空いたままになってしまいます。 しかし、ZFS を使用している場合、それが起こったときに進行中のトランザクションを失うかもしれませんが、ファイルの最後の有効な状態はまだ手つかずのまま残されます。
スナップショットもこの機能に依存しており、実際かなり大きく依存しています。 与えられたデータセット (「データセット」はファイルシステムに対する ZFS の用語です) のスナップショットを取るとき、ZFS はスナップショットが作成されたときのタイムスタンプを記録するだけです。 それだけです。
ファイルシステムが変更され、その中のデータがスナップショットから分岐したときのみ、スナップショットは余分なストレージを消費し始めます。 ZFS は、古いブロックを時間の経過とともにリサイクルする代わりに、それらを保持します。 これにより、ストレージの利用率も向上します。 20GB のデータセットをスナップショットし、あちこちのテキスト ファイルを変更するだけなら、スナップショットは数 MB のスペースしか必要としません。
スナップショットの作成
スナップショットの使用を示すために、問題を簡単にするために、多くのテキスト ファイルを持つデータセットから始めてみましょう。 デモに使用する仮想マシンは FreeBSD 11.1-RELEASE-p3 で、この記事の執筆時点では最新の安定版となっています。 ルートファイルシステムはデフォルトでzrootプールにマウントされ、/usr/src、/home、/etcといったおなじみのディレクトリは、すべてzrootにマウントされた独自のデータセットになっています。
FreeBSD のデフォルトのファイルシステム、あるいはデータセットのひとつは、 zroot/usr/src
そのプロパティを見るには、以下のコマンドを実行してください。 Zroot/usr/src
:~$ zfs snapshot zroot/usr/
Let’s take a snapshot of zroot/usr/src
@記号はデータセットとスナップショット名の間の区切りとして機能し、この場合 snapshot1 とします。
次に、スナップショットが作成されたときの状態を見てみましょう。
zfs list -rt all zroot/usr/src
コマンドを実行すると、スナップショットが作成されるときに、余計なスペースを使用しないことがわかります。 また、読み取り専用のデータセットであるため、スナップショット自体が大きくなったり、変更したり、縮小したりすることもできないため、空き容量もありません。 最後に、それはどこにもマウントされないので、与えられたファイルシステム階層から完全に分離されます。
次に、/usr/src/
にある sbin ディレクトリを削除します。
:$ rm /usr/src/sbin
スナップショットを見ると、成長していることがわかります。
上記の出力にある REFER 列に注目してください。 USED 列が物理ディスク上でどのくらいのスペースが占有されているかを示すのに対し、これはデータセット上のアクセス可能なデータ量を示します。
ZFS のコピーオンライト機構は、ファイルを削除すると以前より多くのスペースが使用されているように見える、直感に反する結果をしばしばもたらします。 しかし、ここまで読んで、実際に何が起こっているのかがわかりましたね！
最後に、snapshot1 から sbin を回復してみましょう。 これを行うには、
:/usr/src$ zfs rollback zroot/usr/
Snapshotting Policy
次の質問は、スナップショットを取得する頻度です。 企業によって異なるかもしれませんが、頻繁に変更される非常に動的なデータベースを例にとってみましょう。
最初は 6 時間ごとにスナップショットを取得し始めますが、データベースは非常に頻繁に変更されるので、作成された多数のスナップショットをすべて保存することはすぐに不可能になるでしょう。 そこで次のステップは、たとえば 48 時間より古いスナップショットをパージすることです。
さて、問題は 49 時間前に失われたものを回復することです。 この問題を回避するには、その 48 時間の履歴から 1 つまたは 2 つのスナップショットを維持し、1 週間はそれらを保持することができます。 282>
そして、この方法を続けることができれば、頻度の低い順に、システムの創世記までスナップショットを詰め込むことができるのです。 最後に、これらのスナップショットは READ-ONLY であることを指摘しておきます。つまり、ランサムウェアに感染して、すべてのデータが暗号化 (変更) された場合です。 これらのスナップショットは、ほとんどの場合、まだ無傷のままです。