本エラーは例えばOracle 11.2のクライアントを使用している場合「oracore11.dll」にて障害が発生した旨Windowsイベントログに記録されている可能性があります。
一部の条件下にて本事象が発生するケースがあり、エラー発生までの流れは以下の通りです。

1. DBMoto から Oracle へ Oracle クライアントで接続するためコネクションをオープンする
2. このオープンしたタイミングで Oracle クライアント側のoracore11.dll というファイル関連で何らかの障害が発生しエラーとなる可能性がある
3. 2に引きずられて DBMoto の Data Replicator が強制終了する

つまり、発生トリガーは1の「Oracle へのコネクションを確立した際」です。

これまで発生事例から Windows のダンプファイルの解析、マイクロソフト社のダンプ解析ツール ADPlus でさらに詳細を解析するなどし下記のことが判明しております。

・エラーは Oracle 側の DLL で発生している
・エラーは .NET Framework の外で発生している
・DBMoto はすべて .NET Framework 内で動作するので本エラーが DBMoto 起因である可能性は極めて低い
（DBMoto が原因の場合は .NET Framework 内でエラー発生する）
・再現するマシンが一部に限られている

回避策としてレプリケーション毎に Oracle への接続をオープンにしないようコネクションプールを有効にする方法がございます。設定手順は以下の通りです。

1. Data Replicator サービスを停止します
2. ターゲットの Oracle 接続を右クリック→「プロパティ」を開きます。
3. 接続 Oracle .NET Driver の右にあるボタンをクリックします。
4. Pooling が False になっているので True へ変更します。

これにより Oracle へのコネクションプーリングが有効となり、
本事象は発生しなくなります。

DBMotoの機能に、レプリケーションのソースとターゲット双方のテーブル間で差異が生じていないかを確認するレプリケーション検証機能があります。
AS/400のテーブルで、VARGRAPHIC型もしくはGRAPHIC型があるテーブルで検証を行うと、「CCSID 65535とCCSID 13488の間の文字変換は正しくない」とのエラーメッセージが出力されることがあります。
このエラーメッセージは通常のレプリケーション中には発生せず、データは問題なくレプリケーションできていることが多いです。

これは、このレプリケーション検証機能使用時に限り、DBMotoの「検証のソート・シーケンステーブル」設定が有効であるため、GRAPHIC型が文字変換を行おうとして失敗しています。
対処法は、この設定個所の部分を空欄にすることです。（設定変更時はData Replicatorの停止が必要です。）

なお、通常のレプリケーションは、前述の通りこの設定を使用していないので、問題なく変換され動作します。

レプリケーションの検証をすることで、ソースのみのレコード、ターゲットのみのレコード、ソースとターゲットで差異のあるレコードを確認できます。

しかし、本来、ソースにもターゲットにも存在し、差異のないレコードがソースのみ、ターゲットのみに存在するレコードとして表示されることがあります。

これは、DBMotoはソースとターゲットのレコードを比較する前に主キーをベースにレコードのソートを行いますが、このときのソースDBとターゲットDBのソートの仕様の違いによるものです。

例えば、Oracleの場合、大文字、小文字を区別してソートするため、D→aの順番でソートされ、MySQLの場合、大文字、小文字を区別せずソートするため、a→Dの順番でソートされます。

このソートの順番が異なるため、このような結果が生じます。

この事象を回避するため、検証機能のオプション「ORDER BY句」の「ソーステーブル」「ターゲットテーブル」に「LOWER(主キー)」を入力してください。こうすることで、大文字、小文字の区別なくソートが行えるため、問題なく検証することが可能です。

SQL Serverの接続設定に「sa」以外のユーザをご利用ください。
シンクロナイゼーションでは、更新がループしないようにするため、接続設定に使用したユーザでの更新はレプリケーション対象として検出しない仕様となっております。
そのため、シンクロナイゼーションを行う場合には、DBMoto専用ユーザを用意する必要がございます。
「sa」はDBMoto専用とすることができないため、このようなエラーが発生します。

Version: Syniti Data Replication 9.6.0 以上

Amazon Redshiftのクラウドデータウェアハウスにレプリケートする際、データタイプがCHARのフィールドにエラーや予期せぬ文字が現れることがあります。 この現象の説明については、以下のURLを参照してください。

https://docs.amazonaws.cn/en_us/redshift/latest/dg/multi-byte-character-load-errors.html

エラーや予期せぬ文字を避けるために、RedshiftのターゲットのデータタイプをCHARではなくVARCHARに設定してください。

データベーススキーマの設計は、データの書式が一貫していること、すべての項目が主キーを持つこと、重要なデータが除外されていないことを保証します。データベーススキーマは、視覚的なものと論理的なものがあり、データベースを管理するための公式のセットを含んでいます。開発者は、これらの公式とデータ定義を使用して、データベーススキーマを作成します。

最も一般的なデータベーススキーマの種類を以下に概説します。

階層的モデル: 階層型：ルートノードに子ノードが付随するツリー状の構造を持つデータベーススキーマを階層型という。このデータベーススキーマモデルは、家系図などのネストされたデータを格納することができる。

フラットモデル:フラットモデル: データを単次元または二次元の配列に整理したもので、行と列を持つスプレッドシートのようなモデル。このモデルは、複雑な関係を持たない単純なデータを表形式で整理するのに適している。

リレーショナルモデル:リレーショナルモデルは、データが表、行、列に整理されるフラットモデルに似ている。ただし、このモデルでは、異なるエンティティ間の関係を定義することができる。

スタースキーマ: スターデータベーススキーマは、データを「ディメンション」と「ファクト」に整理します。ディメンジョンには説明的なデータが含まれ、ファクトには数値が含まれる。

スノーフレークスキーマ: スノーフレーク(雪片)型データベーススキーマは、データベース内のデータを論理的に表現したものである。このタイプのスキーマの表現はスノーフレークに似ており、複数のディメンジョンが1つの集中ファクトテーブルにくっ付いている。

ネットワークモデル: ネットワークデータベーススキーマは、データを接続された複数のノードとして含みます。このモデルは、多対多の関係などの複雑な接続を可能にするため、特定のタスクを達成するために使用されます。

データベーススキーマを最大限に活用するためのベストプラクティスを以下に紹介します。

セキュリティ: 効果的なデータベーススキーマの設計は、データセキュリティに重点を置く必要があります。また、ログイン情報、個人を特定できる情報（PII）、パスワードなどの機密データを保護するために、高度な暗号化を使用します。
名前の規則: スキーマ設計をより効果的にするために、データベースで適切な命名規則を定義することができます。テーブル、カラム、フィールド名には、複雑な名前、特殊文字、予約語を使用しないようにします。
正規化: 正規化とは、独立したエンティティやリレーションシップが、同じテーブルやカラムにまとめられないようにすることで、冗長性を排除するものです。これにより、データの整合性が向上し、開発者が情報を取得しやすくなります。また、正規化により、データベースのパフォーマンスを最適化することもできます。
ドキュメンテーション: データベーススキーマは、開発者とドキュメンテーションの作成にとって非常に重要です。データベーススキーマの設計は、説明書、コメント、スクリプトなどとともに文書化する必要があります。

物理データベーススキーマ: 物理データベーススキーマは、データの物理的な配置と、ファイル、インデックス、キーと値のペアなどのストレージのブロックへの格納方法を表します。

論理データベーススキーマ:論理データベーススキーマはデータの論理的な表現を記述し、論理的な制約を伝達する。データはある種のデータレコードとして記述することができ、異なるデータ構造として格納される。ただし、データの実装などの内部的な詳細はこのレベルでは隠されている。

データベーススキーマは、情報を体系的に整理するために設計された認知的な枠組みや概念です。スキーマがあれば、膨大な量の情報を素早く解釈することができる。未整理のデータベースは混乱しやすく、維持・管理も困難です。きれいで、効率的で、一貫性のあるデータベーススキーマの設計により、組織のデータを最大限に活用することができます。リレーショナルデータベースは、データの冗長性を排除し、データの不整合を防ぎ、データの検索と分析を容易にし、データの整合性を確保し、不正なアクセスからデータを保護するために、データベーススキーマ設計に大きく依存します。強力なテスト環境でデータをテーブルとカラムに整理することが極めて重要です。データの整合性を管理し、データベースとソースコードを更新する計画が必要です。

データベーススキーマ設計は、データベースのアーキテクチャを開発するための設計図を提供することで、膨大な情報を体系的に格納することができる。また、データベースの構築に関わる戦略やベストプラクティスを指します。データベーススキーマ設計は、データを個別のエンティティに整理し、整理されたエンティティ間の関係を決定することによって、データの消費、解釈、取得をはるかに容易にします。

データベース設計者は、プログラマーが効率的にデータベースを操作できるように、データベーススキーマを作成します。データベースを作成するプロセスは、データモデリングとして知られています。データベーススキーマを設計するためには、情報を収集し、それらをテーブル、行、列に並べる必要があります。情報を整理することで、理解しやすく、関連付けやすく、使いやすくする必要があります。

データベーススキーマとは、リレーショナルデータベース全体の論理的、視覚的な構成のことである。データベースのオブジェクトは、テーブル、関数、リレーションとしてグループ化され表示されることが多い。スキーマは、データベース内のデータの構成と格納を記述し、さまざまなテーブル間の関係を定義します。データベーススキーマは、スキーマ図を通して描くことができるデータベースの記述的な詳細を含んでいます。

DBMotoはVer9.7から名称をSyniti Data Replication (略: Syniti DR)に変更しました。
名称のみの変更で機能に変更はありません。
今後名称をSyniti Data Replicationに変更してまいります。

まず更新対象レコードがターゲットに存在しない場合に「Record to update not found in target table」警告が発生し、その後DBMotoは補完INSERTを行います（行わないようにすることも可能です）

しかし Oracle のトランザクションログモードがLog Readerの場合、REDOログから取得できる情報は更新したカラムとPKのみとなります。
このため更新していないカラムはNULLとしてターゲットへのINSERTを行い、結果NOT NULL制約のカラムがあるとエラーになります。

対処方法は以下の2通りです。

1. Oracle のトランザクションログモードを「トリガー」にする（Oracle 10gかつDBMoto v9以降）

2. Oracle に対して以下のクエリを発行し、すべてのカラム情報をREDOログから取得できるようにする。
>ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS

可能です。
ただし、DBMotoではDML文のみレプリケーションするため、パーティションがDDL文で削除されたときはそれを反映できません。

Oracleからのミラーリング時にはデフォルトでアーカイブログを参照し、またその際にCONTINIOUS_MINEオプションを有効にしています。
一部のOracle環境ではCONTINIOUS_MINEオプションをオンにしているとミラーリングタイミングがバラバラになることがあります。
CONTINIOUS_MINEオプションを外すとこの事象が解消することがあります。
オプションの切り替えにより、レプリケーションの性能劣化やOracleに対する負荷増加が発生することはほとんどありません。

トリガー形式およびログ参照形式のいずれも不可です。
DB2側の仕様でトリガーに必要な機能もログ参照に必要なAPIもスタンバイサーバでは利用できません。

SQL Serverの仕様上の制約によりできません。

可能です。

MySQLへミラーリングを行うためには、MySQLでautocommitが有効になっている必要があります。以下のクエリで確認が可能です。
mysql>SELECT @@autocommit;

もしもこの結果が0の場合、autocommitが無効になっているので、有効化してください。
もしアプリの都合で有効化が困難な場合は、以下の対応を行ってください。

1. Data Replicator を停止し、Management Center を閉じます。
2. 以下のファイルをダウンロードし、ExecuteList.xml を開きます。
https://www.climb.co.jp/soft/download/DBMoto/ExecuteList.zip
3. <connection name=”ここ”> に DBMoto で設定済みのMySQL 接続名を指定します。
4. ExecuteList.xml を DBMoto インストールディレクトリに配置します。
5. Data Replicator を開始し、正常にレプリケーションされることを確認します。

