tar でも インクリメンタル モードはありません。ジョブを実行するためのより包括的なツールがいくつかあります。
- 重複
- 重複
増分バックアップをサポートするだけでなく、完全バックアップを実行する必要があるスケジュールを簡単に構成できます。例えば duplicity で :duplicity --full-if-older-than 1M 完全バックアップが実行されたことを確認します。また、特定のファイルにさかのぼることもサポートしています。プレーン tar を使用すると、適切なファイルを含むファイルが見つかるまで、すべての増分ファイルを調べる必要があります。
さらに、暗号化とさまざまなバックエンド (sftp、blob ストレージなど) へのアップロードをサポートしています。明らかに、暗号化する場合は、二次バックアップにキーの適切なバックアップを作成することを忘れないでください!
もう 1 つの重要な側面は、たとえば duplicity verify を使用して、バックアップの整合性を検証し、確実に復元できることです。 .
git ベースのバックアップ戦略については否定的にアドバイスします。大規模な復元にはかなりの時間がかかります。
<ブロック引用>
rsync を試しましたが、やりたいことを実行できないようです。または、それを実行する方法がわからない可能性が高いです。
おそらく、差分を実行し、結果に基づいてバックアップするファイルを選択するスクリプトを作成できることはわかっています（または、より効率的には、チェックサムを取得して比較するだけです）が、これを実行できるユーティリティがあるかどうかを知りたいです少し簡単:)
rsync diffに基づいてコピーするプログラムはまさにそのプログラムです。デフォルトでは最終更新時刻やサイズに差がある場合のみコピーしますが、-c のチェックサムで比較することもできます .
ここでの問題は、あなたが tar であることです バックアップを行っています。これをしないと簡単になります。なぜそんなことをしているのかさえわからない。それらを圧縮しているのであれば意味があるかもしれませんが、そうしていません.
増分バックアップに関するウィキペディアの記事には、 rsync の例があります おおよそのコマンド:
rsync -va \
--link-dest="$dst/2020-02-16--05-10-45--testdir/" \
"$src/testdir/" \
"$dst/2020-02-17--03-24-16--testdir/"
ソースから変更されていないときに、以前のバックアップからファイルをハードリンクします。 --copy-dest もあります 代わりにコピーする場合 ($dst の場合はさらに高速です) はリモートまたはより高速なドライブ上にあります)。
btrfs のようなサブボリュームを持つファイルシステムを使用する場合、rsync を実行する前に以前のバックアップからスナップショットを作成することもできます。スナップショットは瞬時に作成され、追加のスペースを必要としません[1]。
btrfs subvolume snapshot \
"$dst/2020-02-16--05-10-45--testdir" \
"$dst/2020-02-17--03-24-16--testdir"
または、ext4 などの reflinks をサポートするファイルシステムを使用している場合は、それも可能です。 Reflinks は、新しい i ノードを作成することによって行われますが、ソース ファイルと同じブロックを参照し、COW サポートを実装します。データの読み取りと書き込みを行わず、追加のスペースも必要としないため、通常のコピーよりも高速です[1]。
cp --reflink -av \
"$dst/2020-02-16--05-10-45--testdir" \
"$dst/2020-02-17--03-24-16--testdir"
とにかく、そのようなことをしたら、通常の rsync を実行できます 違いをコピーするには:
rsync -va \
"$src/testdir/" \
"$dst/2020-02-17--03-24-16--testdir/"
ただし、 --delete を追加したい場合があります これにより、ソースに存在しなくなったファイルが rsync によって宛先から削除されます。
別の便利なオプションは -i です または --itemize-changes . rsync が行っている変更を説明する簡潔で機械可読な出力を生成します。私は通常、そのオプションを追加して次のようにパイプします:
rsync -Pai --delete \
"$src/testdir/" \
"$dst/2020-02-17--03-24-16--testdir/" \
|& tee -a "$dst/2020-02-17--03-24-16--testdir.log"
簡単に grep 経由で変更を記録する 可能なファイル。 |& stdout と stderr の両方をパイプすることです。
-P --partial の略です と --progress . --partial 部分的に転送されたファイルを保持しますが、さらに重要なのは --progress ファイルごとの進行状況を報告します。
tar による変更のアーカイブとの比較
上記の解決策は、すべてを保持しているように見えるディレクトリになります。その場合でも、バックアップの量/頻度に関係なく、合計すると、変更のみのプレーンな tar アーカイブとほぼ同じ量のスペースを占有します。これは、ハードリンク、参照リンク、およびスナップショットがどのように機能するかによるものです。バックアップを作成する際の帯域幅の使用も同じです。
利点は次のとおりです。
- rsync はバックアップからの差分のみを転送するため、rsync を使用するとバックアップを簡単かつ迅速に復元できます。
- 必要に応じて簡単に参照および変更できます。
- ファイルの削除は、新しいバックアップにファイルが存在しないこととして自然にエンコードできます。 tar アーカイブを使用する場合、ファイル
fooを削除するなどのハックに頼る必要があります。 、それをマークfoo.DELETEDまたは複雑なことをします。たとえば、重複を使用したことはありませんが、そのドキュメントを見ると、新しい tar に同じ名前の空のファイルを追加し、ファイルの元の署名を別の .sigtar ファイルに保持することで、削除をエンコードしているようです。ファイルの削除と実際の空のファイルへの変更を区別するために、元の署名と空のファイルの署名を比較していると思います。
異なる (追加または変更された) ファイルのみを保持するように各バックアップをセットアップしたい場合は、--link-dest を使用できます。 上記の解決策を試してから、次のような方法でハードリンクを削除してください:
find $new_backup -type f ! -links 1 -delete
[1] 厳密に言えば、ファイル名などのように、重複するメタデータの形で追加のスペースを使用します。しかし、誰もがそれを取るに足らないと考えると思います.
そして、なぜ git を検討しないのですか? 自体？
あなたが説明した戦略は、1回の完全バックアップと2回の増分バックアップの後、続行すると複雑になります。間違いを犯しやすく、できます 変更によっては非常に非効率になります。一種のローテーションが必要です。つまり、ときどき新しい完全バックアップを作成し、古いバックアップを保持しますか?
働く プロジェクトを含むディレクトリ「testdir」 (ファイル、およびサブディレクトリ)、git デフォルトで非表示の .git を作成します データのサブディレクトリ。これは、ローカルの追加のバージョン管理用です 特徴。バックアップのために、メディアにアーカイブ/コピーしたり、ネットワーク経由でクローンしたりできます。
リビジョン コントロール あなたが得る（尋ねることなく）は、gitの差分ストレージの副作用です。
分岐/分岐などはすべて省略できます。これは、「マスター」と呼ばれる 1 つのブランチがあることを意味します。
コミットする (実際には git アーカイブ/レポに書き込む) 前に、構成ファイル用に最小限のユーザーを構成する必要があります。次に、最初にサブディレクトリ (おそらく tmpfs) で学習してテストする必要があります。 Git は tar と同じくらい扱いにくい場合があります。
とにかく、コメントが言うように:バックアップは簡単ですが、難しいのは復元です.
git の欠点は、わずかなオーバーヘッド/やり過ぎです。
利点は次のとおりです:git tracks コンテンツとファイル名。差分に基づいて、必要なものだけを保存します (少なくともテキスト ファイルの場合)。
例
ディレクトリに3つのファイルがあります。 git init の後 、 git add . と git commit 私は 260K .git を持っています dir.
それから私は cp -r .git /tmp/abpic.git (バックアップを保存するのに適した場所:)。私は rm 154K jpg、および変更 1 つのテキスト ファイル。私もrm -r .git .
]# ls
atext btext
]# git --git-dir=/tmp/abpic.git/ ls-files
atext
btext
pic154k.jpg
ファイルを復元する前に、正確な違いを取得できます:
]# git --git-dir=/tmp/abpic.git/ status
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: atext
deleted: pic154k.jpg
no changes added to commit (use "git add" and/or "git commit -a")
ここでは git restore に従いたいと思います ヒント。
git --git-dir=/tmp/abpic.git/ restore \* の後 :
]# ls -st
total 164
4 atext 156 pic154k.jpg 4 btext
jpeg が復活し、テキスト ファイル btext 持っているいない 更新されました (タイムスタンプを保持します)。 atext の変更点 上書きされます。
レポと（作業中の）ディレクトリを再結合するには、コピーして戻すことができます。
]# cp -r /tmp/abpic.git/ .git
]# git status
On branch master
nothing to commit, working tree clean
現在のディレクトリのファイルは .git と同じです アーカイブ (restore の後) ）。新しい変更が表示され、計画を立てることなく追加およびコミットできます。バックアップ目的で、別のメディアに保存するだけです。
ファイルが変更された後、 status を使用できます または diff :
]# echo more >>btext
]# git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: btext
no changes added to commit (use "git add" and/or "git commit -a")
]# git diff
diff --git a/btext b/btext
index 96b5d76..a4a6c5b 100644
--- a/btext
+++ b/btext
@@ -1,2 +1,3 @@
This is file b
second line
+more
#]
git のように ファイル「btext」の「+more」について知っている場合、その行も増分的にのみ保存されます。
git add . の後 (または git add btext ) status コマンドは赤から緑に切り替わり、commit 情報を提供します。
]# git add .
]# git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: btext
]# git commit -m 'btext: more'
[master fad0453] btext: more
1 file changed, 1 insertion(+)
そして、どういうわけか、本当に内容を理解することができます:
]# git ls-tree @
100644 blob 321e55a5dc61e25fe34e7c79f388101bd1ae4bbf atext
100644 blob a4a6c5bd3359d84705e5fd01884caa8abd1736d0 btext
100644 blob 2d550ffe96aa4347e465109831ac52b7897b9f0d pic154k.jpg
そして、最初の 4 つの 16 進ハッシュ数字
]# git cat-file blob a4a6
This is file b
second line
more
1 つのコミットで時間をさかのぼるには:
]# git ls-tree @^
100644 blob 321e55a5dc61e25fe34e7c79f388101bd1ae4bbf atext
100644 blob 96b5d76c5ee3ccb7e02be421e21c4fb8b96ca2f0 btext
100644 blob 2d550ffe96aa4347e465109831ac52b7897b9f0d pic154k.jpg
]# git cat-file blob 96b5
This is file b
second line
btext の blob は最後のコミットの前に異なるハッシュを持っていますが、他のものは同じです。
概要は次のようになります:
]# git log
commit fad04538f7f8ddae1f630b648d1fe85c1fafa1b4 (HEAD -> master)
Author: Your Name <[email protected]>
Date: Sun Feb 16 10:51:51 2020 +0000
btext: more
commit 0bfc1837e20988f1b80f8b7070c5cdd2de346dc7
Author: Your Name <[email protected]>
Date: Sun Feb 16 08:45:16 2020 +0000
added 3 files with 'add .'
手動でタイムスタンプが付けられた tar ファイルの代わりに、メッセージと日付 (および作成者) を含むコミットがあります。これらのコミットには、ファイル リストとコンテンツが論理的に関連付けられています。
シンプル git tar より 20% 複雑です 、しかし、決定的な 50% 以上の機能が得られます。
私は OP の 3 番目の変更を行いたかった:ファイルと 2 つの新しい「画像」ファイルを変更します。私はそうしましたが、今は:
]# git log
commit deca7be7de8571a222d9fb9c0d1287e1d4d3160c (HEAD -> master)
Author: Your Name <[email protected]>
Date: Sun Feb 16 17:56:18 2020 +0000
didn't add the pics before :(
commit b0355a07476c8d8103ce937ddc372575f0fb8ebf
Author: Your Name <[email protected]>
Date: Sun Feb 16 17:54:03 2020 +0000
Two new picture files
Had to change btext...
commit fad04538f7f8ddae1f630b648d1fe85c1fafa1b4
Author: Your Name <[email protected]>
Date: Sun Feb 16 10:51:51 2020 +0000
btext: more
commit 0bfc1837e20988f1b80f8b7070c5cdd2de346dc7
Author: Your Name <[email protected]>
Date: Sun Feb 16 08:45:16 2020 +0000
added 3 files with 'add .'
]#
では、午後 6 時少し前に、Your Name Guy は 2 つのコミットで正確に何をしたのでしょうか?
最後のコミットの詳細は次のとおりです:
]# git show
commit deca7be7de8571a222d9fb9c0d1287e1d4d3160c (HEAD -> master)
Author: Your Name <[email protected]>
Date: Sun Feb 16 17:56:18 2020 +0000
didn't add the pics before :(
diff --git a/picture2 b/picture2
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/picture2
@@ -0,0 +1 @@
+1
diff --git a/picture3 b/picture3
new file mode 100644
index 0000000..0cfbf08
--- /dev/null
+++ b/picture3
@@ -0,0 +1 @@
+2
]#
最後から 2 番目のコミットを確認するには、メッセージが 2 つの画像を通知します:
]# git show @^
commit b0355a07476c8d8103ce937ddc372575f0fb8ebf
Author: Your Name <[email protected]>
Date: Sun Feb 16 17:54:03 2020 +0000
Two new picture files
Had to change btext...
diff --git a/btext b/btext
index a4a6c5b..de7291e 100644
--- a/btext
+++ b/btext
@@ -1,3 +1 @@
-This is file b
-second line
-more
+Completely changed file b
]#
これは、git commit -a を試したために発生しました git add . をショートカットするには 、そして 2 つのファイルは新しいものでした （追跡されていません）。 git status で赤く表示されました ですが、私が言うように、git は tar や unix よりもトリッキーです。
「あなたのデビュタントはあなたが何を必要としているのかを知っていますが、私はあなたが何を望んでいるのかを知っています」(またはその逆。ポイントは常に同じではないということです)