バックアップ、パヌト1目的、方法ずテクノロゞヌの抂芁

バックアップバックアップは必芁ありたせん!!






なぜバックアップを䜜成する必芁があるのですか 結局のずころ、機噚は非垞に信頌性が高く、さらに、信頌性の点で物理サヌバヌよりも優れた「クラりド」がありたす。正しく構成されおいれば、「クラりド」サヌバヌはむンフラストラクチャ物理サヌバヌの障害に簡単に耐えるこずができ、サヌビスナヌザヌの芳点からは、わずかにほずんど目立たないゞャンプがありたすサヌビス。 たた、情報の耇補には、倚くの堎合、「䜙分な」プロセッサ時間、ディスク負荷、ネットワヌクトラフィックの支払いが必芁です。



理想的なプログラムは高速で実行され、RAMを通過せず、穎がなく、存圚したせん。



-䞍明
プログラムはただタンパク質開発者によっお曞かれおおり、テストプロセスは倚くの堎合䞍圚であるこずに加えお、「ベストプラクティス」それ自䜓もプログラムであるため䞍完党の䜿甚ではプログラムの配信が非垞にたれなので、システム管理者はしばしば問題を解決する必芁がありたす簡朔だが簡朔に「元に戻す」、「ベヌスを通垞の動䜜に戻す」、「動䜜が遅い-ロヌルバックする」、そしおお気に入りの「䜕がわからないが修正する」。



開発者の䞍泚意な䜜業、たたは状況の組み合わせの結果ずしお生じる論理゚ラヌに加えお、オペレヌティングシステム、ドラむバヌ、ファヌムりェアなどのバむンダヌやシステムのプログラムを含むプログラム構築の小さな機胜の䞍完党な知識たたは誀解に加えお、他の゚ラヌがありたす。 たずえば、ほずんどの開発者はランタむムに䟝存しおおり、プログラムの助けを借りおもバむパスできない物理的な法則を完党に忘れおいたす。 これには、ディスクサブシステムずすべおのデヌタストレヌゞサブシステムの䞀般的な無限の信頌性RAMずプロセッサキャッシュを含むが含たれたす。たた、プロセッサでの凊理時間がれロであり、ネットワヌクを介した䌝送およびプロセッサでの凊理䞭に゚ラヌが発生しないこず、およびネットワヌクレむテンシが0になりたす。悪名高い締め切りを無芖しないでください。時間がない堎合、ネットワヌクずディスクのニュアンスよりもきれいな問題が発生するためです。



シェフ、それはすべおなくなった k \ fダむダモンドハンドに基づく



しかし、完党な成長で発生し、貎重なデヌタにたたがる問題に぀いおはどうでしょうか ラむブ開発者を眮き換えるものは䜕もなく、近い将来に可胜になるずいう事実もありたせん。 䞀方、プログラムが意図したずおりに機胜するこずを完党に蚌明するために、これたでのずころ少数のプロゞェクトのみが成功しおおり、他の同様のプロゞェクトに蚌拠を取り入れお適甚するこずはたったく䞍可胜です。 たた、そのような蚌拠には倚くの時間がかかり、特別なスキルず知識が必芁です。これにより、締め切りを考慮しおアプリケヌションを適甚する可胜性が実質的に最小限に抑えられたす。 さらに、情報を保存、凊理、および送信するための超高速で安䟡で無限に信頌できる技術をどのように䜿甚するかはただわかりたせん。 そのような技術は、もし存圚すれば、抂念の圢で、たたは-ほずんどの堎合-サむ゚ンスフィクションの本や映画でのみです。

良いアヌティストはコピヌし、玠晎らしいアヌティストは盗みたす。



—パブロ・ピカ゜。
最も成功した゜リュヌションず驚くほど単玔なこずは、通垞、抂念、技術、知識、科孊の分野が䞀芋しおたったく互換性がない堎合に起こりたす。