これによりMySQL への接続毎に「SET autocommit=1;」のコマンドを発行して一時的にautocommitを有効化してレプリケーションを行うようになります。

【RDS Auroraの場合】
パラメータグループのDB Cluster Parameter Groupにてbinlog_formatを「ROW」に変更することでバイナリログを記録するようになり、ミラーリング可能となります。

【RDS MySQLの場合】
パラメータグループのDB Parameter Groupにてbinlog_formatを「ROW」に変更することでバイナリログを記録するようになり、ミラーリング可能となります。

【DBMotoでの設定】
「DBMySqlUtil.dll」をDBMotoインストールディレクトリに配置する必要があります。
お手元にない場合はお問合せください。

【RDS Auroraの場合】
パラメータグループのDB Cluster Parameter Groupにてbinlog_formatが「OFF」になってる場合はそのままトリガーを使用可能です。
binlog_formatが有効化されている場合は、DB Parameter Groupにてlog_bin_trust_function_creatorsを「1」へ変更することでトリガーを使用することが可能となります。

【RDS MySQLの場合】
パラメータグループのDB Parameter Groupにてlog_bin_trust_function_creatorsを「1」へ変更することでトリガーを使用することが可能となります。

トリガーを使用することで可能です。

ただし、Sybase ASEでは1つのテーブルにおいて1つのトリガーのみしか使用できない仕様のため、既存でテーブルにトリガーを設定している場合は、DBMotoから差分レプリケーションを実施することはできません。

こちらはDBMotoで使用している.NET Frameworkの仕様による問題です。
仕様上SMTP over SSLのポート番号である465番を使用したメールの送信ができないようになっております。
別のポート番号をご利用ください。

スクリプトに記述した、.Net Frameworkの関数が動作しないことがあります。

これは、その関数の動作に必要な.Net FrameworkのライブラリがDBMotoに読み込まれていないのが原因です。

DBMotoでは本体の動作に不要な.Net Frameworkのライブラリは読み込まないようになっております。
適宜リファレンスで必要な.Net Frameworkのライブラリを読み込んでください。

■例
SHA256CryptoServiceProvider関数を利用する場合、System.Core.dllというライブラリを呼び出す必要があります。
Microsoft公式のSHA256CryptoServiceProvider解説ページ
このDLLファイルは、C:\Windows\Microsoft.NET\Framework64\vX.X.XXXX（Xは任意のバージョン数値）にありますので、ここへのリファレンスを追加してください。（64bit版の場合）

リフレッシュとミラーリングが可能です。
 
ミラーリング時の注意点として、DBMotoは差分データの取得にトランザクションログを用いていますが、マテリアライズビューにあるレコードに対するUPDATE操作をOracleが内部で行う際、UPDATEではなくDELETEとINSERTを組み合わせて行っているため、トランザクションログの数が1つではなく、2つになっています。
 
DBMotoのレコード処理件数表示はトランザクションログをベースにしている都合上、マテリアライズドビューのリフレッシュモードが「完全」の場合は、ビュー上の全レコード数×２、「部分」の場合は、UPDATE対象レコードの数×２の数が、レコード処理件数として表示されます。これはOracle側の仕様によるものです。

EC2上のWindowsに用意したDBMotoからRedshiftに接続しようとするとフリーズすることがあります。
これは、EC2上のインスタンスのNIC設定に由来する問題です。レジストリ上からMTU値を設定します。
次の場所にあるレジストリ内にMTU値を示すレジストリエントリーを追加します。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\（アダプタのID）
追加するレジストリは、DWORD型で、値の名前は MTU 、データの値は 1500 に設定します。設定後コンピュータを再起動して、新しい値を適用します。
詳細は下記Amazon様ページをご覧いただきますよう、お願いいたします。
データベースへの接続が中断された – Amazon Redshift

AS400上のマルチメンバーファイルとなっているテーブルからレプリケーションしようとすると、ステータスは成功なのに処理件数が0件のまま動かないことがあります。

これはマルチメンバーファイルの仕様上の制限でSELECTクエリが実行できないためです。
テーブルのエイリアスを作成していただければSELECTクエリで結果が取得できるため、レプリケーションできるようになります。
エイリアスを作成するクエリの一例は以下の通りです。

CREATE ALIAS MYLIB.FILE1MBR1 FOR MYLIB.MYFILE(MBR1)
CREATE ALIAS MYLIB.FILE1MBR2 FOR MYLIB.MYFILE(MBR2)


DBMotoのメタデータは、複数作成することは可能です。
これにより運用環境とテスト環境それぞれのメタデータを用意できます。
しかし、複数のメタデータを同時に使用することはできません。それぞれのメタデータ内にあるレプリケーションは、それぞれのメタデータを有効化していない限り動作しません。
メタデータの切り替えは、メタデータ上で右クリックして表示されるメニューの、「既定のメタデータにする」で可能です。

スレーブ側MySQLのmy.iniの[mysqld]に次の一行を付け加えます。
log_slave_updates=TRUE
これは、スレーブサーバがマスターサーバから受け取った更新をスレーブサーバ自身のバイナリログに反映する設定となります。

デフォルトですと設定がされていない（FALSE）ため、DBMotoからスレーブ側のバイナリログを読み込みにいっても、マスター側の更新が記録されず、変更を検知できません。

参照するベースのテーブルが1つの場合かつSQLServerのビュー更新条件（特定の関数が使用されていないこと）を満たしている場合に限り、リフレッシュのみ可能です。
複数のベーステーブルを参照するビューの場合は、ビューの仕様でinsert, update, deleteが行えず、selectのみ可能となりますので、DBMotoでも同様にレプリケーションは行えなくなります。

Windows OSのマシン(物理/仮想)にインストールします。
インストールしたマシンからソースDB・ターゲットDBのマシンに接続してレプリケーションの設定・実行を行います。
システム要件：https://www.climb.co.jp/soft/dbmoto/outline/system.html

Windows OSでMicrosoft .NET Frameworkがインストールされている必要があります。詳細は下記をご確認ください。
https://www.climb.co.jp/soft/dbmoto/outline/system.html

可能ですが注意が必要です。
ミラーリング時はPKが各テーブルで重複していなければ問題ありませんが、リフレッシュ時はそのまま実行してしまいますとリフレッシュ前に一度レコードを削除する処理（DBMotoの仕様）が行われます。これを回避するためにスクリプトでリフレッシュ時にレコードを削除しないようブロックする必要があります。
なお、各テーブル内のレコードが結合後に重複する可能性がある場合は、PK代わりのフィールドを新規で作成することでPK重複エラーを回避可能です。

VMwareのvSphere ESX/ESXiやMicrosoftのHyper-Vなど、仮想マシン上にもインストール可能です。

ソースDB・ターゲットDB・DBMotoマシンいずれに対してもエージェントを導入する必要はありません。

AS/400をはじめとする非常に多くのDBをサポートしております。また、DBのプラットフォーム（OS）には依存しません。
詳細な対応DB一覧は下記をご覧ください。
対応データベース一覧

下記の3つのモードをサポートしております。
・リフレッシュ（レコード全件レプリケーション）
・ミラーリング（片方向差分レプリケーション）
・シンクロナイゼーション（双方向差分レプリケーション）

ソースDBとターゲットDBの種類とマシンのスペックに依存します。
詳細はこちらをご参照ください。

シンクロナイゼーション（双方向）を使用せず、ミラーリング（片方向）のみを使用する場合は、割引がございます。詳細はお問合せください。

開発環境, バックアップ、HA環境、RACなどの構成で使用する場合は、価格が変わりますのでお問い合わせください。

お問合せはコチラ

弊社から販売、代理店を通しての販売どちらも行っております。

回数に制限はありません。

サポート期間内の場合、無償でバージョンアップをお客様自身で行うことができます。
また、弊社でもバージョンアップ作業(有償)を行っています。

操作画面は日本語化しております。
製品の操作マニュアルも日本語版を用意しております。

別料金となりますが、弊社にて設計、インストール、設定を行います。

年間保守費用はライセンス価格の 20% となっており、初年度は必須です。

評価用ライセンスキーが発行されてから15日間となります。

無償でご利用いただけます。
質問の内容により、お時間を頂く場合がございます。予めご了承ください。

評価版に機能制限はありません。

評価版のお申込みはコチラ

下記の環境をご用意ください。
・DBMotoインストール用のWindowsPC（仮想マシンでも可）
・ソースDBとターゲットDB、及び評価の際に使用するテストデータ
※インストールするサーバについては、システム要件をご確認ください。
※インストールや設定方法についてのマニュアルやデモ動画を事前にご確認ください。

デフォルト値は60秒です。変更可能ですが、30秒～5分が推奨値となっております。

AS/400のミラーリングではトランザクションログとして「ジャーナル・レシーバ」を参照しますので、予め物理ファイルに対してジャーナルを起動しておく必要があります。
また、DBMotoからジャーナルを参照するためのプロシージャをAS/400のライブラリに対して作成する必要がありますが、DBMotoでAS/400の接続設定を行う際に簡単に作成することができます。

自動で切り替わります。

DBMotoから参照しているジャーナルより前のものについては削除して問題ありません。

Ritmo/iというドライバを使用します。DBMotoに同梱されております。

1つにまとめても問題ありません。DBMotoではテーブル単位でレプリケーション定義を作成し、定義ごとにトランザクションIDを管理することが可能なためです。

可能ですが非推奨です。DBMOTOLIBにはDBMotoからAS/400のジャーナルを参 照するためのプロシージャが存在しますので、DBMOTOLIBにプロシージャ以外のデータが存在するとレプリケーションのパフォーマンスに影響が出る場合があります。

Redoログを参照します。事前にサプリメンタルロギングの設定が必要ですが、DBMotoから行うことが可能です。

DBMoto側のOracleクライアントドライバを最新の11gにしてください。Oracle側の既知不具合です。

可能です。

対応しております。

対応しておりますが、ミラーリングとシンクロナイゼーションについては、
Log Server経由のみ対応しています。

対応しておりません。

以下のサイトからOracleクライアント又はODACをダウンロード可能です。
http://www.oracle.com/technetwork/jp/database/windows/downloads/index.html
また、Oracleデータベースのバージョンに関わらず、ドライバのバージョンは11を使用してください。

DB2 Logを参照する方法と、トリガーログテーブルを作成する方法があります。DB2 Logを使用する場合、予めdb2udbreadlogという拡張ファイル（DBMotoに同梱済み）をDB2側に格納する必要があります。

Ritmo/DB2というドライバを使用します。DBMotoに同梱されております。

Distributorを参照する方法と、トリガーログテーブルを作成する方法があります。

対応しております。ただし差分レプリケーションの際にDistributorを使用することはできず、トリガーテーブルを作成する必要があります。

MySQLのバイナリログを参照する方法と、トリガーログテーブルを作成する方法があります。MySQLのバイナリログを使用する場合、拡張ファイルが必要となりますので別途お問い合わせください。

可能です。

DBMotoからAS/400のジャーナルレシーバを参照するためのプロシージャを手動で作成した場合に、正しく作成されていない可能性があります。

カタログ・技術資料一覧から以下をご参照ください。
[DBMoto共通]AS400ジャーナル・プロシージャ作成手順書

弊社営業時間内(10:00～18:00)となります。

プロダクションサポートの場合、
弊社営業時間外はメーカーの英語サポートのみとなります。

OracleのRedoログが1周してDBMotoが参照しに行くIDが既になくなってしまった際に発生するエラーです。
復旧はリフレッシュするか、最新のトランザクションIDを取得する必要があります。
また、このエラーが頻発する場合はRedoログのサイズ設定を見直す必要があります。

この Warning は現在時刻と最後にレプリケーションした際の時刻がしきい値を超えたときに「レプリケーションが遅延しています」と警告を出すものです。

可能です。詳細は下記ページをご参照ください。
https://www.climb.co.jp/soft/dbmoto/outline/example.html

可能です。詳細は下記ページをご参照ください。

https://www.climb.co.jp/soft/dbmoto/outline/example.html

下記ブログ記事をご参照ください。

