Oracle Cloud Infrastructureブロック・ボリューム・バックアップDeep Dive

Last updated at 2024-05-13Posted at 2019-12-21

この記事は「Oracle Cloud Infrastructure Advent Calendar 2019」の12月22日の記事として書かれています。

1. はじめに

Oracle Cloud Infrastructure Computeでバックアップ／リカバリしたことがあるだろうか？　とくに本番システムでは重要なのに、紹介している記事があまり見当たらない。あっても、マニュアルと大差ないものが多いように感じる。

そこで今回は、Oracle Cloud Infrastructure Computeにおけるバックアップ／リカバリ方法について書いてみようと思う。なお、内部構造は公開されていないので、一部推測で書いている。また、Oracleデータベースのバックアップは複雑なので今回は触れない。

1-1. TL;DR

バックアップは重要なのにQiitaを含め紹介記事が少ない
オンプレミスとクラウドではバックアップ手法が異なる
ブロック・ボリュームのバックアップ方法が複数ある
バックアップの仕組みを理解していないと、期待したバックアップを取得できない可能性がある

1-2. 使用環境

Oracle Cloud Infrastructure Compute（AWSでも通用する部分は多いはず）
Oracle Linux 9 / CentOS 9
Oracle Linux 8 / CentOS 8
Oracle Linux 7 / CentOS 7
Oracle Linux 6 / CentOS 6
Windows Server 2016 Standard

上記以外のオペレーティングシステムでも本記事の内容は有効だ。しかし、DenseIOシェイプのLocal NVMeはバックアップ機能の対象外（ブート・ボリュームは対象）。

1-3. 参考情報

日本語マニュアル

英語マニュアル

その他

2. ブロック・ボリューム・バックアップの基本

Oracle Cloud Infrastructureのブロック・ボリュームには、AWSのEBS Snapshotに類似したバックアップ機能がある。このバックアップ機能を利用すると、簡単にストレージをバックアップできる。

2-1. バックアップ機能の特徴

おもな特徴は以下のとおり。基本的なことは、冒頭の参考情報で紹介した「Oracle Cloud Infrastructureマニュアル」や「Block Volume FAQ」を読んでもらうとして、今回は青文字の項目を説明する。

バックアップ開始時点のポイント・イン・タイム・バックアップ
クラッシュ・コンシステントなバックアップなので静止点を取ることを推奨
ブート・ボリュームとブロック・ボリュームが対象
暗号化されてオブジェクト・ストレージに格納
フルバックアップと増分バックアップ
ボリューム・グループを使用すると、複数ボリュームにわたった一貫性のあるバックアップを取得できる
バックアップは別リージョンにコピーできる
手動実行とポリシーベースの自動実行
保存期間や世代は無制限
リストアするときは、バックアップを元に新規ボリュームとして作成

3. ポイント・イン・タイム・バックアップを理解する

ブロック・ボリュームのバックアップは、ポイント・イン・タイムで取得される。どのような仕組みになっているのか理解することは重要だ。

3-1. バックアップのアーキテクチャー

下記の図はバックアップの内部アーキテクチャーを表したものだ（推測モード）。

管理コンソールやREST API等でバックアップを指示したあと、ステータスが「REQUEST_RECIEVED」になった時点のバックアップを取得できる。特定の一時点であることからポイント・イン・タイムと呼ばれている。

またオブジェクト・ストレージへのバックアップはバックグラウンドで実行される。FAQによると、バックアップが完全に終了するまでの目安は2TBで約30分とのこと。

3-2. 静止点の確保

バックアップで気になるのは静止点だろう。Oracle Cloud Infrastructureでは、下図のように一時的に書き込みを禁止することで静止点を確保している。

この仕組みのうまいところは、バックアップを2つのフェーズに分けることで、システムへの影響を最小限に抑えていることだ。

第1フェーズ：静止点を維持してる間は物理ディスクに対する書き込みを停止
第2フェーズ：静止点を取ったあとに、オブジェクト・ストレージへのバックアップを開始

