クリフハンガー：バックアップは正しい…ここに…正しい？

私の仕事では、バックアップの優先度は驚くほど低いです。バックアップ戦略は少し前に実装されており、それ以降はバックアップが正常であると想定されています。システム管理者に尋ねると、すべてがバックアップされたと言われます。

しかし、その後、特定のバックアップを要求すると、半分の時間がバックアップにありません。

• ディスクがいっぱいになりました
• テープが故障しました
• 誰かがバックアップジョブを無効にしたようです
• ネットワーク接続にダウンタイムがありました
• 私たちは数年前にそのディスクを注文しましたが、財務は購入注文を承認していません
• ファイルが破損しています
• ファイルに間違ったデータベースが含まれています
• トランザクションログバックアップのみ（完全なバックアップなしでは役に立ちません）

数週間前、サーバーの1つが非常に多くのRAIDディスクを失ったため、災害は現実のものとなりました。幸運にも、何度も試してみると、1つのディスクでデータをコピーすることができました。

しかし、その災害に近い後でも、システム管理者に状況を改善するよう説得することはできません。だから、人の目を開くためのヒントはありますか？崖の端を歩いているようです。

これらのことは常に上から修正する必要があります。

現在のバックアップ戦略は経営陣によって裏付けられ、理解されていますか？そうでなければ、それは役に立たない。

経営陣は、問題と関連するリスク（生き残るために合法的に持ち出す必要のある財務データを失うのか、それとも収集に何年もかかった顧客データを失うのか）を知る必要があります。 （あなたのような）誰かに行動を起こさせる。

管理ができない場合は、データの取得とその整合性が会社のレポートにとって非常に重要であるビジネスコントローラーまたはその他の財政状態を試してください。必要に応じて、彼らは順番に「嵐を始める」ことができます...

どこから始めますか？これは起こるのを待っている災害です。Sysadminの主要なジョブ機能は、データがバックアップされ、回復可能であることを確認することです。それ以外はすべてセカンダリです。ノーならノーです。

できることは次のとおりです。

1. 復元のためにKPIを追跡します。成功した復元要求の数を示すレポートを作成できるはずです。100％未満の場合は、徹底的に調査する必要があります。経営陣はレポートを愛し、これは確固たる証拠です。

2. すべてのシステムとそのバックアップ戦略、テープローテーション、スケジュール、エスカレーションパス、テストの復元などを含む、すべてのバックアップおよび復元操作の手順を文書化する必要があります。確認してください。

3. システム管理者のマネージャーと話し、懸念を表明してください。復元が機能しないことを証明してください。喜びがより高くならない場合。

真剣に-大騒ぎしてください。このようなものは会社を破壊する可能性があります。

（少なくとも）年次災害復旧テストを提案します。テストを正常に実行するために必要な作業により、欠点が明らかになります。

私が働いている場所には、非常に優れたIT部門があり、毎年ヨーロッパ各地のすべてのオフィスから集まって、データセンター内のレンタルサーバーに「復元イベント」を行っています。その夜、オフィスは燃え尽きていました。

大ボスを巻き込んで、災害が発生した場合、彼はその年のボーナスから（またはもっと悪いことに！）ボーナスを失うことを思い出させてください。それほど長い時間も費用もかからないはずです。管理者はオフサイトのバックアップテープを持ち帰り、それらから同じオフィス環境を立ち上げるように言われます。

そして、ITが良くなるのを待ちます-会社のデータが完全に失われる危険に近いと管理者が認識すると、火花が飛びます（管理者に戦略的に配置されるロケットから）

管理者を非難するのは簡単ですが、Oskarには正しいことがあります。これらのことはトップから推進されています。経営陣がバックアップを優先するために費用を費やさない場合、システム管理者は通常運が悪く、所有するリソースを最大限に活用します。

あなたがそれらの不運な管理者の一人であるなら、そして私がいくつかの顧客エンゲージメントのためにこのボートにいました-鍵は、あなたが管理が簡潔に、簡潔に説明され、紙の証跡確認可能な方法で、これがそうであることを確実にすることですビジネスへのリスク。

私の戦略は、常に問題に打ち勝つことです。そうすれば、問題が解決することもありますが、ほとんどの場合、報告した人が「説明を受けなかった」という言い訳の後ろに隠れることはできません。コンサルタントとして、私は通常より良いものに行くことができます。私は上司に、脆弱性があることよりも上級管理職に簡潔に説明することができます。これは非難を広めるか、少なくとも私よりも高いレベルに集中させます。

同時に、お客様は独創的であり、顧客が提供できるあらゆるリソースでリスクを最小限に抑えるために懸命に努力する必要があります。

場合によっては管理者が過失になる可能性がありますが、管理者は常にリスクを認識しており、リスクを軽減するのに十分なことをしていないか、これらのリスクを警告していない人を雇っています。

私は、英国北西部に広がる約200台のサーバーを担当していますが、これは明らかに多すぎて手動で確認することができません。

バックアップを構成して、完了時に（VBScript）スクリプトを実行して、バックアップログを調べ、バックアップが機能したかどうかを判断し、バックアップ結果と共に中央データベースにレコードを書き込みます。次に、本社でこのデータベースを照会するスクリプトを実行し、バックアップがエラーを報告したか、サイトからの報告がなかったサイトのリストを提示します。

その結果、机に座ると、バックアップを確認する必要があるすべてのサイトのリストが表示されます。

このすべてのポイントは、デフォルトの仮定ではバックアップが失敗し、VBScriptがエラーを検出せず、データベースにこの結論を書き込んだ場合にのみバックアップが機能したと見なされることです。これにより、バックアップの失敗が見過ごされないようになります。

一部のサーバーはBackup Execを使用し、一部のサーバーはNTBackupを使用し、一部のサーバーはネットワーク上の別のサーバーにファイルをコピーします。VBScriptを微調整してエラーをチェックするのは簡単なので、サーバーがどのタイプのバックアップを行うかは関係ありません。私のスクリプトは実際には非常に基本的です。バックアップレポートをテキストファイルとして開き、「マウントに失敗しました」、「テープがいっぱいです」、「CRCエラー」などのフレーズを探します。なめらかな仕事。しかし、全体はシンプルで堅牢であり、バックアップ失敗レポートを表示するかどうかにかかわらず積極的に対応し、意識してレポートを無視することにした場合にのみエラーに気付かないでしょう。

JR

PSバックアップエラーの99％は、ユーザーがバックアップテープの交換を忘れたためです。あなたはただのルアーを愛してはいけません:-)

テストされていないバックアップは、バックアップではありません。