https://www.climb.co.jp/blog_dbmoto/archives/491

リフレッシュ完了後にミラーリングモードに移行し、更新分が差分レプリケーションされます。

同じ値を更新した場合はコンフリクトとはみなされません。

●Minimal Level

レプリケーションするテーブルのみ（最低限）にサプリメンタルロギングの設定が行われます。

以下のSQLが実行されます。

・サプリメンタルロギング設定時

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA

・レプリケーション作成時

ALTER TABLE テーブル名 ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS
●Database Level

データベース全体（すべてのテーブル）に対してサプリメンタルロギングの設定が行われます。

以下のSQLが実行されます。

・サプリメンタルロギング設定時

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS

予めソース・ターゲットの接続設定を済ませたうえで「マルチレプリケーション作成」を選択することで可能です。

はい、AS/400側のジャーナルに合わせてDBMotoが参照するジャーナルも自動で切り替わります。

リフレッシュはソース→ターゲット方向のみサポートしております。

可能です。

下記のブログ記事をご参照ください。

https://www.climb.co.jp/blog_dbmoto/archives/337

Oracle9iの仕様によるものです。

SQLServerのフィールドIdentityの仕様によるものです。Identity以外のPKフィールドを用意するかIdentity自体をOFFにする必要があります。

ミラーリング時にはPKの設定が必要です。DBに設定されているかご確認ください。もしされていない場合は、DBMotoから疑似PKを設定することも可能です。

レプリケーション定義を作成した後に、Data Replicatorを起動する必要があります。

.NET Framework 2.0 SP2がインストールされていないのが原因です。

WindowsXPやWindowsServer2003・2003R2の場合、デフォルトではインストールされていないので、別途インストールが必要です。また、.NET Framework4.0単独では動作いたしません。

以下の流れとなります。

ソースのトランザクションログを検索⇒ターゲットのトランザクションログを検索⇒ソースからターゲットへの更新処理⇒ターゲットからソースへの更新処理

下記ブログ記事をご参照ください。

https://www.climb.co.jp/blog_dbmoto/archives/560

ミラーリングプロセス終了後にリフレッシュされます。強引に割り込むことはありません。

Data Replicator Option画面にある「Thread Execution Factor」の値を増やすことで処理速度の向上が期待できます。

スクリプトで対応可能です。

ステータスがMirroringで動いていないように見えるときは、実際にはトランザクションログの参照を行っています。大量トランザクション処理時は時間がかかるケースがあります。

リフレッシュをする方法と、トランザクションIDを任意の位置に戻す方法の2通りあります。

OracleとDBMoto間のネットワーク障害によるものです。

疑似PKの重複キーチェックは行われません。重複キーエラーが出るのはDBのPK使用時に重複していた場合のみです。

可能です。

スクリプトで実現可能です。

DBMotoはDBに対するクライアントツールとしてのアクセスしか行わないため大きな負荷はかかりません。DBに対するエージェント導入も不要です。

自動で行われます。

回線が速ければレプリケーション速度も向上しますが、回線が遅くてもレプリケーションは十分可能です。ISDN回線を使用しているお客様もいらっしゃいます。

Windowsイベントログでの運用の場合、historyファイルはご使用いただけません。

AS/400でレコードの全消去を含む操作（CLRPFMやCPYF（REPLACEオプション））を行った場合、他データベースに対してこの変更をTRUNCATEとして他データベースに反映します。しかしレコードが対象ではなく、ファイルそのものを置き換えている場合など（RSTOBJ等）の場合、変更は他データベースへ反映されません。

下記のオプションから選択可能です。
・ソースDBを優先する
・ターゲットDBを優先する
・TimeStampの早いほうを優先する（先勝ち）
・カスタムスクリプト（上記3つ以外の挙動を設定したい場合など）
なお、「TimeStampの遅いほうを優先（後勝ち）」としたい場合には、カスタムスクリプトの記述が必要となります。

問題ありません。DBMotoで文字コード変換を吸収します。
DBMoto内部ではUnicodeで処理され、双方のDBに対して文字コード変換を行います。

シンクロナイゼーションではDBMotoでの接続ユーザでレコードの更新をかけた場合にはレプリケーションされず、エラーも出力されません。これは無限ループを回避するための仕様です。シンクロナイゼーションを利用する場合、DBMotoで使用する接続ユーザは他のアプリケーションでは使用しないDBMoto専用のユーザを用意してください。

SQL Server側とDBMoto側のMax Pool Sizeをご確認ください。DBMoto側のデフォルト値は100です。

はい、あります。
リフレッシュを定期的に実行するリフレッシュスケジュール、ミラーリングを実行する日時を制限するミラーリングスケジュールの設定が可能です。
スケジュールは時・分・秒、年・月・日・曜日単位で細かく設定でき、複数設定も可能です。

DBMotoは最後に更新したトランザクションIDを常に保持しておりますので、DB障害復旧後には、障害発生前の最後のトランザクションIDからレプリケーションを再開します。よって通常はデータの不整合が発生することはまずありません。

エラーメッセージ「ターゲットにレコードが存在しません」をログファイルに出力し、更新時にはターゲットに対して登録処理が行われます。オプション設定変更により登録処理を行わないようにもできます。

TCP/IPで通信し、DB で使用するデフォルトポートを使用します。例えばOracleの場合はデフォルトで1521を使用します。

可能です。Expressionという機能を使用し、VB.NET の関数を使用できます。

可能です。スクリプトとしてオリジナルの関数を定義し、Expression という機能で呼び出すことが可能です。

可能です。Expressionという機能を使用し、固定値を入れることも可能ですし、現在日時を挿入するなど、関数を使用することも可能です

ソースとターゲットで同一レコードの更新があった場合の挙動は以下から選択可能です。
・ソースDBを優先する
・ターゲットDBを優先する
・TimeStampの早いほうを優先する
・カスタムスクリプト（上記3つ以外の挙動を設定したい場合など）
さらにターゲットの複数サーバで同一レコードの更新があった場合には、TimeStampの早いほうが優先されます。

可能です。下記の弊社ブログをご参照ください。
DBMotoでの全件リフレッシュ・差分ミラーリングの再設定手順

スクリプトを使用することで実現可能です。詳細は下記をご参照ください。
https://www.climb.co.jp/blog_dbmoto/archives/452
https://www.climb.co.jp/blog_dbmoto/archives/460

はい、可能です。下記の単位でのバックアップが可能です。
・クラスタ
・フォルダ
・リソースプール
・Virual App
・ホスト
・ユーザーが選択した仮想マシン

はい、対応しています。

Veeam Backup for Nutanix AHVを導入することで
Nutanix AHV上仮想マシンのバックアップを簡単に実施することができます。

◇Veeam Backup for Nutanix AHV製品ページ
https://www.climb.co.jp/soft/veeam/van/

Active Full Backupの設定をご確認ください。

ジョブのスケジュールとは別に、Active Full Backupを実行するよう設定した曜日にもジョブが実行されます。

例えば、毎週土曜日 20:00にジョブを実行するようスケジュールしており、

Active Full Backupを日～土までの全て曜日で有効にしている場合、

土曜日以外の日～金も20:00にジョブが実行されます。

バックアップすることは可能ですが、CBT機能を有効にできないため、毎回、VMの全データを読み取り、増分の検出を行います。
そのため、増分バックアップは可能ですが、フルバックアップと同程度の時間がかかってしまうかもしれません。

ジョブの成功、失敗問わず、後続のジョブは実行されます。

保護対象の単位です。1インスタンスにつき10個まで、以下のバックアップ対象を割り当てることができます。
●1仮想マシン（vSphere/Hyper-V/AHV）
●1物理サーバ（Windows/Linuxなど）
●1クラウドインスタンス（AWS/Azure/GCP）
●500 GB分のNASデータ

詳しくはお問合せください。
お問合せフォームはコチラ

Veeam Backup & ReplicationとVeeam ONEとのパッケージ製品（Veeam Availability Suite）の廉価版で、中小規模向けの仮想環境統合ソリューションです。

1ライセンスにつき5インスタンス保護できます。

※1管理サーバあたり、10ライセンス（50インスタンス）の制限があります。

詳細はこちらをご参照ください。

Veeamサーバのウィルススキャン時に、Windowsイベントログに以下の警告が発生することがあります。

———————————————————————————————————

ソース “SpntLog” からのイベント ID 212 の説明が見つかりません。このイベントを発生させるコンポーネントがローカル コンピューターにインストールされていないか、インストールが壊れています。ローカル コンピューターにコンポーネントをインストールするか、コンポーネントを修復してください。

イベントが別のコンピューターから発生している場合、イベントと共に表示情報を保存する必要があります。

イベントには次の情報が含まれています:

C:\ProgramData\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\veeam.log

———————————————————————————————————

これはWindows側の無限ループ問題です。
基本的にProgramDataフォルダはデフォルトでApplication Data内にシンボリックリンク(ショートカット)されています。
これはWindows側の仕様となっており、このシンボリックリンクがウィルス対策ソフトにてスキャンされたとき、
フォルダ階層の無限ループが発生することがあります。

また、ウィルス対策ソフトのスキャンアルゴリズムのバグ等でも発生することがあります。

Veeamの動作としては問題はありませんが、Application DataとProgramDataフォルダ配下はウィルス対策ソフトの対象から除外することでこの警告を回避できます。

各ジョブのバックアップ対象が同じvApp内のVMか確認してください。
その場合、現在処理中のジョブによってvAppがロックされているため、
もう片方のジョブは待ち状態となります。
現在処理中のジョブが終了後、処理が開始されます。

FAQ

可能です。
要件を満たしていれば、物理/仮想問わずインストールできます。
システム要件はコチラのページの管理サーバ（Veeamインストール先）をご確認ください。

はい、Veeam Backup & Replication Universalライセンスをご利用いただくことで、
仮想サーバに限らず、物理サーバも併せてバックアップ可能です。
Universalライセンスにつきましては、こちらをご参照ください。

以下をご確認ください。
・レプリケーション元ESXiホスト
・レプリケーション先ESXiホスト
・レプリケーション対象VMのハードウェアバージョン

レプリケーション先のESXiホストがVMのハードウェアバージョンと互換性がない場合に、
このエラーによってレプリケーションが失敗します。

【参考】ハードウェアバージョンの互換性リスト

互換性のある状態にする必要があるため、
対処法としては、以下の2通りの方法があります。
・レプリケーション先ESXiホストをバージョンアップする。
・VMのハードウェアバージョンをダウングレードする。

【参考】ハードウェアバージョンのダウングレード方法

以下に該当していないかご確認ください。
・vCenter経由とスタンドアロンホストの両方で同一ホストを登録している。
・どちらもホスト名で登録されている。

このとき、名前解決が行えず、Enterprise Managerが情報を正常に収集できません。

以下の対応を実施することで、全てのホストが表示されるようになります。
1.以下のいずれかを実施します。
・スタンドアロンホストをホスト名ではなく、IPアドレスで登録しなおす。
・Veeamサーバのhostsファイルにスタンドアロンホストのホスト名をIPアドレスを記載する。
2.Veeamコンソールで上記のホストをRescanします。
3.Enterprise ManagerでVeeamサーバの情報を収集します。

オリジナルの仮想マシンとクローンの仮想マシンをマッピングすることで、
差分レプリケーションからジョブを開始することができます。

参考: レプリカシーディング・レプリカマッピング機能について

関連トピック

既存のレプリカVMを利用して初回のフルレプリケーションを行わず、差分レプリケーションが行えますか？

Veeam Universal License(VUL)は、サブスクリプション（年額前払）形態でご利用いただけます。インスタンス数（保護対象数）または保護容量で課金するライセンス体系で、以下が保護対象となります。
●仮想マシン（vSphere/Hyper-V/AHV）
●物理サーバ（Windows/Linuxなど）
●クラウドインスタンス（AWS/Azure/GCP）
●NASデータ

詳細は：

Veeam Universal License (VUL)について | クライム情報発信ブログ：ClimbMeUp