試しに静止点を維持している間にO_DIRECTでファイルシステムに書き込んだところ、I/O待ちにならなかった。手順が悪いのか、瞬間で気付かないのか、それとも仮想サーバーなどのキャッシュが使われていたのだろうか。

dd if=/dev/zero of=＜ファイル＞ bs=1M count=＜回数＞ ofrag=direct

3-3. スナップショット or バックアップ

Oracle Cloud Infrastructureのブロック・ボリューム・バックアップは、AWSのEBS Snapshotと、ほぼ同じ仕組みだと思われる。そしてスナップショットと聞くと「スナップショットはバックアップではない」という人もいるかもしれない。そのあたりの仕組みを説明する。

NetAppなどのストレージが持つ「スナップショット機能」は巧妙に差分情報を取っている。そのためバックアップ時間やディスク容量を劇的に削減できる。ただし差分しか持っていないので、元となるディスクが破損するとリカバリーできない。

それに対してOCIのブロック・ボリューム・バックアップは、スナップショットとバックアップ両方の利点を活用し、次のように実装していると思われる。当然推測モード。

第1フェーズ：「ストレージへの書き込み禁止」と「KVMのライブスナップショット機能」でストレージレベルで静止点のあるスナップショットを短時間に作成する
第2フェーズ：取得したスナップショットを元に、そのスナップショットが参照する実データをオブジェクト・ストレージへコピーする

3-4. まとめ

ブロック・ボリューム・バックアップはポイント・イン・タイムで取得される
バックアップは2つのフェーズで構成され、静止点を取ったあとは、バックグラウンドで実行される

4. クラッシュ・コンシステントを理解する

静止点を取っていても安心してはいけない。マニュアルにはBest Practicesとして次のように書いてある。

Before creating a backup, you should ensure that the data is consistent: Sync the file system, unmount the file system if possible, and save your application data. Only the data on the disk will be backed up.

可能ならば、ファイルシステムをsyncもしくはアンマウントしてデータの一貫性を確保すべきだと。

4-1. クラッシュ・コンシステントとは

実は、ブロック・ストレージのバックアップはクラッシュ・コンシステント（クラッシュ整合性）という状態だ。わかりやすく言い換えると**「電源強制切断」状態**である。

このようになる理由は、バックアップ機能の仕組みに起因している。下図のような仮想サーバー環境では、ディスクイメージをバックアップしていることをゲストOSは認識できない。そのためゲストOS内で開いているファイルや変更されたキャッシュなど、メモリだけに存在するデータはバックアップに含まれない。

4-2. バックアップの整合性レベル

バックアップ（スナップショット）の整合性は、おもに以下の3つのレベルがある。これを見ると、マニュアルにsyncやアンマウントと書かれている理由がわかるだろう。詳しくは下記資料を参照のこと。

クラッシュ・コンシステント（クラッシュ整合性）: 電源強制切断と同じ。近年のファイルシステムはジャーナリング機能があるので修復できないほどは壊れないが、一部のデータはリカバリー処理で損失する可能性がある。
ファイルシステム・コンシステント（ファイルシステム整合性）: ファイルシステム全体で一貫性があること。キャッシュをsyncして、メモリ上の変更がディスクに反映している状態。一般的なデータの損失はない。しかしDBなどは、つねに書き込み、独自の整合性機能を持っているので、この整合性では不十分なことがある。
アプリケーション・コンシステント（アプリケーション整合性）: アプリケーションの特性まで考えた一貫性。OSやアプリケーションの機能を利用した、完全に一貫性のあるバックアップ。

参考資料：

実は、このあたりの機能はWindowsのVSS（Volume Shadow Copy Service）が優れている。簡単に一貫性のあるバックアップを取得できるだけでなく、スクリプトを組み合わせてアプリケーション・コンシステントを実現できる。

