/homeにマウントされたファイルシステムには2.6PBのストレージ容量があります。現在、/homeディレクトリの下に300TB以上のデータが散在しています。300TB以上のデータ全体をバックアップするつもりです。日常的に/home/fs_backup にコピーしようとしましたが、次のコマンドはtar非常に遅いことがわかりました。
cd /home/fs_backup && tar -cpf backup.tar.gz --exclude="/home/fs_backup" --one-file-system "/home"
10GB/分しか生成できないと見積もっています。つまり、300TB 以上のデータ全体を 24 時間でバックアップすることはできないということです。/home の現在のデータが十分に圧縮されているか、まったく圧縮されていないか、あるいは短時間でないかに関係なく、そのデータの「コピー」を作成する方法をご存知ですか。どうもありがとうございます。
答え1
規定の 24 時間以内に 300 GB 全体をバックアップできないことがすでに判明しているため、要件を確認する必要があります。
starファイル レベルでは、、、duplicityまたはrsync/などの増分ツールでは、rsnapshotベース バックアップの作成に 1 日以上かかる場合がありますが、その後は大幅に高速化されます。当然、これは 24 時間のバックアップ期間内に変更されるファイルの数とサイズに依存します。
ファイルシステム レベルでは、スナップショットで十分かもしれません (ただし、これは実際にはバックアップではありません)。特に、完了するまでの時間をあまり気にせずに、スナップショットから実際のバックアップを自由に作成できるためです。以前と同様に、ベース バックアップが作成されると、増分バックアップの作成にかかる時間が大幅に短縮されます。
バックアップをどのように保存するかは指定されていませんが、多くの小さなファイルの場合は、次のような方法がrsnapshot適している可能性があります。(私は、回復目的で個々のファイルに簡単にアクセスできるため、多くの社内ファイルサーバーのファイルベースのバックアップにこれを使用しています。)
ちなみに、同じホスト上の別のディスクへのバックアップは、実際には安全なバックアップとは見なされません。まったく別のホストにバックアップする方がはるかに良いでしょう。(別のサーバーからのリモート マウントの場合は、リモート マウントされたファイル システムを経由するのではなく、または/ を使用してリモート ホストと直接通信することを/home/fs_backup真剣に検討してください。)duplicityrsyncrsnapshot
答え2
私が知っているバックアップを行う最も速い方法は、 を使用することですstar(このプログラムの最新バージョンは で参照してくださいschilytools)。このプログラムは、ファイルシステム プロセスとアーカイブ I/O を行う別のプロセスの間にある任意のサイズのリング バッファを実装します。FIFO サイズが適切に選択されていれば、ほぼすべてのファイルが 1 つのread()システム コールを使用して読み取られ、これにより (最適化されたコードと相まって) 非常に高速になります。
このリング バッファは と呼ばれFIFO、デフォルトでは を使用しますが、任意のサイズを使用するように指示することもできます。使用可能な最大値は、マシン内の8MBの量の半分です。RAM
starまた、実用的な増分ダンプもサポートしており、最終段階で時間がほとんどかからない方法でファイルシステムの内容を保存するには、完全ダンプの後に増分ダンプを実行することをお勧めします。
次の man ページをご覧になることをお勧めします:http://schilytools.sourceforge.net/man/man1/star.1.html
このマニュアル ページでは、ライブ ファイル システムからではなく、snapshotファイル システム レベルからバックアップを実行することを推奨していることに注意してください。