最近発見したように、単純なファイル ストレージよりも高度なものの完全なファイル システム バックアップは、あまり役に立たないようです。例:
- AD、レジストリ、Windows自体: 復元はハードウェアに依存しません
- MSSQL および pgsql サーバー: VSS を使用してバックアップを作成しない限り (データベースのホット バックアップを実行するのと同じくらいサーバーに負荷がかかるようです)、データは必ずしも使用可能な状態ではありません。
- NTBackup で作成されたバックアップは、Windows Server 2003 より新しいバージョンでは復元できません。
サーバーのハードウェアが使用できなくなった場合、入手できるハードウェアに応じて、単一サーバーの 9 時から 5 時までの可用性環境で代替マシンを構築すると、最初から構築して設定しなければならないため、可能な限り互換性のあるバックアップを用意することが望ましいと思います。それを考えると、次のバックアップ戦略に大きな欠点はありますか?
- SQL サービスがダウンしています
- すべてのサーバーハードディスクを外部バックアップファイルに7-zip tarで更新する
- 整合性を確認する
- SQLサービスを再開
(tar 更新は、完全なバックアップを復元してから増分バックアップを 1 つずつ復元するという、復元時の中間ステップを回避するためだけのものです。)
答え1
システム状態のバックアップは、異なるハードウェアに復元できます。これは難しい作業ですが、実行可能です。 リンクテキスト
SQL DB ダンプはハードウェアに依存しませんが、アプリケーションは復元されません。
ディスクの tar が同一のハードウェア上で機能すると仮定した場合 (サーバーが Linux ブート CD から起動され、その環境から tar が実行されない限りは疑わしい)、ターゲット サーバーが完全に新しい場合、または mb または RAID カードが交換された場合は機能しますか? サーバーをシャットダウンしないと、システム状態のバックアップが別途実行されない限り、AD の復元可能なバックアップは作成されません。
このソリューションは自動化できますか? 出力は検証できますか? ドキュメント化できますか? また、休暇中や別の会社に異動した場合でも回復を実行できるほど手順は簡単ですか? 問題が発生した場合にテクニカル サポートを利用できますか? 緊急時のフラストレーションを軽減したいのであれば、これらすべての問題を考慮する必要があります。
MS が Server 2008 で NTbackup をサポートしていないという記述は誤りです。Server 2008 では NT バックアップの復元が可能です。 リンクテキスト
同じまたは異なるハードウェアに復元できる、または仮想マシン (P2V) として復元できるイメージ ベースのバックアップは、「高速」復元が必要な場合の最小要件の一部です。通常、これには、サードパーティ製品や MS アドオン (StorageCraft、Acronis、BackupExec、MS DPM、VMWare/Xen/HyperV)、またはレプリケーションとともに SAN 内の VM のハードウェア ベースのスナップショット作成が必要です。SBS 2003 には「十分」と考えられるサーバー バックアップがあり、すべての Server 2008 にはイメージ ベースのバックアップがあります。
答え2
あなたの言うことがすべてのケースで正しいとは思いませんが、ある程度は正しいと思います。ただし、バックアップしたのと同じハードウェアとソフトウェアベースに復元する場合を考慮する必要があります（ほとんどの場所ではそうします - 少なくともすべき（いずれにせよ当然のこととして）このシナリオは、サーバーが故障し、それを復旧させる必要があるDRである。今レガシー バックアップまたは履歴バックアップから復元するのではなく (おそらくこちらの方が検討されていると思います)、
データを復元するのは簡単です。OS とその構成を復元するのは、比較的簡単なものから明らかに簡単ではないものまでさまざまです。サーバー アプリケーションとその構成を復元するのは、ほとんどの場合簡単ではありません。完全バックアップは、このような状況で役立ちます。
私が言いたいのは、健全なバックアップ戦略では、復元手順だけでなく、復元された環境のハードウェアとソフトウェアも考慮する必要があるということです。