詳しくはお問合せください。
お問合せフォームはコチラ

Veeam Backup & Replication とVeeam ONEとのパッケージ製品です。

Veeam (Backup) Essentialsのような数量制限はありません。

詳しくはこちらのサイトを参照ください。

はい、あります。
Guest Processingステップの「Credentials…」にて個別に認証設定を行うことが可能です。

詳細は、以下URLをご参照ください。

Veeam静止点処理において必要な認証情報をVM個別に指定する方法

関連トピック

Job作成時のオプション “Enable application-aware image processing” はどんな機能ですか?

●仮想マシン（vSphere/Hyper-V/AHV）
●物理サーバ（Windows/Linuxなど）
●クラウドインスタンス（AWS/Azure/GCP）
●NASデータ

対象によって、インスタンスのカウント方法は異なります。

詳しくはお問合せください。
お問合せフォームはコチラ

必要ありません。
ライセンスはレプリケーション元となるオリジナルの仮想マシンのみ必要になります。
フェイルオーバーやフェイルバックの際、DR環境に作成した仮想マシンにライセンスは必要ありません。

サーバ仮想化の基本要素である、1台のホスト上に存在するすべてのVMは、物理サーバのリソースを共有し、1つのハイパーバイザによって管理されていることを忘れてはいけません。もし、これら全てのVMが同時にバックアップジョブを開始したらどうなるのでしょうか？ハイパーバイザーやホストサーバのリソースに負担がかかり、遅延が発生したり、最悪の場合バックアップが失敗したりする可能性があります。

ここでスナップショットの威力が発揮されます。スナップショットはVMのある時点のコピーを取得し、フルバックアップと比較してはるかに迅速な処理が可能です。スナップショット自体はバックアップではありませんが、イメージベースバックアップの重要な構成要素です。VMスナップショットがバックアップと同等でない主な理由は、VMから独立して保存できないからです。このため、スナップショットの取得頻度によっては、VMのストレージ容量が急速に増大し、パフォーマンスに影響を与える可能性があります。このため、取得するスナップショットの数量を認識することが重要です。

Veeam Backup for Azure の最新版v3で何が追加されたのか、少し掘り下げてみましょう。

既にVeeam Backup for Azureを使用している場合は、内蔵のアップデーターを使用して以前のインストールをアップグレードすることができます。

何が含まれているか?

毎回のリリースと同様に、いくつかの主要な機能強化があり、細かい改善と同様に多くのアンダーザフードのものがあります。

最初の大きな特徴は、Azure SQLのサポートです。Veeam Backup for Microsoft Azureは、SQL ServerまたはAzure SQL Managed Instanceとして実行されているSQLデータベースをバックアップおよびリストアすることができるようになりました。

AWSのVeeam BackupがS3 Glacierを使用した長期アーカイブのサポートを追加したように、Veeamは、Azureにもこの機能を追加しました。バックアップを長期間保存するために、ホットまたはクール・ストレージを使用しなければならないのは嫌ではありませんか？もう心配する必要はありません! 今日からAzure Archiveへのバックアップの階層化を始めましょう! 今こそコスト削減のチャンスです（クラウドでは何にでもお金がかかります）。

複数のAzureアカウントに対応

今回のリリースで大きな特徴のひとつは、実は複数のAzureアカウントをサポートしたことです。これはVeeamのAWSとGCPのソリューションで既に可能でしたが、Azureは1つのAzureアカウントに限定されていました。これを強化し、複数のアカウントを許可することで、1枚のガラスからすべてのアカウントを管理および保護することが容易になります。

セキュリティ強化の追加

セキュリティは重要なテーマであり、ここでも需要の高まりが感じられます。そこで、2つの新機能を追加しました。

●ロールベースのアクセスコントロール:ロールベースのアクセスコントロール：ビルトインのロールを使用して特定のユーザーにアクセスを委任することにより、組織内でより高いセキュリティを確保するために範囲を制限することができます。現在、3つの異なるロールがサポートされており、アプライアンス内でそれぞれのロールが独自の範囲を持ちます。
●シングルサインオンをサポート：外部のIDプロバイダーを登録し、ローカル・ユーザーを作成する必要はありません。既存のユーザー・アカウントを再利用して、Veeam Backup for Azureで日常的なタスクを実行するだけです。
●Azure Key Vaultのサポート。バックアップ・データを暗号化するためにAzure Key Vaultを使用することができるようになりました。もうパスワードをメモして保管庫に入れる必要はありません

その他の追加機能

Azure、AWS、GCPを問わず、リリースするたびに、ユーザーインターフェイスとエクスペリエンスの改善に努めています。

更新されたウィザード（例えば、リポジトリとポリシーウィザード）では、全画面を使って構成設定を明確に表示するようになり、ウィザードを簡単に進めることができるようになりました。初めてログインすると、製品の最新情報を紹介する「What’s New」が表示されます。

Veeamは、ログイン画面を更新し、Veeam Backup for Azureで作成したアカウントでログインするか、シングルサインオンの恩恵を受けるかを簡単に選択することができます。

いいえ、保持しません。
例えば、リストアポイントを4世代とした場合、バックアップを取得するたびに世代数が減っていきます。
11/1, 11/2, 11/3, 11/4とバックアップを取得し、11/5にVM02が除外されたバックアップを取得した場合、VM02のリストアポイントは11/2, 11/3, 11/4となり、11/1のリストアポイントは消されます。
最終的には11/4のリストアポイントがフルバックアップファイル内に残り続けます。
これを消すにはフルバックアップの再作成や再構成（Compact full）が必要です。

V12では、Direct-to-ObjectとDirect-to-Cloudの2つの主要な機能を提供しています。最初の機能は、バックアッププロキシやエージェントからオブジェクトストレージに直接バックアップを送信することで、中間ステップを回避することができます。さらに、このようなストレージへの直接接続が不可能な場合、トラフィックはゲートウェイサーバーの弾力的なプールを介してリダイレクトされることができます。さらに、ROBO（Remote Office Branch Office）環境を含め、より効率的なクラウドへの直接バックアップを実装しています。

また、新しいSmart Object Storage API（SOSAPI）ソフトウェア・インターフェースにより、オブジェクト・ストレージ・ベンダーがVeeam Backup & Replication v12と深く統合できるようになったことも特筆に値する（パフォーマンスの向上とユーザー・エクスペリエンスの改善に向けて）。

イミュータブル(Immutable)バックアップ機能は、ランサムウェアからバックアップを保護する手段を実装しています。この機能は、オンプレミスとクラウドネイティブの両方のワークロードで利用でき、ストレージのライフサイクルを通じてバックアップを保護し、管理者側の操作からも保護します。また、バックアップだけでなく、アラームにも不変性を持たせることができるため、より高度なインフラ保護が可能です。

イメージレベルでのバックアップのサポートに加え、NASストレージ、スタンドアロンエージェント、AWSとMicrosoft Azureのバックアップ（Azure Blob Storageも）、HPE StoreOnceストレージでバックアップのイミュータビリティが利用可能です。また、トランザクションログやエンタープライズアプリケーションに対しても、プラグインを介して利用することができます。

これらの高度なセキュリティ機能により、管理者は2つの新しいツールを手に入れることができます：

多要素認証は、RFC 6238に基づくTOTP（Time-Based One-Time Passwords）の仕組みに基づく2要素認証（2FA）機能を通じてコンソールへのアクセスを可能にします。個々のアカウントに対して有効にすることができます。

Best Practices Analyzerコンポーネントは、バックアップサーバーと製品の構成をチェックし、セキュリティと復旧成功の可能性を向上させるための重要な変更を管理者に提案します。

回転メディアに切り替えると、ディスクは自動的に既存の古いバックアップからクリアされます。さらに、ユーザは既存のバックアップチェーンを使い続けることもでき、現在のタスクにのみ属するバックアップを削除するか、メディア上のすべてのバックアップを削除するかの2つのオプションのうち1つを選択することができます。

v12では、SOBRリバランス機能が導入されました。Performance Tierエクステントのブロックおよびファイルストレージレベルでストレージ消費をリバランスし、エクステント間のデータ分散を均等にすることができるようになりました。この操作は、新しいエクステントを追加するときに実行する必要がありますが、常に実行する必要はありません。エクステント退避とSOBRリバランスの操作は、前述した新しいVeeaMoverエンジンを使用して、エクステント間でより効率的にバックアップを移動させます。

また、ユーザーの要望により、マルチサイトやネットワーク環境でのトラフィックを管理するためのいくつかのインターネットルールが追加されました：

最後に、メール通知のOAuth 2.0対応です。SMTPによる認証に加え、Google GmailとMicrosoft 365のOAuthプロトコルによる認証をVBR V12がサポートするようになりました：

新しいBackup Copyジョブは、新しいプラットフォームの機能との互換性を確保するために、個々のVMに基づく新しいフォーマットでチェーンを作成します（Per-machine backup chain）。既存のジョブはこのアップデートの影響を受けません。

アプリケーショングループについては、仮想テストラボで起動する前に、Windowsファイアウォールのネットワーク接続を自動的に無効化するオプションが追加されました。これは、リストアプロセスのテストが必要なバックアップで、ファイアウォールが外部接続をブロックするのを防ぐために必要です。

そして最後の非常に便利な機能です。これからは、更新されたBackup Browserを使って、復元ポイントと本番機のファイルを比較することができ、選択したバックアップが取られた後にどのファイルが変更または削除されたかを表示します。

また、バックアップシステムと本番システムの間で、個々のファイルやフォルダの属性の違いを、新しいダイアログボックスを使って1画面で確認するオプションが追加されました：

もう一つの新機能は、ファイルやフォルダーのアクセスコントロールリスト（ACL）だけを復元する機能です。これは、管理者が誤ってフォルダやファイルのパーミッションを一括で変更してしまった場合に必要になることがあります。また、v12では、Windowsファイルを直接復元する際に、異なるターゲットマシンを選択できるようになりました（これまではLinuxのみ）。最後に、バックアップのエクスポートの機能が向上し、元のバックアップがあった同じリポジトリだけでなく、エクスポートしたポイントの保存先を任意に選択できるようになりました：

WindowsとLinuxの両サーバーに接続されたテープライブラリーやメディアをテープバックアップ用に登録することが可能に：

Backup-to-Tapeタスクは、ワークロードの種類に関係なく、即時モードまたは定期モードの新しいマルチプラットフォームBackup Copyジョブタイプによって作成されたすべてのバックアップコピーのエクスポートをサポートするようになりました。

すべてのテープ機能で、LTO-9テープの初期化プロセスをサポートし、初期化に時間がかかるとタイムアウトするのではなく、初期化が完了するまで正しく待機するようになりました。カセットテープを誤って消去しないように、InventoryとCatalogの操作後にテープメディアが自動的にテープライブラリードライブから排出されるようになりました。

CDPプロキシはLinuxサーバー上で動作するため、Windowsのライセンスを節約することができます。通常のバックアップ作業に加え、任意のクラウドホストサービスプロバイダを使用して、CDPポリシー内でレプリケーションを実行することができます。そして、VMやvAppモジュールのインスタントリカバリ機能を持つCloud Directorインスタンス内でレプリケーションを使用することができます。また、CDPはvVolスナップショットのネイティブサポートを提供するようになり、そこに保存されるオブジェクトの数を減らし、vVolボリュームのスケーリングに小さな制限があるデバイスでの信頼性を向上させます。

Windows Serverに加え、保護グループウィザードに、Windows 10以降を実行しているワークステーションにVeeam changed block tracking (CBT) ドライバをインストールし、より高速な増分バックアップを行うオプションが追加されました。また、管理者はBare Metal Recoveryのリストアタスクのためにユーザーに与えることができる一時的なアクセスキーまたはリカバートークンを生成することができます。

v12のリリースに伴い、ゲストOS用の利用可能なすべてのエージェントがソリューション内で更新されたことに留意してください：

• Veeam Agent for Microsoft Windows
• Veeam Agent for Linux
• Veeam Agent for Mac
• Veeam Agent for AIX
• Veeam Agent for Solaris

