無償で使えるVeeam Backup & Replication Community Editionを使ってみた【05. エージェント経由でのバックアップ 取得編(for Windows OS)】
今回は、前回の記事で紹介をした”バックアップ エージェント”を利用したバックアップジョブの実行手順と結果の見方を解説します。
今回の環境
引き続き前回の記事で紹介をした構成と同じ状況です。
今回はファイルベースバックアップを次のマシンに対して実行します。
- 1台のWindows Server仮想マシン
- 2台のWindows 10 物理コンピューター
バックアップジョブの実行
基本的にバックアップソフトでは、1つ1つの作業のことを”ジョブ”という単位で呼ぶことが多いです。
VBRの場合も同様であり、これからジョブを構成します。
- バックアップジョブの作成
ホーム画面内の”Backup Job”をクリックし、”Windows computer”を選択します。
今回は仮想マシンとしてのWindows Serverもありますが、OS内のエージェントを経由して取得をしますので、こちらの選択肢が正しいです。(Virtual machineではありません)
- バックアップ対象のOS種別選択
今回はWindows Serverのバックアップを取得しますので”Server”を選択します。Windows 10などのクライアントOSの場合は”Workstation”、Windows Serverでクラスタリングを構成している場合は、”Failover cluster”となります。
また、管理モードについては”Managed by agent”を選択しました。自宅ラボの環境内でもバックアップ対象のWindowsは電源を切る状態もある程度想定されますので、こちらを選択しました。
基本的に常時稼働しているようなタイプのワークロードには、”Managed by backup server”が向いています。 - バックアップ ジョブ名の指定
ユーザーは任意の文字列をつけることができます。 - バックアップ対象の指定
私の環境の場合は各Windows OSはすべてが同時に起動している可能性も低いので、1台ずつジョブを分割します。もちろん1つのジョブに複数台のバックアップ対象を追加することも可能です。 - バックアップ対象OSの情報入力
Windows OSはコンピューター名でもIPアドレスでも指定が可能です。コンピューター名での指定を行いたい場合は、名前解決が出来る状態かどうかを確認しておきましょう。
クレデンシャル情報は、ユーザー名とパスワードの情報です。
名前解決が出来るかどうかの確認のためpingを使用しています。
今回は、このVBRがインストールされているWindows端末上からバックアップ対象となるWindows OSのホスト名に対してpingを実行しており、ping応答が返答されていることがわかりました。
ネットワーク通信は問題がないことを確認できました。
クレデンシャル情報の欄にはWindows OSへのログイン情報を入力します。
なお、ここで注意点ですがドメイン環境を使用していない場合は、Windows 10などのクライアントOSはMicrosoftアカウントを使用している場合があります。
こちらを利用してる場合は、各利用者の方にメールアドレスとパスワードを尋ねるのはプライバシー面でもあまり良い方法とは言えませんので、各端末内にバックアップ操作のためのローカルユーザーを別途作成しておくと良いでしょう。
2つの情報が揃いましたので、次に進みます。 - バックアップ対象の追加を確認
上記の入力を受けて、バックアップ対象が追加されました。
複数台のバックアップ対象を追加したい場合は、この作業を繰り返します。(Addから行います) - バックアップ手法の選択
今回はOS全体のバックアップを取得しますので、”Entire computer”を指定します。
OSに接続された特定のボリュームのバックアップを取得したい場合は、”Volume level backup”を、
個別のファイルをバックアプ取得したい場合は、”File level backup”を選択します。 - バックアップデータ保存デバイスの選択
今回はVBRに設定をしている記憶域にバックアップを保存します。
この記事時点では、VBRに接続されているハードドライブがバックアップ先です。
現在は”Dell EMC Data Domain VE”を保存先としています。そういえば、書きながら気がついたのですが、Data Domainとの連携記事を書いていなかったので、後日別記事で掲載します。 - バックアップサーバの指定
これはVBRがインストールされているサーバを指定しますが、この操作をしているWindows OS自体そのものですので、そのまま自身のFQDNを指定します。
VBRはコンソールのみをクライアントOSにインストールして使用することも可能ですので、そのような場合はVBRがインストールされているOSを指定します。 - バックアップデータ保存先の指定
上述のステップでは、VBRが管理をする領域を保存先に指定するようにしましたが、
ここでは複数の領域が存在する場合、特定の領域を選択が可能です。
下図では59.4GBのハードドライブ(空き領域は26.6GB)を選択しています。 - バックアップ キャッシュの使用
今回はキャッシュ機能を使用しませんので、このまま次へ進みます。
なお、バックアップ キャッシュとは、一時的にリモートバックアップができない場合に一時的なバックアップデータ保存域として使用される領域とのことです。
Backup Cache – Veeam Backup and Replication v11 - ゲストに対する操作
ここでは2種類の拡張機能の使用有無を選択できます。
Application-aware processingでは、VSSを使用する特定のアプリケーションに最適化されたバックアップジョブを実行するかを選択ができます。今回はWindows OS用のエージェントということもあり、Microsoft ExchangeやSQLなどがその対象となります。詳細はこちら。
Guest file system indexingでは、バックアップ対象のファイルに関するインデクスカタログを作成し、個別ファイルでのリストアを1クリックで出来るようにするというものです。詳細はこちら。 - スケジュールの設定
定期的にバックアップ ジョブを実行したい場合は、こちらでスケジュール指定が可能です。
私のラボは常時稼働を想定していないので、今回はまずはテストであるので予定は組まずにこのまま次へ進みます。 - 最終確認画面
これまで設定をしてきた内容に間違いがないかを確認します。
バックアップ対象の様子
エージェントがインストールされたOSの一覧は次の通りです。
ジョブを実行したい場合は、構成済みのジョブを右クリックすると開始メニューなどが確認できます。
なお、エージェントのインストール手順は別記事で紹介済みですが、VBRと互換性が無いエージェントを入れてしまうと、バックアップジョブが失敗します。
バックアップ取得結果
ここで3つのジョブを実行してみましたので、それぞれの結果を掲示してみます。
- Total Sizeがハードディスクの全容量(空き容量も込の数値)
- Data readは実際にバックアップソフトが読み取ったデータ(データ保護対象)
- Transferredはバックアップ対象から送信されたデータ量(図内のBackup Sizeに等しい)
いずれもWindows OSであり、VBRでは重複排除と圧縮処理を行ってから
あるWindows Server OS(ドメインコントローラー)の場合
こちらはVMware Workstation上で実行される仮想マシンとしてのWindows Server環境をバックアップしたものです。他の結果はWindows 10クライアントOSですが、サーバOSだからといって特別著しい変化があるわけではなく、平均的な結果になったかなと言えます。
あるWindows 10のタブレットの場合(1)
こちらはDell Venueというタブレット上でWindows 10を実行している環境をバックアップしたものです。
内部ストレージの容量が58.1GBと小さいのはそのためです。内部データ量は28.4GBで圧縮後が20GB。
まずまずといった感じの結果だと言えます。但し、バックアップジョブに2時間ほどかかっていますが、恐らくこれは無線経由でバックアップを実行したことは1つの要因だと言えます。
あるWindows 10のノートパソコンの場合(2)
こちらはDell Insipiron上で実行されるWindows 10環境をバックアップしたものです。
このWindows 10環境の場合、空き容量が大変大きかったこともあり、重複排除率が他の2つと比べて以上に大きくなっています。実際に29.4GBのデータに対して圧縮を行い17.1GBのデータ量を転送してのバックアップジョブ完了となっています。数値としてはパソコン(1)の場合と3GBの違いがあります。
またバックアップジョブの実行時間が長いのは、上記のタブレットと同様です。(Wi-Fi経由です)
コメント