たずえば、鳥ず飛行機には翌がありたすが、機胜の類䌌性にもかかわらず、いく぀かのモヌドでの動䜜原理は同じであり、技術的な問題は同様に解決されたす䞭空の骚、匷力で軜量な材料の䜿甚など-結果は完党に異なりたすが、非垞に䌌おいたす。 私たちの技術で芳察する最高のサンプルは、倧郚分が自然から借りたものです。船や朜氎艊の気密区画-環圢動物ずの盎接的な類䌌点。 RAIDアレむの構築ずデヌタの敎合性のチェック-DNAチェヌンの耇補。 臓噚のペアず同様に、さたざたな臓噚の仕事が䞭枢神経系自動心機胜および反射から独立しおいるこずは、むンタヌネット䞊の自埋システムです。 もちろん、既成の゜リュヌションを「盎接」採甚しお適甚するこずには問題が䌎いたすが、他の゜リュヌションはないかもしれたせん。

あなたがどこに萜ちるか知っおいたら、私はストロヌを敷くでしょう



-ベラルヌシのこずわざ
そのため、バックアップは次のようなナヌザヌにずっお䞍可欠です。





ここにちょっずした理論がありたす
分類は任意です。 自然は分類したせん。 私たちはより䟿利だから分類したす。 そしお、私たちもarbitrarily意的に取るデヌタに埓っお分類したす。



—ダン・ブラヌラヌ
物理ストレヌゞ方法に関係なく、デヌタの論理ストレヌゞは、このデヌタにアクセスする2぀の方法に分割できたす。ブロックずファむルです。 この区分は最近、非垞に䞍明瞭になりたした。これは、玔粋にブロック化された論理ストレヌゞが存圚しないためです。 ただし、簡単にするために、それらはそうであるず仮定したす。



デヌタのブロックストレヌゞは、デヌタがいく぀かの固定郚分、ブロックに蚘録される物理デバむスがあるこずを意味したす。 ブロックぞのアクセスは特定のアドレスに行き、各ブロックはデバむス内で独自のアドレスを持ちたす。



通垞、バックアップはデヌタブロックをコピヌするこずによっお行われたす。 コピヌ時のデヌタの敎合性を確保するために、新しいブロックの蚘録ず既存のブロックの倉曎は䞭断されたす。 通垞の䞖界から類掚するず、最も近いクロヌれットは同じ番号のセルになりたす。



ブロックデヌタストレヌゞ



論理デバむスの原理によるデヌタのファむルストレヌゞは、ブロックストレヌゞに近く、倚くの堎合䞊に線成されたす。 重芁な違いは、ストレヌゞの階局ず人間が読める名前です。 抜象化は、ファむルの圢匏で匷調衚瀺されたす-名前付きデヌタ領域ずディレクトリ-説明ず他のファむルぞのアクセスが保存される特別なファむル。 ファむルには、䜜成時間、アクセスフラグなどの远加のメタデヌタを指定できたす。 通垞、この方法でバックアップしたす。倉曎されたファむルを探し、同じ構造の別のファむルストレヌゞにコピヌしたす。 デヌタの敎合性は、通垞、曞き蟌たれるファむルがないこずによっお実装されたす。 ファむルのメタデヌタも同様にバックアップされたす。 最も近い類掚は図曞通であり、そこには異なる本のセクションず、人間が読める本の名前のカタログがありたす。



ファむルデヌタストレヌゞ



最近、原則ずしおファむルストレヌゞが開始され、同じ叀颚な機胜を持぀別のオプションであるオブゞェクトデヌタストレヌゞが説明されるこずがありたす。



耇数のネストフラットレむアりトを持たないずいう点でファむルストレヌゞずは異なりたす。ファむル名は、人間が読み取れるものの、マシンによる凊理に適しおいたす。 バックアップするずき、オブゞェクトストアはほずんどの堎合ファむルストレヌゞのように扱われたすが、時には他のオプションがありたす。

-システム管理者には、バックアップを䜜成しない人ず既に䜜成する人の2皮類がありたす。

-実際には、3぀のタむプがありたす。バックアップを埩元できるこずを確認する人もいたす。



-䞍明
デヌタのバックアップ自䜓のプロセスはプログラムによっお実行されるため、別のプログラムず同じ欠点があるこずを理解するこずも䟡倀がありたす。 排陀するには陀倖しない人的芁因ぞの䟝存、および機胜-個別に匷く圱響を䞎えないが、具䜓的な効果を䞎えるこずができる機胜-いわゆる ルヌル3-2-1。 それを埩号化するための倚くのオプションがありたすが、私は次の解釈を奜みたす同じデヌタを3セット保存し、2セットを異なるフォヌマットで保存し、1セットを地理的に離れたストレヌゞに保存する必芁がありたす。



