Veeam Softwareの高橋です。
Veeam Backup & Replication v9.5からはWindows ReFS、Veeam Backup & Replication v10からはLinux XFSがサポートされました。今回は、Veeam Backup & Replication v10でサポートされたリポジトリのLinux XFSサポートについてお話します。
実は、Linux XFSサポートは私自身、一番お勧めの機能です。
まず、Linux XFSについてですが、Linux XFSは、SGI IRIXで開発されたファイルシステムで1994年に開発されました。SGIのXFSがLinuxに移植されています。LinuxのXFSにもバージョンがあり、VeeamでサポートされているのはXFSのバージョン5です。また、LinuxのXFSは、最近開発版としてのサポートが外れて正式版になったので、プロダクション環境でのLinuxのディストリビューションの選択は注意が必要です。
(多くのディストリビューションは、ディストリビューションとしてはXFSを以前からサポートしていましたが、カーネルは開発版のドライバーを利用していました。)
正式版のXFSを利用するには、Kernel 4.16以降が必要となります。
Linux Kernel 4.16以上が利用されているLinux ディストリビューションはUbuntu Linux 20.04 LTSあるいは、RHEL/CentOS 8以降です。
私としては、最新Kernelを利用しているUbuntu Linux 20.04 LTSでのご利用を強くお勧めします。
VeeamのLinuxリポジトリでXFSを使うためには以下のコマンドラインでファイルシステムを作成します。
mkfs.xfs -b size=4096 -m reflink=1,crc=1 /dev/sdb1
オプションのreflinkというスイッチで、XFSが持つCoW Copy on Write)の機能が利用できます。
Veeam Backup & Replication v10では、このreflinkという機能を効率的に利用することができます。
Veeam Backup & Replication v10でLinux XFSサポートを利用すると以下の２つの効果が得られます。
- ジョブ: Fast Clone
- ディスク容量: 合成フルバックアップで生成された複数のバックアップファイル
Fast Cloneは、合成フルの時のパフォーマンスが劇的にアップします。合成フルは、ほぼ全てのバックアップ形式で使う機能です。
Linux XFSで利用されるFast Cloneは、Linux XFSにあるエクステント（ブロックの単位）を組み替えて高速に動作します。ファイルシステムの機能なので、リポジトリのシステムリソースにあまり影響しません。
パフォーマンスを実際に測定してみました。
＜ 増分量が毎回約2GB程度発生するジョブでのマージ (Fast Clone無し） ＞
- マージにかかった時間 1:07
＜ 増分量が毎回約2GB程度発生するジョブでのマージ (Fast Cloneあり）＞
- マージにかかった時間 0:21
このように合成フルが高速に動作します。
合成フルバックアップで生成された複数のバックアップファイルの恩恵を受けられるものについてですが、あくまでもLinux XFS上で作成された２つ以上のフルバックアップファイルがある環境で有効に作用します。
Linux XFSは、ファイルシステムで利用されるエクステントを共有化することで、消費するファイルを少なくします。
バックアップチェーン毎にみてみると…
– 逆増分バックアップチェーン
容量の削減効果はありません。理由は、チェーンに１つしか合成フルで作成されたフルバックアップファイルが無いためです。
– 永久増分バックアップチェーン
容量の削減効果はありません。理由は、チェーンに１つしか合成フルで作成されたフルバックアップファイルが無いためです。
– 増分バックアップチェーン
フルバックアップを２つ以上もつ増分バックアップチェーンでは合成フルで作成されたフルバックアップファイルのファイルサイズが削減できます。 実際にファイルを確認してみると以下に２つのフルバックアップファイルがあるのが分かります。
root@ent1-xfs:/backup/Repo1/Basic Backup Job 1# ls -lhs total 24G 9.2G -rw-r--r-- 1 root root 9.2G Aug 8 13:03 'Basic Backup Job 1D2020-08-08T220326_7F2A.vbk' 527M -rw-r--r-- 1 root root 527M Aug 9 13:03 'Basic Backup Job 1D2020-08-09T220033_789B.vib' 628M -rw-r--r-- 1 root root 628M Aug 10 13:04 'Basic Backup Job 1D2020-08-10T220048_8AEC.vib' 463M -rw-r--r-- 1 root root 463M Aug 11 13:03 'Basic Backup Job 1D2020-08-11T220040_0629.vib' 505M -rw-r--r-- 1 root root 505M Aug 12 13:04 'Basic Backup Job 1D2020-08-12T220050_1868.vib' 596M -rw-r--r-- 1 root root 596M Aug 13 13:05 'Basic Backup Job 1D2020-08-13T220106_721B.vib' 513M -rw-r--r-- 1 root root 513M Aug 14 13:06 'Basic Backup Job 1D2020-08-14T220042_AA3C.vib' 9.2G -rw-r--r-- 1 root root 9.2G Aug 15 13:10 'Basic Backup Job 1D2020-08-15T221028_DA19.vbk' 478M -rw-r--r-- 1 root root 478M Aug 16 13:05 'Basic Backup Job 1D2020-08-16T220047_DF23.vib' 642M -rw-r--r-- 1 root root 642M Aug 17 13:10 'Basic Backup Job 1D2020-08-17T220036_F8AD.vib' 506M -rw-r--r-- 1 root root 506M Aug 18 13:04 'Basic Backup Job 1D2020-08-18T220029_D07B.vib' 205M -rw-r--r-- 1 root root 205M Aug 19 02:30 'Basic Backup Job 1D2020-08-19T112905_CBAF.vib' 491M -rw-r--r-- 1 root root 491M Aug 19 13:03 'Basic Backup Job 1D2020-08-19T220049_DF64.vib' 144K -rw-rw-rw- 1 root root 144K Aug 19 13:03 'Basic Backup Job 1.vbm'
filefragコマンドの出力をそれぞれ比較すると、同じエクステントが共有(shared)となっていることが分かります。
root@ent1-xfs:/backup/Repo1/Basic Backup Job 1# filefrag -v 'Basic Backup Job 1D2020-08-08T220326_7F2A.vbk' | head Filesystem type is: 58465342 File size of Basic Backup Job 1D2020-08-08T220326_7F2A.vbk is 9853898752 (2405737 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 0: 28835736.. 28835736: 1: 1: 1.. 4360: 43157637.. 43161996: 4360: 28835737: 2: 4361.. 4362: 34665583.. 34665584: 2: 43161997: 3: 4363.. 4366: 34665588.. 34665591: 4: 34665585: 4: 4367.. 4367: 34665577.. 34665577: 1: 34665592: 5: 4368.. 4369: 28840114.. 28840115: 2: 34665578: shared 6: 4370.. 4404: 35442852.. 35442886: 35: 28840116: shared root@ent1-xfs:/backup/Repo1/Basic Backup Job 1# filefrag -v 'Basic Backup Job 1D2020-08-15T221028_DA19.vbk' | head Filesystem type is: 58465342 File size of Basic Backup Job 1D2020-08-15T221028_DA19.vbk is 9874632704 (2410799 blocks of 4096 bytes) ext: logical_offset: physical_offset: length: expected: flags: 0: 0.. 0: 28835723.. 28835723: 1: 1: 1.. 4360: 34505052.. 34509411: 4360: 28835724: 2: 4361.. 4366: 35795913.. 35795918: 6: 34509412: 3: 4367.. 4367: 35795911.. 35795911: 1: 35795919: 4: 4368.. 4369: 28840114.. 28840115: 2: 35795912: shared 5: 4370.. 4404: 35442852.. 35442886: 35: 28840116: shared 6: 4405.. 4406: 28840151.. 28840152: 2: 35442887: shared
利用用途としては、週次フルバックアップやGFSバックアップなどのフルバックアップファイルが複数ある環境で効果を発揮します。
同じXFS/ReFSリポジトリ内のフルバックアップデータであれば、重複排除に「似た」効果があるため、重複排除ストレージの代用としても利用ができます。（実際には重複排除とは異なります。）
さらにクラウド内にリポジトリを置く場合、インスタンスストレージのディスク使用容量も削減ができるという効果が期待できます。
注意点としては、アクティブフルのような実際に取ったフルバックファイルでは全く効果がなく、１回以上合成フルを実行した時からとなります。
さらにリストアポイントシミュレーター（コミュニティが作成したもの）でもXFSの設定があります。
リストアポイントの６と１３がXFS無しの場合 500G → 50Gまで削減できます。
Linuxリポジトリを利用する場合のいくつか注意点があります。
- Linuxリポジトリは、マウントサーバ機能が持てないため、別のWindowsサーバがマウントサーバになる必要があります。
Linuxリポジトリでのデフォルトのマウントサーバは、バックアップサーバになります。
特にインスタントVMリカバリや、Secure Restoreなどを行う場合、トラフィックが思いもしない部分を通過することがあります。
Linuxリポジトリを利用する場合、適切なサーバをマウントサーバとして設定することが重要です。
- XFSをNFSとしてエクスポートをしてもVeeam Backup & Replication v10では効果を発揮しません。
XFSは、あくまでもLinuxリポジトリとして利用する必要があります。
もし、ネットワークファイルシステムでFast Cloneを使いたい場合は、Windows Server 2019のReFSを3.1.1でエクスポートして利用することを検討してください。
マウントサーバが行う合成フルは、あまり意識する必要はないかと思います。（それでもあまり遠いところに置かないことをお勧めします。） Linuxリポジトリを構築、設定する場合に是非参考いただければと思います。
関連するその他の製品・ソリューションはこちら
Microsoft 365のデータの包括的なバックアップをサポートする「Veeam Backup for Microsoft Office 365」。製品概要や利用シーン、成功事例はこちら。
Windowsベースのシステム、物理サーバー、クラウドインスタンス向けの包括的なバックアップおよび復元ソリューション「Agent for Microsoft Windows」。製品概要やエディション比較、成功事例はこちら。
SharePointのオブジェクトを迅速かつ簡単にリストアできる「Veeam Explorer for SharePoint」。製品概要や新機能、エディション比較、特長はこちら。 l
投資対効果が高く安全で、エンタープライズにも対応している、Microsoft Azureのバックアップ専用製品「Veeam Backup for Microsoft Azure」。製品概要や成功事例などはこちら。
