
「実験的なささいなこと」の継続。 前の部分:
one 、
two 、
three 。
今日は、試行錯誤の結果として構築された
バックアップの
原則についてお話します。
バックアップの
原則は 、一見予期せぬ瞬間に状況を保存しました。
バックアップは傷害保険会社です。 バックアップを作成することも規則ではなく、公理です。 火傷した管理者が何であれ、「手が震える」こともあります。スクリプトの記述が間違っていたり、ボタンがランダムに押されたりすると、HDD、火災、その他の災害はもちろんのこと、多くのトラブルが発生します。 はい、バックアップは高価です(時間、リソース、機器)。その一時的な効果は明らかではありませんが、それらが与える主なものは会社のリスクの保険です。 そして、これは非常に価値があります。 ステートメントは誰もが理解できるように見えますが、サーバーがクラッシュし、バックアップが存在するが、何もできず、システムが復元されていない場合に状況が発生することがよくあります。 そして、オーケストラとタンバリンのためのダンスが始まり、少なくともいくつかのデータなどを引き出します。 喜び。
まず、アーカイブやバックアップなどの概念を紹介し、明確に分けましょう。 たとえば、次のように:
- アーカイブは、長期データストレージを使用したバックアップです。 手順は、一度コピーされて、金庫に運ばれたとき。 アーカイブへのアクセスはルールよりも例外であり、手順は非常に時間がかかる場合があります(アーカイブの保存場所と保存方法によって異なります)。
- バックアップは、SHORT-TERMデータストレージを使用したバックアップです。 手順は、コピーが定期的に行われ、メディアが上書きされる場合、「ストレージの深さ」の概念があります。 同時に、バックアップへのアクセスは通常、可能な限り高速である必要があります。
アーカイブ

アーカイブはすべての人に必要なわけではなく、常に必要なわけでもありません。 ほとんどの場合、この質問は、会社が「私、私の友人、妻、宅配便」を超えたときに発生し、通常はファイル、金融データベース、メールデータベース、つまり アーカイブ内の非電子的な生活を維持するために受け入れられたこれらの文書(手紙、注文、経理など)。
アーカイブは通常、年に1回作成され、安全な場所、銀行の部屋、ゼネラルディレクターのコテージの外部メディアに保存されます(必要なものを強調します)。 ここではすべてが明確になっています。主なことは、少なくとも1年に1回アーカイブステータスを確認することを忘れないことです(たとえば、新しいものの記録中、古いデータから一部のデータを復元します)。 5年前に作成され、テープに保存されたアーカイブが必要になったとき、ストリーマーは壊れて削除されただけでなく、長い間リリースされていませんでした。 )
ちなみに、ここ数年は、アーカイブではテープではなく通常のHDDを使用することが多くなっています。 ボリュームが十分であり、アーカイブの作業速度が十分であり、価格が妥当であり、単一の接続インターフェイス(以前のIDE、現在はSATA)により、「壊れたストリーマー」の問題が排除されます。 データは、特別な機器を使用せずに、事実上どのコンピューターでも読み取ることができます(テープの場合のように)。 IDEが完全に消えたら、おそらくそれをSATAにコピーします(またはその後何でも)。
バックアップ

このようなバックアップのタスクは、「誤って\特別に削除された」、「バーンアウト」、または「誤って設定された」の迅速な回復のために、新しいバックアップコピーを保持することです。 通常、アーカイブが組織の存続期間中、場合によってはそれより長く保存される場合、バックアップのために、すでに
ストレージの深さの概念を導入できます。 バックアップが期限切れになり、より新しいデータで上書きされる可能性があります。 全体としてのバックアップは、
データ バックアップシステムと
バックアップシステム 、および
システム のコンテンツのスタンドアロン
バックアップの 2つの主要部分に分けることができ
ます 。 後者は非常に広範かつ具体的なトピックであり、バックアップする特定のシステム(メールサーバー、データベース、CRM、ソフトウェア設定など)の内容に大きく依存するため、ここでは説明しません。
バックアップシステム
システムのバックアップは、個々のファイルではなく、いくつかのコンポーネント(特殊なソフトウェア、SQLデータベース、ファイルデータなど)で構成されたシステム全体をバックアップする必要がある場合であり、一部ではなく全体を復元することをお勧めします。 ここではすべてが非常に簡単です。お客様に合ったバックアップソフトウェア(価格、機能、利便性)を選択し、サーバーが完全に故障した場合でも復元できるようにシステムをバックアップします。 すべての種類のAcronis、Symantec System Recoveryなどが適しています。 これを覚えておくことが重要です。
- バックアップから復元できる必要があります。 いつでもどこでも練習できますが、あなたはそれを行うことができなければなりません。
- 正確に何をバックアップするかを考えてください。 これは、たとえば、1つのサーバー、社内サイト、およびボリュームがファイルリソースに追加的に接続されているデータベースなど、ユニバーサルサーバーにとって重要です。 このような状況では、複雑に構成されたSQLとサイトリンクをバックアップするために、1500 TBの2番目のファイルボリュームを同時にバックアップしないでください。 一般に、「1つのタスク-1つのサーバー」の状況に努め、すべて、すべて、すべてを同じマシンでハングさせないでください。ハングさせた場合は、「体系的に」バックアップします。
- ソフトウェアは、現在のハードウェアとは異なる他のハードウェアに回復できる必要があります。 そして、少なくとも一度は試してみてください!
- 「システム」バックアップ、特に継続的に使用されるシステムは、1週間以上保存しないでください。 1か月前にドメインコントローラーのバックアップが必要な理由を考えてみてください。 緊急の場合は、MOSTの最新のバックアップが必要になります。 そして、何らかの理由で「最新」のものが機能しなかった場合に備えて、残りはすべてセーフティネットです。 私の意見では、このようなセーフティネットに1〜2回以上の反復を割り当てることは非論理的であり、スペースを不必要に無駄にします。
- インフラストラクチャ全体と複雑に相互接続されたシステムがあり、それらを復元することは、特定のサーバーの新しい「システムバックアップ」を手元に置いていても、簡単ではありません。 オフハンド:Active Directory、Exchangeなど。 時間をかけて、ドキュメントを調べ、テスト環境で少なくとも1回-しかし、すべてを完全に復元してみてください! 頭の上に怒っているボスを置くよりも、インターネットを手に入れてリラックスした雰囲気の中でこれを行う方法を学ぶ方が良いです。
データのバックアップ
データバックアップは、個別の独立したデータのバックアップです(基本的に、これは企業のファイルストレージの内容です)。 ここでは多くの知恵は必要ありません-それを取り、コピーします。バックアップスキームについてのみ考えることができます。 たとえば、私は次のスキームを順守しています:

