最高は善の敵
バックアップを作成するか、ソフトウェアをインストールして構成することは、私たちにとって常に撮影作業でした。 リポジトリのいずれかを配置すると、結果を完全に確認することはできません。 はい、すべてが完璧に行われたとしても、メンテナーは遅かれ早かれ何かを壊します。 バックアップに関しては、問題が発生したときに記憶されます。 人々はすでに危機にonしており、他の何かが彼らが期待したようにうまくいかない場合...まあ、あなたは理解しています。
非常に多くのバックアップ方法がありますが、それぞれに1つの目標があります。プロセスを可能な限り高速にすると同時に、可能な限り安価にすることです。
みんなを喜ばせようとする
2011年外。 サーバーの合計バックアップが忘却に陥ってから1年以上が経過しました。 いいえ、彼らは仮想サーバーのバックアップを行い、現在それを行っています。 たとえば、WHD.moscowでは、ライブマイグレーションを通じて仮想サーバーをバックアップする本当にエレガントな方法を教えられました。 そして今でも、これは10〜15年前ほどではありません。
強力なイベントシステムと内部呼び出しが実装された独自のフレームワークに基づいて、製品の5番目のバージョンの開発を開始しました。
ユーザーが時間を設定し、バックアップの種類と内容を選択し、それらを異なるストレージに配置できるように、バックアップを設定するための真に柔軟で普遍的なアプローチを実装することが決定されました。 さらに、このソリューションをいくつかの製品に拡張することにしました。
また、バックアップの目標も大きく異なる場合があります。 誰かが機器の故障から保護するためにバックアップを作成し、誰かが管理者の過失によるデータ損失から保険をかけます。 素朴な、私たちはみんなを喜ばせたかった。
側面から見ると、柔軟なシステムを作成するための試みは次のようになりました。
右足のつま先で、尻を押します 。 カスタムストレージを追加しました。 結局のところ、問題は何ですか？既成のアーカイブを2つの場所に注ぐことですか？ 実際、問題があります。アーカイブをリポジトリの1つにアップロードできない場合、バックアップは成功したと見なされますか？なぜこれをしているのですか？ 非常に柔軟なため、無数のユースケースが発生し、それらすべてをテストすることはほぼ不可能になりました。 したがって、単純化の道に従うことにしました。 数キロバイトかかる場合にメタデータを保存するかどうかをユーザーに尋ねる理由。 または、たとえば、どのアーカイバを使用しているのか本当に興味がありますか？
左足のつま先で2番目の尻を押します 。 アーカイブを暗号化することにより槍を破る。 ユーザーがパスワードを変更したい場合に何をすべきかを考えるまでは簡単です。
そして今、あなたは両方のスタブを一緒にプッシュしています！
別の面白い間違い：バックアップ時間を4:00から8:00に制限したユーザーがいました。 問題は、プロセス自体が毎日3:00にスケジューラを介して起動されることでした（標準の@daily設定）。 プロセスが開始され、その時点で彼が仕事をすることを禁じられていると判断し、去りました。 バックアップは作成されませんでした。
バイクダーを書く
10倍半ばに、クラスターに関する誇大広告が拡大し始め、続いて雲が広がりました。 傾向があります-1つのサーバーだけでなく、サーバーのグループを管理してクラウドと呼びましょう:)これはISPmanagerにも影響しました。
また、多くのサーバーがあったため、データ圧縮を別のサーバーに置くという考え方が復活しました。 何年も前のように、私たちは既成のソリューションを見つけようとしました。 奇妙なことに、彼らはバキュラが生きていることを発見しましたが、同じくらい複雑です。 それを管理するには、おそらく別のパネルを書く必要がありました。 それから、かつてispbackupに投資されていた多くのアイデアを実装したdarに出会いました。 それは
2014年に、darを使用したソリューションが作成されました。 しかし、2つの重大な問題が含まれていました。まず、受信したdarアーカイブは、元のアーカイバー（つまり、dar自体）のみが解凍できます。 2番目に、darはメモリ内のファイルのリストをXML（その母！）形式で作成します。
このユーティリティのおかげで、Cのメモリを小さなブロック（centos 7では120バイト未満にする必要があります）にメモリを割り当てると、プロセスを完了せずにシステムに戻すことができないことがわかりました。しかし、そうでなければ、彼は私にとても親切でした。 そのため、2015年に、独自のdar-isptarバイクを作成することにしました。 ご想像のとおり、tar.gz形式が選択されました-非常に簡単に実装できます。 ispbackupを作成したときに、あらゆる種類のPAXヘッダーを見つけました。
この問題に関するドキュメントはあまり多くないことを言わなければなりません。 そのため、やがて、tarが長いファイル名と大きなサイズでどのように機能するかを調べるのに時間を費やさなければなりませんでした。 ファイル名の長さは100バイト、ディレクトリは155、ファイルサイズの10進レコードは12バイトなどです。まあ、640キロバイトで十分です。 ハ！ ハ！ ハ！
いくつかの問題を解決するために残った。 1つ目は、アーカイブを完全に解凍する必要なく、ファイルのリストをすばやく取得することです。 2つ目は、任意のファイルを完全に解凍せずに抽出する機能です。 3つ目は、tgzのままにすることです。これは、任意のアーカイバで展開できます。 これらの問題をそれぞれ解決しました！
特定のオフセットからアーカイブの展開を開始する方法は？
gzスレッドを接着できることがわかりました！ 簡単なスクリプトでこれを証明できます。
cat 1.gz 2.gz | gunzip -
エラーのないファイルの接着されたコンテンツを取得します。 各ファイルが個別のストリームであるかのように書き込まれている場合、問題は解決されます。 もちろん、これにより圧縮率は低下しますが、それほど大きくはなりません。
リストはさらに簡単です。
リストをアーカイブの最後に通常のファイルとして配置しましょう。 また、リストでは、アーカイブにファイルオフセットも書き込みます（ところで、darはアーカイブの最後にリストを保存します）。
なぜ最後に？ サイズが数百ギガバイトをバックアップする場合、アーカイブ全体を保存するのに十分なスペースがない場合があります。 したがって、作成するときに、それを部分的にストレージにマージします。 素晴らしいのは、1つのファイルを取得する必要がある場合、リストとデータを含む部分だけが必要なことです。
残っている問題は1つだけです：リスト自体のオフセットを取得する方法は？
これを行うために、リスト自体の最後に、リスト自体のパックサイズを含むアーカイブに関するサービス情報を追加し、サービス情報の最後に、個別のgzストリームの形式で、サービス情報自体のパックサイズを追加しました（これらは2桁のみです）。 リストをすばやく取得するには、最後の数バイトを読んで展開するだけです。 次に、サービス情報（現在わかっているファイルの末尾に対するオフセット）を読み取り、次にリスト自体（サービス情報から取得したオフセット）を読み取ります。
簡単なリストの例。 さまざまな色が個々のgzストリームを強調しています。 したがって、最初に赤を解凍します（最後の20〜40バイトを分析するだけです）。 次に、パックされた短い情報（青で強調表示）を含む68バイトをアンパックします。 最後に、リストを読み取るためにさらに6247バイトを解凍します。実際のサイズは33522バイトです。
etc/.billmgr-backup root#0 root#0 488 dir
etc/.billmgr-backup/.backups_cleancache root#0 root#0 420 file 1487234390 0
etc/.billmgr-backup/.backups_imported root#0 root#0 420 file 1488512406 92 0:1:165:0
etc/.billmgr-backup/backups root#0 root#0 488 dir
etc/.billmgr-backup/plans root#0 root#0 488 dir
…
listing_header=512
listing_real_size=33522
listing_size=6247
header_size= 68
少し混乱しているように聞こえますが、ソースを調べて自分のやり方を覚えていなければなりませんでした。 isptarソースも確認できます。ispbackupソースと同様に、私はgithubに投稿しました。
もちろん、話はそこで終わりません。 火、駐車した女性、松葉杖の助けを借りて他の人を倒そうとする人をいつでも見ることができます。