作業中に発生する破損ファイルのほとんどは、オフィス（ドキュメント、表、プレゼンテーション）またはグラフィック形式に関連しています。 また、その特徴は比較的小さいサイズです（10 MB未満）。 これには2つの理由があります。 まず、これらの形式のファイルを作成して使用する膨大な数のユーザーがいます。 第二に、通常は非常に小さく、多くの場合信じられているように、あまり重要ではないファイルは企業データ保護の範囲に含まれません。 このようなファイルは、多くの場合、ポータブルデータストレージ（USBフラッシュ、場合によってはフロッピーディスク）に保存されます。これは、その安全性にも非常に嘆かわしい影響を与えます。 このクラスのファイルを処理する場合、通常、入力データのサイズに関連する問題はありません。入力ファイルは、必要に応じてRAMに完全に投影して直接実行できます。
また、ファイルの回復のために私たちのところに来るファイルのかなりの割合がさまざまなデータベースです。 そのサイズは通常、数百メガバイトから数十ギガバイトの範囲です。 通常、このようなファイルは企業のデータ保護対策の対象になりますが、これは完全な障害が発生した場合にデータが保存されるという絶対的な保証を与えるものではありません。 これらのファイルのほとんどは不適切であるか、メモリに保存できません。 したがって、それらがRAMで処理されると、ファイル内のデータの場所のマークアップが最初に形成され、それに応じてリカバリに適したデータが読み取られ、出力データが次のリカバリステップで生成されます。 ファイルマークアップで占有される可能性のある大容量の場合、および回復プロセス中に、1つのオブジェクトを形成する異なるデータを接続する必要がある場合（たとえば、レターをExchange Serverストレージデータベースに接続する）、マークアップを格納する一時データベースが使用されます。
しかし、例外的なケースがあります-サイズが数百ギガバイトから数テラバイトに及ぶ破損したデータベース。 もちろん、そのようなボリュームのデータは重要ではありません。多くの場合、会社全体の作業はそのようなデータベースを中心に構築されます。 明らかに、ストレージの信頼性を確保するために、すべてのバックアップスキームをそのようなデータに適用する必要がありますが、これにはすべて、データベースが落ちる場合があります。 これらのケースの1つについては、後で説明します。
問題の陳述
当社には、1.8テラバイトのMS SQL Serverデータベースを復元する必要があるユーザーから連絡がありました。 このケースの前に処理する必要があった最大のファイルは200ギガバイトのExchange Serverデータベースであったため、このサイズのファイルを操作した経験はありませんでした。 ユーザーがこのデータベース形式のリカバリ用に製品-Recovery for SQL Server（ www.officerecovery.com/mssql/ ）を購入しましたが、データベースを復元しようとすると、プログラムはテーブルの最初の99999 sqlスクリプトファイルを記録し、視覚的には何もしませんでした。 この問題の解決策は、出力ファイル名のsqlスクリプトカウンターのビット数を増やし、各ファイルに書き込まれるデータの量を増やすことでした。 更新されたプログラムのビルドが送信された後、ユーザーはデータベースを復元するために再度ビルドを開始しましたが、数日後にプログラムがクラッシュしました。 ユーザーは、プログラムの処理がそれほど速くないことについても不満を述べました。 今後の作業は、これら2つの苦情に基づいています。
これらの問題を解決するプロセスを高速化するために、ユーザーに秘密保持契約（NDA）に署名して、問題のベースのコピーを送信するようにユーザーに依頼しました。 データベースはハードドライブ上にあり、カリフォルニアのサーバーの1つに接続しました。 そこで実際のデータのさらなる実行が行われました。
プログラムの変更
このリクエストに取り組んでいるとき、プログラムの改善は2つの主な目標を追求しました。
- 超大容量のファイルを復元するための基本的な可能性-3テラバイトのデータベースを復元できるようになった場合、実質的にあらゆるサイズのデータベースを復元する可能性について話し合うことができます。
- プログラムの加速-回復するのに4〜6時間の差はほとんど重要ではありません。20〜30日の差は重要です。
まず第一に、このファイルでの転倒の問題に関するプログラムの調査が行われました。 誤ったデータからのアルゴリズムの保護が不十分であることが原因であるというオプションがありました-この場合、これらの誤ったデータの場所を特定し、それらに対処し、そのようなビットネスからの保護を導入する必要がありました このデータベースを構成する約500個の個々のファイルを検索する必要があります。 しかし、別のバージョンのフォールが確認されました-一時データベースからマークアップを読み取るための最適でないアルゴリズムのため、超大量のデータに十分なRAMがありませんでした。 アルゴリズムが再設計され、落下がなくなりました。 さらなる作業の過程で他の転倒は発生しませんでした。
プログラムの速度は次の2つの方法で改善されました。
- ベースの初期分析の速度。 最初は約2日でした。 読み取りバッファの独自の実装のためにシステムバッファリングを拒否してファイルの読み取りを処理した後、解析時間は6〜7時間に短縮されました。 システムファイルの読み取りバッファでRAMが詰まる問題も解決されました。
- 出力生成レート。 出力はsqlスクリプトであるため、プロセッサ時間のほとんどはバイナリデータから文字列を生成するために費やされます。 SQLスクリプトジェネレーターの大規模な最適化が実行されました。 結果-ハードドライブに書き込みを行わずにデータベースを完全に復元します（ただし、すべての出力が生成されます）-6日8時間。 最初（最適化前の部分的なファイルリカバリに基づく計算による）、復元には25〜27日かかりました。
出力ファイルをハードドライブに書き込まずに「仮想」データベースリカバリを完全に実行した後、別の問題が明らかになりました。データベースを再作成する出力スクリプトは、12,730,132,244,866バイト（11.6テラバイト）を占有しなければならず、単に保存する場所がありませんでした
出力ファイルを保存する問題を解決するために、SQLスクリプトはzipアーカイブにその場で圧縮されました。 パッケージは、対応するスクリプトのパッケージが削除された後、約20ギガバイトのスクリプトパックの個別のストリームで起動されました。 しかし、スクリプトは以前のものよりも速く生成され、スレッド数の増加に伴い、ハードディスクの負荷が急激に増加したため、パッケージングで同時に動作するスレッドの数は4つに制限されました。 この制限に達すると、メインリカバリフローが停止し、パッケージングの完了を待ちました。
その結果、データベースの回復は成功しました。 復旧時間は17日間で、データのアーカイブによりプロセスが遅くなりましたが、この妥協を余儀なくされました。 パッケージ化されたスクリプトのサイズは1.1テラバイトです。 スクリプトは別のハードドライブに記録され、ユーザーに送信されました。 すべてのスクリプトを実行してベースをシステムに返すのにしばらく時間がかかった後、ユーザーから肯定的な応答が受信されました。
結論
このような膨大な量のデータを回復することも可能ですが、ほとんどの場合、回復サービスからの個別のアプローチと、特定のケースのプログラムの最終化または調整が必要になります。
問題が発生した場合、このクラスのデータベースは、破損したファイルをすぐに復元できないプログラムをスローする必要はありません。 そのような場合の私たちとの直接のコミュニケーションは、そのようなファイルをマスターできるレベルまでプログラムを改良するのに役立ちます。 OfficeRecoveryがこのような唯一のケースではありません。200〜500ギガバイトのデータベースをリカバリするいくつかのケースを認識しており、そのようなケースすべてを知っているわけではありません。
次の構成ですべてのパフォーマンスインジケーターがプログラムから削除されました。IntelCore i7 920、8Gb RAM、1Tb（システム）+ 2Tb（入力）+ 2Tb（出力）SATA-2 HDD。 リカバリを高速化するために、パッケージ化を目的としたスクリプトの一時的な保存には別のSSDが非常に役立ちます。
忘れずにバックアップして、信頼できるストレージ方法を使用してください。 しかし、誰もデータ損失から安全ではないことを忘れないでください。 データの損失がまだ発生している場合-OfficeRecoveryがあなたを待っています。