また仮想サーバー環境ならば、vSphereのVMware ToolsやKVMの**qemu-guest-agent**を利用すると、Linuxでもファイルシステム・コンシステントを実現できる（ただしVSSほど賢くない）。しかし、Oracle Cloud Infrastructureのバックアップ機能は対応していない。AWSのEBS Snapshotも似たような状況なので問題があるのか。

4-3. クラッシュ・コンシステントの対策

クラッシュ・コンシステントを理解したところで対策を考えてみよう。整合性を高めるには以下の方法がある。なお、アプリケーション・コンシステントは利用しているソフトウェアに依存する。そのため、今回は考慮外にする。

ファイルシステムをアンマウントする
ファイルシステムをリードオンリーとしてリマウントする
fsfreezeやxfs_freezeコマンドでファイルシステムへのI/Oを停止する
syncでキャッシュの内容をディスクに書き出す
カーネルパラメータをチューニングする

この中で1～3は強力だが、制限事項やデメリットもある。それぞれについて説明する。なお、独断と偏見の評価は次のとおり。

対策	ルート・ファイルシステム	整合性	可用性※	備考
アンマウント/リマウント	非対応	高い	影響あり	使用しているファイルがあると失敗する
fsfreeze/xfs_freeze	非対応	高い	影響あり
sync	対応	完全ではない	影響なし
カーネルパラメータ	対応	気休め	影響なし

※ 「影響あり」は、ブロック・ボリューム・バックアップが静止点を取っているあいだ、ディスクI/O停止もしくはサービスを停止する必要がある。

ブート・ボリュームの対策は？
ブート・ボリュームは抜本的な対策ができないのと、数分前に戻るくらいの損失は許容できることも多いので、積極的に対策しない考えもある（こっちの方が多いハズ）。

どうしても高い整合性が必要ならば、ブロック・ボリュームを追加して、整合性が必要なデータを配置すべきだろう。

4-3-1. アンマウント／リマウント

ファイルシステムを**アンマウント（umount）もしくはリードオンリーでリマウント（remount）**すると、完全に一貫性を持った状態になる。ただし、ルート・ファイルシステムは対象外で、また対象ファイルシステムを利用しているプロセスやユーザーがいると失敗する。

次のようにブロック・ボリューム/dev/oracleoci/oraclevdb1を/mnt/vol01にマウントしている環境で考える。

# findmnt -s
TARGET     SOURCE                                    FSTYPE OPTIONS
/          UUID=e5a0d6d8-6141-4c6d-a2f7-ebe65eb7513a xfs    defaults,_netdev,_netdev
/boot/efi  UUID=A2CF-0CCB                            vfat   defaults,uid=0,gid=0,umask=0077,shortname=winnt,_netdev
swap       UUID=ffa35d76-0947-49fe-b030-3bf270640b7a swap   defaults,_netdev,x-initrd.mount
/mnt/vol01 /dev/oracleoci/oraclevdb1                 xfs    defaults,_netdev,nofail

この方法を利用した手順は次のようになる。

# ファイルシステムをリードオンリーでリマウント
mount -o remount,ro /mnt/vol01

# ★ここでブロック・ボリューム・バックアップを取得する

# CLIのレスポンスが戻ってくる、もしくはステータスがCREATINGになったら
# ファイルシステムをリードライトでリマウント
mount -o remount,rw /mnt/vol01

ただし/mnt/vol01上のファイルをつかんでいるプロセスがあると、次のエラーでリマウントできない。

# mount -o remount,ro /mnt/vol01
mount: /mnt/vol01 is busy

このようなエラーが発生したときはfuserやlsofでプロセスを特定して対処する。fuserがインストールされていないときはpsmiscパッケージをインストールしよう。

PID=12187のプロセスがつかんでいる

# fuser -m /mnt/vol01
/mnt/vol01:          12187

umount -fやumount -lを使えば強制アンマウントできる可能性はある。しかし整合性を保つことが目的なので、やらない方がいいだろう。

4-3-2. fsfreeze/xfs_freeze

