ActiveImage Protector

AIPのライセンス認証サーバーをお客様の環境に設置できるようになりました。

今回リリースされたActiveImage Protector 2018 Update 7用最新パッチに含まれる「Actiphy Authentication Service」について、まったくの新しい内容となりますので、ご説明させて頂きます。

今回のアップデートパッチでは、細かな機能の修正及び変更などを行っておりますが、パッチ適応後より、ActiveImage Protector のライセンスのアクティベーション方法が一部変更されます。

現在の ActiveImage Protector のアクティベーションの仕様は次の通りです。

●オンラインキーの場合

・ActiveImage Protector インストール時にプロダクトキーを入力。

 ・インストール完了後、自動的にインターネットに接続してアクティベーション完了。

 ・以後、1日1回アクティファイライセンスサーバーに接続。

 ・接続が切れた場合にも30日の猶予期間あり。

●オフラインキーの場合

 ・ActiveImage Protector インストール時にプロダクトキーを入力。

 ・アクティファイライセンスサーバー未接続で運用。

今回オフラインキーについては、廃止となります。

では、インターネットに接続していないマシンは? ネットワーク自体インターネットに接続していない場合はどのようにアクティベーションを行うか?といった課題がありますが、オフラインのローカルエリアネットワークでも、アクティベーションが出来るように、今回新しく「Actiphy Authentication Service(略してAAS)」がリリースされました。

カタカナでは(アクティファイ オーセンティケーション サービス)となり、認証サーバーをローカルエリアネットワーク内に設置する事を可能にします。

通常のオンラインキーの場合:

上図のようにダイレクトに Actiphy ライセンスサーバーにアクセスしてライセンスのアクティベーションを行います。

AASの利用の場合:

上図のように、ローカルエリア内に AAS を設置する事により、直接 Actiphy ライセンスサーバーへのアクセスを不要とします。

● Actiphy Authentication Service(AAS)の仕組みと導入から運用の流れ

AASをインストールするマシンを選んで、AAS をインストールします。

AAS の初回起動時にモード選択があります。

・プロキシモード

プロキシモードは ActiveImage Protectorのインストール先がインターネット接続可能な環境の場合に、AAS をプロキシとして通過させる事により、AAS 上にアクティベーションの情報を保管するので、ライセンス管理を容易にする目的で使用します。

・サーバーモード

今回はこのモードについて解説を行います。オフライン環境でのアクティベーションを可能にします。

起動すると下図の画面が表示されます。

赤い囲みの部分に URL が表示されます。この URL をコピーしてメモ帳などに保存して、インターネット接続可能なマシンでブラウザ接続します。

上図のような Actiphy のページに接続しますので、メールアドレスを登録し、製品のアクティベーションキーを入力してウィザードに沿ってバンドル化を行います。最終的には登録したメールアドレスにバンドルファイルがデリバリーされます。

※この接続のURLは、実際にローカルエリアでのアクティベーションを行うマシンにインストールしたAASを起動した時に表示されるURLを必ず使用してください。異なるマシンにインストールされたAASのURLでバンドル化されたファイルはAAS側で登録が行えません。

メールでバンドルファイルを受信後このファイルをAASにコピーをします。

AASの運用の流れは下図の通りです。

このようにして同じオンラインアクティベーションキーでも、インターネットへの接続されていない環境も同様にアクティベーションして使用する事が出来ます。

実際のシステム構成、詳細な設定内容、ドメイン環境でのDNS設定などにつきましては、製品ダウンロードページから「AAS_v100.zip」をダウンロードし、ファイル内の「Actiphy Authentication Service(AAS)導入説明資料(pdfファイル)」やドキュメントをご確認ください。

ご不明な点につきましては、Actiphy 営業本部( sales@actiphy.com )にお問合せ頂ければ幸いです。

By Sato

ActiveImage Protector 豆知識 ~ ImageCenter LE の増分ファイルの結合機能の仕組みについて ~

今回は、ImageCenter LE(※1)に搭載されている増分ファイルの結合機能の仕組みについて解説します。

(※1):ImageCenter LEは、バックアップ元のサーバーに負荷をかけることなく、ActiveImage Protectorとは別のサーバーでバックアップファイルのレプリケーションや増分ファイルの結合(コンソリデーション)が行える ActiveImage Protector の無償オプションです。ダウンロードはこちら

