Data Center Migration

Bitbucket Server を管理する

このページの内容

お困りですか?

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

コミュニティに質問

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 data can be imported or exported into Bitbucket Data Center from another Bitbucket Server or Data Center deployment, along with pull requests, comments and attachment history.

This feature is only available to customers with a Bitbucket Data Center instance.

Before starting a migration, review the below information carefully. There is also information around troubleshooting, canceling and cleanup, and error and warning messages.

始める前に

This is a high-level description of considerations and tasks to review and complete before performing a migration. Read through the following sections carefully before starting a migration. 

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

There's no graphical user interface in the initial (Bitbucket Server 5.14) release of this feature. Instead, REST calls can be made to control the migration process. 

To perform the migration you will need to either:

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. 

Using the preview REST endpoint

You can use the preview function to review the scope of the export, prior to a migration.

The preview takes into account fork hierarchies, which are always migrated fully. 

ディスク容量の要件

Always make sure you have enough disk space for the files you're migrating. The space required on disk during export is roughly the size of the Git data and attachments being exported.

Additional space is required for ElasticSearch, and for your database server.

If you are unsure what space you have available, the following knowledge base article tells you how to identify a repository ID in Bitbucket, which you can then use to check the available disk space.

Issues with project name conflicts

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.

To avoid this either:

  • check all project names and rename before migration, or
  • after the migration, review the warnings on the import job, and rename projects manually.

The same logic applies to repository names in personal projects.

Time needed for export

There is no real way to predict the time required for the export, it is impacted by your data set, individual load, and traffic.

Some tests have shown that an export of 200GB can take anywhere between 2 - 4 hours, but this can be higher. 

Time needed for import

There is no real way to predict the time required for import, it is impacted by the size of the export archive being imported, the number of pull requests, and the number of repositories.

An import will take longer than an export (roughly four times as long). This is because indexing and validation (performed during import) doesn't occur during export, and remains dependent on your data set, individual load, and traffic.

User and license management recommendations

Non-active users are added to a generated list of "deleted users" on export, and do not take up licenses on migration.

We strongly recommend that both the source and destination instances are connected to the same user directory prior to migration.

Even though users will not be migrated, their permissions on projects and repositories will, and permissions are matched by username. If users are missing on the destination instance, permissions might not be migrated and a warning will be logged.

If user directories are different on both instances, it is possible that users with the same username exist on the destination instance, but are actually different users in the source instance. This would result in incorrect permissions being granted to those users on import.

Third party plugins

It's important to know that third party plugins will not  be migrated, neither will their data.

Plugins can implement their own migrations using this API.

Pull request comments

If a pull request comment references an attachment that was uploaded to a different repository, there is a possibility that the attachment will not be successfully imported.

E.g if a user has uploaded an attachment to a comment on a pull request in one repository, then copies and pastes the link into a different comment on a pull request, in another repository.

This will not impact the import of the rest of the comment, only the attachment. 

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

Entities included in migration

The below table lists the entities that will be imported and exported during migration. 

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 (tick) (tick)
Git LFS LFS objects on file system (error) (error)
プルリクエスト Pull request metadata (tick) (tick)

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

PR comments (tick) (tick)

PR attachments (tick) (tick)

PR File comments (tick) (tick)
プロジェクト設定 説明 (tick) (tick)

Project permissions (user access) (tick) (tick)

Project permissions (group access) (tick) (tick)

Project permissions (public) (tick) (tick)

Project permissions (default permission) (tick) (tick)
リポジトリ設定 既定のブランチ (tick) (tick)

Forks (tick) (tick)

Transcode diffs (tick) (tick)

LFS enabled (tick) (tick)

Repo permissions (user access) (tick) (tick)

Repo permissions (group access) (tick) (tick)

Repo permissions (public access) (tick) (tick)

Git hooks on disk (tick) (tick)

Repository hooks (error) (error)
最終更新日 2019 年 6 月 18 日

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

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