fsfreeze/xfs_freezeはファイルシステムのI/Oを一時停止する機能だ。ルート・ファイルシステムは対象外だが、アンマウント／リマウントとは異なり、つかんでいるプロセスに邪魔されることはない。

fsfreezeとxfs_freezeは、いずれもext3/ext4/XFSファイルシステムに対して実行可能だ。

RHEL7マニュアル: ストレージ管理ガイド

fsfreezとxfs_freezeは同じ文法

fsfreeze -f ＜マウントポイント＞　# 書き込み停止
fsfreeze -u ＜マウントポイント＞　# 書き込み再開

xfs_freeze -f ＜マウントポイント＞　# 書き込み停止
xfs_freeze -u ＜マウントポイント＞　# 書き込み再開

fsfreezeを使ってスクリプトを組むと次のようになるだろうか。

# manを読むと不要っぽいが、念のためキャッシュ書き込み
sync

# ファイルシステムのI/Oを一時停止
fsfreeze -f マウントポイント

# ★ここでブロック・ボリューム・バックアップを実行

# CLIのレスポンスが戻ってくる、もしくはステータスがCREATINGになったら
# 一時停止を解除
fsfreeze -u マウントポイント

4-3-3. カーネルパラメータのチューニング

対応策としては弱いが、ダーティーなキャッシュを減らすようにカーネルパラメータを設定する方法もある。チューニングするのは次のパラメーターだ。

パラメータ	説明
vm.dirty_ratio	ダーティーなページの割合が指定した割合を超えると、優先度の高いフォアグラウンドでページを書き出す。デフォルトは20
vm.dirty_background_ratio	ダーティーなページの割合が指定した割合を超えると、優先度の低いバックグラウンドでページを書き出す。デフォルトは10

あまり小さな値に設定するとパフォーマンスに影響するが、RHEL6のマニュアルではDBワークロードに「dirty_ratio=15, dirty_background_ratio=3」を推奨していた。ここでは少し攻めて「dirty_ratio=10, dirty_background_ratio=3」にしてみよう。

現在の値を確認する。

# sysctl -a | grep vm.dirty
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10　★
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20 ★
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200

2./etc/sysctl.confに追記して有効化する。なお、Oracle Linux 7以降では/etc/sysctl.d/99-sysctl.confも導入されているが、/etc/sysctl.confのシンボリックリンクなので、どちらを修正しても問題ない。

cat << _EOL_ >> /etc/sysctl.conf
vm.dirty_ratio = 10
vm.dirty_background_ratio = 3
_EOL_

sysctl -p

注意：tunedに気を付ける
tunedはLinuxのOSパラメータをチューニングするデーモンだ。tunedで同じパラメータを設定しているとsysctlの設定が上書きされる。

パラメータの優先順位：
　ソース＜ /etc/sysctl.confなど＜ tuned

RHEL7「パフォーマンスチューニングガイド」第3章 TUNED

tunedを確認するとサービスが有効になっている。

# systemctl is-active tuned
active

2.Oracle Cloud Infrastructure Computeでは次のプロファイルが有効になっている。

# tuned-adm active
Current active profile: oci-rps-xps oci-busy-polling oci-cpu-power