保護グループウィザードが改善され、グループに含まれるサーバーのアプリケーションプラグインのインストールとアップデートを制御するための設定が追加されました。アプリケーションのトポロジーに関する情報収集と、スキャンおよび再スキャン時のOracle RACおよびSAP HANAシステムの検出ができるようになりました。

アプリケーションのバックアップポリシーには、各サーバーのバックアップ処理をリアルタイムで監視し、データベースやREDOログのバックアップの統計やレポートを可視化するツールがあります。

また、Oracle RMAN、SAP HANA、SAP on Oracleのバックアップをバックアップコンソールからポリシーに基づいてオーケストレーションする機能があり、各データベースサーバーのプラグイン設定やバックアップシナリオを手動で整備する必要がなくなりました。また、Version12では、これらのプラグインによるバックアップと復旧の速度が最大で3倍に向上しています。

Microsoft SQL Server用の新しいプラグインは完全に刷新され、SQL Server（VDIプラグイン）との深い統合を実現し、Veeamリポジトリへの直接バックアップを可能にしました。VDIプラグインは、バックアップの一貫性を確保するためにネイティブな手段を使用し、スナップショットベースのバックアップとは異なり、Microsoft VSSに依存しないため、共有ボリュームを持つWindows Server Failover Clustersなど、異なるSQL Server構成のバックアップを可能にします。

マルチプラットフォームのPostgreSQLエンジンがサポートされ、Microsoft SQL Server Express Editionのデータベースサイズ（10GB）の制限を回避することができるようになりました。SQL Server Express Editionはまだサポートされていますが、Veeam Backup and Replication製品に含まれなくなりました。

PGAdminでPostgreSQLデータベースがどのように見えるかをご紹介します：

さらに、Linux上のPostgreSQLデータベースのポイントインタイムリカバリーのためのトランザクションログのアプリケーションアウェアバックアップがサポートされるようになりました。同じ機能は、Microsoft SQL ServerやOracleではすでに提供されていました。

また、PostgreSQLの経験を持つ管理者でなくてもインスタンスをリストアできる「Veeam Explorer for PostgreSQL」という製品も登場しました。インスタンスの任意のポイントインタイム状態をバックアップから指定されたDev/Testサーバに直接公開することができ、その後、公開されたデータベースに加えられた変更をエクスポートまたは元に戻すことができます。

VeeaMoverを使用すれば、異なるタイプのリポジトリ間でデータを移動することができます。ソースとターゲットリポジトリのタイプを気にする必要はもうありません – VeeaMoverが自動的にデータ移動のすべての作業を処理します。

さらに、バックアップはタスク間で簡単に移動できるようになり、関連するすべての操作が自動的に実行されます（例えば、包含リストや除外リストの操作など）。また、保持ポリシーを保持したまま（変更も可能）、数回のクリックでバックアップチェーン全体を別の場所に移動させることができます。

タスクセッションで対応するマシンをクリックすることで、タスク内のすべてのマシンに対してこの操作を開始することなく、個々のマシンに対して処理の再開やアクティブフルバックアップの実行ができるようになりました。また、誤ってタスクに追加された場合でも、処理から完全に除外したいマシンのマスターリストを指定することで、恒久的または一時的な除外の管理がより簡単になりました。Global Exclusionsダイアログはメインメニューから利用でき、これらのマシンはインベントリータブでDisable processingオプションが選択されています。

また、便利な機能として、既存のバックアップをタスクから切り離すことができ、次のフルバックアップ実行時に新しいバックアップチェーンが開始されます。切断されたバックアップは、「バックアップ」タブの「孤児」セクションに、最新の保持ポリシーとともに表示されます。

バックアップタスクは、既存のストレージレプリケーションリンクを使用して、追加のリカバリポイントとしてストレージベースのスナップショットに基づくレプリカを作成できるようになりました。これにより、プライマリストレージへの負荷を避けるために、セカンダリストレージアレイからバックアップを取ることができます。

さらに、Veeam のUniversal Storage APIのVer2が導入され、スナップショットレプリケーションとアーカイブのオーケストレーション機能、および同期レプリケーションのサポートが含まれています。Cisco HyperFlex、IBM Spectrum Virtualize、NetApp All SAN Array（ASA）、Dell Data Domain、Infinidat InfiniGuard、富士通 CS800、HPE StoreOnce、HPE Nimble、HPE Alletra 5000/6000ストレージアレイ向けに、バックアップの不変性など多くの重要機能が追加されています。ネイティブブロッククローニング機能の拡張サポートがExaGridストレージアレイに追加されました。

オブジェクト・ロック（Object Lock）の利点

オブジェクト・ロックは、指定された期間に達するまで、データがストレージから削除または変更されるのを防ぎます。これは、誰も誤って、または悪意を持って、Veeamバックアップを変更または暗号化できないことを意味します。本質的に、これはランサムウェアに対する究極の保護を提供します。

データ保護の課題

オフサイトに保存されていても、バックアップは危険にさらされています。データを保護するためにデータをエアギャップする従来の方法は、組織のデータが電源から切り離されたLTOテープ・カートリッジやHDDにオフラインで保存されることを意味しました。この方法で保存されたデータを取り出すには数時間から数日かかり、ビットの腐敗や損傷が起こりやすく、最終的にはデータが破壊される可能性がありました。バックアップをイミュータブルにすることで、オブジェクト・ロックはこの脆弱性を排除し、データが保存された場所に正確に残るようにします。データが保存された場所に正確に残ることを保証します。

なぜオブジェクト・ロックが重要なのか？

なぜなら、物事は変化するからです。イミュータブルオブジェクトにより、情報は偶発的または意図的な削除や改ざんから保護されます。一度情報がWasabiホットストレージクラウドに保存されると、ロックの有効期限が切れるか、バケットが完全に削除されるまで（これはまた別の問題ですが）、保存され続けることが保証されます。

サイバー犯罪者はランサムウェアキャンペーンの一環としてバックアップやアーカイブを攻撃するからです。プライマリ・システムをダウンさせるだけでは不十分で、ランサムウェアへのアクセスを確保するためにセカンダリ／バックアップ・システムも攻撃します

なぜなら、規制当局はこれらを定期的にチェックしているからです。コンプライアンスと消費者保護基準のために、規制業界のデータを保護することは必須です。

監視ビデオのようなデジタル証拠に関しては、偽造または改ざんされた映像が今や司法に対する脅威となっているため、法的手続きは親権の連鎖と不変性に依存しています。オブジェクトロック機能は、HIPAA、FINRA、CJISのような特定の政府および業界の規制に対応する組織であり、電子記録、取引データ、および活動ログを安全に提供することができます。

Veeam Backup & Replicationとのオブジェクトロック機能

Wasabiのオブジェクトロック機能は、Veeam Backup & Replication v10以上のEnterpriseおよびEnterprise Plusエディションの両方をサポートします。

業界をリードするバックアップとリストアと不変のホットクラウドストレージを組み合わせて、最高のハイブリッドクラウドデータ保護を実現

データ量とデータ速度は指数関数的なペースで増加し続けており、業界によっては年複利で20%、40%、80%の成長を経験しています。従来のオンプレミスバックアップアプローチは、コストのかかるスケールアップアーキテクチャとクラウド接続性を備えていないため、コンプライアンス規制を満たしたり、ランサムウェア攻撃と戦うために必要なデータ量と増え続ける保持時間に追いつくことができません。

VeeamとWasabiを組み合わせることで、オンプレミスおよびクラウドネイティブなワークロードのための完全なデータ保護ソリューションを提供します。Veeam Backup & Replication (v9.5.4、v10、v11、v12)、Veeam Backup for Microsoft Office 365、Wasabiのホットクラウドストレージ、Object Lockによるバックアップの不変性が含まれます。Veeamの単一的なインターフェースは、バックアップの運用管理をシンプルにし、Wasabiの無制限クラウドストレージは、卓越したセキュリティとデータの不変性を提供します。

データ保護戦略で最も重要なのは、正確なデータを迅速にリストアし、通常業務を再開する能力です。そのためには、信頼できるバックアップデータと、復旧時間目標（RTO）を満たすストレージ性能が必要です。WasabiのS3 Object Lock APIの実装により、データが改ざんされていないことを確認できます。S3 Object Lockは、組織内外の誰によってもデータが削除されたり変更されたりしないことを保証します。ロックされたデータセットは不変であり、ユーザが定義した期間保持されます。

データ損失の可能性を想定して演習するには、頻繁にリストアの演習をする必要があります。クラウドストレージを使用する場合、データをダウンロードする必要があり、場合によってはギガバイトやマルチテラバイトの規模になることもあります。Wasabiのホットクラウドストレージでは、追加料金はかかりません。部分的または完全なリストアでバックアップデータの完全性を検証する場合、その作業に必要な時間と人以外にコストはかかりません。このため、Wasabiは他のクラウドストレージプロバイダーとは一線を画し、このような作業をより簡単に、低コストで頻繁に実行することができます。

Microsoft Office 365用バックアップ

Veeam Backup for Microsoft 365は、Exchange、SharePoint、OneDrive、Teamsのバックアップとリカバリを可能にします。また、Veeam Backup for Microsoft Office 365は、プライマリ・バックアップ・ストレージ・システムとしてWasabiホット・クラウド・オブジェクト・ストレージをサポートし、大企業および中小企業が短期および長期の保持のため、クラウドの無限の容量を経済的に活用することを可能にします。

Veeam Backup and Replicationがデータ保護を合理化 ：バックアップ・ジョブとクラウドへの移行をさらに簡単にします。

Veeam Backup and Recoveryは、古いオンプレミス・バックアップをコピー・ジョブでクラウドに移動するように自動的にスケジュールすることができます。このセット・アンド・フォーゲット機能は、オンプレミスシステムが常に利用可能なディスクスペースを維持し、最高のRTOのためにリストアパフォーマンスを最大化することを保証します。また、バックアップをローカルストレージとクラウドに同時に送信するように設定することもできます。これにより、オフサイト・バックアップが劇的に簡素化され、3-2-1-1-0ガイドラインに準拠することができます。

Veeam Backup and Replicationは、異なるクラウド・オブジェクト・ストレージ・レポジトリ間のデータ移行をサポートします。例えば、AWS S3を使用していたが、Wasabiホット・クラウド・ストレージに変更することを決定したとします。この機能を使えば、AWSからWasabiにデータを移行することができます。

非構造化データの保護を簡素化

WasabiはVeeam Ready Objectとして、またVeeam Ready Object – Object Lockとして認定されています。Wasabiは現在、Veeam Backup and Recoveryの名前付きクラウドストレージサービスです。

Wasabiホットクラウドストレージが画期的な経済性とデータセキュリティを実現

Wasabiホットクラウドストレージは、低コスト、高速、信頼性の高いクラウドストレージをオンデマンドで提供します。Wasabiは、全てのデータを「ホット」に保ち、数ミリ秒でアクセスできるようにします。すべてのVeeamとWasabiのユーザは、データをホットデータとして扱うことができるため、バックアップウィンドウを短縮し、データに素早くアクセスして、リストア時間を短縮することができます。

仮想マシン名に日本語が含まれている影響で、バックアップやリストア中に予期せぬ動作を引き起こす可能性があります。
※例えば、38文字以上のVM名（日本語）の VMからファイルリストアを行う際に失敗する可能性があります。

そのため仮想マシン名やネットワーク名等はなるべく英数字での記載をお願いいたします。

Hyper-V上の仮想マシンに接続されたパススルーディスク（物理ディスク）のバックアップおよびレプリケーションはHyper-V側の制約により行うことができません。処理はスキップされます。
仮想ディスク部分は正常に処理されます。

はい、可能です。

VMware 5.5 Update 2以降でしたら、継続して差分バックアップを行うことが可能です。

それ以前のバージョンですと、VMwareの制限に引っかかり、CBTがリセットされてしまいます。
■ Change Block Tracking が vSphere 5.x でのストレージ vMotion 操作の後でリセットされる