まず、ImageCenter LEの増分ファイルの結合処理のタイミングは、以下の3つから選択できます。

1)即時

新しいイメージ ファイルが作成されるとすぐにタスクが実行されます。

2)xx個の新しいイメージが作成されるたびに実行する

新規イメージが指定個数作成されるとタスクが実行されます。

3)時間指定

指定した週単位/月単位の指定した時間にタスクが実行されます。

ここからは、個々の結合処理の仕組みについて解説していきます。

1.「即時」を指定した場合の動作

以下の設定例で説明します。

最新の増分ファイルを7個残すという設定をした場合、常に増分ファイルを7個残すために、初回の結合処理においては増分8はスキップされ、増分9が作成されたタイミングで、最も古い増分1が増分2に結合され、増分1が削除されます。結合済みの増分ファイルは、残す増分ファイル数から除外されて管理しています。

次に、増分10が作成されたタイミングで、増分2が増分3に結合され、増分2が削除されます。

次に、増分11が作成されたタイミングで、増分3が増分4に結合され、増分3が削除されます。このように、増分ファイルが作成されるたびに結合処理が繰り返されます。

2.「xx個の新しいイメージが作成されるたびに実行」を指定し場合の動作

以下の設定例で説明します。

残す増分ファイルは7として、2個の新しい増分が作成されるたびに結合処理を行う設定をした場合、増分8と増分9の2つの増分が作成されたタイミングで増分1が増分2に結合され、増分1が削除されます。

次に、増分10と増分11が作成されたタイミングで、増分3が増分4に結合され、増分3が削除されますが、増分2は残ったままになります。このように、「即時」実行とは異なるのは、結合済みの増分が複数保持されます。

ここで、設定例として結合済みの増分を2個残す設定の場合、増分12と増分13が作成されたタイミングで増分5と増分6が結合され、増分5が削除されます。さらに、結合済みの増分2が増分4に結合され、増分2が削除されます。

3)「時間指定を指定した場合の動作

以下の設定例で説明します。

時間指定の場合は、結合処理のタイミングの違いだけで「xx個の新しいイメージが作成されるたびに実行」と同じ動作となります。

00:00の時点で増分ファイル8、9、10が新たに作成されていた場合、増分1、2が増分3に結合され、増分1、2が削除されます。新しく作成された増分ファイルの数分、最も古い増分を含む数分の増分ファイルが結合されていきます。

次の日の00:00の時点で増分ファイル11、12が新たに作成されていた場合、増分4が増分5に結合され、増分4が削除されます。

次の日の00:00の時点で増分ファイル13、14が新たに作成されていた場合、増分6が増分7に結合され、増分6が削除されます。さらに、「結合された増分を2個残す」と設定していると増分2が増分5に結合され、増分2が削除されます。

ActiveImage Protectorでは、永久増分という初回にフルバックアップを取得して、以降は増分バックアップを取得する運用が可能となっていますが、デメリットとして古い増分ファイルを消すことはできません。例えば毎日1回増分バックアップの運用を1年間行うと365個の増分ファイルが作成されることになり、バックアップ保存先容量の圧迫もありますが、増分バックアップの処理時間の増加や最も重要な万一の復元処理時間が増大する可能性があります。

増分バックアップの結合処理は重要ではありますが、安定したバックアップ運用を行っていただくためには、定期的に例えば3ヶ月ごとにフルバックアップを取得し直す運用をお勧めしています。

今後とも ActiveImage Protector およびアクティファイをよろしくお願いいたします。

* ブログでは、ActiveImage Protector の使い方のコツ、豆知識をご紹介しています。是非以下の記事も併せてお読みください。

ActiveImage Protector 豆知識
~ uEFI GPT構成イメージのボリューム単位のリストア手順 ~

ActiveImage Protector 豆知識 ~ uEFI GPT構成イメージのボリューム単位のリストア手順 ~

uEFI GPT 構成のイメージからのベアメタルリカバリーは、ディスク単位でリストアすることを推奨していますが、バックアップ元よりリストア先ディスクのサイズが小さいと、以下のように「復元元以上のサイズを持つ別の復元先を選択してください。」とメッセージが表示されリストアできません。

