この記事では、業務で使えるバックアップの基礎知識を公開します。
バックアップの目的
サーバのバックアップの計画を立案するのは、システム構築時において重要な事項です。バックアップを取る目的は基本的に以下 2 つです。
- システム障害からの復旧
- ユーザの誤操作によるデータ消失からの復旧
システム障害とは、主に HDD 障害 (RAID を組んでいる場合はその想定を超える故障) によりデータが消失してしまうことを指します。また、稀ではありますが、パッチ適用をした後に OS がソフトウェア的に壊れてしまい、リブートでも治らないような状態も含まれます。
ユーザの誤操作によるデータ消失とは、ファイルサーバ上のファイルやメールサーバ上のメールを誤って削除してしまったことを指します。
ディザスタリカバリーとは
ディザスタリカバリー (Disaster Recovery) とは、元々は自然災害等の影響によりダウンしたシステムを復旧させるための準備のことを言い、例えば、遠隔地にバックアップデータを配置し、万が一のときはそちらを使うような構成を指していました。
ところが最近では解釈が拡大されており、『単純なハードウェア障害からの復旧』という意味も含まれるようになっています。OS イメージバックアップの取得を『ディザスタリカバリー』と呼ぶことも多々あります。
後述しますが、スナップショットはディザスタリカバリーの効果はありません。
バックアップの手段
バックアップには大きく分けて以下 3 つの手段があります。
1. ファイルデータバックアップ
ファイルシステム上のフォルダ、ファイル単位でバックアップを取ります。そのため、リストアもファイル単位で可能となります。単純に他のドライブへコピーするだけでもバックアップとなりますが、(NTFS や ext4、XFS 等のファイルシステムの) アクセス権や SELinux のコンテキストが変わってしまう可能性があるため、注意が必要です。
市販のソフトを使うのであれば、Acronis や BackupExec といった製品、OS標準のものであれば robocopy や rsync といったツールを使えば、アクセス権への対応も可能です。
また、フルバックアップ、差分バックアップ、増分バックアップ、といった設定も簡単にできるようになります。
2. イメージバックアップ
ファイルデータバックアップだと、OS がファイルシステムとして認識できる領域のみバックアップが可能ですが、システム予約領域などはバックアップできません。
OS が壊れた際にもとに戻せるようにするためには、OS 領域含めたドライブ全体のイメージバックアップを取得する必要があります。
なのでリストアはドライブ単位になります。基本的にはファイル単位でのリストアはできませんが、取り方によっては、Linux サーバ等からループバックマウントによりファイルを取り出せる場合があります。
取得方法は OS をシャットダウンした状態で手動でバックアップを取得するオフライン方式が主流でしたが、ここ 10 年くらいで「スナップショット」という機能が実用的になり、サーバ稼働中の OS イメージバックアップを取得できるオンライン方式も一般的になってきました。
確実性ではオフラインが勝るものの、サーバを止めずに夜間に自動で取得する、といった手軽さでは圧倒的にオンラインが勝ります。
また、仮想サーバであれば OS イメージ自体がファイルという扱いができるため、さらに手軽にバックアップが可能となっています。
3. スナップショット
スナップショットは「COW (Copy on Write)」という機能を応用した技術です。
あるタイミングでのファイルシステム上のフォルダ配下、もしくはボリューム全体のビットの状態を写真のように時間軸で切り抜いて保存しておく機能です。
バックアップを取得する際、例えばファイルAとファイルBの一部分は互いに同じ情報を持つ必要があるとします。
ファイルAを取得し終わり、ファイルBを取得する前にAとBが更新された場合、バックアップデータとして持っている情報ではAとBで不整合が発生してしまい、うまく復元できない可能性があります。
そのため、スナップショットを使い、ある時間でのファイルAとファイルBの状態を写真で取得し、その写真を元にコピーすることで整合性を保つことができます。
スナップショットの動作としては以下のようになります。
例えばファイルAとファイルBのスナップショットを撮ると、ファイルA'(ダッシュ)、ファイルB'(ダッシュ)、および、スナップショットキャッシュ (スナップショットの管理領域) が生成されます。
ただし、これらは初期状態では情報量を持ちません。ファイルA'は実体は無く、ファイルAへの参照情報のみ持ちます。ファイルB'も同様です。そしてスナップショットキャッシュには、ファイルAやBで情報が更新された際に、その変更分だけ情報が格納されます。
そしてスナップショットをサポートしているファイルシステムでは、あるブロック単位 (例えば 1 KBytes 単位) で変更が有るかどうかを示すフラグ (ビット) を用意しており、ファイルに更新があった場合はそのブロックのそのフラグを 1 にした上で更新し、さらにスナップショットキャッシュに元の情報を書き込みます。
そしてスナップショット上のファイルA'やB'を取得したい場合は、そのフラグが 0 であればファイルAやBの情報を取得し、フラグが 1 であればスナップショットキャッシュの情報を取得します。
スナップショットのイメージバックアップへの適用
このスナップショットを使うことで、一貫性のあるバックアップが取得できるため、前述のオンライン方式のイメージバックアップが可能となります。
具体的には Windows Server Backup ではVSS (Volume Shadow copy Service) というスナップショットを取ることで、オンラインでのバックアップを可能としています。
また、VMware 等の仮想環境では、仮想サーバ自体が (vmdk ファイル等の) ファイルとして管理できるので、ハイパーバイザーが仮想サーバのスナップショットを取得し、それをファイルとしてコピーすることで、障害時の復旧が可能なイメージバックアップがオンラインで取得可能です。
スナップショットの単体利用
スナップショットは単体でも頻繁に使われています。例えば毎日夜間に 1 回スナップショットを取得すれば、万が一データを誤って消してしまった場合であっても、夜間の時点に戻すことができます。
例えば、あるファイルサーバ上でスナップショットを取ったファイル、もしくはフォルダは、Windows PC の Explorer でそのサーバ上のファイルやフォルダを右クリックし、プロパティを開き、「以前のバージョン」タブをクリックすると、スナップショット取得時点の情報が出てきますので、「復元」ボタンを押せば元に戻すことができます。
下記の例では毎日 12 時と 23 時にスナップショットを取得した場合の例です。「開く」ボタンを押すと、復元する前に中身を確認することができます。
つまり、スナップショット単体の機能は、バックアップの目的の 2 番目にある「ユーザの誤操作によるデータ消失からの復旧」には最適です。
また、仮想環境においては、パッチ適用時の「システム不具合からの復旧」にはよく利用されています。パッチ適用前に仮想サーバのスナップショットを取得し、OS のソフトウェア的な不具合が発生した際には元に戻す、という使い方です。
しかし、これらの動きから分かるように、スナップショットは元データが破壊されてしまった場合は元に戻せません。なのでバックアップではない、と主張する人もいます。
その主張もある観点からは正しいですが、このサイトではバックアップの定義としてシステム障害以外への対応も想定しているため、バックアップと考えます。
この章のまとめ
- バックアップを取る目的は「1. システム障害からの復旧」と「2. ユーザの誤操作によるデータ消失からの復旧」の2つ。
- バックアップの方法は大きく3つ。「1. ファイルデータバックアップ」と「2. イメージバックアップ」と「3. スナップショット」。
- ファイルデータバックアップはファイル単位でのリストアが可能なので小回りが利くが、OSの復旧はできない。
- イメージバックアップはOSの復旧が可能だが、取り方によってはリストアはドライブ単位。オンラインで取る場合はスナップショットの機能を利用する。
- スナップショットは単体で利用する場合は「ユーザの誤操作によるデータ消失からの復旧」には最適。ただし、元データを利用するため、ディスク障害があった場合は復元できない。つまり、ディザスタリカバリーとしての効果は無い。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント