---
title: "Spanner バックアップ&復元の仕様と特徴 | grasys blog"
url: "https://blog.grasys.io/post/tsunoda/googlecloudspanner"
description: "こんにちはtsunodaです。 2021年10月、Spannerのバックアップ&復元が正式に改修されてリリースされましたのでちょっとご紹介。 spannerバックアップ&復元やってみる この辺を参考にひとまずもろもろ作成。 gcloudでCloud Spannerを使ってみる バックアップ取得 作成をぽち backu…"
---

# Spanner バックアップ&復元の仕様と特徴

-   ![](/_astro/noicon.CTHOhNiB_1HMs6A.webp)[tsunoda](/authors/tsunoda/)
-   公開日：2021年10月20日
-   カテゴリー：[Tech](/categories/tech/)
-   タグ：[#Google Cloud](/tags/google-cloud/)[#spanner](/tags/spanner/)

![Spanner バックアップ&復元の仕様と特徴](/_astro/og-image.DDSiu2Ny_XHpDd.webp)

こんにちはtsunodaです。  
2021年10月、Spannerのバックアップ&復元が正式に改修されてリリースされましたのでちょっとご紹介。

## spannerバックアップ&復元やってみる

この辺を参考にひとまずもろもろ作成。  
[gcloudでCloud Spannerを使ってみる](https://cloud.google.com/spanner/docs/getting-started/gcloud?hl=ja)

Plain textcontent\_copy

```
復元元
test-spanner001
1node
database: example-db
table: Albums,Singers

復元先
test-spanner002
1node
```

バックアップ取得  
作成をぽち

![Cloud Spannerのバックアップ作成を開始する画面](/_astro/01-14-11-1024x400-1978c9f9.DXFKl5UY_1HH1aO.webp)

backup作成

![Cloud Spannerのバックアップ名と有効期限を設定する画面](/_astro/02-15-12-814x1024-51d9d538.d1n5pWv9_2fHMrK.webp)

開始されています

![Cloud Spannerでバックアップ作成が進行中の画面](/_astro/03-16-7-1024x856-eb9355fa.yxAzK5jX_Z1RYOUS.webp)

backup完了

![Cloud Spannerでバックアップ作成が完了した画面](/_astro/04-17-6-1024x754-e7eb3785.9b1kUmjJ_BA1vo.webp)

test-spanner002で取得したbackupを復元

![Cloud Spannerのバックアップから別のインスタンスへ復元する画面](/_astro/05-18-4-1024x230-5e729bcd.Cr5Teb5U_24gxfb.webp)

完了

![Cloud Spannerのバックアップからの復元が完了した画面](/_astro/06-19-2-1024x230-06640696.DktEcaY8_Z23gfXi.webp)

こんな感じでバックアップ&復元は可能です。

### バックアップ&復元の特徴

2021年10月の改修によって以下の特徴があります。

-   改修後はバックアップ時間が短くなっている。
-   バックアップ機能はユーザーが使用しているインスタンスとは別のインスタンスで実施されており、実際に使用しているインスタンスへの影響はほぼない。
-   バックアップは物理バックアップ的であり、2次利用するには復元する必要があり若干使い勝手が悪いが、取得が速い。
-   インポート/エクスポートは倫理バックアップ的なものであり、CSVやTXTに変換をかけているので2次利用しやすいが、取得が遅い。

という感じです。  
また、使用しているspannerインスタンスではデータの整理や圧縮、健全性維持のための負荷が定期的にかかる仕様となっているようです。  
バックアップ機能は別インスタンスで実施しているため使用しているインスタンスにはほぼ影響が無いものの、実際にバックアップを実施してみると確かに負荷は少しかかっていました。(CPU10~20%程度)  
この辺の負荷についてはnode数を増やすことで対応可能となっております。

もう一点、復元についてですが、復元データのサイズが大きいと復元完了したにも関わらずコンソールで確認できるストレージ利用率に復元元と差異が出ることがあります。(復元先のサイズが小さい)  
これは時間の経過と共に増加していき、最終的には復元元と同じサイズに追いつきます。  
Spanner のストレージレイヤーは複雑になっており、直近に書き込まれたデータ等は in memory に書き込まれる可能性があります（これは Spanner の最適化のアルゴリズムの判断に依存し、必ず in memory にストアされるわけではありません）。  
一方でメトリクスで表示されているデータベースのサイズは実際にストレージに書き込まれたデータからの報告となります。  
なので一定時間の遅れが生じることは想定内の仕様となっています。

きちんと復元が完了したかどうかを確認する際は、対象データベースの状態を確認し、**READY** 状態であれば完了とするようにしましょう。

Plain textcontent\_copy

```
$ gcloud spanner databases list --instance test-spanner002
NAME        STATE
example-db  READY
```

#### 料金について

バックアップの料金は、  
単位時間あたりのバックアップで使用されるストレージの量に基づいて課金されます。  
作成が完了したバックアップには、最低でも 24 時間分の料金が発生します。  
バックアップを作成し、完了してから 1 分後に削除した場合でも、24 時間分の料金が請求されます。  
[spanner料金](https://cloud.google.com/spanner/pricing)

Plain textcontent\_copy

```
[バックアップストレージ料金]
リージョン構成：$0.10（GB 単位/月）
マルチリージョン構成：$0.30（GB 単位/月）
```

ちなみに復元自体は無料です。  
バックアップストレージについては料金がかかるので、復元後不要なら削除しても良いかと思います。

そして復元について気になる仕様が。。。  
**復元先のnode数は、復元元と同じnode数でなければなりません。**

例えば 10node でサービス稼働しているプロジェクトで復元しようとすると、同じように 10node のインスタンスを用意する必要があります。  
復元する際のnode数を見ているので、可能であれば10 → 1nodeへ変更して復元開始をしたいところですが、サービス稼働中となるとそれもできず。。。  
またバックアップ時の負荷も考慮して、結構CPUを使っているサービスであればnode数を一旦増やしてバックアップ取得、node数を戻して復元開始、などといった作業をすることも考えられます。  
spannerは料金が高い というイメージを持っている方もいらっしゃると思います。  
バックアップ&復元について自分のプロジェクトで検討している方はこの辺の挙動、作業内容、料金を考慮する必要がありますやっほい。

## まとめ

実際の作業は分かりやすく、初めて触る方もそこまで迷わず実施できる感じです。  
あとは料金のことを考慮してどうやるか。  
そこまでサイズが大きくなくバックアップもすぐ終われる、CPUにも余裕があるといった場合はメンテナンスに入れてその間に復元まで済ませちゃうのもありかなぁ。  
spannerはGoogleも推している面白いプロダクツなので、検討している方は仕様を確認して是非使ってみては!?

## この記事を書いた人

[![](/_astro/tsunoda.CrA_Wh9V_Z1aOeCP.webp)](/authors/tsunoda/)

### [tsunoda](/authors/tsunoda/)

tsunodaのプロフィールと執筆記事をご覧いただけます。

[プロフィールと記事一覧](/authors/tsunoda/)