データのバックアップを考えるのは大変ですよね。
セキュリティとバックアップは考え出すとキリがなくて、出費も青天井になる2大巨頭だと思っています。
それゆえに施策者が「ここまでやる。」という水準を決めてブレないように実施しなければ、時間も費用も手間も掛かる割には効果が感じられない、後に残るのは疲弊感だけという報われない業務になりがちです。
経験則で恐縮ですが、バックアップで抑えたいポイントや思考の部分をご紹介します。
OS部分：イメージバックアップ
ミドルウェア：イメージバックアップとファイルバックアップ
データ：ファイルバックアップ
イメージバックアップはAcronisやSymantecなどが有名な老舗で、最近はWindows標準の「Windowsバックアップ」などで結構身近な存在になっています。
実際の管理業務ではOS部分のバックアップはイメージバックアップソフトウェアによる丸ごと収集の処理に任せてしまうことになります。単純です。
一方、伝統のファイルバックアップはどんな道具（ツール）を使うか、で効率が変わってくる部分ではあります。故に複雑です。
また、ロックファイルをどのように収集するか、が課題になりますので、Agentタイプのバックアップソリューションを用意する必要があるかどうか、という部分に判断が分かれるところです。
と、ここまで書いておいてこのようなことを言い出すのは心苦しいのですが、道具の話になると、キリがなくなってしまいますし先人たちがあちこちで比較を掲載してくれています。
どんな道具を使うにしろ、またイメージバックアップもファイルバックアップも問わない汎用的な（もしくは基礎となる）使える知識と考え方をここに書き出してみたいと思います。
「バックアップの取り方を議論する前に、どのような復旧が必要とかを議論する。」
まずここに尽きると思っています。（バックアップは復旧するために取得するデータ、ということです。）
過去の私もやらかしていましたが、バックアップの収集が打ち合わせのメインテーマになってああでもないこうでもない、と不毛な議論になり、疲弊してきたところで「結局どれをどういうタイミングで取ればいいかはシステムオーナー（エンドユーザ）にしかわからない。」という転嫁によって逃げたくなってきます。
気持ちはすごく分かるのですが、システムオーナーは企業内のデータについてバックアップを考えたことがないので、元システム部門の社員でもない限り答えを教えてくれることがありません。
バックアップ対象のデータが全部なくなったところからどれくらい前にデータの状態が巻き戻しされても許容できるか？
まずはここから考えた方が課題を整理しやすくなります。
例えば毎日ファイルが変更されるファイルサーバのデータを復旧させる場合、復旧したデータが1か月前というのは少々巻き戻りすぎとエンドユーザは考えると思います。（単純に考えて月次の処理で使った共有データが前月分消えてしまうことになりますから）
1か月前より1週間前、1週間前より1日前、もっとシビアな環境では数時間前、といった具合に復旧時に巻き戻るタイムラグが少なければ少ないほど良い、というのは間違いありません。
まずは日々の変更が蓄積されるバックアップが必要ということになります。
次の"例えば"は、更新頻度の低い（利用頻度の低い）重要なデータの場合です。
月一回程度しか利用しないデータはやはり企業であれば存在します。長いと四半期ごとや半期、もっと長いと年一回ということもあります。
こういった更新頻度の低いデータは重要であっても、単純に1日前の状態に復旧するだけでは要件として不足することがあります。
更新頻度が低い故に、データ破損やヒューマンエラー（誤って上書きされた、のような）の発見が遅れる傾向にあるからです。
こうなると、業務の周期を元に前回以前の業務で利用し更新した時点まで巻き戻せる必要がある、ということになります。
つまり業務の更新単位でバックアップを実行して世代管理することで、「誤って前回データを破損した、上書きした。」という事態に対処できることになります。
ここまでで巷でよく言われる「RAIDはバックアップではありません。」といわれる理由が理解出来た貴殿はとても優秀です。
RAIDは世代を管理したり○日前と遡ったのデータを切り出して復元する、ということはできないからバックアップになり得ない、ということです。
ここまでをまとめると、どのくらいのデータを失っても許せる/許されるか、という言い方もできます。
バックアップのインフラ設計やバックアップ手法の検討前に、バックアップ対象となるデータについて考えておくことで、要求されるスペックや費用の掛けドコロが見えてくる、はずです。
データを失わないための理想形は
「更新されたデータは即収集、更新される前の元データを世代管理でアーカイブ（コピー）する。」
ということで、データロストしたら最新から復旧、更新されたデータが誤っているのならアーカイブから前の世代のデータを取り出して復旧、ということが可能になりデータが失われないことになります。
でも、掛けられる予算と時間には限りがあります。（いつだってお金と時間は有限です。）
掛けられるお金と時間が制約となって、どんなバックアップを実行するか、理想と現実の折衷案を用意してすり合わせることになります。（バックアップ担当の腕の見せ所です。）
多数派のバックアップ方法は
フルバックアップ（全部バックアップ）を定期的に実行して、フルバックアップより短い周期で差分バックアップを実行する。
これがよく見かけるバックアップです。
バックアップ用のストレージが少ない場合差分バックアップが増分バックアップになっていることもあります。
「定期的」と表記した部分に1日おき、1週間おきを当てはめ、より短い周期は○時間おき、○日おき、を当てはめます。
- 例：フルバックアップを毎日実行して、3時間おきに差分バックアップを実行する＝3時間前までの状態に復旧ができるようになる。
- 例：フルバックアップを毎週実行して、1日おきに差分バックアップを実行する＝昨日までの状態に復旧ができるようになる。
あとはフルバックアップで世代管理（例えば3世代）するようにすると更新頻度の低いデータも変更2回まではカバーすることができるようになります。
あとはこれらをジョブにして自動化するわけですね。
（Windows標準機能ならシステムイメージとVSS（ファイル履歴）でフルバックアップと差分バックアップが用意できます。）
実際のバックアップ取得以外でも特に考慮しなければならないことが「バックアップしたデータが記憶されたメディアをどのように保管するか、という部分も重要です。
昨今は情報漏えいに厳しい社会です。機密情報の記憶されたバックアップメディアを盗み出すことは機密事項をごっそり盗み出すことと同じ意味です。
SOHOや小規模企業ではD2D（Disk-to-Disk）でバックアップが完結することが多いので必ずしも当てはまらないのですが、D2T（Disk-to-Tape）といったバックアップメディアで最終的な保管をする場合には、
- バックアップメディアを保管する場所は物理的なセキュリティ（施錠できる保管庫、≒金庫）が必要。これで盗難防止。
- バックアップしたサーバの設置場所とは別の場所にバックアップメディアを保管する。これで災害防止。
- バックアップの実行者とバックアップからの復元者、バックアップメディアの保管社（取扱責任者）を別々の担当者が実施する。これで人的な抑止。
という点についてもできるだけ考慮しておく（考慮できる体制にする）のは必要な業務です。
最近では、メディアを暗号化してバックアップデータを復旧するために必要となる電子的な鍵を用意することで安易な復元をできなくする、というのも技術的には流行りのようです。
これを読んでいる貴方がもしSOHOや小規模企業の兼任（押し付けられたとも言う）担当者、だとしたら、まずは
いまの職場（のサーバ設置場所）が消滅し社員だけが生き残った状況から業務を遂行するにはどうするか、それに必要なものは何か、
を妄想してみましょう。
これはバックアップを収集するため思考をはじめることです。思考を始めると、いま足りないものがいつか見えてくるはずです。
乱暴に言えば外付けUSBハードディスクか安価なNASを買って（場合によっては廃棄寸前の古いパソコンを甦らせて）社内インフラのデータバックアップを集約（とにかく溜め込むとも言う）する、ことになるんでしょうね。いえでもいいんです、バックアップのはじめの一歩が踏み出せたということは重要です。
少々語り過ぎたようです。悪い癖で長くなってしまいました。
ですがこれだけやってもまだ取っ掛かりです。
すべてのIT担当者が最良のバックアップが収集できることを祈っています。
