ダウンタイムを削減する際に重要なのは、ベンダー固有の最適なデータベースおよびファイル システム バックアップ ツールを使用することです。これらのツールでは一般に、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 のインスタンスを等しくサポートしており、一方で動作する DIY Backup ソリューションはもう一方でもそのまま動作します。

Bitbucket Server の他のバックアップ戦略の詳細については、「データの復元とバックアップ」を参照してください。また、このページでは、ディスク上の 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 と似た方法で機能し、以下を実行します。

1. Bitbucket Server インスタンスのバックアップを準備します。これは、Bitbucket Server がロックされる前に発生します。あとから発生するダウンタイムを最小限に抑えるため、ここでできるだけ多くの処理を実行するようにします。たとえば、インクリメンタル データベースおよびファイルシステム ユーティリティを使用して最初のスナップショットを取得できます。Bitbucket Server はまだ実行中で、データベースやファイルシステムを変更しているため、これは 100% 一貫している必要はありません。この時点で最初のスナップショットを取得することで、特にバックアップ間に変更したデータの量が大きい場合、あとで (アプリケーションがロックされている間に) 実行される作業の量を減らすことができます。手順には以下が含まれます。
   • データベースの最初のバックアップを実行する (プログレッシブ/差分バックアップをサポートしている場合)。
   • Doing an initial rsync of the home folder to the backup folder.
2. バックアップを初期化します。これにより、以下が行われます。
   • Bitbucket Server インスタンスがロックされる。
   • データベースおよびファイルシステムへのコネクションがドレインおよびラッチされる。
   • ドレイン/ラッチ手順の完了を待機する。
3. インスタンスでバックアップの準備が整ったら、実際の DIY Backup を開始できます。これには、次の手順が含まれます。
   • Make a fully consistent backup of the database, using pg_dump.
   • Make a fully consistent backup of the filesystem, using rsync.
4. バックアップ プロセスが終了してロックが解除され次第、Bitbucket Server インスタンスに通知が送信されます。
5. バックアップ中に作成したすべてのファイルを 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 scripting
• jq - an open source command line JSON processor for parsing the REST responses from Bitbucket Server
• pg_dump (or sqlcmd) - for backing up a PostgreSQL database
• rsync - for backing up the filesystem
• tar - 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 copy bitbucket.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 (およびバックアップ スクリプト) を実行する。

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:

DIY Backup が機能するには、2 つのディレクトリを作成する必要があります。

1. ${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. 
2. ${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

バックアップのキャンセル

必要に応じて、実行中のバックアップ操作をキャンセルできます。

バックアップのキャンセル方法

1. 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" を使用

2. ブラウザで Bitbucket Server インターフェイスに移動します。Bitbucket Server は次の画面を表示します。
   
   
3. [バックアップを取消] をクリックし、キャンセル トークンを入力します。
   
   
4. [バックアップを取消] をクリックします。

Bitbucket Server は引き続き、メンテナンス モードでロックされています。"locked with" トークン (例: "7187ae1824ce1ede38a8e7de4bccf58d9a8e1a7a") を使用してこれらの手順を繰り返し、メンテナンス モードを終了して、Bitbucket Server のロックを解除します。

詳細 - REST API を使用した独自の DIY Backup を作成

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. 

バックアップの完了を Bitbucket Server インスタンスに通知

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 で応答し、アクセスのロックを解除します。