- 週末には、すべてのデータの完全バックアップが作成されます。 ストレージの深さは28日間です。 4つの独立した完全バックアップがあります。 したがって、先月は、休日のデータを復元することができます。
- 営業日には、14日間のストレージ深度で差分バックアップが作成されます。 したがって、過去2週間にわたって、任意の日のデータを復元できます。
- 毎月の最初の週末に、残りの作業とは別に、12か月のストレージの深さで、毎月のバックアップが作成されます。 これは、バックアップとアーカイブのクロスです。 一方では、保存期間は非常に長く、他方では、「数か月前、最大で6か月」データを復元する必要がある場合がよくあります。 または、毎月のバックアップを個別の作業として行うことはできませんが、適切な毎週のバックアップを単にコピーしてください。
さらに、私はこれらのルールを厳守しようとします:
- 差分バックアップを使用しますが、増分バックアップは使用しません。 (それが何であるかわからない場合-ドキュメントを必ず読んでください、これらは非常に重要な概念です)。 回復速度の向上は、バックアップの量よりも重要です。
- 朝まで追いつくことができるようにバックアップ時間を計画しています。 バックアップに時間がかかる場合-複数のジョブ、複数のサーバーに分割するか、他のより高速な機器について質問します。
- バックアップスケジュールでは、週(7日間、28日間など)に関連付けられた間隔を厳守し、「月の最初/最後の日」にアタッチしないようにします。 1週間はほぼ一定の値で、7日間です。ほとんどの場合、土曜日、日曜日は休日です。
- テープではなくディスクを使用しています。 バックアップ内のデータとファイルストレージ内のデータの間の高価なストリーマーの仲介者が好きではありません。 何らかの理由で機能しない場合、バックアップシステム全体が長時間にわたって侵害されます。 ハードドライブを使用する場合、これは回避できます。
- データの論理的に独立した部分が別のバックアップにあるようにします。 たとえば、Symantec Backup Execについて話す場合、1つのジョブ= 1つのメディアです。 1つの作品が複数のファイルに「広がっている」状況は本当に嫌いです。 これはシステムに混乱をもたらすだけでなく、誤ってファイルの1つを上書きした場合(「手が震えた」)、1つのジョブだけでなく、隣接するすべてのジョブにも損害を与えます。
- 必ずメールで通知するソフトウェアを使用しています。 これが自己記述スクリプトである場合-少なくとも新しいバックアップの存在、サイズ、およびメールによるデータの送信をチェックするピースを追加することを誰も気にしません。 これにより、バックアップの監視にかかる時間が大幅に節約されます。
とりわけ、いわゆるを使用することもファッショナブルです。 ユーザーがドキュメントの最新バージョンから復元するものを選択できる場合の、WindowsのVSSサービスと同じ深さ(1〜2日)の「インスタント」バックアップ。 これは、ユーザーが午前中にドキュメントを編集し、昼食時に削除し、午前中のバージョンを復元するように要求するときに非常に役立ちます。
DFSシステムを永続的なオンラインバックアップとして使用することもできますが、これについては別の投稿で説明します。これについては後で行います。
継続する。
PSルールを設定するのではなく、小さな組織(30〜500台のPC)で得た経験、普遍的な経験を共有します。 それ以外のことを行うのが慣例である場合は、コメントで喜んで読みます。