データベースをバックアップするためのベストプラクティス
stackoverflow で質問しましたが、誰かがここで質問したほうがいいと指摘しました。
RAIDNAS上のSubversionとMySQLを想定しましょう。データをバックアップするためのベストプラクティスは何ですか？
私はmysqldumpsをsubversionnの制御下に置き、それから全体を7zipすることによってsvnリポジトリを定期的にバックアップすることを考えていました。
Svnバックアップを別の物理ハードドライブに保存していない限り、リポジトリのバックアップを作成することは役に立たないようです。これは本当ですか？そうでない場合、なぜですか？
最後に、バックアップはどのくらいの頻度で作成し、いくつ保存する必要がありますか？
まず、データベースのバックアップをバージョン管理しないでください。
バックアップはバックアップであり、ある時点です。バージョン管理を使用するのはいい考えのように聞こえますが、SVNリポジトリ全体を復元する必要があることを理解してください（ZOMG Freaking[〜＃〜]巨大な[〜＃ 〜]）壊滅的な障害が発生し、データベースを元に戻す必要がある場合。それはあなたが余裕がない追加のダウンタイム時間かもしれません。
次に、バックアップが何らかの理由でサイトから外れていることを確認します。混乱してドロップしたためにデータを復元する必要がある場合は、ローカルマシンでのバックアップが最適です。テーブル。サーバーのディスクが死んだ場合、それはまったく役に立たない。
オプションには、外付けハードドライブ、またはrsyncを使用したリモートマシンへのバックアップの出荷が含まれます。それを専門とするストレージサービスプロバイダーもあります rsync.netのように 。
第3に、バックアップの頻度について：これを行う必要がある頻度を知っているのはあなただけです。
私の現在の会社には、本番データのほぼリアルタイムのレプリケーションを備えたスレーブデータベースがあります。そのスレーブは毎晩ローカルマシンにバックアップされ、ローカルマシンはオフサイトのストレージ施設に同期します。
本番ハードウェアに障害が発生した場合、スレーブをアクティブ化します。ダウンタイムと同様に、データの損失は最小限に抑える必要があります。誤ってテーブルを削除した場合は、ローカルバックアップから復元できます（最大1日のデータが失われます）。壊滅的なインシデントが発生した場合は、オフサイトバックアップから復元できます（これにはしばらく時間がかかりますが、最大1日分のデータしか失われません）。
この種のバックアップスキームが機能するかどうかは、データによって異なります。頻繁に変更される場合は、ポイントインタイムリカバリを実現するバックアップ戦略を調査する必要があります（ログ配布ソリューションでこれを実行できることがよくあります）。 。ほとんど静的な場合は、月に1回だけバックアップする必要があります。重要なのは、データの変更が行われてから妥当な時間内にデータへの変更をキャプチャし、重大なインシデントが発生した場合にそれらの変更が失われないようにすることです。
一般的なアドバイス：
- バックアップを監視してください
- それらが正常に終了したかどうかを確認します[たとえば、フィニッシュラインを検索するmysqldumpの結果。ダンプコマンドによって返されるエラーコードを確認してください]、
- バックアップサイズが妥当な場合
- たまにリカバリテストを実行します-おそらく3〜6か月ごと
- 悪意のある攻撃の場合にデータを失わないように、オフラインメディアにバックアップします
- 自然災害が発生した場合にデータが失われないように、バックアップをオフサイトに保管してください
具体的なアドバイス：
- バージョン管理のためにsvnにポンプされたmysqldumpsはやり過ぎのように聞こえます-svnから何かを削除することは非常に困難です。 rdiff-backup を使用して、最後のバックアップと以前のいくつかの「diff」を保持するのはどうですか？
- svn-svnadmindumpを使用します-これはsvnのダンプを取得する「適切な」方法です
- さらに安全にしたい場合は、lvmを使用し、mysqlとsvnの両方のデータディレクトリのlvmスナップショットを追加で取得します
- innodbストレージエンジンを使用してバックアップをロックフリーにします
バックアップ戦略を準備する際には、目標復旧時点（RPO）と目標復旧時間（RTO）を評価することから始める必要があります。 RPOは、インシデントが発生した場合にビジネスが失うことをいとわないデータの量を示し、RTOは、回復にかかる時間を示します。 RTOとRPOの要件により、バックアップを維持するための経済的コストとパフォーマンスコストが増大します。 [1] 。
一般に、4つのバックアップ戦略があります。
- サーバーレプリカ：メインデータベースサーバーから物理的および論理的に分離された別のサーバーを使用し、データベースにデータを書き込むときは常にレプリケートデータベースにも書き込みます。
- データベースダンプ：データベースを定期的にファイルにダンプし、そのファイルをバックアップサーバーに送信します。
- データベーススナップショット： rsnapshot などのファイルシステムスナップショットツールを使用して、データベースの基になるデータファイルの定期的なスナップショットを作成し、バックアップサーバーに送信します。
- クラウドおよびエージェントベース：データベースサーバーにエージェントをインストールするだけで、定期的にクラウドにバックアップします。
それぞれのアプローチには独自の長所と短所があり、さまざまな観点から比較できます。
非ブロッキング：データベーススナップショットを除いて、すべてのメソッドはバックアップのためにdbへの書き込みアクセスを停止する必要はありません。たとえば、ジャーナリングが有効になっているmongodbでは、LVMスナップショットを使用しても、スナップショットが一貫していて有効であるという保証はありません。
インクリメンタル：ダンプとスナップショットは通常インクリメンタルではないため、バックアップ速度は他の速度よりも遅くなります。レプリカとクラウドのメソッドは、本質的にインクリメンタルです。
Workload：基になるファイルだけがコピーされるため、スナップショットはデータベースに負荷をかけません。ダンプの負荷が最も高くなります。他の方法では、ワークロードはデータベースの稼働時間に分散されます。