本記事では、この場合の解決策としてベアメタルリカバリーをボリューム単位で行う(備考1)手順を紹介します。

備考1:ActiveImage Protector(AIP)には、シュリンクオンザフライというNTFSのボリュームを縮小してボリューム単位でリストアする機能が実装されています。

※ボリューム単位のリストアの際の注意
ベアメタルリカバリーをボリューム単位で行う場合は、リストア先のディスクは事前に初期化しておく必要があります。
初期化されていないディスクにボリューム単位でリストアした場合は、0xc0000225または 0xc000000eのエラーが発生しシステムが起動しない場合があります。参考までに、この場合の解決策は以下になります。

解決策:
① AIP起動環境(Windows PE)を起動します。
② Ctrl + Shift + F12 を押下します。
③ 左パネルに「コマンド行」が追加されるのでクリックします。
④ 下記の3つのコマンドを入力します。
bcdedit /set {bootmgr} device partition=D:
bcdedit /set {default} device partition=D:
bcdedit /set {default} osdevice partition=D:
⑤ AIP起動環境(Windows PE)を終了し、Windowsを起動します。

■ボリューム単位のリストア手順
1)リストア先ディスクの初期化
最初に、OSの「diskpart」コマンドを使用してリストア先のディスクを初期化します。AIP起動環境を起動して、「ユーティリティー」を選択、次に「コマンドプロンプトを起動」をクリックします。

コマンドプロンプトの画面が開いたら、ディスクを初期化するために、下記のコマンドを実行します。

① 「diskpart」と入力します。
② DISKPARTという新しいウィンドウが開きます。ここで今度は「list disk」と入力します。ディスクのリストが出てきますので、初期化したいディスクを選択します。
③ ディスク0を初期化する場合は、「select disk 0」と入力しています。
④「list disk」と入力して、「*」印の位置を確認します。「*」印の付いたディスクが対象のディスクです。容量などを確認して初期化したい対象のディスクになっているか必ず確認します。
⑤「clean」と入力します。「DiskPartはディスクを正常にクリーンな状態にしました。」と出れば、復元先のディスク0の初期化は完了です。

※ディスクの初期化後に、リストアを実行する前にAIP起動環境を再起動させます。

2)ボリューム単位のリストア
WindowsPE ベースのAIP起動環境からのリストア操作の「復元設定」から説明します。
※今回のリストア手順は、ディスクサイズ100GB環境のイメージを80GBのディスクにボリューム単位でリストアしています。

リストア先ディスクのフォーマットを行います。リストア先のディスク枠(リストア先のディスクマップの左部分)にカーソルをあて右クリックして「ディスクの初期化」をクリックします。

ディスクの初期化ダイアログが表示されますので、GPT を選択し「OK」をクリックします。

ディスクマップ上のリストア対象となる各ボリューム(例:回復、uEFI、Cボリューム、Dボリューム)に対して、カーソルをあて右クリック、リストア先は「未割り当て」領域を指定(備考2)する操作を順番に行います。

備考2:あらかじめリストア先のボリュームをサイズ指定して作成してからリストアすることもできます。

全てのリストアするボリュームの設定が完了した状態で、「次へ」をクリックします。

確認画面から「完了」をクリックし、リストアを実行します。

全てのボリュームのリストアが完了したら、再起動しリストア作業は完了です。

システムが起動したら、ディスクの管理より80GBのディスク上に、回復、uEFI、Cボリュームは同じサイズ、Dボリュームは縮小されてリストアされていることが確認できます。

uEFI GPT構成イメージのバックアップ元より小さいサイズのディスクへのボリューム単位のリストア手順の紹介は以上ですが、どこまで小さなサイズのディスクにリストア可能なのかについては、ディスクの仕様に関わる部分もあり具体的に明言できませんが、少なくともバックアップ元と同サイズのディスクを用意したのに、製造メーカーやロットにより若干サイズが異なることがあり、リストアできないという問題は解決できます。

今後もActiveImage Protectorの豆知識をブログで紹介していきたいと思いますので、よろしくお願いいたします。

NEC社のCLUSTERPRO X4.2に対応した 「ActiveImage Protector 2018 Update for CLUSTERPRO」のご紹介

10月2日に、NEC社のHAクラスタソフトの最新バージョン「CLUSTERPRO X4.2 for Windows(以降、CLUSTERPRO)」に対応したバックアップツール「ActiveImage Protector 2018 Update for CLUSTERPRO(以降、ActiveImage Protector)」をリリースしました。

今回は、CLUSTERPRO 環境のバックアップの必要性と「ActiveImage Protector 2018 Update for CLUSTERPRO」の導入のメリットについて説明していきます。

ご存じのように CLUSTERPRO は、複数台のサーバーを用いてクラスタシステムを構築することで、システムに障害が発生した場合でも、健全な「待機系サーバー」に業務を引き継ぎ、わずかなダウンタイムで業務を継続させることができるHAクラスタソフトです。

NEC社の資料によると、HAクラスタソフトの分野で19年連続国内シェアNo.1の実績を誇り、止めることが許されないミッションクリティカルなシステムには欠かすことができない高可用性ソリューションといえます。

CLUSTERPRO 環境のバックアップは不要でしょうか?

CLUSTERPRO 環境において、バックアップは不要ではないかと考えてしまいがちですが、システムダウンやデータ消失のリスクがあることを理解しなければなりません。

以下の表は、システムダウンやデータ消失のリスク要因とCLUSTERPRO がカバーしている範囲を示しています。重要な点は、CLUSTERPRO によりHA構成にしてもリスク要因の「人為的ミス」や「ウイルス感染」には対応できないことです。

①人為的ミス

人間が操作することからミスは少なからず発生するもので、何らかの原因で間違って大事なデータを消してしまう事もありえます。また、ミス防止のために処理を自動化している場合でも、バッチ処理のスクリプトが間違っていたために、データが丸ごと消失した事例もあります。

②ウイルス感染

弊社のブログでも度々話題にあげている「ランサムウェア」に代表されるコンピュータウイルスは、事業継続を脅かす大きな脅威になっています。万一、ウイルスに感染したサーバーを復旧するには、データを復旧する前に感染したサーバー内のウイルスを駆除する必要があることを忘れてはなりません。ウイルスを駆除する方法としては、セキュリティソ対策フトが有効ですが万能ではありませんので、ウイルスによっては駆除できずに再発した事例もあります。また、駆除するためにはウイルスのプログラムの削除以外に、手作業でOSのレジストリーからの削除も必要になる場合があり、危険な操作を伴う作業となります。

■ ウイルスに感染したサーバーを安全に復旧するには?

ウイルスに感染したサーバーを安全・確実に復旧するには、OSを初期化してシステムを再構築することです。しかし、再構築には膨大な作業工数が必要となることから、サーバーの再稼働までに多くの時間が必要とされています。

以下は、データのみバックアップを取得した場合とActiveImage Protector のバックアップからの復旧手順を示しています。データのみのバックアップからの復旧には、多くの工数と時間が必要になります。

■ ActiveImage Protector 導入のメリット

以下は、ActiveImage Protector を使用したCLUSTERPRO 環境のバックアップ構成例です。データだけでなく両ノードのシステムをまるごと一括でバックアップできます。また、復元は健全な時点のバックアップからシステムおよびデータをワンステップで復元できます。

①耐障害性強化

高可用性を実現するCLUSTERPROとの組合せにより、システムの強力な耐障害性を実現することが可能です。

②CLUSTERPRO 環境での動作検証済み

対応 CLUSTERPRO バージョンは、弊社内で十分な動作検証を行っています。また、専用のバックアップ運用ガイドを内製していますので安心して導入が可能です。

③導入コスト

CLUSTERPRO のHAクラスタ構成に対して、お得なライセンス価格を設定しています。

■ 最後に

ActiveImage Protector の CLUSTERPRO 版は、忘れもしない2011年の東日本大震災の年にNEC社との協業によりリリースを開始して、あっという間に来年は10周年を迎えます。継続は力なりということわざがありますが、今後もさらにCLUSTERPRO 環境の快適で安定したバックアップ運用をお届けして参ります。

また、弊社 CLUSTERPRO の販売パートナーとして、ActiveImage Protector とCLUSTERPRO のバンドル製品をお得な価格設定で提供していますので、新規購入のお客様は、是非検討いただけますと幸いです。

・バンドル製品:ActiveImage Protector plus CLUSTERPRO X

◇ 参考情報

ActiveImage Protector for CLUSTERPRO製品紹介サイト

ActiveImage Protector for CLUSTERPRO評価版申込サイト

低コストでシステムのDR対策を実現「ActiveImage Protector 2018 Update for RDX」のご紹介

今回は、低コストで実現するシステムのDR対策(災害復旧対策)として、「ActiveImage Protector 2018 Update for RDX」の活用例について紹介します。

近年の度重なる集中豪雨や台風による水害などの自然災害、火災、ランサムウェアに代表されるコンピュータウイルスは事業継続を脅かす脅威になっています。これらの災害時に、迅速な復旧による事業継続のシナリオを確保するためには、バックアップによるシステムやデータの保護は必要不可欠といえます。

しかし、災害によってすべてのバックアップデータが一気に消失したら、業務継続はもちろんですが、企業としての信頼を損なう可能性があります。このため、バックアップデータをリモートサイトやクラウドストレージなど安全な場所に保管するための対策が必要になります。ただし、膨大なバックアップデータをネットワーク経由で転送するための高速な回線やバックアップ保存先の大容量のストレージなど設備が必要となることから、限られた予算の中で対策を実現することは依然として重要な課題となっています。

災害復旧対策の1つの現実解

DR対策として、タンベルグデータ社のRDXをバックアップ保存先として使用する専用バックアップツール「ActiveImage Protector for RDX」について活用例を交えて紹介していきます。

◇ ActiveImage Protector for RDXの特長

① シンプルなバックアップ構成

ActiveImage Protector for RDXは、WindowsおよびLinuxサーバーに、USBに接続したRDX装置(*1)にシステムおよびデータを丸ごと簡単にバックアップできます。また、大容量のサーバーやNASについては、複数のRDXカートリッジを1つのカートリッジとして使用することも可能な最大8つのRDXカートリッジを搭載可能なiSCSI接続のRDX装置も利用できます。

* 1:RDX(Removable Disk Exchange system)とは

DDSやDATテープの代替を主な目的に開発されたHDDを内蔵したカートリッジをRDXドライブに着脱して使用するバックアップ装置です。小型で軽量なカートリッジは非常に頑丈な設計で、持ち運び・外部保管に適しているので災害対策もできるバックアップ装置です。

② バックアップデータを暗号化して安全に外部保管が可能

RDXカートリッジは、可搬性や外部保管にすぐれていますので、高速なネットワーク接続や高価な保管先のストレージが無くても、定期的にRDXカートリッジを取り外してリモートサイトへの搬送や耐火金庫に保管して、バックアップデータを災害から安全に保護することができます。また、不測の事態にはRDXカートリッジを手でもって安全な場所に避難するだけでもバックアップデータを保護することができるのです。さらに、ActiveImage Protector for RDXは、バックアップデータを暗号化してRDXカートリッジに保存する機能を搭載していますので外部保管も安心です。

③ 自動イジェクト機能によるバックアップデータのオフライン化

ランサムウェアはネットワークを介して感染を広げることから、ネットワークに接続されているストレージのバックアップデータまで暗号化される可能性があります。この点を考慮すると、バックアップ保存先はネットワークから完全に隔離できる媒体を選択することも有効な対策となります。

ActiveImage Protector for RDXは、バックアップ終了後など以下のタイミングでRDXカートリッジを自動的にイジェクトしてオフラインにする機能を搭載しています。これにより、RDXカートリッジを取り外し忘れるというミスをなくすことで、バックアップデータの損失やウィルス感染のリスクを軽減することができます。

・週単位: 特定曜日の最後のバックアップ完了後

・日単位: 毎日特定の時間

・バックアップ終了後: 毎回バックアップ完了後

◇ 最後に

自然災害、火災、ウィルスなどの災害に対して、100%未然に防ぐことは不可能であることを考慮すると、日々のバックアップ運用はもちろんですが、バックアップデータの保護も重要となります。しかし、バックアップデータの保護対策まで手が回らず後回しになっているケースが多いのではないでしょうか。

今回、DR対策として低コストで簡単に導入できる「ActiveImage Protector for RDX」を検討いただければ幸いです。

参考情報

ActiveImage Protector for RDX 製品紹介サイト