関連トピック
バックアップ対象の仮想マシンをStorage vMotionで移動する際にスナップショットエラーは発生しますか?
バックアップ対象の仮想マシンをStorage vMotionで移動した後、バックアップジョブを作り直す必要がありますか？

Veeamはバックアップの際にスナップショット機能を利用します。そのためこの機能が利用できない物理モードのRow Device Mappingではバックアップが行えません。
またリストアやレプリケーションの際に作成するVMにつきましてはThickもしくはThinディスクでの作成が可能です。

はい、引き継げます。
Veeam Backup & Replicationの設定情報はSQL Serverに保存されているため、既にあるVeeam Backup & Replicationのインスタンスを再利用することで設定情報等の引き継ぎが行えます。
しかしバージョンアップに伴い表の構造等が変更されますので、基本的には同一バージョンもしくは上位のバージョンでのみ再利用が可能です。古いバージョンを再インストールした際に、インスタンスの再利用が行えない場合もございますので、お気をつけください。

はい。Veeam Backup & Replication は、Hyper-V のすべてのバージョンをサポートします。

技術的にはVeeam Backup & Replication（Veeam B&R）とvCenter Serverを同じWindowsマシンに導入することは問題ありません。
しかし、この２つのソフトウェアを同居させることは推奨しておりません。
理由として以下の3点があげられます。

• 双方ともにリソースを消費しやすいソフトウェアであり、リソースの適切なプロヴィジョニングが難しいこと
• 片方に障害が発生しマシンの再起動が必要となった場合、もう片方の動作に影響をおよぼすこと
• 双方ともにデフォルトのインストールではSQL Server Express Editionをインストールし使用しますが、Express Editionは使用可能なリソースに制限が加えられており、VeeamとvCenter双方からの激しいアクセスに耐え切れず双方の挙動に影響を及ぼすことがあること

これらの理由のため、可能であれば別々のマシンにインストールしていただくことを推奨しております。

基本的にはどちらも同様に使用できます。
しかし、仮想マシンでは物理接続のデバイスが使用できません。
また、Veeamサーバの負荷がホストにも影響します。

Veeam Backup & Replicationと同じライセンスを使用します。

Enterprise Managerについてはコチラ

Contract No.はユーザがVeeam/クライムとのサポート・保守に加入した最新（または最後）の追跡番号です。
この番号はユーザのライセンス・ポータルでも確認することができます。
サポート・保守更新時には必ず必要になりますので、Contract No.をお問合せください。
サポート・保守が更新されますと、暫くした後、新たなContract No.がアサインされます。
以前のContract No.では追跡ができなくなります。

仮想マシンの電源ON/OFFの違いやOSの違いによるバックアップの可/不可はありません。
また、OSをインストールしていない状態の仮想マシンであってもバックアップ可能です。

関連トピック

Linux系のOSの仮想マシンのバックアップは可能ですか？

OSをインストールしていない、又はVMDKファイルなしの仮想マシンをバックアップできますか?

Veeam Backup & Replicationサーバは仮想または物理環境のどちらでもインストール可能です。
自身のバックアップについては接続情報や構成情報のみであればConfiguration Backup機能でバックアップ可能です。
https://www.climb.co.jp/blog_veeam/veeam-backup-7953

OSのイメージごとバックアップする場合は、仮想マシンにインストールしていればVeem自身でバックアップ可能です。
物理環境にインストールした時にはVeeam Agentを導入することでバックアップが可能です。

Windows Storage ServerとWindows Serverは同じコードを元に構築されているため、基本的には全てのVeeamのコンポーネントをStorage Server OS上にインストール可能です。
Veeam Server console
Veeam Backup Proxy
Vpower NFS server
WAN accelerator
Backup repository

しかし、Windows Storage Serverはベンダーによってカスタマイズされていることが多く、.NETの機能が有効化されていない場合や.NET Frameworkのインストールに問題がある場合があります。このような場合にはVeeam ServerのGUIは.NETコンポーネントに依存しているため、インストールすることができません。

.NETコンポーネントについてWindows Storage Serverのエンドユーザライセンス(EULA)のご確認やベンダーへのお問い合わせをお願いいたします。
EULAのパス　C:\windows\system32\license.rtf
開発元KB http://www.veeam.com/kb1923

はい、対応しています。

サポートするプラットフォームについてはこちらをご参照ください。

スタンドアロンのvSphereホストの登録が可能なので、必須ではありません。
vCenter Serverを登録しておくと、VMwareのHAやDRSで仮想マシンが移動した場合も、
移動先を追跡しJobの継続実行が可能です。

必須ではございません。
ただし、Veeamとの連携機能は使用できないため、通常の重複排除ストレージとして使用します。
その場合には、リポジトリの種類は「Dedupe Storage」ではなく、「CIFS」として登録します。

Veeam Backup & Replication Ver8からQuick Rollbackという機能が追加されました。
これは差分データ・リストア機能です。

このQuick Rollback機能の使用制限：
1. Network または Virtual Appliance モードのみで使用可能。VMwareサイドの制限でDirect SAN Accessモードでは使用できません。

2.続けて2つの差分リストア・セッションを実行することは出来ません。VMまたはVMディスクに対して差分リストアを実行した後にそのVM上のCBTはリセットされます。差分リストアが再度実行できるように最低1回の差分バックアップを実行する必要があります。

使用できません。
古いバージョンから新しいバージョンへアップグレードした際には、
そのままバックアップファイルを使い続けることが可能ですが、
新しいバージョンのファイルを古いバージョンで扱うことはできません。

可能です。
その他対応しているファイルシステムの詳細は下記弊社ブログ記事をご覧ください。
Veeamのファイルレベルリストアはここが違う！多くのファイルシステムをサポートできる理由とは？

IDEとSCSIが混在しているVMの場合、すべてのディスクでVirtual Applianceモードが使用できないのは仕様となります。

バックアップ処理が開始される前にすべてのディスクをチェックしており、一つでもHotAddが使用できないディスクがあるとすべてのディスクがNetworkモードで処理されるようになっています。これはVDDKの制限です。

回数に制限はありません。

仮想マシンのディスクタイプにはシンプロビジョニングとシックプロビジョニングがありますが、
それぞれに必要なディスクスペースに違いがあります。
これはシンとシックではストレージ領域の確保方法に違いがあるためです。

シンプロビジョニングで作成した仮想マシンの場合は
ストレージ領域が必要になるごとに領域を確保するため、
レプリケーション元の仮想マシンで使用済みのディスクサイズ分の
フリースペースがレプリケーション先に必要です。

シックプロビジョニングで作成した仮想マシンの場合は
仮想マシン作成時に指定したサイズ分の領域を確保するため、
レプリケーション元の仮想マシン全体のディスクサイズ分の
フリースペースがレプリケーション先に必要です。

サポート期間内の場合、無償でバージョンアップをお客様自身で行うことができます。
また、弊社でもバージョンアップ作業(有償)を行っています。

VMwareとHyper-Vではアーキテクチャが異なるため、完全に同等とまではいきませんが、ほぼ全ての機能を1つの統合されたコンソールから利用可能です。

ソフトのメニュー類は日本語には未対応です。
しかし、直観的なクリック操作で簡単に扱える製品となっておりますし、
日本語の製品マニュアルもご用意しておりますので使用には問題ありません。

■Commit Failback
レプリケーション先の VM をレプリケーションジョブを実行できる状態(“Failover” を実行する前の状態)にします。

■Undo Failback
レプリケーション先の VM を “Failback” を実行する前の状態(“Failover” を実行している状態)に戻します。

どちらもレプリケーション先の VM の状態を変更する機能です。
そのため、”Undo Failback” を実行した場合でも、
レプリケーション元の VM は変更が反映された状態(“Failback” 実行後の状態)のままになります。

はい、行っております。

無料相談窓口：03-3660-9336

別途オプションで、弊社にて設計、インストール、設定等の支援も行っております。

詳しくはこちら

可能です。
当然ながら、各ジョブのリストアポイントはレプリケーションジョブを実行したタイミング(レプリカへ本番機のデータをコピーしたタイミング)のものになりますが、レプリカのほうからバックアップ、レプリケーション、フェイルオーバーなどが実行できます。

ただし、本番機への切り戻しは行えませんので、以降はレプリカを本番機として使用する必要がございます。

はい、含まれます。
サブスクリプションライセンス期間内は保守サポートのご利用が可能です。

Veeamのコンソール画面からジョブを右クリックして “Statistics” を開きます。
“Action” ログの中に “Changed block tracking is ～” と書かれており、有効化されていれば “enabled”、無効化されていれば “disabled” となります。

ジョブ実行前からゲストOSにスナップショットが存在するなどの理由で、CBTが有効にできなかった場合、ジョブ終了後にワーニングとして表示されます。

オリジナルの仮想マシンとレプリカの仮想マシンをマッピングすることで、
差分レプリケーションからジョブを開始することができます。

参考: レプリカシーディング・レプリカマッピング機能について

関連トピック

レプリケーションしたいVMのクローンVMを利用して初回のフルレプリケーションを行わず、差分レプリケーションを行えますか？

最新バージョン以外の古いバージョンのサポートも承っております。
しかし、開発元(Veeam 社)の正式サポートは最新バージョンとその1つ前のバージョンまでとなります。(例:2022年1月現在のVeeam Backup & ReplicationのバージョンはVer11.0、10.0、9.5、9.0、8.0、7.0、6.5…と存在していますが、このときの正式サポート対象はVer11.0、10.0 となります。)
そのため、古いバージョンの場合、いただいたご質問の内容によっては開発元からのサポートを受けられず、アップグレードをお願いすることになりますので、ご了承ください。

ジョブ実行後、スナップショットが作成され、それを元にバックアップを取得します。

そのため、スナップショットを作成した時点の状態でバックアップファイルは作成されます。

サブスクリプション（年額前払）形式となります。
1ライセンスにつき10個まで以下対象を保護できます。
●1仮想マシン（vSphere/Hyper-V/AHV）
●1物理サーバ（Windows/Linuxなど）
●1クラウドインスタンス（AWS/Azure/GCP）
●500 GB分のNASデータ

※Veeam Backup Essentials の場合
1ライセンスで5台（1環境につき50台の制限）

詳細はこちら

Veeamではプロキシサーバ(デフォルトではVeeamをインストールしたサーバ)で重複排除や圧縮を行ったあと、リポジトリ(バックアップ保存先)に転送して保存されます。そのため、直接ではなくプロキシサーバを経由することになります。

スクリプト終了時に返される終了コードでスクリプトの成功、失敗を判断しています。

終了コードが0以外の場合は静止点の作成に失敗したものとして、スナップショットの取得に失敗します。

可能です。
Veeamでは圧縮率に関するオプションが用意されており、
バックアップジョブごとに設定が可能となっております。
対象のジョブを右クリック > Edit > Storage > Advanced > Storage

■Failover
ターゲットホストのレプリカVMを起動する機能です。
オリジナルのVMに障害が発生した場合に、レプリカ VM で処理を引き継ぎます。

■Undo Failover
Failover機能により電源ON状態となったレプリカVMを電源OFF状態に戻す機能です。
レプリカVMへ行われた変更は破棄されます。

Veeamには3つの処理モードが用意されております。

・ダイレクトストレージアクセスモード
・バーチャルアプライアンスモード
・ネットワークモード

参考

バックアップ、レプリケーション時の処理モードX 3
VMware環境での3つの転送モード方式と処理の流れ
処理モードの中では一番の高速バックアップ【Veeam Backup & Replication：Direct SANモード】
手間とコストをかけずに簡単に高速バックアップ【Veeam Backup & Replication：Virtual Applianceモード】
特別な条件の必要ない簡単・確実なバックアップ【Veeam Backup & Replication：Networkモード】

バックアップ時、リストア時にどの条件を満たしているかによって処理モードが変更されます。
しかし、リストアの場合は処理モードがVirtual ApplianceモードとNetworkモードのみ使用可能となっております。