ストレヌゞ圢匏は次のように理解する必芁がありたす。



  • 物理的な保管方法に䟝存しおいる堎合は、物理的な方法を倉曎したす。
  • 論理ストレヌゞ方匏に䟝存しおいる堎合、論理方匏を倉曎したす。


ルヌル3-2-1の最倧の効果を実珟するには、䞡方の方法でストレヌゞ圢匏を倉曎するこずをお勧めしたす。



意図した目的操䜜性の埩元のためのバックアップコピヌの可甚性の芳点から、「ホット」および「コヌルド」バックアップがありたす。 ホットずコヌルドの違いは1぀だけです。すぐに䜜業の準備ができおいるのに察しお、リカバリのコヌルドには、埩号化、アヌカむブからの抜出などの远加のアクションが必芁です。



ホットコピヌずコヌルドコピヌをオンラむンコピヌずオフラむンコピヌず混同しないでください。オンラむンコピヌずオフラむンコピヌは、デヌタの物理的な分離を意味し、実際、バックアップ方法の分類のもう1぀の兆候です。 そのため、オフラむンコピヌは、埩元する必芁があるシステムに盎接接続されおいないため、ホットたたはコヌルドのいずれかになりたすリカバリの準備の芳点から。 オンラむンコピヌは、埩元する必芁がある堎所で盎接利甚できる堎合がありたす。ほずんどの堎合、オンラむンコピヌはホットですが、コヌルドコピヌもありたす。



さらに、バックアップの䜜成プロセスは通垞、単䞀のバックアップの䜜成で終わるわけではなく、非垞に倚くのコピヌが存圚する可胜性があるこずを忘れないでください。 したがっお、完党バックアップを区別する必芁がありたす。 他のバックアップから独立しお回埩可胜なもの、および差分増分、差分、枛分などコピヌ-単独では埩元できず、1぀以䞊の他のバックアップの予備埩元が必芁なもの。



差分増分バックアップ-バックアップを保存するためのスペヌスのサむズを節玄する詊み。 したがっお、以前のバックアップから倉曎されたデヌタのみがバックアップに曞き蟌たれたす。



差分デクリメンタルは同じ目的で䜜成されたすが、わずかに異なる方法で䜜成されたす。完党バックアップが䜜成されたすが、新しいコピヌず以前のコピヌの違いのみが実際に保存されたす。



それずは別に、ストレヌゞ䞊でのバックアッププロセスを怜蚎する䟡倀がありたす。これにより、重耇するストレヌゞがなくなりたす。 したがっお、完党バックアップをその䞊に曞き蟌むず、実際にはバックアップ間の違いのみが蚘録されたすが、バックアップの埩元プロセスは完党コピヌからの埩元ず完党に透過的です。



Quis custodiet ipsos custodes



監芖員自身を守るのは誰ですか-lat。




バックアップがない堎合は非垞に䞍快ですが、バックアップが䜜成されたように芋える堎合はさらに悪いですが、埩元䞭に埩元できないこずがわかりたす。



  • ゜ヌスデヌタの敎合性が䟵害されおいたす。
  • バックアップストレヌゞが砎損しおいたす。
  • リカバリの動䜜は非垞に遅く、郚分的に埩元されたデヌタは䜿甚できたせん。




適切に構築されたバックアッププロセスでは、このようなコメント、特に最初の2぀を考慮する必芁がありたす。



゜ヌスデヌタの敎合性は、いく぀かの方法で保蚌できたす。 最も䞀般的に䜿甚されるのは、aブロックレベルでのファむルシステムスナップショットの䜜成、bファむルシステムの状態の凍結、cバヌゞョンストレヌゞを備えた特別なブロックデバむス、dファむルたたはブロックの順次蚘録です。 チェックサムは、リカバリ䞭のデヌタ怜蚌を確実にするためにも䜿甚されたす。



ストレヌゞの損傷は、チェックサムを䜿甚しお怜出するこずもできたす。 远加の方法は、既に蚘録されたデヌタを倉曎するこずは䞍可胜ですが、新しいものを远加するこずができる特殊なデバむスたたはファむルシステムの䜿甚です。



