私は主にNASとしてサーバーを設定しました。 Ubuntu Server 22.04 LTSを実行し、データはハードウェア制御RAIDに保存されます。
明らかにオフサイト保存用のバックアップを作成し、\
tar -cvpzf \
/backup/location/backup1.tar.gz \
--exclude=/some/files/* \
/source/directory/
問題の説明：
小さなデータセットでテストした結果、正常にバックアップされました。フルドライブを試みた後、バックアッププロセスがある時点で停止し、破損したtarファイルが残りました。
- 障害点が別のファイルで発生しました。これまでは、.isoファイルと.exeファイルを削除すると、これが起こるようです。
- 当時のアーカイブサイズは5.4GBでした。
tar -tf /backup/location/backup1.tar.gz返品：
gzip: stdin: unexpected end of file
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now
質問0： このユースケースでtarを使用しますか？
...またはまったく異なるソリューションをお勧めしますか？
質問1： アーカイブが破損しているのはなぜですか？
これまで、私はこれがアーカイブファイルの種類やフルサイズに関連している可能性があると思います。しかし、私はこれを議論するスレッドを見ませんでした。
質問2： この衝突を避ける方法は？
質問1に続いて、バックアッププロセス中に自動的に整合性をチェックして競合なしでバックアップを作成する方法は何ですか？
質問3： 破損したアーカイブを修復できますか（最後の/破損したファイルを除く）？
バックアップが破損した後にバックアップを再作成する方法はありますか？
答え1
小さなデータセットでテストした結果、正常にバックアップされました。フルドライブを試みた後、バックアッププロセスがある時点で停止し、破損したtarファイルが残りました。
失敗の原因を調査する必要があります。ソースファイルを読みますか？ターゲットファイルに書きますか？ターゲットファイルシステムがいっぱいだからですか？それとも、両方のストレージデバイスのいずれかが信頼できないためですか？
良い点は、tarが非常に単純な形式であることです。実際には、ファイル記述ヘッダー、ファイル内容、次の512Bの倍数、次のファイル記述ヘッダーのパディングです。
それで、私が保存しようとした最後のものを除いて、すべてはまったく大丈夫でした。
悪いことは、tarが非常に素朴な形式であるということです。チェックサムはなく、ファイルの長さだけがヘッダーに格納されているため知るファイルが正しく作成されたかどうか。
- Q0：個人的に気に入らない
tar。多くの点で非効率的です。私はsquashfsが実際にディレクトリを含んでいるので好みます。したがって、tarのように最後のファイル名が何であるかを知るために、すべてのアーカイブファイルを読む必要はありません。また、事後に適用する必要のない圧縮機能が組み込まれており、検索する場所を知るために大容量アーカイブを解凍せずに検索できるという利点があります。同じデータは一度だけ保存されます。最後に、squashfsアーカイブを抽出せずにファイルシステムに簡単にマウントできます。よりユーザーフレンドリーです。
ただし、実際には毎回コンテンツ全体をアーカイブとしてアーカイブしようとしていると仮定します。普通はこんなことをしたくないでしょうが、増分バックアップ。使用するツールは、特定のユースケースと目的によって異なります。 btrfsの組み込みスナップショット機能を使用するソリューションに接続する方法については、実際に多くの議論があります。増分バックアップ用のLinuxバックアップユーティリティ - 質問1：私たちは本当に知りません。 「ある時点で止まる」という説明が足りません。詳しくは直接調べてみてください。
- Q2：Q1を参照してください。
- Q3: 変更することはありません。最後のファイルまで（含まれていない）アーカイブは完全な順序になっています。
xアーカイブからファイルを抽出するだけです。
ところで、あなたはすでに最新のシステムを持っています。使用時に-z圧縮を使用しないでくださいtar。これはでも利用可能なgzipです--zstd。