Bitbucket DIY Backup
この記事では、Bitbucket Server 4.x+で使用できる、Bitbucket Server DIY Backup スクリプトの使用について説明します。この製品の以前のバージョン (Stash) を実行している場合、「Stash (3.11) DIY Backup の使用」を参照してください。
Bitbucket Server DIY Backup は、Bitbucket Server Backup Client の使用の代替戦略です。これにより以下を実現できます。
- 一貫性のあるバックアップを作成するために必要なダウンタイムを大幅に削減する。
- ご利用のバックエンドのデータベースに適した、ベンダー固有のバックアップ ツールを使用する。例:
pg_dump
: バックエンドのデータベースが PostgreSQL の場合、またはsqlcmd
: バック エンドのデータベースが MS SQL Server の場合、差分バックアップ用の適切なコマンドとともに使用。
- Bitbucket Server ホーム ディレクトリに最適なファイル システム バックアップ ツールを使用します。例:
- お使いの Bitbucket Server ホーム ディレクトリが LVM を使用している場合は LVM スナップショットの論理ボリューム。
- Bitbucket Server ホーム ディレクトリがストレージ エリア ネットワークを使用している場合は SAN ベースのバックアップ。
rsync
(利用可能であれば)
- ノードを手動で停止させずに Bitbucket Data Center および Bitbucket Mesh インスタンスのバックアップを作成する。
On this page:
動作確認済みのサンプル リクエストを Bitbucket からダウンロードできます。
ダウンタイムを削減する際に重要なのは、ベンダー固有の最適なデータベースおよびファイル システム バックアップ ツールを使用することです。これらのツールでは一般に、Bitbucket Server Backup Client が使用する汎用的なベンダーに依存しない形式よりも短い時間で、(場合によってはベンダー固有の形式を通じて)スナップショットを作成できます。
Bitbucket Server DIY Backup では、任意の言語でコードを記述し、Bitbucket Server 4.0 で利用可能な REST API を使用して、必要なバックアップ手順を実行する必要があります。
DIY Backup は Windows および Linux プラットフォーム、および Bitbucket Server バージョン 4.0 以降をサポートしています。DIY Backup は Bitbucket Server 、Bitbucket Data Center、および Bitbucket Mesh のインスタンスを等しくサポートしており、一方で動作する DIY Backup ソリューションはもう一方でもそのまま動作します。
Bitbucket Server の他のバックアップ戦略の詳細については、「データの復元とバックアップ」を参照してください。また、このページでは、ディスク上の Bitbucket Server ファイル システムと、アプリケーションが使用するデータベースとの間の緊密な連携についても説明します。
このページの例は、DIY Backup ソリューションを開発する際のガイダンスとして提供されています。このため、記載されているサードパーティ ツールは一例であり、ご利用の Bitbucket Server インストールに適したツールを選択する必要があります。
選択したサードパーティ ツールについては、ベンダーのドキュメントをご確認ください。アトラシアンではこのようなツールのサポートを提供できません。
このページでは次のような内容について説明します。
bash
シェル スクリプトを使用した、PostgreSQL データベースおよびローカル ファイルシステム用の完全な DIY Backup ソリューションについて説明します。- DIY Backup で Bitbucket Server の REST API をどのように使用できるかについての背景情報を提供します。
ご利用の Bitbucket Server インスタンスに同じまたは類似した設定がある場合はこのソリューションを直接使用できるほか、ご利用のハードウェア設定に合わせた独自の DIY Backup ソリューションを開発するための出発点として使用することができます。
動作の仕組み
Bitbucket Server Backup Client の代わりに DIY Backup を使用する場合は、バックアップ手順を完全に制御し、任意の言語で任意のカスタム プロセスを実装できます。たとえば、DIY Backup の一環として、データベースのインクリメントまたはファスト スナップショット ツールやファイル サーバー固有のツールを使用できます。
DIY Backup は Bitbucket Server Backup Client と似た方法で機能し、以下を実行します。
- Bitbucket Server インスタンスのバックアップを準備します。これは、Bitbucket Server がロックされる前に発生します。あとから発生するダウンタイムを最小限に抑えるため、ここでできるだけ多くの処理を実行するようにします。たとえば、インクリメンタル データベースおよびファイルシステム ユーティリティを使用して最初のスナップショットを取得できます。Bitbucket Server はまだ実行中で、データベースやファイルシステムを変更しているため、これは 100% 一貫している必要はありません。この時点で最初のスナップショットを取得することで、特にバックアップ間に変更したデータの量が大きい場合、あとで (アプリケーションがロックされている間に) 実行される作業の量を減らすことができます。手順には以下が含まれます。
- データベースの最初のバックアップを実行する (プログレッシブ/差分バックアップをサポートしている場合)。
- ホーム フォルダからバックアップ フォルダへの初回の
rsync
を実行する。
- バックアップを初期化します。これにより、以下が行われます。
- Bitbucket Server インスタンスがロックされる。
- データベースおよびファイルシステムへのコネクションがドレインおよびラッチされる。
- ドレイン/ラッチ手順の完了を待機する。
- インスタンスでバックアップの準備が整ったら、実際の DIY Backup を開始できます。これには、次の手順が含まれます。
pg_dump
を使用して、データベースの完全に一貫したバックアップを作成する。rsync
を使用して、ファイルシステムの完全に一貫したバックアップを作成する。リポジトリの保存に Bitbucket Mesh を使用している場合は、この段階で各リポジトリで DIY Backup スクリプトを実行する必要があります。
- バックアップ プロセスが終了してロックが解除され次第、Bitbucket Server インスタンスに通知が送信されます。
- バックアップ中に作成したすべてのファイルを 1 つの大きなアーカイブに保存します。
アプリケーションがメンテナンス モードになっている場合、ユーザーが Web インターフェイスへのアクセスやホスティング サービスの使用を試みると、エラー メッセージが表示されます。
利用が不可能な時間を予測するための参考値として、アトラシアンの内部使用では、Bitbucket Server のダウンタイムは 7–8 分 (Bitbucket Server Backup Client を使用、リポジトリのサイズが合計 6 GB の場合) になりました。比較のために、同じリポジトリで Bitbucket Server DIY Backup を使用すると、一般にダウンタイムは 1 分未満になります。
バックアップ対象
Bitbucket Server DIY Backup は、Bitbucket Server Backup Client と同じデータをすべてバックアップします。
- インスタンスが接続されているデータベース (内部または外部 DB)
- 管理された Git リポジトリ
- Bitbucket Server ログ
- インストール済みのプラグインとそれらのデータ
Bash スクリプトを使用した DIY Backup
このセクションでは、次のツールを使用する、完全な DIY Backup ソリューションを紹介します。
bash
-スクリプト用jq
- Bitbucket Server からの REST レスポンスをパースするための、オープン ソースのコマンド ライン JSON プロセッサーpg_dump
(またはsqlcmd
) - PostgreSQL データベースのバックアップ用rsync
- ファイルシステムのバックアップ用tar
- バックアップ アーカイブの作成用
このアプローチに小規模な変更を加えることで、以下で DIY Backups を実行するために使用できます。
- Linux と Unix
- macOS
- cygwin を持つ Windows (cygwin Git は Bitbucket Server ではサポートされません)。
Bash スクリプト
Bitbucket からサンプル スクリプトをダウンロードするか、リポジトリをクローンできます。
Bash スクリプトの実行
Bash スクリプトをダウンロードしたら、1 つのファイルを作成する必要があります。
bitbucket.diy-backup.vars.sh
(bitbucket.diy-backup.vars.sh.example
をコピーして開始できます)
たとえば、次の場合の bitbucket.diy-backup.vars.sh
の設定方法を紹介します。
- Bitbucket Server の名前が
bitbucket.example.com,
で、ポートは 7990 を使い、ホーム ディレクトリは/bitbucket-home
/bitbucket-backup
にバックアップを生成し、.tar.gz
バックアップを/bitbucket-backup-archives
に保存したい- Bitbucket にユーザー名 "admin"、パスワード "admin" のシステム管理者があり、OS ユーザー "atlbitbucket" として Bitbucket (およびバックアップ スクリプト) を実行する。
bitbucket.diy-backup.vars.sh
#!/bin/bash
CURL_OPTIONS="-L -s -f"
INSTANCE_NAME=bitbucket
BITBUCKET_URL=http://bitbucket.example.com:7990
BITBUCKET_HOME=/bitbucket-home/
BITBUCKET_UID=atlbitbucket
BITBUCKET_GID=atlbitbucket
BACKUP_HOME_TYPE=rsync
BACKUP_DATABASE_TYPE=postgresql
BACKUP_ARCHIVE_TYPE=tar
BITBUCKET_BACKUP_USER=admin
BITBUCKET_BACKUP_PASS=admin
BITBUCKET_BACKUP_EXCLUDE_REPOS=()
BITBUCKET_DB=bitbucket
POSTGRES_HOST=localhost
POSTGRES_USERNAME=dbuser
export PGPASSWORD=dbpass
POSTGRES_PORT=5432
# Make use of PostgreSQL 9.3+ options if available
psql_version="$(psql --version | awk '{print $3}')"
psql_majorminor="$(printf "%d%03d" $(echo "${psql_version}" | tr "." "\n" | head -n 2))"
if [[ ${psql_majorminor} -ge 9003 ]]; then
PG_PARALLEL="-j 5"
PG_SNAPSHOT_OPT="--no-synchronized-snapshots"
fi
BITBUCKET_BACKUP_ROOT=/bitbucket-backup
BITBUCKET_BACKUP_DB=${BITBUCKET_BACKUP_ROOT}/bitbucket-db/
BITBUCKET_BACKUP_HOME=${BITBUCKET_BACKUP_ROOT}/bitbucket-home/
BITBUCKET_BACKUP_ARCHIVE_ROOT=/bitbucket-backup-archives
# Used by the scripts for verbose logging. If not true only errors will be shown.
BITBUCKET_VERBOSE_BACKUP=TRUE
HIPCHAT_URL=https://api.hipchat.com
HIPCHAT_ROOM=
HIPCHAT_TOKEN=
KEEP_BACKUPS=0
提供の bitbucket.diy-backup.vars.sh
は、デフォルトで PostgreSQL、rsync、tar を使用するように書かれています。別のツールを使用したい場合、このファイルの上部のセクションをカスタマイズすることもできます。
使用例
# Strategy for backing up the Bitbucket home directory:
# - amazon-ebs - Amazon EBS snapshots of the volume containing the home directory
# - rsync - "rsync" of the home directory contents to a temporary location. NOTE: This can NOT be used
# with BACKUP_ZERO_DOWNTIME=true.
BACKUP_HOME_TYPE=rsync
# Strategy for backing up the database:
# - amazon-rds - Amazon RDS snapshots
# - mysql - MySQL using "mysqldump" to backup and "mysql" to restore
# - postgresql - PostgreSQL using "pg_dump" to backup and "pg_restore" to restore
# - postgresql93-fslevel - PostgreSQL 9.3 with data directory located in the file system volume as home directory (so
# that it will be included implicitly in the home volume snapshot)
BACKUP_DATABASE_TYPE=postgresql
# Strategy for backing up Elasticsearch:
# - <leave blank> - No separate snapshot and restore of Elasticsearch state (default).
# - s3 - Amazon S3 bucket - requires the Elasticsearch Cloud plugin to be installed.
# - fs - Shared filesystem - requires all data and master nodes to mount a shared file system to the same mount point.
BACKUP_ELASTICSEARCH_TYPE=
DIY Backup が機能するには、2 つのディレクトリを作成する必要があります。
${BITBUCKET_BACKUP_ROOT}
は、DIY Backup プロセス中に Bitbucket Server のホーム ディレクトリとデータベース ダンプのコピーが作成される作業ディレクトリ (この例では/bitbucket-backup
) です。${BITBUCKET_BACKUP_ARCHIVE_ROOT}
は、最終的なバックアップアーカイブが保存されるディレクトリ (この例では/bitbucket-backup-archives
)です。
Bash スクリプトが以下の条件を満たしている場合、このスクリプトをあらゆるホストで実行できます。
- 上記の
${BITBUCKET_BACKUP_ROOT}
および${BITBUCKET_BACKUP_ARCHIVE_ROOT}
ディレクトリへの読み取り/書き込みアクセス、 ${BITBUCKET_HOME}
ディレクトリへの読み取りアクセス、- データベースへの読み取りアクセス
- Bitbucket Server のサーバーで
curl
コマンドを実行するためのネットワーク アクセス。
これは、Bitbucket Server または Bitbucket Data Center のどちらのインスタンスの場合も当てはまります。ファイルシステムへのアクセスが直接/NFS 経由か、あるいはネットワーク アクセスが Bitbucket Server ノードまたはロード バランサ/リバース プロキシのどちらに転送されるかは問いません。
bitbucket.diy-backup.vars.sh
が正しく設定できたら、ターミナル ウィンドウでバックアップを実行してください。
$ ./bitbucket.diy-backup.sh
バックアップを初めて実行する際には rsync
がほとんどの作業を実行します /bitbucket-backup
作業ディレクトリは最初は空のため)。これは通常の挙動です。このスクリプトは Bitbucket Server をロックする前に rsync
を 1 度実行し、Bitbucket Server がロックされている間に 2 度目の rsync
を実行することで、ダウンタイムを最小限に抑えます。
2 回目以降のバックアップ実行時、/bitbucket-backup
にはすでにファイルが存在するため、バックアップ プロセスはより短時間で完了します。表示される出力は次のようになるはずです。
$ ./bitbucket.diy-backup.sh
[http://localhost:7990/bitbucket] INFO: Prepared backup of DB bitbucket in /bitbucket-backup/bitbucket-db/
building file list ... done.
sent 4.17M bytes received 484 bytes 2.78M bytes/sec
total size is 121.12M speedup is 29.06
[http://localhost:7990/bitbucket] INFO: Prepared backup of /bitbucket-home to /bitbucket-backup/bitbucket-home/
[http://localhost:7990/bitbucket] INFO: locked with '7187ae1824ce1ede38a8e7de4bccf58d9a8e1a7a'
[http://localhost:7990/bitbucket] INFO: backup started with '82c73f89e790b27fef3032e81c7071388ae4e371'
[http://localhost:7990/bitbucket] INFO: Waiting for DRAINED state....... done
[http://localhost:7990/bitbucket] INFO: db state 'DRAINED'
[http://localhost:7990/bitbucket] INFO: scm state 'DRAINED'
[http://localhost:7990/bitbucket] INFO: Performed backup of DB bitbucket in /bitbucket-backup/bitbucket-db/
[http://localhost:7990/bitbucket] INFO: Backup progress updated to 50
building file list ... done.
sent 4.87M bytes received 484 bytes 3.25M bytes/sec
total size is 121.82M speedup is 24.99
[http://localhost:7990/bitbucket] INFO: Performed backup of /bitbucket-home to /bitbucket-backup/bitbucket-home/
[http://localhost:7990/bitbucket] INFO: Backup progress updated to 100
[http://localhost:7990/bitbucket] INFO: Bitbucket instance unlocked
[http://localhost:7990/bitbucket] INFO: Archiving /bitbucket-backup into /bitbucket-backup-archives/bitbucket-20150917-082818-498.tar.gz
[http://localhost:7990/bitbucket] INFO: Archived /bitbucket-backup into /bitbucket-backup-archives/bitbucket-20150917-082818-498.tar.gz
DIY Backup の復元
Bitbucket Server を復元する際には、Bitbucket Server を復元する必要があるマシンで
bitbucket.diy-restore.sh
スクリプトを実行する必要があります。誤った復元で既存のデータが削除されないよう、既存のホーム ディレクトリには復元しないでください。
新しいデータベースは、「Bitbucket を外部データベースに接続する」およびご利用のデータベース タイプに対応するサブページの指示にしたがって構成されている必要があります。
${BITBUCKET_BACKUP_ARCHIVE_ROOT}
ディレクトリにある利用可能なバックアップを確認するには、次のように入力してください。
$ ./bitbucket.diy-restore.sh
次のように表示されるはずです。
$ ./bitbucket.diy-restore.sh
Usage: ./bitbucket.diy-restore.sh <backup-file-name>.tar.gz
Available backups:
bitbucket-20150917-082818-498.tar.gz bitbucket-20150918-083745-001.tar.gz
バックアップを復元するには、bitbucket.diy-restore.sh
を、ファイル名を引数として実行してください。
$ ./bitbucket.diy-restore.sh bitbucket-20150917-082818-498
出力は次のように表示されます。
$ ./bitbucket.diy-restore.sh bitbucket-20150917-082818-498.tar.gz
[http://localhost:7990/bitbucket] INFO: Extracted /bitbucket-backup-archives/bitbucket-20150917-082818-498.tar.gz into /tmp/bitbucket.diy-restore.dQsbzU
[http://localhost:7990/bitbucket] INFO: Performed restore of /tmp/bitbucket.diy-restore.dQsbzU/bitbucket-db to DB bitbucket2
[http://localhost:7990/bitbucket] INFO: Performed restore of /tmp/bitbucket.diy-restore.dQsbzU/bitbucket-home to /bitbucket-home2
バックアップのキャンセル
必要に応じて、実行中のバックアップ操作をキャンセルできます。
バックアップのキャンセル方法
ターミナル (または Windows のコマンド プロンプト) で返されるキャンセル トークンをコピーします。「backup started with
token
」行を探します。$ ./bitbucket.diy-backup.sh [http://localhost:7990/bitbucket] INFO: Prepared backup of DB bitbucket in /bitbucket-backup/bitbucket-db/ building file list ... done. sent 4.17M bytes received 484 bytes 2.78M bytes/sec total size is 121.12M speedup is 29.06 [http://localhost:7990/bitbucket] INFO: Prepared backup of /bitbucket-home to /bitbucket-backup/bitbucket-home/ [http://localhost:7990/bitbucket] INFO: locked with '7187ae1824ce1ede38a8e7de4bccf58d9a8e1a7a' [http://localhost:7990/bitbucket] INFO: backup started with '82c73f89e790b27fef3032e81c7071388ae4e371' [http://localhost:7990/bitbucket] INFO: Waiting for DRAINED state....... done [http://localhost:7990/bitbucket] INFO: db state 'DRAINED' [http://localhost:7990/bitbucket] INFO: scm state 'DRAINED'
例: "82c73f89e790b27fef3032e81c7071388ae4e371" を使用
- ブラウザで Bitbucket Server インターフェイスに移動します。Bitbucket Server は次の画面を表示します。
- [バックアップを取消] をクリックし、キャンセル トークンを入力します。
- [バックアップを取消] をクリックします。
Bitbucket Server は引き続き、メンテナンス モードでロックされています。"locked with" トークン (例: "7187ae1824ce1ede38a8e7de4bccf58d9a8e1a7a") を使用してこれらの手順を繰り返し、メンテナンス モードを終了して、Bitbucket Server のロックを解除します。
詳細 - REST API を使用した独自の DIY Backup を作成
このセクションはオプションで、上記の DIY Backup スクリプトをご希望の言語で書き換えたり、大幅にカスタマイズしたりする必要がある場合のために、Bitbucket Server の REST API の使用方法の背景情報を提供します。
ここでは、Bash での curl
コマンドを示していますが、任意の言語を使用できます。
次の手順が含まれます。
準備
Bitbucket Server をロックする前に、任意の準備を実行することができます。あとから発生するダウンタイムを最小限に抑えるため、アプリケーションをロックする前に、できるだけ多くの処理を実行することをおすすめします。たとえば、rsync
を実行できます。
rsync -avh --delete --delete-excluded --exclude=/caches/ --exclude=/data/db.* --exclude=/export/ --exclude=/log/ --exclude=/plugins/.*/ --exclude=/tmp --exclude=/.lock ${BITBUCKET_HOME} ${BITBUCKET_BACKUP_HOME}
Bitbucket Server インスタンスをロックする
Bitbucket Server インスタンスのバックアップ作成の次の手順は、メンテナンス用にインスタンスをロックすることです。これは、/mvc/maintenance/lock
REST ポイントへの POST リクエストを使用して実行できます (BITBUCKET_URL
は Bitbucket Server インスタンスを指し、BITBUCKET_BACKUP_USER
はバックアップ権限を持つ Bitbucket Server ユーザー、BITBUCKET_BACKUP_PASS
はこのユーザーのパスワードです)。
curl -s \
-u ${BITBUCKET_BACKUP_USER}:${BITBUCKET_BACKUP_PASS} \
-X POST \
-H "Content-type: application/json" \
"${BITBUCKET_URL}/mvc/maintenance/lock"
{
"unlockToken":"0476adeb6cde3a41aa0cc19fb394779191f5d306",
"owner": {
"displayName":"admin",
"name":"admin"
}
}
成功すると、Bitbucket Server インスタンスは 202 で応答し、上記のようなレスポンス JSON を返します。この unlockToken
は、$BITBUCKET_LOCK_TOKEN
が要求される以降のすべてのリクエストで使用する必要があります。このトークンは、インスタンスのロックを手動で解除するためにも使用できます。
バックアップ プロセスの開始
次に、データベースとファイルシステムの両方へのすべてのコネクションを、ドレインおよびラッチする必要があります。コードでファイルシステムとデータベースの両方のバックアップを処理する必要があります。
この時点で、/mvc/admin/backups
に POST
リクエストをする必要があります。curl
コールには、?external=true
パラメーターが含まれる点に注意してください。
curl -s \
-u ${BITBUCKET_BACKUP_USER}:${BITBUCKET_BACKUP_PASS} \
-X POST \
-H "X-Atlassian-Maintenance-Token: ${BITBUCKET_LOCK_TOKEN}" \
-H "Accept: application/json" \
-H "Content-type: application/json" \
"${BITBUCKET_URL}/mvc/admin/backups?external=true"
{
"id":"d2e15c3c2da282b0990e8efb30b4bffbcbf09e04",
"progress": {
"message":"Closing connections to the current database",
"percentage":5
},
"state":"RUNNING",
"type":"BACKUP",
"cancelToken":"d2e15c3c2da282b0990e8efb30b4bffbcbf09e04"
}
成功すると、インスタンスは 202 で応答し、上記のようなレスポンス JSON を返指す。cancelToken
は、バックアップ プロセスを手動でキャンセルする際に使用できます。
インスタンスの準備が完了するまで待ちます。
バックアップ プロセスの一環には、データベースおよびファイルシステムへのコネクションのドレインおよびラッチが含まれます。バックアップを続行する前に、この手順が完了したことをインスタンスが報告するのを待機する必要があります。現在のステータスの詳細を確認したい場合、/mvc/maintenance
REST ポイントに GET
リクエストを行います。
curl -s \
-u ${BITBUCKET_BACKUP_USER}:${BITBUCKET_BACKUP_PASS} \
-X GET \
-H "X-Atlassian-Maintenance-Token: ${BITBUCKET_LOCK_TOKEN}" \
-H "Accept: application/json" \
-H "Content-type: application/json" \
"${BITBUCKET_URL}/mvc/maintenance"
{
"task":{
"id":"0bb6b2ed52a6a12322e515e88c5d515d6b6fa95e",
"progress":{
"message":"Backing up Bitbucket home",
"percentage":10
},
"state":"RUNNING",
"type":"BACKUP"
},
"db-state":"DRAINED",
"scm-state":"DRAINED"
}
これにより、Bitbucket Server インスタンスは現在の状態を報告します。バックアップを続行する前に、db-state
と scm-state
の両方のステータスが DRAINED
になるのを待機する必要があります。
実際のバックアップの実行
この時点で、ファイルシステムの実際のバックアップを作成する準備が整いました。たとえば、もう一度 rsync を使用できます。
rsync -avh --delete --delete-excluded --exclude=/caches/ --exclude=/data/db.* --exclude=/export/ --exclude=/log/ --exclude=/plugins/.*/ --exclude=/tmp --exclude=/.lock ${BITBUCKET_HOME} ${BITBUCKET_BACKUP_HOME}
ここに示す rsync オプションは例に過ぎませんが、バックアップ プロセスに必要なファイルのみを含め、それ以外を除外する方法を示しています。詳細な説明については、rsync
またはお好きなツールのドキュメントを参照してください。
データベース バックアップを作成する際には、ベンダー固有のバックアップ ツールを使用できます。たとえば、PostgreSQL を使用している場合は pg_dump
を使用できます。
pg_dump -Fd ${BITBUCKET_DB} -j 5 --no-synchronized-snapshots -f ${BITBUCKET_BACKUP_DB}
これらの操作を実行する際は、バックアップの進捗でインスタンスを更新し、進捗を UI で確認できるようにすることをおすすめします。これを行うには、トークンと完了済みのパーセント値をパラメーターとして使用し、/mvc/admin/backups/progress/client
に POST
リクエストを発行します。
curl -s \
-u ${BITBUCKET_BACKUP_USER}:${BITBUCKET_BACKUP_PASS} \
-X POST \
-H "Accept: application/json" \
-H "Content-type: application/json" \
"${BITBUCKET_URL}/mvc/admin/backups/progress/client?token=${BITBUCKET_LOCK_TOKEN}&percentage=${BITBUCKET_BACKUP_PERCENTAGE}"
問題ない場合、Bitbucket Server はこのリクエストに空の 202 で応答します。
ユーザーに進捗を表示する際、Bitbucket Server は 100 パーセントの進捗のうち、90 パーセントを DIY Backup、10 パーセントをアプリケーションの準備に分割します。つまり、スクリプトが percentage=0
を送信した場合、Bitbucket Server はバックアップ作業の割り当て分について最大 10 パーセントの進捗を表示する可能性があります。
(オプション) インスタンスに接続されている各 Bitbucket Mesh ノードに Backup スクリプトを実行する
Bitbucket Mesh を使用してリポジトリを保存している場合は、適切なオプションを設定し、各 Mesh ノードで 個別に バックアップスクリプトを実行して、上記のプロセスを繰り返す必要があります。
バックアップの完了を Bitbucket Server インスタンスに通知
バックアップ プロセスが終了したら、進捗が 100 パーセントに到達したことを Bitbucket Server インスタンスに報告する必要があります。これは、進捗リクエストに似たリクエストを使用して実行されます。POST
リクエストを /mvc/admin/backups/progress/client
にトークンおよびパーセンテージとして100 を伴って発行します。
curl -s \
-u ${BITBUCKET_BACKUP_USER}:${BITBUCKET_BACKUP_PASS} \
-X POST \
-H "Accept: application/json" \
-H "Content-type: application/json" \
"${BITBUCKET_URL}/mvc/admin/backups/progress/client?token=${BITBUCKET_LOCK_TOKEN}&percentage=100"
問題ない場合、Bitbucket Server は空の 202 で応答します。パーセント値が 100 になると、バックアップ プロセスは完了済みとみなされます。これにより、この Bitbucket Server のインスタンスのデータベースとファイルシステムのラッチが解除されます。
Bitbucket Server インスタンスのロックを解除する
バックアップ プロセスで行う必要がある最後の手順は、インスタンスのロックを解除することです。これは、/mvc/maintenance/lock
REST ポイントへの DELETE
リクエストで実施します。
curl -s \
-u ${BITBUCKET_BACKUP_USER}:${BITBUCKET_BACKUP_PASS} \
-X DELETE \
-H "Accept: application/json" \
-H "Content-type: application/json" \
"${BITBUCKET_URL}/mvc/maintenance/lock?token=${BITBUCKET_LOCK_TOKEN}"
問題ない場合、Bitbucket Server インスタンスはこのリクエストに空の 202 で応答し、アクセスのロックを解除します。