関連トピック
VMwareのHot add機能を利用したバックアップは可能か？
SAN内の仮想マシンを別のSANにバックアップする際にモード選択でSANモードで処理可能か？

Veeamでバックアップを取得するためには仮想マシンのスナップショットが取得できる必要がございます。そのため、スナップショットをサポートしていない物理互換のRDMはバックアップが行えませんが、仮想互換のRDMであればバックアップを取得可能です。

Veeamでは仮想互換のRDMであればバックアップ/リストアが可能です。
仮想マシンのバックアップを取得時にRDM領域はvmdkファイルに変換されます。そのため、リストア時にはRDM領域はvmdkファイルに置き換えられてリストアされます。

カタログファイルの保存先はWindowsの共有設定が行える必要がございます。そのため、ネットワークドライブなどは指定するとインストール中にエラーとなり、インストールが終了できません。

これは、複数ジョブを実行するためのリソースが不足しているため、処理中のジョブが終了し、リソースが解放されるまで待機状態になっていることを表しています。

そのため、複数のジョブを同時刻に実行したいということであれば、ジョブごとにプロキシサーバ(処理サーバ)を用意していただくか、プロキシサーバのスペックをあげていただく必要がございます。デフォルトではVeeamサーバがプロキシサーバとして動作します。

参考
プロキシサーバの同時実行タスク数について

Veeamには2つのバックアップモード(増分・差分)があり、増分バックアップであれば実行中にもバックアップ可能ですが、差分バックアップの場合は行えません。

差分バックアップは毎回フルバックアップファイル(vbk)に差分をマージするのでvbkに書き込みを行います。しかし、インスタントVMリカバリではバックアップファイルから直接仮想マシンを作成するため、フルバックアップファイル(vbk)をロックします。そのため、vbkに書き込みが行えずエラーとなります。

増分バックアップでは増分ファイル(vib)の作成は行いますが、vbkに対して書き込みを行わないためバックアップ可能となります。しかし、バックアップファイルの変換オプション(Transform previous full backup chains into rollbacks)を有効にした場合は、増分バックアップは問題ありませんが、フルバックアップ時には増分ファイルを差分ファイルへ変換する処理が入りますので、ファイルがロックされるインスタントVMリカバリ中にフルバックアップは行えません。

バックアップ先ストレージとして利用可能なのはWindows、Linux、共有フォルダとなっています。
登録可能なデータ保存先(リポジトリ)

ESXにはLinuxをベースとした管理用OSが搭載されているため、Linuxのバックアップ先ストレージとして利用可能でした。

しかし、ESXi(vSphere5.1)はこの管理用OSを削除しており、直接バックアップ先ストレージとして利用できなくなっております。そのため、vSphere5.1上に仮想マシンを登録し、その仮想マシンをバックアップ先として利用する必要があります。

Enterprise / Enterprise Plusエディションで可能です。
通常のVeeam Backup & ReplicationコンソールとEnterprise ManagerのWebコンソールから行えます。
しかし、Standardエディションでは対応しておりません。

制限はありません。
ジョブを実行するプロキシサーバの性能に依存します。
おおよそ、1タスクに1CPUです。

はい、行えます。
Veeamではプロキシ – プロキシ間、プロキシ – リポジトリ間で帯域制限を行います。
そのため、vSphereホストからバックアップを行う際にネットワーク経由で以下のように処理を行っておりますと、vSphereホスト – プロキシ間では帯域制限は実施されず上限までネットワークを使用します。プロキシ – リポジトリ間では帯域制限が実施されます。
例) vSphereホスト – プロキシ – レポジトリ

VeeamサーバをVMware FT構成にすることは、基本的には問題ありません。

しかし、いくつか注意点がございます。

1．Veeamのコンソールとして使用するのは問題ないですが、プロキシとして使用するのは非推奨となります。もし、Virtual Applianceモードでバックアップを実行していた場合、処理途中で仮想マシンが切り替わるとVirtual Applianceモードが動作しなくなります。

2．バックアップ保存先への接続はNASかCIFSを使用する必要があります。Veeamサーバに直接接続されたディスクを使用すると、切り替わった際に機能しなくなります。

テープ・ライブラリ・コンパチブル・リスト（Unofficial）

ADIC Scalar 100

Dell PowerVault 124T
Dell PowerVault 136T
Dell PowerVault TL2000

FalconStor (VTL) [VERIFIED]

Fujitsu Eternus LT40

HP ESL 712e
HP MSL G3 Series 4048
HP MSL G3 Series 8096
HP MSL 6030
HP MSL 6480
HP StorageWorks 1/8 G2 LTO-3 Ultrium 920
HP StorageWorks LTO-4 Ultrium 1840 SCSI
HP StoreOnce (VTL) [MSL series emulation]

IBM TS3100
IBM TS3200
IBM TS3310
IBM TS3500
IBM ProtectTier 7650 (VTL)
IBM ULTRIUM HH5 SCSI

Overland NEO 100s [VERIFIED]
Overland NEO 200s [VERIFIED]
Overland NEO 400s [VERIFIED]
Overland NEO 2000e [VERIFIED]
Overland NEO 4000e [VERIFIED]
Overland NEO 8000e [VERIFIED]

Quantum Scalar i40
Quantum Scalar i80
Quantum Scalar i500
Quantum Scalar i6000

QUADStor (VTL) [IBM TS3100/3580 emulation] [VERIFIED]

Qualstar RLS

Spectra Logic T50e [Quantum P7000 emulation]

Tandberg T24 [VERIFIED]
Tandberg T40+ [VERIFIED]
Tandberg T80+ [VERIFIED]
Tandberg T120+ [VERIFIED]
Tandberg T160+ [VERIFIED]
Tandberg RDX Quikstation (VTL) [T80+ emulation] [VERIFIED]

mhVTL (VTL) [64KB block size] [VERIFIED]

プロキシはVeeamのライセンスに依存せず、台数制限もございません。

バックアップジョブにvCenter経由で仮想マシンを登録していれば、Veeamは仮想マシンに割り振られた参照IDを追跡しますので、ジョブの作り直しは必要ありません。
参考： vMotionやStorage vMotionに対応したジョブの作成

しかし、Storage vMotion実施後は仮想マシンのCBTがリセットされるため、実施後最初のバックアップはフルバックアップになります。
参考： Change Block Tracking is reset after a storage vMotion operation in vSphere 5.x

関連トピック
バックアップ対象の仮想マシンをStorage vMotionで移動する際にスナップショットエラーは発生しますか?
バックアップを取得している仮想マシンのデータストアを、ストレージvMotionで別のデータストアに移動した場合、差分バックアップを継続できますか？

Veeamの並列処理が利用可能なジョブは、バックアップジョブとレプリケーションジョブ、バックアップコピージョブとなりますが、WANアクセラレータを使用したバックアップコピージョブは逐次処理になります。

※バックアップコピージョブが並列処理になったのはver9.0以降になります。

自動リトライを設定している場合、通知メールはジョブがSuccess/Warningになるか、指定回数分のリトライ処理が終わった時にまとめて送信されます。

通知されません。
通知メールはリトライも含めた最終的なジョブ結果に基づいて送信されますので、リトライの結果、ジョブがSuccessになれば通知されません。

バックアップデータからは、下記リストアが可能です。
・新規の仮想マシンの作成
・VMDK、VMX等の仮想マシンの構成ファイルのリストア
・Amazon EC2やAzure VMとしてクラウド環境へ仮想マシンをリストア
・ファイルレベルのリストア
・一部アプリケーションのアイテム
Active Directory、SQL Server、Exchange など
※Standardエディションでは制限がございます。
https://www.climb.co.jp/soft/veeam/outline/price.html#price02
https://www.climb.co.jp/soft/veeam/detail/restore.html#detail4

関連トピック
レプリケーションデータからのリストアでできることは何ですか？

影響ありません。
問題なくバックアップ、リストア、レプリケーション等を行えます。

レプリケーションデータからは、下記リストアが可能です。
・レプリケーション（複製）した仮想マシンの起動
・ファイルレベルのリストア
・一部アプリケーションのアイテム
Active Directory、SQL Server、Exchange など
※Standardエディションでは制限がございます。
https://www.climb.co.jp/soft/veeam/outline/price.html#price02
https://www.climb.co.jp/soft/veeam/detail/restore.html#detail4

関連トピック
バックアップデータからのリストアでできることは何ですか？

サポートしています。
但し、VeeamサーバをWindows Server 2012以降で構築する必要があります。

はい、可能です。ただしディスク交換後の初回のバックアップはフルバックアップを行う必要があります。

ジョブごとにバックアップで1～999世代、レプリケーションで1～28世代取得可能です。

重複排除率や圧縮率は細かい値が丸められているため、計算した場合多少の誤差が発生します。

【バックアップ】
ディスクサイズが変更されたことによりCBTがリセットされます。
そのため、変更後最初の一回は全データを読み込むことになります。
二回目以降は差分でのバックアップが可能です。

【レプリケーション】
既存のリストアポイントがすべて削除され、
新たなリストアポイントが作成されます。

MACアドレスが動的から静的に変更されるのは、Veeam B&Rの仕様になります。
ソースマシンのMACアドレスを保持するために静的に変更しています。

Veeam自身はSMBに関する機能は持っておらず、インストールされているWindowsのSMB機能を利用します。
そのため、使用するSMBのバージョンはVeeamがインストールされているWindowsのバージョンおよびデータ転送先のデバイスの対応状況に依存します。

バージョン7.0のパッチ2（R2）より、レプリケーション中に、ソースとターゲットのサイト間のネットワーク接続が切断されたとき、ソースとターゲットのプロキシサーバの再接続を試行し、レプリケーションを途中から再開する機能が追加されています。
デフォルトでは切断から５分の間、１０秒ごとに接続のリトライを行います。
この時間を過ぎますと、エラーとなります。

Backup Job作成時に「Backup Mode」がIncrementalモードで、「Synthetic full」が有効になっている場合、設定した世代数をキープするため、設定したリストアポイント数より多くのリストアポイントが作成されます。
※バージョンによっては”Restore points to keep on disk”と表記されております。

参考:
増分・差分による保持するバックアップファイルの違い
世代を管理するバックアップチェーン
バックアップモードによる保持するバックアップファイルの違い【Veeam Backup & Replication】

はい。バックアップ可能です。

関連トピック
バックアップ対象の仮想マシンについて、OSの違いによるバックアップの可/不可はありますか？また、仮想マシンの電源ON/OFFの違いによるバックアップの可/不可はありますか？
Linux系のOSの仮想マシンのバックアップは可能ですか？

はい、設定可能です。スケジュール設定画面にてPeriodically every(定期的)の時間を設定すると、指定時間毎に動作します。

参考
Job作成時のスケジュール(除外設定機能)について【VMWare専用 バックアップ & レプリケーションソフト Veeam】

はい、可能です。下記の単位でのバックアップが可能です。
・クラスタ
・フォルダ
・リソースプール
・Virual App
・ホスト
・ユーザーが選択した仮想マシン

Veeamはテープへの2次バックアップをサポートしております。
一度ディスク上にバックアップしていただき、そのバックアップファイルをテープへ2次バックアップします。

可能です。

参考:
手間とコストをかけずに簡単に高速バックアップ【Veeam Backup & Replication：Virtual Applianceモード】
Virtual Applianceモードのチェックリスト【Veeam Backup & Replication】

関連トピック
リストア時の処理方法について教えてください。

どちらもSQL Serverを使用するため、SQL Serverへの負荷が高くなり、それによってバックアップジョブへ影響が出る可能性もございます。特にデフォルトでは、Expressエディションがインストールされるため、影響が出やすいかもしれません。

はい、可能です。
参考:
VMware vSphere環境でLANフリーバックアップをDirect SANアクセスモード[Veeam Backup & Replication]
処理モードの中では一番の高速バックアップ【Veeam Backup & Replication：Direct SANモード】
Direct SAN accessモードのチェックリスト【Veeam Backup & Replcation】

関連トピック
リストア時の処理方法について教えてください。

