Linuxでのより親切で穏やかなバックアップ
今週の初めに、サーバーで「パーフェクトストーム」の瞬間がありました。2つのバックアップジョブ（システム上のRAID10アレイごとに1つ）がハミングしていました。 18時間経過した後、I/Oを多用するアプリケーションでトラフィックが急増しました。その結果、パフォーマンスが許容できないほど遅くなり、管理者にバックアップのキャンセルを強制する必要がありました。 （彼はこれに満足していませんでした...まったくありません。 "私は責任を負いません..."）
その結果、多くのストレス、不幸な顧客、そして非常に不機嫌なStu。
ボトルネックはディスク使用率でした。ジョブがキャンセルされると、すべてが正常に機能していました。 サーバーへの影響を軽減するために管理者に何を提案できますか？
残酷な詳細のいくつかを次に示します。
バックアップコマンド自体（これはpsから取得しましたが、実際には何を意味するのかわかりません。）
bpbkar -r 1209600 -ru root -dt 0 -to 0 -clnt xtx-le00 -class F_Full_on_Thursday
-sched Incr_Fri_to_Wed -st INCR -bpstart_to 300 -bpend_to 300 -read_to 300
-blks_per_buffer 127 -stream_count 8 -stream_number 8 -jobgrpid 223932 -tir -tir_plus
-use_otm -use_ofb -b svr_1259183136 -kl 28 -fso
システム
- RHEL464ビット
- 4GB RAM（〜アプリケーションで半分使用）
- 2つの接続されたDL380G5 SAS RAID10パーティション、〜550GBおよび〜825GB
データ
1TB
- 約1,000万ファイル
アプリケーション
- 平日の0900から2300まで忙しい
- I/O集中型（99％読み取り）は主に数百MBのファイルに焦点を当てています
Bpbkarが実際にどのように機能するかはわかりませんが、rsyncを使用してすべてのファイルをオフサイトにバックアップし、同期を維持します。変更されたファイルのみが更新されるため、リソースの消費はほとんどありません。当然、これは最初のバックアップにかなりの時間がかかることを意味しますが、あなたはすでに「18時間ハミングしている」と言っています。
次に、他のマシンからバックアップされたデータを必要に応じて管理するだけです。
小さな編集：テープバックアップからディスクバックアップに移行することを選択した場合は、デュアルパリティを提供するRAID6を使用することをお勧めします。
ライブサーバーをバックアップサーバー（安価な1TB SATAディスクで構築されている）にrsyncしてから、バックアップサーバーの完全なテープバックアップを作成するシステムがあります。それは素晴らしいです：
- ベルトおよび中括弧-両方のバックアップのすべての利点
- ライブサーバーのIO負荷を大幅に削減
- 1つまたは2つのファイルが必要な場合は、より高速に復元できます
- オフサイトアーカイブ用のテープのフルセット
bpbkarは、VeritasNetbackupsバックアップクライアントです。スロットリングをサポートしているため、通常のI/OとバックアップI/Oの組み合わせでディスクが飽和することはありません。ここを見てください：
http://seer.entsupport.symantec.com/docs/265707.htm
システムは平日はほとんど忙しく、平日は増分バックアップであるとおっしゃっていますが、週末に完全バックアップを実行するのを妨げるものはありますか？これは、2300〜0900の静かな時間帯にバックアップを実行するのに役立ちます
バックアップが正常に実行されるまでに18時間かかる場合、バックアップの優先順位を下げても問題は解決しない可能性があります（一度に数日間バックアップを実行する場合を除く）。別のマシン（私はDRBDが好きです）にディスクレプリケーションメカニズムをセットアップしてから、LVMを使用して特定の時点のスナップショットを作成し、それをバックアップして、次に進む傾向があります。別のマシンで実行されているため、（a）ライブアプリに影響を与えることなく好きなだけ強く叩くことができ、（b）ディスクIOについてライブアプリと競合することはありません。つまり、おそらく実行されます。全体的にもはるかに高速です。
私が確かに言えることの1つは、同じマシンで行うことはすべて、ディスクキャッシュを完全に骨抜きにすることです。バックアッププロセスは、バックアップするディスクからすべてのデータを読み取るためです（読み取りではなくmtimesをチェックするだけの場合でも）そして、すべてのファイルをチェックサムする）、それはまだあなたのキャッシュに実行されている多くのメタデータブロックであり、それらはキャッシュから有用なデータを追い出し、他の方法で保証されるよりも多くのディスクIOを引き起こします。
rsyncへの別の投票。非常に頻繁に使用されるファイルサーバーの9TBを毎日バックアップするために使用します。問題はありませんでした。
「特定の時点」が心配な場合は、LVMスナップショットを作成し、mount、rsync、umount、destroyします。サーバーの負荷はやや高くなりますが、フルコピーよりもはるかに（はるかに！）短い時間です。
管理者が積極的に、絶対にbpbkarでなければならないと言った場合は、最初にあまり使用されていないシステムに対してrsyncを実行し、次にそこからbpbkarを実行します。プロダクションシステムを占有する必要はありません。
テストからの逸話：ext3の8TBの制限に近づいたときに、いくつかの「プラグを抜く」テストを行って、コピー中にハードウェア障害によってファイルが破損する可能性があるかどうかを判断しました。サーバー、ストレージボックス、およびSAN配線のプラグを抜きました。数千万のファイルをコピーしました。
結論：
- ext3には、10回の失敗ごとに平均して1つのファイルがありませんでした。
- XFSは、ストレージの障害ごとに平均5エラー未満（サーバーの障害ではほぼゼロ）でした（驚いたことに、XFSは常にハードウェア障害で高速かつハードに障害が発生したと思いました）
- JFSは、毎回何百ものファイルを壊しました。
要するに、rsyncは本当に本当にうまく機能します。エラーは、ハードウェアやファイルシステムに起因する可能性があります。 bpbkarは、同じ障害に直面してもパフォーマンスが向上しません。
投稿したコマンドから判断し、-classオプションと-schedオプションを見ると、木曜日に完全バックアップを実行しているように見えます。使用スケジュール（900〜2300平日）を考慮すると、おそらく最善の計画ではありません。
このような巨大なデータセットでは、完全バックアップのタイミングに加えて、その週に取得する増分バックアップの種類を確認する必要があります。 NetBackupには2種類の増分バックアップがあります。
- 累積増分-最後の完全バックアップ以降に変更されたすべてのファイルをバックアップします
- 差分増分-最後のバックアップ（完全または増分）以降に変更されたすべてのファイルをバックアップします
そのシステムのバックアップ戦略を土曜日または日曜日の完全バックアップに移行し、残りの週は差分増分バックアップに移行することを検討します。これにより、十分な時間がある場合（ユーザーがいない/少ない場合）に完全バックアップが実行され、使用率が低い数時間で増分が短くなります。この方法の問題は、復元が少し複雑になる可能性があることです-より多くのテープが必要になります-完全なテープに加えて、その完全なものからデータを復元する必要があるポイントまでのすべての増分。
あなたの質問から、あなたはバックアップシステムにひどく精通していないように思えます。 sysadminをバックアップオペレーターから分離することは理解していますが、それらの間でいくつかの議論を行う必要があります。バックアップオペレータは、システムがどのように使用されているかわからない場合、システムの適切なポリシーとスケジュールを作成できません。
NetBackup管理者にバックアップのスケジュールを改善してもらいます。RAIDアレイごとに隔週で完全バックアップを実行します。
また、合成完全バックアップを調べて、それほど多くの完全バックアップを実行する必要がないようにすることもできます。
いくつかの提案：
- 完全バックアップの頻度を減らします。データがかなり静的である場合は、2か月ごとに1か月に1回の完全バックアップと、それ以外の時間の累積増分バックアップを使用することができます。 1本ではなく2本のテープが必要ですが、それは大したことではありません。
- バックアップをより適切にスケジュールします。 netbackupを使用すると、サーバーに特定の頻度で特定のウィンドウでバックアップを実行するように要求できますが、実際のバックアップの開始と終了をスケジュールすることができます。これは通常、手動でスケジュールを設定する場合よりも効率的にバックアップインフラストラクチャを使用します。
- 最初にnetbackupにバックアップをディスクにダンプさせ、バックアップの完了後にそれらのイメージをテープに複製します。
他のrsyncの提案も良いです-これがデータベースアプリケーションでない限り、データのrsyncされたコピーがプライマリサーバー上のイメージほど良くない理由はありません。データベースのようなアプリケーションの場合は、トランザクションログとバックアップイメージを作成時に別のシステムにコピーし、それらをバックアップする必要があります。
Rsyncターゲットのデータをnetbackupにバックアップしますが、OSと、プライマリターゲットとrsyncターゲットのプログラムデータ（スペースを占有しているもの）以外のすべてもバックアップします。 OSとプログラムのデータのバックアップは簡単かつ迅速である必要があり、とにかく別のバックアップポリシーに含まれている必要があります。
2つの問題があります。1つはアーキテクチャの問題で、もう1つは実装の問題です。
バックアップウィンドウを変更したり、バックアップの頻度を減らしたり、より高速なディスク、ネットワーク、テープドライブを購入したり、データを別のシステムに複製したりすることで、実装を簡単に最適化できます。これらの変更は有効で適切であり、ムーアの法則により、サービスが永久に適切に実行され続ける可能性があります。
また、スケーリングの問題がますます頻繁に発生する状況に陥っている可能性もあります。ヒットスケーリングの問題がますます頻繁に発生する可能性があることを少しでも心配している場合は、システムを再設計してスケーリングを改善する方法を検討する必要があります。そのようなことは簡単ではありませんが、簡単ではないので、頭に銃を持ったときのかなり前にそれらを計画する必要があります。
アーキテクチャの調整の例としては、すべてのデータをNASタイプのシステム（NetAppファイラーやSolarisおよびZFSを実行するボックスなど）に移動することが挙げられます。このような設定では、サーバーをバックアップします。これは主にプログラムと構成であり、SANのデータ管理機能を使用してSANをバックアップします。これらは、スナップショットやスナップショットに対するトランザクションログなどです。
また、archive.orgが行うのと同様のことを行うこともできます。この場合、データを多くの異なるシステムに保存します。通常、特定のデータは複数のシステムに存在し、リクエストをにルーティングするフロントエンドシステムのファームがあります。実際にデータをホストしているシステム。
最後に、バックアップも機能しますか？稼働中のシステムで18時間バックアップを実行すると、その18時間全体にわたってそのシステムを反映したバックアップが作成されます。理想的には、バックアップは単一のアトミックな時点でのシステムを反映し、ある時点からのものとほぼ1日後のものがあるというクレイジーなローリングバックアップではありません。データのいずれかが他の場所に依存しているか、データの他の部分を指している場合、バックアップが変更の途中で取得されると、これらの依存関係はひどく台無しになります。データセットがこれほど大きい場合、100％これが発生する可能性があります可能であれば、バックアップごとにシナリオを作成します。