はじめに
非機能要件における運用・保守で決めるバックアップ要件について調べてみた。
まとめ
顧客と何をバックアップし復旧はどれくらいで完了してなど顧客とバックアップ要件を合意する必要があり、そのバックアップ要件を満たすバックアップ手法でバックアップを実施する
バックアップ要件
- バックアップに求められる要件は、システム(お客さん)によって異なる
- バックアップに関する要件は、様々な要件があります。お客様のご利用環境に最適なバックアップ方法を検討する上で、何をバックアップし、どのようにバックアップすればよいのかを決める必要があります。
顧客とのバックアップ要件の合意
まず、顧客との合意が必要。
障害から復旧までに求められる条件を顧客と合意する必要がある。
以下具体的な合意する項目例
-
バックアップ目的
- 障害・災害、構成変更時
-
リカバリ時間
- 障害発生から復旧までにどれだけの時間をかけられるか(RTO=目標復旧時間)
- どの時点のデータに復旧すればよいのか(RPO=目標復旧時点)
-
バックアップ対象
- 物理、論理、構成ファイル、DB、ログ
-
取得世代数
- 保持期間、所得回数
-
バックアップ方法
- フル、差分、増分
-
取得媒体
-
費用
-
RTO(目標復旧時間)、RPO(目標復旧時点)を決めることでバックアップ対象、取得先、バックアップ方法、取得周期などほかの決まってくる
-
どれを選ぶかはどの時点のデータを復元できることを保証するか
-
どのくらいの手間と時間で復元するのか
-
アプリケーションの利用者に対するサービスレベル(SLA)で決まる
バックアップ種類
スナップショット、コピーバックアップ(ストレージ内にあるデータのコピー)、レプリケーション
バックアップの方式 どこに
ローカル
ネットワーク
ストレージ内にあるデータのコピー
- コピーバックアップは一般的に、バックアップソフトウェアを用いてデータをコピーします
- 「フルバックアップ」「増分バックアップ」「差分バックアップ」と3つの方式
- 対象
- システム領域、データ領域
- イメージバックアップかファイルバックアップか
イメージバックアップとファイルバックアップ
- ファイル・バックアップとイメージ・バックアップは要件に応じた使い分けが効果的になります。
差分、増分のメリット、デメリット
-
フルバックアップ
- 差分、増分、どちらもフルバックアップが元で考える
-
差分バックアップ
- 前回のフルバックアップから変化分をバックアップ
-
増分バックアップ
- 直前のバックアップからの変化分をバックアップ
コピーバックアップの具体的な方法
バックアップ種別
システムバックアップとデータバックアップ
システムバックアップ
- OS領域のバックアップ
- あれば復旧時はやい。なければOSインストールしてデータをリストアするイメージなので少し時間がかかりそう
- VMwareではどういうイメージ??
データバックアップ
データ領域
コピーバックアップの方法
バックアップ製品を利用したバックアップ
仮想環境やOS環境に依存しないバックアップが可能
OS標準バックアップ
- WindowsServerバックアップ
- dump,restoreコマンド,rsync
- Linuxでのデータバックアップ
- rsyncで手軽にバックアップ
- rsync -av /data /backup
a ファイルのパーミッションを保持してディレクトリ内をまとめてコピー
v コピーするファイルを保持
-
リストア
- 取得したバックアップデータを復元すること。
-
リカバリ
- リストア後に差分パッチを適用して障害発生直前に戻す
この方法は、数年前までは難なく機能していましたが、ストレージに蓄積するデータ量はここ数年で劇的に増加しており、それに加えて24時間稼働し続けなければならないサーバーが増えています。
従って、バックアップが時間通りに完了しない、バックアップ処理がサーバーに負荷をかけてサービスに影響が出る、バックアップのための時間がなかなか取れないといった問題が発生します。 → このためスナップショット
スナップショット
-
ディスク故障など致命的なストレージ障害などに備えるものではなく、誤って重要なデータを失ってしまったり、データの構成に不整合が発生したりといった場合に、適切な状態に戻すための技術がスナップショットです。
-
分かりやすく言えば、スナップショットを取得した「瞬間」のシステム状態(メタデータ)を記録しているだけです。
-
スナップショットはバックアップの一種として、素早くバックアップを作成できるというメリットがありますが、元データが破損している場合には復旧は不可能ということです。
Raidとともに用いる
https://milestone-of-se.nesuke.com/sv-basic/design4backup/snapshot/
スナップショットの仕組み
スナップショットの仕組み
いろんなスナップショット
ハイパーバイザのスナップショットであったり
ストレージの機能のスナップショットであったり、あるいはLVMスナップショット
ある時点のイメージが同一ストレージ内に保存されているだけなので
万一、ディスク故障が発生した場合は、データを復旧することはできません。
LVMスナップショット機能
https://www.nari64.com/?p=892
VMwareのバックアップ
https://www.climb.co.jp/blog_vmware/vmware-7072
https://www.climb.co.jp/blog_vmware/vmware-5392
通常スナップショットは、ソフトウェアアップデートのテストやVM上での安全でない操作のテストに使用され、必要に応じて初期状態に戻ります。ブックマークや取り消しボタンと考えることができます。
スナップショットいつ使うのか
スナップショットはいつ使うべきか
スナップショットは、パッチや更新のためのテスト環境や開発環境で使用される主な短期的なソリューションであり、迅速にテストし、障害が発生した場合にロールバックします。スナップショットは生産はあまり推奨されていません。ただし、実稼働環境でスナップショットが実際に役立つシナリオがいくつかあります。例えば、OSの更新やシステムに影響を与える設定の変更などの危険なアクションを実行すると、スナップショットが有効です。
実稼働環境でスナップショットを推奨しないのはなぜか。主にデータの整合性のためです。スナップショットでは、仮想ハードディスクのコピーを作成していません。VM仮想ディスクとデルタディスクがあります。つまり、VMディスクボリュームが破損した場合、スナップショットはベースディスクにマージできないため、スナップショットも消えてしまいます。スナップショットはディスクからあなたを守るためではなく、単一の障害点があります。
ストレージに障害が発生した場合にVMを復元するには十分ではありません。
レプリケーション
同じデータを丸々複製するので、複製先のストレージコストがかかりま
レプリケーション以外にも通常のバックアップやスナップショットは必要です。
レプリケーションはリアルタイムかそれに近い間隔で複製を作っていくため、たとえば万が一サーバがウイルスに感染していれば、その「感染した状態」も複製してしまうためです。
レプリケーションは主に遠隔地でのデータ保存にも活用されます。日本は地震をはじめとする自然災害とは切り離せない環境にあります。
そこで、遠隔地(国内の安全な地帯や外国)にレプリケーションでサーバの複製を作っておくことで、万が一災害によってサーバ障害が発生しても、迅速に復旧できます。
災害対策にはリモートレプリケーションを
バックアップで大切なこと
「スナップショットしたから大丈夫」「レプリケーションしたから大丈夫」といった考え方は禁物です。先述のように、数あるバックアップ方法にはそれぞれメリットがあれば、デメリットもあるためです。
ディスクの冗長化とバックアップについて
通常、Raidとバックアップを用いる
- 操作を間違ってデータを削除したときの復旧は「RAID」では不可能です
バックアップとは、ストレージ内にあるデータのコピーを作り、万が一ストレージ内のデータが破損した際にコピーを使ってシステムやファイルを復元するためのものです。スナップショットはいわば、こうしたバックアップの一種です。