ActiveImage Protector for RDX 評価版申込サイト

タンベルグデータ社 RDX 紹介サイト

データストレージ社のWindows用 RDX バンドルモデル紹介サイト

Actiphyの新しいコミュニケーション 「Biz-Communication」始まる

アクティファイでは、以前は全国各地のお客様を積極的に訪問して、ご挨拶から情報交換、製品紹介、技術セミナー、技術支援などを行って参りましたが、現在は同じような活動が行えない状況で、まだしばらくの間は難しいと思い、今回新しいコミュニケーション「アクティファイスタディ」と「アクティファイミート」をスタートさせる事になりました。

  • アクティファイスタディ

今まで毎月定期セミナーとして開催しておりました技術セミナーです。9月中旬開催予定の初回は、ギガスクール需要でまだまだご要望の多い、キッティングに関連するセミナーを開催いたします。

■ パソコンキッティングの効率化セミナー内容(予定)

・キッティングとは

・マスターの作成(Sysprep、Windows Updateについて)

・マスターの展開(ActiveImage Deploy USBのご説明)

・質疑応答

  • アクティファイミート

時間の都合等で「アクティファイスタディ」では詳細が分からない場合などのフォローを時間制限のない「アクティファイミート」で対応させて頂きます。

「アクティファイミート」はアポイント制となりますので、近日中に弊社ホームページからのお申込み受付を開始いたします。

お急ぎの案件やご不明な点などございましたら、お気軽に弊社営業本部( sales@actiphy.com )にご一報頂ければ幸いです。

皆様からのご参加とお誘いを心よりお待ちしております。

AWS EC2からHyper-VへのVM移行を試してみました – その6(最終回)

今回は、最後となりますが、以下のステップ5のHyper-Vへの仮想マシンの移行後に必要な処理について解説していきます。

・ステップ1:AWS EC2を構築
・ステップ2:AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2をバックアップ
・ステップ4:バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5:移行後の処理

移行後に、必ず行う必要があるのが、以下の1) のOSのライセンス認証と2) のネットワーク設定です。
3) については、私が調べた限りでは、AWSのプログラム等はオンプレ上では不要と思われますので削除しています。

1) OSのライセンス認証
移行直後は、Windowsのライセンス認証が外れています。

» 続きを詳しく読む

AWS EC2からHyper-VへのVM移行を試してみました – その5

前回は、Hyper-VへのVM移行に使用するイメージファイルの作成手順を紹介しましたが、今回は、以下のステップ4の[ActiveImage Protector] の仮想化機能を利用して、EC2インスタンスのバックアップイメージから、直接、検証用のHyper-V上に変換した仮想マシンを作成する手順を紹介していきます。以下の検証環境図の赤枠の部分です。

・ステップ1:AWS EC2を構築
・ステップ2:AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2をバックアップ
・ステップ4:バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5:移行後の処理

» 続きを詳しく読む

AWS EC2からHyper-VへのVM移行を試してみました – その4

前回までは、検証用のEC2の作成、バックアップ保存先のストレージボリューム追加の手順を紹介してきましたが、いよいよ本題に入ります。

今回は、以下のステップ3の[ActiveImage Protector]を利用してEC2インスタンスのバックアップを行い、前回、作成した保存先のボリュームへVM移行に使用するイメージファイルを取得してみます。

・ステップ1:AWS EC2を構築
・ステップ2:AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2をバックアップ
・ステップ4:バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5:移行後の処理


» 続きを詳しく読む

AWS EC2からHyper-VへのVM移行を試してみました – その3

前回は、検証用のEC2インスタンスを構築しましたが、今回は、以下の[ステップ2]のEC2のVM移行作業において、「ActiveImage Protector」のバックアップ保存先として、一時的に利用するストレージボリュームをAWS上に新規に作成してみたいと思います。以下の検証環境図の[赤枠] の部分です。

・ステップ1:AWS EC2を構築
・ステップ2:AWS EC2にバックアップ保存用ボリュームを追加
・ステップ3:AWS EC2をバックアップ
・ステップ4:バックアップから直接Hyper-V上に仮想マシン作成
・ステップ5:移行後の処理

» 続きを詳しく読む

アーカイブ

Powered by WordPress, WP Theme designed by WSC Project. ログイン