Data Center Migration
Data Center Migration is a tool for admins to allow consolidation of multiple Bitbucket instances, or move from a server to a Data Center instance.
Git データを、別の Bitbucket Server または Data Center デプロイメントから、プル リクエスト、コメント、および添付ファイル履歴とともに、Bitbucket Data Center にインポートまたはエクスポートできます。
この機能は Bitbucket Data Center インスタンスを持つお客様のみが使用できます。
Before starting a migration, review the below information carefully. There is also information around troubleshooting, canceling and cleanup, and error and warning messages.
始める前に
これは、移行の実行前に確認および完了するタスクに関連する考慮事項の、大まかな概要です。移行を開始する前に、以降のセクションを注意深くご確認ください。
ユーザー インターフェース
この機能の初回 (Bitbucket Server 5.14) リリースにはグラフィカル ユーザー インターフェイスはありません。代わりに REST コールを行って移行プロセスを制御できます。
移行を実行するには、次のいずれかが必要です。
- 任意のツールを使用して REST コールを行う
- refer to the provided sample cURL commands for import and sample cURL commands for export.
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 を特定し、それを使用して、利用可能なディスク空き容量を確認できます。
プロジェクト名の競合の問題
Before migration, check the names of projects on both the source and destination instances. If a project name is in use on the destination instance, the project being imported will be renamed.
これを回避するには、次のいずれかを行います。
- すべてのプロジェクト名を確認し、移行前に名前を変更する
- after the migration, review the warnings on the import job, and rename projects manually.
同じロジックが、個人プロジェクトのリポジトリ名にも適用されます。
エクスポートに必要な時間
エクスポートに必要な時間は、データ セット、個別の負荷、およびトラフィックによる影響を受けるため、この時間を予測する現実的な方法はありません。
一部のテストでは 200 GB のエクスポートに 2 ～ 4 時間がかかったことが確認されていますが、これよりも時間がかかる可能性があります。
インポートに必要な時間
インポートに必要な時間は、インポートされるエクスポート アーカイブのサイズ、プル リクエストの数、およびリポジトリの数の影響を受けるため、この時間を予測する現実的な方法はありません。
インポートにはエクスポートよりも長い時間がかかります (およそ 4 倍) 。これは、エクスポートでは、インポート時に実行されるインデックス作成と検証が行われず、データ セット、個別の負荷、およびトラフィックにのみ依存するためです。
ユーザーおよびライセンス管理の推奨事項
Non-active users are added to a generated list of "deleted users" on export, and do not take up licenses on migration.
移行前に、ソース インスタンスと宛先インスタンスの両方を同じユーザー ディレクトリに接続しておくことを強くおすすめします。
ユーザーは移行されませんが、プロジェクトおよびリポジトリ上のそのユーザーの権限は移行され、権限はユーザー名で照合されます。宛先インスタンスにユーザーが見つからない場合、権限は移行されない可能性があり、警告が記録されます。
両方のインスタンスでユーザー ディレクトリが異なる場合、同じユーザー名のユーザーが宛先インスタンスに存在するが、ソース インスタンスの実際のユーザーとは異なる可能性があります。これにより、インポート時にそのユーザーに誤った権限が付与される可能性があります。
サードパーティ製のプラグイン
It's important to know that third party plugins will not be migrated, neither will their data.
プラグイン側でこの API を使用して独自の移行を実装できます。
プル リクエストのコメント
プル リクエストのコメントが別のリポジトリにアップロードされた添付ファイルを参照している場合は、その添付ファイルが正常にインポートされない可能性があります。
例: ユーザーが 1 つのリポジトリのプル リクエストでコメントに添付ファイルをアップロードし、リンクをコピーして、別のリポジトリのプル リクエストにある別のコメントにペーストしたとします。
これは残りのコメントのインポートには影響せず、添付ファイルにのみ影響します。
For more information see the troubleshooting, canceling and cleanup page.
移行に含まれるエンティティ
次の表は、移行時にインポートおよびエクスポートされるエンティティの一覧です。
Git LFS objects migration needs to be run separately. You can use this Git LFS migration process to export these objects.
カテゴリ | 項目 | インポート | エクスポート |
|---|---|---|---|
| Git | Git repositories on file system |  | |
| Git LFS | LFS objects on file system |  | |
| プルリクエスト | Pull request metadata | | |
| PR user info | | | |
| PR comments | | | |
| PR attachments | | | |
| PR File comments | | | |
| Project Settings | 説明 | | |
| Project permissions (user access) | | | |
| Project permissions (group access) | | | |
| Project permissions (public) | | | |
| Project permissions (default permission) | | | |
| Repository Settings | Default branch | | |
| Forks | | | |
| Transcode diffs | | | |
| LFS enabled | | | |
| Repo permissions (user access) | | | |
| Repo permissions (group access) | | | |
| Repo permissions (public access) | | | |
| Git hooks on disk | | | |
| Repository hooks | | |