はい、可能です。

自動で起動させる機能はありません。VeeamコンソールもしくはvSphere (Web) Clientから手動でのフェイルオーバーが必要です。

関連トピック
レプリケーション後のレプリカVMの起動をvSphere Clientから行いたい。

Veeam Backup & Replicationではバックアップ先のディスクの空き容量が設定した容量より少なくなった際に警告を表示します。
デフォルト設定では、空き容量が10％以下になった場合、警告を表示します。

また、バックアップ先のディスクの空き容量が設定したしきい値よりも下回った場合、VMのスナップショット取得の処理を行わずにジョブを終了させる設定もございます。
※デフォルト設定では、しきい値は5％となっております。

この設定はVeeamの管理コンソールから「Options」>「Notifications」タブで設定可能です。

可能です。スケジュール設定時に “After this job” を選択してください。

指定したジョブ終了後に作成したジョブを実行します。

Job作成時のデフォルト設定のままで2回目以降が差分処理になります。

これはJobを常に実行し続けます。Jobが終了するとすぐにJobを開始するという機能です。
仮想マシンのバックアップまたはレプリケーションをできる限り最新の情報を取得したい場合に使用するモードですが、常に動作しますので、リソースや容量に注意が必要です。

はい、設定可能です。

Replication Job設定時にレプリカVMのネットワーク設定を行うことができます。

SSLで暗号化しています。

はい、設定可能です。スケジュール設定画面にて Daily at this time を on week-days と設定すると、平日のみ動作します。
また、on these days にて任意の曜日を選択することも可能です。

はい、設定可能です。スケジュール設定画面にてPeriodically every(定期的)の設定で除外時間設定ができます。

はい、バックアップ可能です。
但し、アプリケーション側で制約がある場合、リストアした際、不具合が発生する可能性があります。

はい、バックアップ、レプリケーション時は処理終了後、コマンド実行することができ、別の処理を行うことが可能です。

はい、可能です。ディスクの作り方によって2TBを超える仮想マシンのバックアップ、レプリケーションを行うことができます。
詳しくはブログへ記載してあります。 ≫

はい、可能です。

関連トピック

Job作成時のオプション “Enable application-aware image processing” はどんな機能ですか?

はい、可能です。
任意の時点のスナップショットに戻してからレプリカVMを起動してください。

しかし、vSphere clientから起動することでVeeamから管理を行うことができなくなり、Failback(オリジナルへの切り戻し)が行えなくなります。プライマリサイト復旧後は、新規にレプリケーションジョブを作成してDRサイト⇒プライマリサイトの方向にレプリケーションを行う必要があります。レプリカVMを停止することでまたVeeamから管理することが可能になりますが、レプリカVMに対して行われた変更は反映されません。

はい、可能です。但し、同じ仮想マシンに対して同時に複数の処理を行うことはできません。
また、レプリケーションジョブ実行中に処理中のレプリカVM起動(Failover to Replica)やSureBackupで実行中のバックアップジョブを指定して実行するようなこともできません。

ソースVMが静的IPアドレスで設定されている場合、同じIPアドレスで複製のVMが作成されます。
レプリケーションジョブのオプション機能で、ジョブ作成時に複製VMのIPアドレスを指定することも可能です。

仮想マシンのサイズや変更分に影響し、指定したリストアポイント数分差分ファイルを作成します。

可能です。

例)起動中のJob(A)をユーザーが停止後にJob(A)を再開した場合にはJob(A)が正常終了して作成しているバックアップファイルからの変更部分(増分、差分)のバックアップファイルを作成します。

関連トピック

Backup Jobを一度ユーザが手動で停止してもJobを再実行することで継続して使用できますか?

Veeamは仮想ディスク単位で並列処理が可能なため、プロキシサーバを増設したり、プロキシサーバの性能を上げることで、同時に処理するVM数を増やすことが可能になるので、処理速度の向上が望めます。

はい。Jobをユーザが手動で停止してもJobを再度実行することで再利用可能です。

関連トピック

起動中のバックアップJobをユーザー側で停止後にJobを再開させることは可能ですか?

スナップショットはリストアできません。
バックアップ・レプリケーションではスナップショットの構成や情報を保持しているわけではないため、スナップショットの情報は保持されません。

VMwareのStorage vMotionを実行する条件の1つに｢仮想マシンがスナップショットを保持していないこと｣があります。

Veeam Backup & Replicationではバックアップ時に処理対象の仮想マシン内にスナップショットを取得しますが、処理の最後にスナップショットを削除します。
※Veeamの処理中(仮想マシンにスナップショットが残っている時)にStorage vMotionが実行された場合にはStorage vMotionは失敗します。

CBT機能を無効にした場合、前回のバックアップからの変更箇所を追跡できないため、毎回VMの全データを読み取る必要があります。

デフォルトでは53週間(1年間)保持します。コンソールから変更可能です。

仮想環境から削除された仮想マシンを、バックアップデータ内で保持する期間の設定です。
VM削除時のバックアップファイル自動削除機能

※バージョンによっては、”Deleted VMs data retention period”と表記されております。

開発元ドキュメントをご参照ください。

使用ポート

ございます。弊社ブログをご参照ください。
参考:
VBRCatalogフォルダの変更方法【Veeam KB】
How to Move the VBRCatalog Folder

｢Enable VMware Tools quiescence｣を有効にするとVMware Toolsの静止点作成機能を使用します。アプリケーションレベルでの静止点作成には向いていませんがVMware Toolsの静止点作成機能では静止点作成時に仮想マシン内にユーザが配置したbatファイルを実行可能です。

■参考ブログ
Windows OSのオンラインバックアップ手順【Veeam Backup & Replication】
※方法②カスタムスクリプトを利用したオンラインバックアップをご参照下さい。

オプション｢Enable application-aware image processing｣を有効にしてJobを実行するとVeeam独自にカスタマイズした方式でMicrosoftのVSSを利用してアプリケーションレベルでの静止点作成処理を行います。

しかし、Linuxや下記WindowsはMicrosft VSSをサポートしていません。
・Windows 95　・Windows 98　・Windows NT
そのため、静止点を取得する際にはカスタムスクリプトを使用していただく必要があります。

■技術ブログ
Windows OSのオンラインバックアップ手順【VMWare専用 バックアップ & レプリケーションソフト Veeam】
batと連携しての仮想マシンのバックアップ手順(MySQLの起動・停止)
オンラインダンプを使った仮想マシンのバックアップ方法【Veeam Backup & Replication】

関連トピック

Job作成時のオプション “Enable guest file system indexing” はどんな機能ですか?
Veeam静止点処理において必要な認証情報をVM個別に指定する方法はありますか？

｢Enable guest file system indexing｣を有効にした場合、Veeam Enterprise ManagerでWebブラウザからファイルレベルリストアが可能です(Enterpriseエディション機能)。
 

■技術ブログ
Backup Searchの紹介【VMWare専用 バックアップ & レプリケーションソフト Veeam】

VeeamのJobを実行するスクリプトをWinodws Serverの｢タスク スケジューラー ｣から実行することを特定の日付や月末のタイミングにVeeamのJobを起動可能です。

■タスク スケジューラー画面

上限はありません。

ジョブの管理は管理サーバーで行われるため、プロキシ間でジョブの情報等は同期されません。

上限値はありません。

しかし、ホストはライセンスの CPU 数に依存します。

増分バックアップから差分バックアップに、差分バックアップから増分バックアップにモードを変更するかによって、バックアップファイルの保持のされ方が異なります。
弊社ブログをご参照ください。
参考: ジョブ設定変更後のバックアップファイルの変化

ジョブ設定時を基準とし、一定間隔後、リソース収集を行った後に1回目のジョブが開始します。2回目のジョブは1回目のジョブ開始時から一定間隔後リソース収集を行った後に開始されます。

はい、ございます。下記フォルダにあるVeeamBackup.mibをご利用ください。
—–
C:\Program Files\Veeam\Backup and Replication\Backup
—–

いいえ、使用できません。
既存のジョブにバックアップ対象の仮想マシンを追加しなおすか、
新規にジョブを作成する必要があります。

VMware HA構成のバックアップは可能です。
バックアップにはスナップショットが必要なため、スナップショットが利用できないVMware FT構成の場合、バックアップは行えません。
しかし、vSphere 6.0からはVMware FT構成のVMもスナップショットが利用できるようになったため、バックアップを取得可能になりました。

はい、対応しています。

サポートするプラットフォームはこちらをご参照ください。

はい、対応しています。

サポートするプラットフォームはこちらをご参照ください。

Standard、Enterprise、Enterprise Plusのエディションによって、利用できる機能が異なります。

詳細はこちらをご参照ください。

システム要件をご参照ください。

関連トピック
Veeam Backup & ReplicationをLinux系OSにインストール可能ですか?

いいえ、ユーザがESX(i)、仮想マシンにエージェントを導入する必要はありません。

はい、設定できます。時間指定、曜日指定、月指定の他、指定時間毎や指定日（第1週の水曜日等）の設定が可能です。また、除外設定も可能です。

はい、使用することができます。
Veeam Backup & Reokicationのレプリケーション機能を使用することで障害復旧が可能です。

例)ESX(i)(A)で障害発生時にESX(i)(B)にレプリケーション(複製)しておいた仮想マシンを電源ONすることで復旧
※レプリケーション(複製)しておいた仮想マシンを電源ONする作業はユーザーがマニュアルで行う必要があります。
ディザスタリカバリ構成について ≫

はい、可能です。(Windows系、Linux系、Macに対応しています。)
ファイルレベルリストアでサポートしているファイルシステム >>

バックアップ先には、Veeam Backup & Replicationインストールサーバ、接続しているESX(i)のローカルディスクが選択できます。
また、SAN、NAS、DAS、Linuxサーバもバックアップ先に選択可能です。

さらに、2次バックアップ先としてテープデバイスやクラウドをバックアップの保存先として指定することが可能です。

関連トピック
サポートするバックアップ保存先

VMware vSphere Hypervisor（ESXi無償版）は使用できません。
VMware vSphere EssentialsやVMware vSphere ESX(i)へアップグレードが必要となります。導入前の評価を行いたい方はVMware vSphere評価版をお使いください。

はい、可能です。
他にはWindows、Unix、FreeBSD、Solaris、MacOSがバックアップ可能です。

関連トピック
バックアップ対象の仮想マシンについて、OSの違いによるバックアップの可/不可はありますか？また、仮想マシンの電源ON/OFFの違いによるバックアップの可/不可はありますか？
OSをインストールしていない、又はVMDKファイルなしの仮想マシンをバックアップできますか?

Veeam Backup Enterprise Managerを使用することで、ユーザはWEBブラウザから複数のVeeamインストールマシンで作成したJobの管理(Jobの起動、停止)が可能です。
また、リストア可能なユーザを制限できるリストア委任オプションなどを行うために必要です。
参考: Veeam Backup Enterprise ManagerによるVeeam Backupサーバの統合管理

評価用ライセンスキーが発行されてから30日間となります。

30日間の評価用ライセンス期間終了後、機能が制限されたCommunity Edition（無償版）に切り替わります。

はい、ご利用いただけます。
質問の内容により、お時間を頂く場合がございます。
予めご了承ください。

お問合せフォームはこちら

評価版に機能制限はありません。
Veeam Backup & Replicationの全機能を30日間無償でご使用いただけます。

下記の環境をご用意ください。

1.VeeamBackupインストール用のWindows系サーバ(仮想マシンでも可)
2.機能を試用したいバックアップ対象（VULの保護対象）
※インストールするサーバについては、システム要件をご確認ください。

評価版ダウンロードの流れはコチラをご覧ください。

弊社営業時間内(10:00～18:00)となります。

プロダクションサポートの場合、
弊社営業時間外はメーカーの英語サポートのみとなります。

Veeam Backup & ReplicationはWinodws系OSにのみインストール可能です。
Veeamインストール先環境（ソフトウェア）

関連トピック
Veeam Backup & Replicationのインストール要件は？