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
if your back end database is PostgreSQL, orsqlcmd
with an appropriate command for differential backup, if your back end database is MS SQL Server,
- Bitbucket Server ホーム ディレクトリに最適なファイル システム バックアップ ツールを使用します。例:
- お使いの Bitbucket Server ホーム ディレクトリが LVM を使用している場合は LVM スナップショットの論理ボリューム。
- Bitbucket Server ホーム ディレクトリがストレージ エリア ネットワークを使用している場合は SAN ベースのバックアップ。
rsync
, if available.
- take backups of Bitbucket Data Center and Bitbucket Mesh instances without having to bring nodes down manually.
On this page:
動作確認済みのサンプル リクエストを Bitbucket からダウンロードできます。
ダウンタイムを削減する際に重要なのは、ベンダー固有の最適なデータベースおよびファイル システム バックアップ ツールを使用することです。これらのツールでは一般に、Bitbucket Server Backup Client が使用する汎用的なベンダーに依存しない形式よりも短い時間で、(場合によってはベンダー固有の形式を通じて)スナップショットを作成できます。
Bitbucket Server DIY Backup では、任意の言語でコードを記述し、Bitbucket Server 4.0 で利用可能な REST API を使用して、必要なバックアップ手順を実行する必要があります。
DIY Backup supports Windows and Linux platforms, and Bitbucket Server version 4.0 and higher. DIY Backup supports both Bitbucket Server, Bitbucket Data Center, and Bitbucket Mesh instances equally - any DIY Backup solution that works on one should work on the other without modification.
Bitbucket Server の他のバックアップ戦略の詳細については、「データの復元とバックアップ」を参照してください。また、このページでは、ディスク上の Bitbucket Server ファイル システムと、アプリケーションが使用するデータベースとの間の緊密な連携についても説明します。
このページの例は、DIY Backup ソリューションを開発する際のガイダンスとして提供されています。このため、記載されているサードパーティ ツールは一例であり、ご利用の Bitbucket Server インストールに適したツールを選択する必要があります。
選択したサードパーティ ツールについては、ベンダーのドキュメントをご確認ください。アトラシアンではこのようなツールのサポートを提供できません。
このページでは次のような内容について説明します。
- Describes a complete DIY Backup solution for a PostgreSQL database and local filesystem, using
bash
shell scripts. - 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% 一貫している必要はありません。この時点で最初のスナップショットを取得することで、特にバックアップ間に変更したデータの量が大きい場合、あとで (アプリケーションがロックされている間に) 実行される作業の量を減らすことができます。手順には以下が含まれます。
- データベースの最初のバックアップを実行する (プログレッシブ/差分バックアップをサポートしている場合)。
- Doing an initial
rsync
of the home folder to the backup folder.
- バックアップを初期化します。これにより、以下が行われます。
- Bitbucket Server インスタンスがロックされる。
- データベースおよびファイルシステムへのコネクションがドレインおよびラッチされる。
- ドレイン/ラッチ手順の完了を待機する。
- インスタンスでバックアップの準備が整ったら、実際の DIY Backup を開始できます。これには、次の手順が含まれます。
- Make a fully consistent backup of the database, using
pg_dump
. Make a fully consistent backup of the filesystem, using
rsync
.If you're using Bitbucket Mesh for storing your repositories, you will need to run the DIY backup scripts on each of them at this stage
- Make a fully consistent backup of the database, using
- バックアップ プロセスが終了してロックが解除され次第、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
- for scriptingjq
- an open source command line JSON processor for parsing the REST responses from Bitbucket Serverpg_dump
(orsqlcmd
) - for backing up a PostgreSQL databasersync
- for backing up the filesystemtar
- for making a backup archive
このアプローチに小規模な変更を加えることで、以下で DIY Backups を実行するために使用できます。
- Linux と Unix
- macOS
- cygwin を持つ Windows (cygwin Git は Bitbucket Server ではサポートされません)。
Bash スクリプト
Bitbucket からサンプル スクリプトをダウンロードするか、リポジトリをクローン
Bash スクリプトの実行
Bash スクリプトをダウンロードしたら、1 つのファイルを作成する必要があります。
bitbucket.diy-backup.vars.sh
(you can copybitbucket.diy-backup.vars.sh.example
to start)
For example, here's how you might configure bitbucket.diy-backup.vars.sh
if:
- your Bitbucket Server server is called
bitbucket.example.com,
uses port 7990, and has its home directory in/bitbucket-home
- you want to generate the backup in
/bitbucket-backup
, and store your.tar.gz
backups in/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
The supplied bitbucket.diy-backup.vars.sh
is written to use PostgreSQL, rsync, and tar by default. But if you want to use different tools, you can also customize the top section of this file:
使用例
# 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}
is a working directory (/bitbucket-backup
in our example) where copies of Bitbucket Server's home directory and database dump are built during the DIY Backup process.${BITBUCKET_BACKUP_ARCHIVE_ROOT}
is the directory (/bitbucket-backup-archives
in our example) where the final backup archives are saved.
Bash スクリプトが以下の条件を満たしている場合、このスクリプトをあらゆるホストで実行できます。
- read/write access to the above
${BITBUCKET_BACKUP_ROOT}
and${BITBUCKET_BACKUP_ARCHIVE_ROOT}
directories, - read access to the
${BITBUCKET_HOME}
directory, - データベースへの読み取りアクセス
- network access to run
curl
commands on the Bitbucket Server server.
これは、Bitbucket Server または Bitbucket Data Center のどちらのインスタンスの場合も当てはまります。ファイルシステムへのアクセスが直接/NFS 経由か、あるいはネットワーク アクセスが Bitbucket Server ノードまたはロード バランサ/リバース プロキシのどちらに転送されるかは問いません。
Once your bitbucket.diy-backup.vars.sh
is correctly configured, run the backup in a terminal window:
$ ./bitbucket.diy-backup.sh
The first time you run the backup, rsync
will do most of the work since the /bitbucket-backup
working directory is initially empty. This is normal. Fortunately, this script performs one rsync
before locking Bitbucket Server, followed by a second rsync
while Bitbucket Server is locked to minimize downtime.
On second and subsequent backup runs, /bitbucket-backup
is already populated so the backup process should be faster. The output you can expect to see looks something like this:
$ ./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 の復元
When restoring Bitbucket Server, you must run the
bitbucket.diy-restore.sh
script on the machine that Bitbucket Server should be restored to. In order to ensure accidental restores do not delete existing data, you should never restore into an existing home directory.
The new database should be configured following the instructions in Connect Bitbucket to an external database and its sub-page that corresponds to your database type.
To see the available backups in your ${BITBUCKET_BACKUP_ARCHIVE_ROOT}
directory, just type:
$ ./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
To restore a backup, run bitbucket.diy-restore.sh
with the file name as the argument:
$ ./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
バックアップのキャンセル
必要に応じて、実行中のバックアップ操作をキャンセルできます。
バックアップのキャンセル方法
Copy the cancel token echoed in the terminal (or the Command Prompt on Windows). Look for the line "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 の使用方法の背景情報を提供します。
Note that this discussion shows curl
commands in Bash, however you can use any language.
次の手順が含まれます。
準備
Before you lock Bitbucket Server you can perform any preparation you like. It makes sense to perform as much processing as possible before you lock the application, to minimize downtime later. For example, you could perform an 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 インスタンスをロックする
The next step in making a backup of a Bitbucket Server instance is to lock the instance for maintenance. This can be done using a POST request to the /mvc/maintenance/lock
REST point (where BITBUCKET_URL
points to the Bitbucket Server instance, BITBUCKET_BACKUP_USER
is a Bitbucket Server user with backup permissions, and BITBUCKET_BACKUP_PASS
is this user's password).
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"
}
}
If successful, the Bitbucket Server instance will respond with a 202 and will return a response JSON similar to the one above. The unlockToken
should be used in all subsequent requests where $BITBUCKET_LOCK_TOKEN
is required. This token can also be used to manually unlock the instance.
バックアップ プロセスの開始
次に、データベースとファイルシステムの両方へのすべてのコネクションを、ドレインおよびラッチする必要があります。コードでファイルシステムとデータベースの両方のバックアップを処理する必要があります。
At this point, you should make a POST
request to /mvc/admin/backups
. Notice that the curl
call includes the ?external=true
parameter:
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"
}
If successful the instance will respond with 202 and a response JSON similar to the one above will be returned. The cancelToken
can be used to manually cancel the back up process.
インスタンスの準備が完了するまで待ちます。
Part of the back up process includes draining and latching the connections to the database and the filesystem. Before continuing with the back up we have to wait for the instance to report that this has been done. To get details on the current status we make a GET
request to the /mvc/maintenance
REST point.
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"
}
This causes the Bitbucket Server instance to report its current state. We have to wait for both db-state
and scm-state
to have a status of DRAINED
before continuing with the backup.
実際のバックアップの実行
この時点で、ファイルシステムの実際のバックアップを作成する準備が整いました。たとえば、もう一度 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}
The rsync options shown here are for example only, but indicate how you can include only the required files in the backup process and exclude others. Consult the documentation for rsync
, or the tool of your choice, for a more detailed description.
When creating the database backup you could use your vendor-specific database backup tool, for example pg_dump
if you use PostgreSQL:
pg_dump -Fd ${BITBUCKET_DB} -j 5 --no-synchronized-snapshots -f ${BITBUCKET_BACKUP_DB}
While performing these operations, good practice is to update the instance with progress on the backup so that it's visible in the UI. This can be done by issuing a POST
request to /mvc/admin/backups/progress/client
with the token and the percentage completed as parameters:
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 で応答します。
When displaying progress to users, Bitbucket Server divides the 100 percent progress into 90 percent user DIY Backup, and 10 percent application preparation. This means, for example, if your script sends percentage=0
, Bitbucket Server may display up to 10 percent progress for its own share of the backup work.
(Optional) Run the backup scripts for each Bitbucket Mesh node that's connected to your instance
If you’re using Bitbucket Mesh to store your repositories, you will need to repeat the above process by setting the appropriate options and running the backup script on each Mesh node individually.
Inform the Bitbucket Server instance that the backup is complete
Once we've finished the backup process we must report to the Bitbucket Server instance that progress has reached 100 percent. This is done using a similar request to the progress request. We issue a POST
request to /mvc/admin/backups/progress/client
with the token and 100 as the percentage:
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 インスタンスのロックを解除する
The final step we need to do in the back up process is to unlock the instance. This is done with a DELETE
request to the /mvc/maintenance/lock
REST point:
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 で応答し、アクセスのロックを解除します。