WordPressの範囲でバックアップを取得したい

現在、このブログサーバはバックアップを日時に取得しています。取得方法としてはAzure Backupを用いてVMイメージを丸っと取得する方法を採用しています。これが一番楽なバックアップ手法ではあるのですが、今後場合によってはオンプレミスにブログを移設することも考えられることから、Wordpressの論理的なバックアップを取得したいなーと考える時が時々ありまして。

Azure Blob StorageをNFSv3接続できるようになった

ここ最近、Azure Storage Accountにおいて、NFSv3接続がついにGAしました。
これは実に多くの人が期待してた機能だったのではないか？と思っておりましてですね、私自身にとっても待望の機能でした。ブログサーバにNFSv3接続できれば、そこへ送り込んだデータはStorage Explorerなどを用いると参照・ダウンロードできるしこれ便利だよなぁと思いまして。

保存先をこいつにしつつ、バックアップする手法が確立できないかなーと思うようになりました。

Azure BLOB StorageでNFSv3を有効にする

ここは、Microsoft Docsに記載されている手順を参照するとよいでしょう。

docs.microsoft.com

Azure Blob Storage でのネットワーク ファイル システム 3.0 のサポート (プレビ...

https://docs.microsoft.com/ja-jp/azure/storage/blobs/network-file-system-protocol-support

Blob Storage では、ネットワーク ファイル システム (NFS) 3.0 プロトコルがサポートされるようになりました。 このサポートにより、Linux クライアントは、Azure 仮想マシン (VM) またはオンプレミスで実行されているコンピューターから Blob Storage にコンテナーをマウントできます。

基本的には、NFSv3を有効にするには以下の制約があります。

• 有効化はStorage Account作成時にしか行えない。また、あとで無効化することはできない。
• パブリックエンドポイントに制限なしで公開することはできない。
• プライベートエンドポイントを構成するか、サービスエンドポイント経由でアクセスするかが必要になる
• 階層名前空間の有効化が必須

さらに、機能的にさまざまな制限があります。私が直撃したのは以下のような点です。

• ファイルロックはできない（よって、複数のサーバが同じファイルを書き込むような操作はとっても危険）
• サブディレクトリマウントはできない
• 容量管理ができない（dfコマンドたたいても使用量が0のままであった）

それでも以下のような点は結構心強かったです。

• no_root_squashの設定が可能

なお、共有ルートディレクトリはBLOBコンテナになります。
領域を分ける際はBLOBコンテナ単位で設定することになります。

マウント時は、マウント元のサーバで以下のように/etc/fstabへ仕込みをしました。nfs-utilsはちゃんと入れておきましょう。

<Account Name>.blob.core.windows.net:/<Account Name>/<Blob container name>       <bkpath> nfs     _netdev,sec=sys,vers=3,nolock,proto=tcp 0 0

マウントしたらこんな感じになりました。dfコマンド結果を記載します。容量が5.0ペタバイトと表示されてるところがそうです。

# df -h
ファイルシス                                              サイズ  使用  残り 使用% マウント位置
devtmpfs                                                    1.9G     0  1.9G    0% /dev
tmpfs                                                       1.9G     0  1.9G    0% /dev/shm
tmpfs                                                       1.9G  9.2M  1.9G    1% /run
tmpfs                                                       1.9G     0  1.9G    0% /sys/fs/cgroup
/dev/mapper/centos-root                                      35G   16G   20G   45% /
/dev/sda1                                                   497M  295M  203M   60% /boot
/dev/sdb1                                                    16G  2.1G   13G   14% /mnt/resource
tmpfs                                                       379M     0  379M    0% /run/user/1002
nfs30bcore.blob.core.windows.net:/nfs30bcore/bkdata-share   5.0P     0  5.0P    0% /bkdata
tmpfs                                                       379M     0  379M    0% /run/user/982
tmpfs                                                       379M     0  379M    0% /run/user/0

UpDraftPlus を使う

今回、UpDraftPlusというプラグインを使用しました。プラグインインストール画面から簡単に検索・導入ができます。

これ、機能を強化しようとすると有償化する必要があるんですけど、実はスケジュール機能や通知機能など一定の制約に目をつぶれば結構それなりな感じでバックアップができるようになります。

スケジュール設定

設定画面を順に追って説明します。まずバックアップ設定画面を表示させたら「設定」タブを表示させます。

バックアップ対象の指定

無償版だとスケジュール設定はざっくり「頻度ベース」となります。ここで併せてバックアップ保存世代も設定します。その画面の下にバックアップ先の指定がありますが、ここは使用しませんので、なにも設定をしません。

バックアップ対象を指定します。ここは基本的に設定変更する必要はないと考え、全部指定されていることを確認しておきます。

メール通知指定とバックアップ先指定

メール設定にチェックをつけると、簡易ログを含めたバックアップ通知メールが飛ぶようになります。
その次に、今度はエキスパート設定をクリックします。

今回、バックアップ先ディレクトリを明示的に指定します。/bkdataにNFSv3接続をしていますので、この領域を指定します。

その他の設定と設定確定

その他の設定で必要があるものについてはチェックをつけて最後、最下段にある「変更を保存」をクリックします。

バックアップの実行

設定が完了したら一旦手動でバックアップ取得を行います。

画面上部のオレンジ色な「今すぐバックアップ」をクリックするとバックアップが開始されます。バックアップが完了すると、画面下部の「既存のバックアップ」にあるようなバックアップカタログが表示されます。バックアップ時点に切り戻したい場合は「復元」ボタンをクリックすることでリストアができるようになります。

この時、バックアップ領域であるNFSv3接続領域のファイル構成を確認すると以下のようになってました。

# ls /bkdata -alh
合計 685M
drwxrwxrwx   2 root  root    0  6月 26 03:12 .
dr-xr-xr-x. 18 root  root 4.0K  6月 26 02:31 ..
-rw-r--r--   1 httpd root   13  6月 26 02:53 .htaccess
-rw-r--r--   1 httpd root 4.5M  6月 26 03:12 backup_2021-06-26-0254_WWWBLUECORENET_bc07f9162ed5-db.gz
-rw-r--r--   1 httpd root 1.7M  6月 26 03:12 backup_2021-06-26-0254_WWWBLUECORENET_bc07f9162ed5-others.zip
-rw-r--r--   1 httpd root  39M  6月 26 02:57 backup_2021-06-26-0254_WWWBLUECORENET_bc07f9162ed5-plugins.zip
-rw-r--r--   1 httpd root  12M  6月 26 02:57 backup_2021-06-26-0254_WWWBLUECORENET_bc07f9162ed5-themes.zip
-rw-r--r--   1 httpd root 400M  6月 26 03:07 backup_2021-06-26-0254_WWWBLUECORENET_bc07f9162ed5-uploads.zip
-rw-r--r--   1 httpd root 229M  6月 26 03:12 backup_2021-06-26-0254_WWWBLUECORENET_bc07f9162ed5-uploads2.zip
drwxr-xr-x   2 httpd root    0  6月 26 02:54 emptydir
-rw-r--r--   1 httpd root  112  6月 26 02:53 index.html
-rw-r--r--   1 httpd root 101K  6月 26 03:13 log.bc07f9162ed5.txt
-rw-r--r--   1 httpd root  124  6月 26 02:53 web.config

Blobコンテナの中身を見てみるとこんな感じです。これでStorage Explorerから参照することも可能になりますね。

ちなみにバックアップ処理の実行タイミングですが、我が家環境の場合はだいたい昼の12時にバックアップ処理が行われていました。これがどのように指定されて動くのかはまだよくわかってません。ただあまりバックアップタイミングはこだわりがないので、まぁこんなものかーぐらいの認識しかしていませんｗ

Blob領域はものすごく遅いので要注意

大体察しはつくと思うのですが、Azure Blob Storageは今回Standard v2を使いましたけれども、涙がちょちょぎれるほど遅いです。とは言え、バックアップ処理のように比較的大きなブロックサイズでデータ転送をするとそこそこのスループットでバックアップすることも可能です。

・・・・が、明らかにManaged Diskより遅いので、ランダムアクセスするような処理には「絶対」お勧めできませんので注意してください。手元で計測も簡単にしてみましたが、およそ500IOPSぐらいの処理しかできません。スループットも1MB/s-2MB/sとかだったりするので、かなり厳しいと思います。

バックアップ用途、あるいは超低負荷の処理用途にしか使えないということをあらかじめ認識しておいたほうがいいでしょう・・(´・ω・｀)

また、容量がでかいとそれなりにIO Operation課金もでかくなるかなと思います。今回ブログデータのバックアップにはおよそ700MB弱のデータがWriteされていますが、1回のバックアップで30円ほどかかってます。31日実行すれば930円ぐらいの計算になりますね。これ、たぶんCold Tierで実行するとなかなかの課金になると思われますので注意が必要ですね・・IOオペレーション量は都度確認したほうが良いように思います。