Data Center 移行

Bitbucket Server を管理する

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

Data Center Migration is a tool for admins that can be used to:

  • consolidate multiple Bitbucket instances
  • move from a Bitbucket Server to a Bitbucket Data Center instance
  • selectively export/import projects and repositories from one Bitbucket Data Center instance to another 

Git データを、別の Bitbucket Server または Data Center デプロイメントから、プル リクエスト、コメント、および添付ファイル履歴とともに、Bitbucket Data Center にインポートまたはエクスポートできます。

この機能は Bitbucket Data Center インスタンスを持つお客様のみが使用できます。

移行を開始する前に、次の情報を慎重に確認する必要があります。トラブルシューティング、キャンセル、クリーンアップエラーおよび警告メッセージについての情報もあります。

始める前に

これは、移行の実行前に確認および完了するタスクに関連する考慮事項の、大まかな概要です。移行を開始する前に、以降のセクションを注意深くご確認ください。 

ユーザー インターフェース

この機能の初回 (Bitbucket Server 5.14) リリースにはグラフィカル ユーザー インターフェイスはありません。代わりに REST コールを行って移行プロセスを制御できます。 

移行を実行するには、次のいずれかが必要です。

If you plan to use cURL commands, we recommended you setup a .netrc file (sample commands use the -n flag) and install jq on your machine. 

プレビュー REST エンドポイントを使用する

プレビュー機能を使用して、移行の前にエクスポート範囲を確認できます。

プレビューは、常に完全に移行される、フォーク階層を考慮します。 

ディスク容量の要件

移行するファイルに対して十分なディスク空き容量があることを必ず確認します。エクスポート中に必要な大まかなディスク空き容量は、エクスポートされる Git データと添付ファイルのサイズです。

ElasticSearch およびデータベース サーバー用に追加の領域が必要です。

利用可能なスペースが不明な場合、次のナレッジベース記事で Bitbucket のリポジトリ ID を特定し、それを使用して、利用可能なディスク空き容量を確認できます。

プロジェクト名の競合の問題

移行前に、ソース インスタンスと宛先インスタンスの両方でプロジェクト名を確認します。宛先インスタンスでプロジェクト名が使用中の場合、インポートされるプロジェクトの名前が変更されます。

これを回避するには、次のいずれかを行います。

  • すべてのプロジェクト名を確認し、移行前に名前を変更する
  • 移行にインポート ジョブの警告を確認し、プロジェクトの名前を手動で変更する

同じロジックが、個人プロジェクトのリポジトリ名にも適用されます。

エクスポートに必要な時間

エクスポートに必要な時間は、データ セット、個別の負荷、およびトラフィックによる影響を受けるため、この時間を予測する現実的な方法はありません。

一部のテストでは 200 GB のエクスポートに 2 ~ 4 時間がかかったことが確認されていますが、これよりも時間がかかる可能性があります。 

インポートに必要な時間

インポートに必要な時間は、インポートされるエクスポート アーカイブのサイズ、プル リクエストの数、およびリポジトリの数の影響を受けるため、この時間を予測する現実的な方法はありません。

インポートにはエクスポートよりも長い時間がかかります (およそ 4 倍) 。これは、エクスポートでは、インポート時に実行されるインデックス作成と検証が行われず、データ セット、個別の負荷、およびトラフィックにのみ依存するためです。

ユーザーおよびライセンス管理の推奨事項

エクスポート時、非アクティブなユーザーは生成された "削除済みのユーザー" リスト追加され、移行時にライセンスを消費しません。

移行前に、ソース インスタンスと宛先インスタンスの両方を同じユーザー ディレクトリに接続しておくことを強くおすすめします。

ユーザーは移行されませんが、プロジェクトおよびリポジトリ上のそのユーザーの権限は移行され、権限はユーザー名で照合されます。宛先インスタンスにユーザーが見つからない場合、権限は移行されない可能性があり、警告が記録されます。

両方のインスタンスでユーザー ディレクトリが異なる場合、同じユーザー名のユーザーが宛先インスタンスに存在するが、ソース インスタンスの実際のユーザーとは異なる可能性があります。これにより、インポート時にそのユーザーに誤った権限が付与される可能性があります。

サードパーティ製のプラグイン

サードパーティ製のプラグイン、およびそのデータは移行されない点にご注意ください。

プラグイン側でこの API を使用して独自の移行を実装できます。

プル リクエストのコメント

プル リクエストのコメントが別のリポジトリにアップロードされた添付ファイルを参照している場合は、その添付ファイルが正常にインポートされない可能性があります。

例: ユーザーが 1 つのリポジトリのプル リクエストでコメントに添付ファイルをアップロードし、リンクをコピーして、別のリポジトリのプル リクエストにある別のコメントにペーストしたとします。

これは残りのコメントのインポートには影響せず、添付ファイルにのみ影響します。 

詳細は、トラブルシューティング、キャンセルおよびクリーンアップ」ページを参照してください。

移行に含まれるエンティティ

次の表は、移行時にインポートおよびエクスポートされるエンティティの一覧です。 

Git LFS オブジェクトの移行は別途実行する必要があります。Git LFS の移行プロセスを使用してこれらのオブジェクトをエクスポートできます。 



カテゴリ

項目

インポート

エクスポート

Gitファイル システムの Git リポジトリ(tick)(tick)
Git LFSファイル システムの LFS オブジェクト(error)(error)
プルリクエストプル リクエストのメタデータ(tick)(tick)

PR のユーザー情報(tick)(tick)

PR のコメント(tick)(tick)

PR の添付ファイル(tick)(tick)

PR ファイルのコメント(tick)(tick)
プロジェクト設定説明(tick)(tick)

プロジェクト権限 (ユーザー アクセス)(tick)(tick)

プロジェクト権限 (グループ アクセス)(tick)(tick)

プロジェクト権限 (公開)(tick)(tick)

プロジェクト権限 (既定の権限)(tick)(tick)
リポジトリ設定既定のブランチ(tick)(tick)

フォーク(tick)(tick)

トランスコード差分(tick)(tick)

LFS 有効(tick)(tick)

リポジトリ権限 (ユーザー アクセス)(tick)(tick)

リポジトリ権限 (グループ アクセス)(tick)(tick)

リポジトリ権限 (公開アクセス)(tick)(tick)

ディスク上の Git フック(tick)(tick)

リポジトリ フック(error)(error)
最終更新日 2020 年 3 月 2 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.