リカバリを高速化するために、いく぀かのリカバリプロセスでデヌタリカバリが䜿甚されたす-䜎速ネットワヌクたたは䜎速ディスクシステムの圢で「ボトルネック」が存圚しない堎合。 郚分的に埩元されたデヌタの状況を回避するために、バックアッププロセスを比范的小さなサブタスクに分割し、各サブタスクを個別に実行するこずができたす。 したがっお、リカバリ時間を予枬しお䞀貫しおパフォヌマンスを埩元するこずが可胜になりたす。 この問題は、倚くの堎合、組織面SLAにあるため、これに぀いおは詳しく説明したせん。



スパむスに぀いお倚くのこずを知っおいるのは、各料理にスパむスを加える人ではなく、䜙分なものを決しお加えない人です。



—B。 シンダフスキヌ




システム管理者が䜿甚する゜フトりェアに関する慣行は異なる堎合がありたすが、䞀般的な原則はずにかく同じです。



  • 既補の゜リュヌションを匷くお勧めしたす。
  • プログラムは予想どおりに動䜜するはずです。 文曞化されおいない機胜やボトルネックはありたせん。
  • 各プログラムのセットアップは、マニュアルやチヌトシヌトを毎回読む必芁がないように、十分にシンプルでなければなりたせん。
  • 可胜であれば、解決策は普遍的でなければなりたせん。 サヌバヌのハヌドりェア仕様は非垞に異なる堎合がありたす。




ブロックデバむスからバックアップを取埗するには、次の䞀般的なプログラムを䜿甚できたす。



  • システム管理のベテランに銎染みのdd、同様のプログラムたずえば、同じdd_rescueがここに属したす。
  • ファむルシステムのダンプを䜜成するいく぀かのファむルシステムに組み蟌たれおいるナヌティリティナヌティリティ。
  • 雑食ナヌティリティ。 䟋パヌトクロヌン。
  • 倚くの堎合、独自の決定を所有したす。 䟋NortonGhost以降。




ファむルシステムの堎合、バックアップタスクはブロックデバむスに適甚可胜な方法を䜿甚しお郚分的に解決されたすが、次の䟋を䜿甚しお問題をより効率的に解決できたす。



  • Rsync、ファむルシステムの状態を同期するための汎甚プログラムおよびプロトコル。
  • 組み蟌みのアヌカむブツヌルZFS。
  • サヌドパヌティのアヌカむブツヌル。 最も人気のある代衚者はtarです。 他にも、たずえばdarがありたす。tarを最新のシステムに重点を眮いお眮き換えたす。


それずは別に、バックアップの䜜成時にデヌタの䞀貫性を確保するための゜フトりェアツヌルに蚀及する䟡倀がありたす。 最も䞀般的に䜿甚されるオプションは次のずおりです。



  • ファむルシステムを読み取り専甚モヌドでマりントするReadOnly、たたはファむルシステムをフリヌズするフリヌズする-方法は制限されたす。
  • ファむルシステムたたはブロックデバむスLVM、ZFSの状態のスナップショットを䜜成したす。
  • 前の段萜を䜕らかの理由で提䟛できない堎合ホットコピヌなどのプログラムでも、キャストを敎理するためのサヌドパヌティツヌルの䜿甚。
  • 倉曎時のコピヌ手法CopyOnWriteですが、ほずんどの堎合、䜿甚されおいるファむルシステムBTRFS、ZFSに関連付けられおいたす。




そのため、小芏暡サヌバヌの堎合、次の芁件を満たすバックアップスキヌムを提䟛する必芁がありたす。





倚かれ少なかれ芁件を満たす人からの申請者





プロクラステアンベッド



次の特性を持぀仮想マシンXenServerベヌスがテストベンチずしお䜿甚されたす。





ほが同じマシンがバックアップ先サヌバヌずしお䜿甚され、500 GBのハヌドドラむブのみが䜿甚されたす。



オペレヌティングシステム-Centos 7 x64内蚳は暙準であり、远加のパヌティションがデヌタ゜ヌスずしお䜿甚されたす。



40 GBのメディアファむル、mysqlデヌタベヌスを含む゜ヌスデヌタずしおワヌドプレスサむトを取り䞊げたしょう。 仮想サヌバヌには特性が倧きく異なるだけでなく、再珟性も向䞊するため、



sysbenchを䜿甚したサヌバヌテスト結果。
sysbench --threads = 4 --time = 30 --cpu-max-prime = 20,000 cpu run

sysbench 1.1.0-18a9f86バンドルされたLuaJIT 2.1.0-beta3を䜿甚

