このテキストを書くとき、著者は次のキーポイントに導かれました：
0.尊敬される経験豊富な同僚の多くにとって、これはすべて小さく、注目に値しないように思われます。 Facil omnes、cum valemus、recta consilia aegrotis damus。
1.一部ではありますが、少人数ではありますが、尊敬されていない経験豊富な同僚が役に立つ/必要/興味深いでしょう。
2.立っているときや歩いているときに患者の体重を維持するためのデバイスのヒントは、回避策であり回避策であるため、存在する権利があります。
3. Googleが知らないか、見た目が悪い。 しかし、正直に試してみました。
4.最初に似たようなものを書く経験、したがってテクスチャの塊。
挨拶、著名なコミュニティ。
前文
当社のインフラストラクチャには、Veeam B＆Rサーバーの3つの並列ブランチがあります。 ブランチは、事実上すべてのインシデントを説明したいように、「歴史的に形成された」ものです。
1つは、合併後に残されたゆっくりと落ちてくる仮想化ファームのバックアップジョブを提供します。
2つ目は、Veeam B＆Rのパイロット実装で、スムーズに産業用ソリューションになり、現在、vSphere 4.1仮想化ファームのバックアップおよびレプリケーションジョブ（はい、まだ運用中、申し訳ありません）およびvSphere 5.5仮想化ファームのバックアップジョブを提供しています。
3番目は、vSphere 5.5仮想化ファームのレプリケーションジョブとフェイルオーバープランのみを提供します。
これらはすべて、活発で継続的な移行のプロセスにあります。
過去5年以上にわたり、VMware vSphere、Veeam B＆R仮想化、およびWintelサーバーのメイン管理者として、このすべての資産を管理できたことは、私にとって名誉であり幸せでした。
+バックアップ管理者の役割について同僚がいます。
Veeam B＆Rツールを使用した仮想サーバーのレプリケーションに基づくDRソリューションのテストの最近の準備中に、バックアップおよびレプリケーションジョブを構成する仮想サーバーの数とこれらのサーバーの復旧ポイントの数に関する情報の間に理解できない不一致が見つかりました。
ポイントの数に関する情報は、Veeam Backup＆Replication Powershellスナップインを使用してpowershellから取得しました。
Veeam Backup Enterprise Manager Webインターフェイスを介したリクエストによるポイント数の選択的検証は、現実と同様の矛盾を示しました。
それが本当に生活を妨げたり、大きな影響を与えたりしたわけではありません。 しかし、場合によっては、誤った結論につながる可能性があります-たとえば、Powershellスクリプトを使用して統計データを収集する場合、小さな貯水池をガス化し、長い間これに気付かないことがあります。
はい、それは気になる、かゆみ-まあ、まったく同じではありません。 修正する必要があります。
リザーブ管理者は現在、オープンジョブについてVeeamとトレーニングを行っており、レプリケーションジョブの一部として問題を調査しています。
Veeam B＆Rの別のブランチでバックアップジョブを掘り下げて、ベンダーのTPが調査した画像を歪めないようにすることにしました。
不一致の発生の瞬間とその理由は、まだ明らかではありません。 TP Veeamからの正確な回答で、テキストを更新します。
これまでのところ、Veeam B＆Rをバージョン7から現在のバージョン9アップデート1にインプレースアップグレードし、既存のジョブの設定を繰り返し変更するという作業仮説を受け入れました。 プロセスは無駄ではありませんでした。おそらく、Veeam B＆Rデータベースには「ゴミ」が蓄積され、テーブルにエントリが重複しています。
DBMSとしてMS SQLが使用されます。理論的には、データベースの構造を掘り下げることができますが、Aramisを言い換えると、「...しかし、実際、私はDBAではありません...」。
バックアップジョブからサーバーを選択的にチェックしたところ、リカバリポイントのデータですべてが実行されていることがわかりました。
例を挙げます。
特定のネームサーバー仮想サーバーは、Veeam Backup＆Replicationジョブの一部です。 Veeam Backup Enterprise Managerが提供する情報によると、36のリカバリポイントがあります。
同時に、保存されたポイントの数に関するバックアップジョブのプロパティは変更されていません。 ジョブがVeeam B＆R 7バージョンで作成された瞬間から-説明されたジョブでは常に7でした。
36個の復元ポイントのドロップダウンリストは非常に「機能している」ようです。障害、アクセスできない部分、またはポイントが
 |  |
タスクプロパティに保存されている数を明らかに超えた日付のポイントから仮想マシンを復元しようとしませんでした。 主に実験の時間不足のため。 一般に時間の不足は、実験から無期限にバックアップジョブの実行を停止できなくなった直後に、状況から抜け出す方法を見つけるための決定的な要因でした。
KMKは、リポジトリ内の物理的には1つの完全バックアップ、6つの増分バックアップ、およびメタデータファイルであるため、復元しようとすると失敗します。つまり、現在から数えて実際には7ポイントです。 5月10日の場合、最も古い保存ポイントは5月3日に作成されます。 日付によって以前に作成されたものはすべて実際には存在せず、Veeam B＆Rデータベースにのみ存在します。
問題のバックアップジョブのリポジトリの内容は次のとおりです。
バックアップファイルを含むリポジトリの再スキャンでは結果が得られず、メタデータは更新されませんでした。
ほとんどのタスクには、転送する場所がまったくないようなサイズのバックアップファイルがあり、N TBのアーカイブが長時間コピーされるため、タスクをこの時間停止する必要があり、単純なバックアップは受け入れられません。 したがって、バックアップファイルを別のリポジトリに転送し、その後のリポジトリの再スキャンとジョブ設定でのバックアップをマップするオプションは、最善の方法として受け入れられませんでした。 同じ理由で、すべてを削除して再インストールし、定期的に作成されたバックアップからVeeam B＆R設定を復元することはできません。
いわば、かなり狭い枠組みの中で問題を解決する方法を模索する必要がありました。
そして、あまりエレガントではありませんが、彼は模索されました。
アルゴリズムはおよそ次のとおりです。
1.バックアップファイルを含むリポジトリで、ファイル名の拡張子を変更します
-完全バックアップ
-バックアップチェーンメタデータファイル
ご注意 1つのバックアップチェーンメタデータファイルの別のリポジトリに名前を変更/移動しても、その後のリポジトリの再スキャンは役に立ちません。
2.バックアップファイルを含むリポジトリに対して再スキャンを実行します。 1つのバックアップがデータベースから削除されたことがわかります。
3.リポジトリ内のフルバックアップファイルとメタデータの名前の拡張子を元の位置に戻します。
4.バックアップファイルを含むリポジトリに対して繰り返し再スキャンを実行します。 データベースに1つのバックアップが追加されていることがわかります。
5.仮想サーバーnamerekを再度確認し、ジョブ設定に対応する復旧ポイントの数とリポジトリ内のファイルの数を確認します。
6.ジョブのプロパティで、手順4でインポートしたチェーンへのマップバックアップを実行します。
私は、解決策が恵みからほど遠いことを繰り返します。 ジョブの数が約70をはるかに超えるため、私の場合、スクリプトからVeeam B＆Rサーバーの再インストールまで、別の方法を探す必要があります。
見つからない解決策、KB、意見、提案などに鼻を突っ込むことは大歓迎です。