3.プロファイルの設定値は/usr/lib/tuned/*のファイルで確認できる。いずれのプロファイルもdirty_ratioとdirty_background_ratioを使っていないので影響はない。

4.以下のように他のプロファイルでは使っていることもあるので要注意。なお、プロファイルには継承機能があるので、念のため該当のtuned.confを確認したほうがいいだろう。

# find /usr/lib/tuned -name "*.conf" |xargs grep -e vm.dirty.*ratio
/usr/lib/tuned/latency-performance/tuned.conf:vm.dirty_ratio=10
/usr/lib/tuned/latency-performance/tuned.conf:vm.dirty_background_ratio=3
/usr/lib/tuned/throughput-performance/tuned.conf:vm.dirty_ratio = 40
/usr/lib/tuned/throughput-performance/tuned.conf:vm.dirty_background_ratio = 10
/usr/lib/tuned/virtual-guest/tuned.conf:vm.dirty_ratio = 30
/usr/lib/tuned/virtual-host/tuned.conf:vm.dirty_background_ratio = 5

4-3-4. sync

syncは、キャッシュだけで変更されたブロックを強制的にディスクに書き込むコマンドだ。シングルユーザー利用でサービス／デーモン系プログラムが無いならば有効性は高い。しかし、それ以外の環境で大きな期待は禁物だ。

Windowsには無い機能だと思ったら、Windows Internals - Syncで公開されていた。WindowsにはVSSがあるので必要性は微妙だが。

4-4. まとめ

現時点のOCIのバックアップ機能では、強制電源切断と同じクラッシュ・コンシステントな状態でバックアップされる
クラッシュ・コンシステントでは、最新データが反映されていない可能性がある
より整合性を高めるには、ファイルシステムのアンマウントやfsfreezeで静止点を取るなどの対策が必要になる
データベースなど常時書き込みがあるソフトウェアでは「まったく別の手法」や「複数の手法の組み合わせ」を考える必要がある

5. フルバックアップと増分バックアップ

Oracle Cloud Infrastructureのブロック・ボリューム・バックアップでは、「フルバックアップ」と「増分バックアップ」ができる。オンプレミスとは異なる挙動もあるので、十分理解する必要がある。

5-1. バックアップの種類と特性

ブロック・ボリュームのバックアップには**「フル」と「増分」**がある。それぞれの違いは次のとおり。

フル（Full）: ボリュームを作成してからのすべての変更が含まれる
増分（Incremental）: 前回のバックアップ以降の変更が含まれる

ここで重要なことはフルバックアップの「ボリュームを作成してからのすべての変更」という記述である。

たとえば「16TBのブート・ボリュームを作成して、40GB変更したときは、フルバックアップのサイズは40GBになる」。フルバックアップでも、バックアップに必要なのは使用している領域だけだ。

下図はフルバックアップと増分バックアップの実行例だ。フルバックアップしていなくても増分バックアップを実行できるが、そのときには同じバックアップ内容になる。

ブロック・ボリュームのバックアップには不思議な特性がある。下図のようにフルバックアップと増分バックアップを組み合わせたとき、「フル1」が無くなるとリカバリーできなくなるのが一般的だ。ところが「フル1」を削除しても「増分1」～「増分3」のポイントにリカバリーできる。

EBS black beltを読むと、「フル1」を削除しても「増分1」が内部的にフルバックアップの情報を保持しているらしい。また実際にテストすると、途中の増分が無くなっても、その前後のポイントにはリカバリーできる。

5-2. まとめ

バックアップには「フル」と「増分」がある
フルバックアップに必要なサイズは実際に使用している領域で、ブロック・ボリュームのサイズは関係しない
増分バックアップには、前回バックアップ以降の変更が含まれる
途中の「フル」や「増分」を削除しても、他のバックアップには影響しない

6. バックアップのリストア

オンプレミスのリストアでは、元の領域を上書きして戻すことが多い。それに対してクラウドでは、クラウド側に十分なディスクがあり、バックアップ手順も簡単なため、別のディスクとして作成する仕組みになっている。

6-1. リストアの基本

下図はリストア手順を表している。バックアップは直接利用できないので、バックアップから新規ブロック・ボリュームを作成して利用する。

6-1-1. ブロック・ボリュームのリストア手順

バックアップしたボリュームを使うには、次の手順が必要になる。

バックアップから新規ブロック・ボリュームを作成
アタッチしていたブロック・ボリュームをデタッチ
新しく作成したブロック・ボリュームをインスタンスにアタッチ
ファイルシステムをマウント
古いブロック・ボリュームは不要ならば削除。障害解析などの目的で他のインスタンスにアタッチしてもOK

リストア時の補足事項

リストアするときには、元のブロック・ボリュームより大きいサイズを指定できる（リストア後パーティション拡張が必要）
リストアしたブロック・ボリュームを同じインスタンスにアタッチするときは、パーティションIDを変更する必要がある（Linuxのみ）

6-1-2. ブート・ボリュームのリストア手順

ブート・ボリュームも基本的には同じ手順だ。ただしブート・ボリュームのバックアップからブロック・ボリュームを作成したときは、起動用のボリュームとして使えない。起動用のボリュームとして使うときは、バックアップから新規インスタンスを作成する。

6-2. 同じIDのボリュームをマウントする

リストアしたブロック・ボリュームを使うには、次のどちらかの操作が一般的だ。

元のブロック・ボリュームと置き換える
他のインスタンスにアタッチする

しかしファイルの内容を比較したいなどの理由で、元のブロック・ボリュームをマウントしたまま、リストアしたボリュームをマウントしたいことがある。Windowsならば問題ないが、Linuxではエラーが発生してマウントできない。

mountコマンドを実行すると次のエラーメッセージが表示される。

mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

6-2-1. マウントに失敗する理由

原因は「元のボリューム」と「リストアしたボリューム」のUUIDが同じだからだ。確認するとsdb1とsdc1が同じUUIDになっている。

# lsblk -o +UUID
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT UUID
sda      8:16   0 46.6G  0 disk
├─sda2   8:18   0    8G  0 part [SWAP]     2b8d2b93-1d28-4fe9-a756-c0d465698bfd
├─sda3   8:19   0 38.4G  0 part /          85536b94-5d7b-45a2-88b7-5ff5242aae26
└─sda1   8:17   0  200M  0 part /boot/efi  B8DB-0DE3
sdb      8:0    0  200G  0 disk
└─sdb1   8:1    0  100G  0 part /mnt/vol01 e796d24d-60b6-4273-ad2a-4f92862c82e2
sdc      8:32   0  200G  0 disk
└─sdc1   8:33   0  100G  0 part            e796d24d-60b6-4273-ad2a-4f92862c82e2

6-2-2. UUIDを変更する

対応策は、リストアしたボリュームのUUIDを変更することだ。UUIDはxfs_adminもしくはtune2fsで変更できる。文法は以下のとおり。uuidgenを囲っているのはバッククォートなので注意。

XFSのとき
  xfs_admin -U `uuidgen`  <デバイス名>

ext3/ext4のとき
  tune2fs -U `uuidgen`  <デバイス名>

実際に実行すると以下のように表示される。UUIDを変更すればマウントできるようになる。

# xfs_admin -U `uuidgen` /dev/oracleoci/oraclevdc1
Clearing log and setting UUID
writing all SBs
new UUID = 23b63c30-a5c4-4aff-9bc1-b844bdbeb2ec

ヒント
永続的に使用するならば前記のようにUUIDを変更したほうが好ましい。しかし暫定的に同じUUIDのボリュームをマウントする方法としてはmount -o nouuidオプションを使用する方法もある。

6-3. ファイルシステムのメタデータ破損を修復する

リストアしたボリュームは、通常問題なくマウントできる。しかしバックアップは「クラッシュ・コンシステント」なので、まれにファイルシステム破損でマウントできないことがある。

ファイルシステム破損でマウントできないときは修復する必要がある。次のメッセージは、XFSファイルシステムの修復が必要でマウントできないときのものだ。

ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_admin.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.

ファイルシステムを修復するには、XFSではxfs_repair、ext3/ext4ではfsck/e2fsckを使用する。文法は次のとおり。

XFSのとき
  xfs_repair -L  <デバイス名>

ext3/ext4のとき
  e2fsck -V <デバイス名>

次の画面は、実際にXFSを修復したときの出力だ。

# xfs_repair -L /dev/oracleoci/oraclevdd1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
        - zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
        - scan filesystem freespace and inode maps...
sb_fdblocks 26167264, counted 26175456
        - found root inode chunk
★以下省略

次のマニュアルはブート・ボリュームが破損したときの修復手順だが、ブロック・ボリュームでも一部の内容は流用できる。

6-4. まとめ

バックアップをリストアするときは、新規ブロック・ボリュームとして作成する
ブート・ボリュームのバックアップは、新規ブロック・ボリュームとして作成できるだけでなく、新規インスタンスとしても作成できる
バックアップはクラッシュ・コンシステントなので、リストアしたボリュームが破損してマウントできないことがある。そのときにはファイルシステムの復旧を試みる

7. バックアップ機能、その他もろもろ

ここでは、1つの章にするほどの文章量が無いことをいくつか紹介する。

7.1. クローンとの違い

Oracle Cloud Infrastructureにはクローンというボリュームを複製する機能がある。バックアップと似ているが、用途が違うことを理解する必要がある。

マニュアルにdisk-to-disk deep copyと書いてあるように、ボリュームの完全な複製である。他の仮想化プロダクトにおけるフル・クローンであり、リンク・クローンではない。インスタンスを複製したいときに利用する。

7.2. カスタム・イメージ

カスタマイズしたオペレーティング・システムをテンプレート化できるカスタム・イメージという機能がある（AWSのカスタムAMIに相当）。

ある程度固定化した構成のときは、バックアップではなく、カスタム・イメージで対応する方法もある。ただしカスタム・イメージの最大数は「Monthly Flex：100、PAYG：25」と限られているので、運用にマッチするか検討する必要はある（サービス・リミットの最大値）。

7.3. ボリューム・グループ

これまで単一ボリュームのバックアップにおける「ポイント・イン・タイム」と「クラッシュ・コンシステント」を説明した。しかしエンタープライズ・システムの中には、複数ボリュームにわたる一貫性を維持したいことがある。

このようなときに利用できるのが「ボリューム・グループ」だ。ボリューム・グループには、ブート・ボリュームとブロック・ボリュームの両方を含められるだけでなく、さらに複数インスタンスや複数コンパートメントのボリュームも含められる。

ボリューム・グループを作成すると、ボリューム・グループ単位で「ポイント・イン・タイム」で「クラッシュ・コンシステント」なバックアップもしくはクローンを作成できる。

おもな特性は以下のとおり。少し複雑な部分もあるので、実際に挙動を確認してから使った方がよいだろう。

1つのボリューム・グループあたり、最大32ボリューム、最大128TBまで追加できる
各ボリュームが属するのは、1つのボリューム・グループに限られる
ボリューム・グループを削除しても、グループ内のボリュームは削除されない
ボリュームを削除するときは、属しているボリューム・グループから先に除外して、それから削除する

7.4. ポリシーベースのバックアップ

ポリシーベースのバックアップを利用すると、自動でバックアップを管理できるようになる。バックアップの作成だけでなく、削除まで自動化できるので便利だ。

また2019/11からは、実行時間や保存期間などのポリシーをカスタマイズできるようになった。

ただしクラッシュ・コンシステントであることは変わりないので、より高い整合性が必要なときにはスクリプト化などの検討が必要だ。

AWSやAzureでは、バックアップの前後でスクリプト呼び出しが可能なソリューションを提供している。OCIでも、今後に期待したい。

7.5. 透過的なオブジェクト・ストレージへのアクセス

オブジェクト・ストレージにアクセスするには、次の2つの条件を満たす必要がある。

バケットが作成してあること
バケットにアクセス権限があること

ブロック・ボリュームのバックアップは、特別なオブジェクト・ストレージ領域に格納される。そのため前記の条件を満たさなくてもバックアップ機能を利用できる。ただし、バックアップ機能を利用するIAMポリシーは必要である。

#8. ほかのバックアップ方法は？

これまでOracle Cloud Infrastructure Computeのバックアップ機能を説明してきた。しかし、他にも多くの選択肢があり、最適なバックアップには全体像の理解が欠かせない。そこで簡単に振り返ってみたい。

8-1. バックアップ方法の選択肢

バックアップには多くの選択肢がある。

クラウドのバックアップ機能（ボリューム・バックアップ、クローン、カスタム・イメージ）
CommvaultやNetBackup、Oracle Secure Backupなどの商用バックアップソフト
BaculaやAmanda
などのOSSバックアップソフト（商用版あり）
cp/tar/cpio/rsyncなどOSコマンド

8-2. バックアップ方法ごとのメリット／デメリット

クラウドの標準機能

「手動／自動」や「フル／増分」などのバックアップが簡単にできる
オブジェクト・ストレージへバックアップできる
ポイント・イン・タイムなバックアップを短時間に取得できる
クラッシュ・コンシステントなバックアップなので、その特性を理解して使う必要がある
高い整合性が必要なときや複雑な要件があるときは、スクリプトやジョブなどを開発する必要がある
DenseIOシェイプのLocal NMVeはバックアップ機能の対象外

商用/OSSのバックアップ・ソフトウェア

オンプレミスとクラウドのハイブリッド環境を統合的に管理できる
複数リージョン／複数コンパートメントにまたがったデータを統合的にバックアップできる
個別のエージェントを使用して、オペレーティング・システムやミドルウェアごとに最適なバックアップができる
ファイル単位や更新されたファイルだけ、といった細かな制御ができる
クラウド・ストレージに対応した製品はオブジェクト・ストレージを利用できる
商用製品の場合、ライセンス費やサポート費が必須になる
競合するマネージドサービスが将来提供される可能性がある

9. おわりに

Advent Calendar掲載で1回にまとめようと思ったら、大作になってしまった。

日々コツコツと書き続けて3週間近く。画面出力を除いて10,000文字オーバー。当初は「データベースのバックアップ」や「OSSのバックアップ・ソフト」も軽く触れる予定だったけれど、完全にスタミナ切れ。タイムリーな別記事をパラで書いたしね。

「Just Right!」+「TC日本語スタイルガイド」+「共同通信社記者ハンドブック校正辞書 for Just Right!」にも助けられた。高かったけれど、Qiitaデビューのために買ってよかった。用字は全部従っていないけどね。

また、以前に担当していただいた編集者K氏の教えも大きい。感謝！

間違っている！タイポがある！こんなことを書いてほしい！などあったら、気軽にコメントお願いします。

10. まとめ

理解するべきバックアップの特性

ブロック・ボリューム・バックアップはポイント・イン・タイムで取得される
バックアップは2つのフェーズで構成され、静止点を取ったあとは、バックグラウンドで実行される
現時点のOCIのバックアップ機能では、強制電源切断と同じクラッシュ・コンシステントな状態でバックアップされる
クラッシュ・コンシステントでは、最新データが反映されていない可能性がある
より整合性を高めるには、ファイルシステムのアンマウントやfsfreezeで静止点を取るなどの対策が必要になる
ボリューム・グループを使用すると、複数ボリュームにまたがった「ポイント・イン・タイム」で「クラッシュ・コンシステント」なバックアップもしくはクローンを作成できる
データベースなど常時書き込みがあるソフトウェアでは「まったく別の手法」や「複数の手法の組み合わせ」を考える必要がある

フルバックアップ／増分バックアップ*

バックアップには「フル」と「増分」がある
フルバックアップに必要なサイズは実際に使用している領域で、ブロック・ボリュームのサイズは関係ない
増分バックアップには、前回バックアップ以降の変更が含まれる
途中の「フル」や「増分」を削除しても、他のバックアップには影響しない

リストア

バックアップをリストアするときは、新規ブロック・ボリュームとして作成する
ブート・ボリュームのバックアップは、新規ブロック・ボリュームとして作成できるだけでなく、新規インスタンスとしても作成できる
バックアップはクラッシュ・コンシステントなので、リストアしたボリュームが破損してマウントできないことがある。そのときにはファイルシステムの復旧を試みる

その他

ポリシーベースのバックアップでは、自動でバックアップを管理できる
バックアップは「変更領域だけをオブジェクト・ストレージに保存」であるのに対し、クローンは「ブロック・ストレージへのフル・クローン」である

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up