次のオプションを䜿甚しおテストを実行したす。

スレッド数4

珟圚時刻から乱数ゞェネレヌタヌを初期化する



玠数の制限20,000



ワヌカヌスレッドの初期化...



スレッドが開始したした



CPU速床

1秒あたりのむベント836.69



スルヌプット

むベント/秒eps836.6908

経過時間30.0039s

むベントの総数25104



レむテンシヌミリ秒

最小2.38

平均4.78

最倧22.39

95パヌセンタむル10.46

合蚈119923.64



スレッドの公平性

むベントavg / stddev6276.0000 / 13.91

実行時間avg / stddev29.9809 / 0.01



sysbench --threads = 4 --time = 30 --memory-block-size = 1K --memory-scope = global --memory-total-size = 100G --memory-oper = read memory run

sysbench 1.1.0-18a9f86バンドルされたLuaJIT 2.1.0-beta3を䜿甚

次のオプションを䜿甚しおテストを実行したす。

スレッド数4

珟圚時刻から乱数ゞェネレヌタヌを初期化する



次のオプションを䜿甚しおメモリ速床テストを実行したす。

ブロックサむズ1KiB

合蚈サむズ102400MiB

操䜜読み取り

スコヌプグロヌバル



ワヌカヌスレッドの初期化...



スレッドが開始したした



合蚈操䜜509004461696677.10 /秒



49707.47 MiB転送1656.91 MiB /秒



スルヌプット

むベント/秒eps1696677.1017

経過時間30.0001s

むベントの総数50900446



レむテンシヌミリ秒

最小0.00

平均0.00

最倧24.01

95パヌセンタむル0.00

合蚈39106.74



スレッドの公平性

むベントavg / stddev12725111.5000 / 137775.15

実行時間avg / stddev9.7767 / 0.10



sysbench --threads = 4 --time = 30 --memory-block-size = 1K --memory-scope = global --memory-total-size = 100G --memory-oper = write memory run

sysbench 1.1.0-18a9f86バンドルされたLuaJIT 2.1.0-beta3を䜿甚

次のオプションを䜿甚しおテストを実行したす。

スレッド数4

珟圚時刻から乱数ゞェネレヌタヌを初期化する



次のオプションを䜿甚しおメモリ速床テストを実行したす。

ブロックサむズ1KiB

合蚈サむズ102400MiB

操䜜曞き蟌み

スコヌプグロヌバル



ワヌカヌスレッドの初期化...



スレッドが開始したした



合蚈操䜜359104131197008.62毎秒



35068.76 MiB転送1168.95 MiB /秒



スルヌプット

むベント/秒eps1197008.6179

経過時間30.0001s

むベントの総数35910413



レむテンシヌミリ秒

最小0.00

平均0.00

最倧16.90

95パヌセンタむル0.00

合蚈43604.83



スレッドの公平性

むベントavg / stddev8977603.2500 / 233905.84

実行時間avg / stddev10.9012 / 0.41



sysbench --threads = 4 --file-test-mode = rndrw --time = 60 --file-block-size = 4K --file-total-size = 1G fileio run

sysbench 1.1.0-18a9f86バンドルされたLuaJIT 2.1.0-beta3を䜿甚

次のオプションを䜿甚しおテストを実行したす。

スレッド数4

珟圚時刻から乱数ゞェネレヌタヌを初期化する



远加のファむルオヌプンフラグなし

128ファむル、それぞれ8MiB

1GiBの合蚈ファむルサむズ

ブロックサむズ4KiB

IOリク゚ストの数0

組み合わされたランダムIOテストの読み取り/曞き蟌み比率1.50

定期的なFSYNCを有効にし、100リク゚ストごずにfsyncを呌び出したす。

テストの終了時にfsyncを呌び出しお有効にしたす。

同期I / Oモヌドを䜿甚する

ランダムr / wテストを行う

ワヌカヌスレッドの初期化...



スレッドが開始したした



スルヌプット

読み取りIOPS = 3868.21 15.11 MiB / s15.84 MB / s

曞き蟌みIOPS = 2578.83 10.07 MiB / s10.56 MB / s

fsyncIOPS = 8226.98



レむテンシヌミリ秒

最小0.00

平均0.27

最倧18.01

95パヌセンタむル1.08

合蚈238469.45



このメモは倧きく始たりたす







Finnix による投皿



All Articles