増分バックアップ用のLinuxバックアップユーティリティ
増分バックアップを備えたバックアップユーティリティを探していますが、もっと複雑な方法をとっています。
私はrsyncを試しましたが、それは私が望むことを行うことができないようです、あるいは、それを行う方法を知りません。
これは私がそれで達成したいことの例です。次のファイルがあります。
testdir
├── picture1
├── randomfile1
├── randomfile2
└── textfile1
バックアップユーティリティを実行して、基本的にこれらのファイルすべてのアーカイブ（またはtarball）を別のディレクトリに作成します。
$ mystery-command testdir/ testbak
testbak
└── 2020-02-16--05-10-45--testdir.tar
さて、翌日、ファイルが追加され、構造が次のようになるとします。
testdir
├── picture1
├── randomfile1
├── randomfile2
├── randomfile3
└── textfile1
次に、mysteryコマンドを実行すると、その日の別のtarballが取得されます。
$ mystery-command testdir/ testbak
testbak
├── 2020-02-16--05-10-45--testdir.tar
└── 2020-02-17--03-24-16--testdir.tar
これがキッカーです。バックアップユーティリティがpicture1、randomfile1、randomfile2およびtextfile1は前回のバックアップ以降変更されておらず、新規/変更されたファイルのみをバックアップします。この場合はrandomfile3、 そのような：
tester@raspberrypi:~ $ tar -tf testbak/2020-02-16--05-10-45--testdir.tar
testdir/
testdir/randomfile1
testdir/textfile1
testdir/randomfile2
testdir/picture1
tester@raspberrypi:~ $ tar -tf testbak/2020-02-17--03-24-16--testdir.tar
testdir/randomfile3
最後の例として、次の日に私がtextfile1、追加されたpicture2およびpicture3：
$ mystery-command testdir/ testbak
testbak/
├── 2020-02-16--05-10-45--testdir.tar
├── 2020-02-17--03-24-16--testdir.tar
└── 2020-02-18--01-54-41--testdir.tar
tester@raspberrypi:~ $ tar -tf testbak/2020-02-16--05-10-45--testdir.tar
testdir/
testdir/randomfile1
testdir/textfile1
testdir/randomfile2
testdir/picture1
tester@raspberrypi:~ $ tar -tf testbak/2020-02-17--03-24-16--testdir.tar
testdir/randomfile3
tester@raspberrypi:~ $ tar -tf testbak/2020-02-18--01-54-41--testdir.tar
testdir/textfile1
testdir/picture2
testdir/picture3
このシステムでは、各バックアップ間の増分変更のみをバックアップすることでスペースを節約し（明らかにすべての初期ファイルを含むマスターバックアップを使用）、増分変更のバックアップを作成します。たとえば、 2日目に、同じことを3日目に再度変更しましたが、2日目からの変更を含むファイルを取得できますが、3日目からの変更前です。
GitHubの動作方法のようなものだと思います:)
おそらく、diffを実行し、その結果に基づいてバックアップするファイルを選択するスクリプトを作成することもできます（より効率的には、チェックサムを取得して比較するだけです）。ただし、これを実行できるユーティリティがあるかどうかを知りたいです。少し簡単:)
更新：
ここでいくつかの警告を参照してください： システムの完全バックアップにtarを使用することは可能ですか？
その回答によると、tarを使用した増分バックアップの復元はエラーが発生しやすく、回避する必要があります。必要なときにデータを回復できることが確実でない限り、以下の方法を使用しないでください。
ドキュメントによると、-g /-listed-incrementalオプションを使用して増分tarファイルを作成できます。
tar -cg data.inc -f DATE-data.tar /path/to/data
次に、次のようなことをします
tar -cg data.inc -f NEWDATE-data.tar /path/to/data
ここで、data.incは増分メタデータであり、DATE-data.tarは増分アーカイブです。
tarにはインクリメンタルモードがありますが、この作業を行うためのより包括的なツールがいくつかあります。
増分バックアップをサポートするだけでなく、完全バックアップを実行する必要があるスケジュールを簡単に構成できます。たとえば、duplicityの場合：duplicity --full-if-older-than 1Mは、完全バックアップが実行されたことを確認します。また、特定のファイルにさかのぼって遡ることもできます。プレーンtarでは、適切なファイルを含むファイルが見つかるまで、すべての増分ファイルを調べる必要があります。
さらに、暗号化とさまざまなバックエンド（sftp、blobストレージなど）へのアップロードをサポートしています。暗号化する場合は、キーの適切なバックアップを二次バックアップに作成することを忘れないでください！
もう1つの重要な側面は、バックアップの整合性を検証して、たとえばduplicity verifyを使用して確実に復元できることです。
私はgitベースのバックアップ戦略について否定的なアドバイスをします。大規模な復元にはかなりの時間がかかります。
私はrsyncを試しましたが、それは私が望むことを行うことができないようです、あるいは、それを行う方法を知りません。
おそらく、diffを実行し、その結果に基づいてバックアップするファイルを選択するスクリプトを作成することもできます（より効率的には、チェックサムを取得して比較するだけです）。ただし、これを実行できるユーティリティがあるかどうかを知りたいです。少し簡単:)
rsyncは、差分に基づいてコピーするプログラムです。デフォルトでは、最終変更時刻またはサイズに違いがある場合のみコピーしますが、チェックサムで-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"
簡単にgrepableファイルを使用して変更の記録を保持します。 |&は、stdoutとstderrの両方をパイプ処理するためのものです。
-Pは--partialおよび--progressの略です。 --partialは部分的に転送されたファイルを保持しますが、さらに重要なのは--progressがファイルごとの進行状況を報告することです。
これとtarによる変更のアーカイブとの比較
上記のソリューションでは、すべてを保持しているように見えるディレクトリが作成されます。たとえそうであっても、バックアップの量/頻度を合計すると、変更のみの単純なtarアーカイブとほぼ同じ量のスペースが占有されます。これは、ハードリンク、reflink、およびスナップショットがどのように機能するかによるものです。バックアップを作成する際の帯域幅の使用も同じです。
利点は次のとおりです。
- rsyncはバックアップからの差分のみを転送するため、バックアップはrsyncを使用して簡単に復元でき、高速です。
- 必要に応じて、閲覧および変更する方が簡単です。
- ファイルの削除は、新しいバックアップにファイルが存在しないため、自然にエンコードできます。 tarアーカイブを使用する場合、
fooファイルを削除したり、foo.DELETEDをマークしたり、複雑なことをしたりするなど、ハッキングに頼らなければなりません。たとえば、重複を使用したことはありませんが、そのドキュメントを見ると、同じ名前の空のファイルを新しいtarに追加し、ファイルの元の署名を別の.sigtarファイルに保持することで、削除をエンコードしているようです。ファイルの削除と実際の空のファイルへの変更を区別するために、元の署名と空のファイルの署名を比較すると思います。
それでも、各バックアップを異なる（追加または変更された）ファイルのみを保持するように設定したい場合は、上記の--link-destソリューションを使用し、次のようなものを使用してハードリンクを削除できます。
find $new_backup -type f ! -links 1 -delete
[1]厳密に言えば、ファイル名など、メタデータの重複という形で追加のスペースを使用します。しかし、私はだれでもそれを取るに足りないと考えているでしょう。
そして、なぜgit自体を考慮しないのですか？
1つの完全バックアップと2つの増分バックアップを行った後の戦略では、続行すると複雑になります。間違いを犯しやすく、変更によっては can が非常に非効率になります。ある種のローテーションが必要になる場合があります。つまり、時々、新しい完全バックアップを作成し、次に古いものを保持しますか？
working dir "testdir"に project （ファイルとサブディレクトリ）が含まれていると、gitはデフォルトで非表示になりますデータの.gitサブディレクトリ。これは、ローカルの追加のバージョン管理機能用です。バックアップの場合は、メディアにアーカイブ/コピーするか、ネットワーク経由で複製できます。
あなたが得る revision control （尋ねることなく）はgitの差分ストレージの副作用です。
すべての分岐/分岐などを省略することができます。これは、「マスター」というブランチが1つあることを意味します。
コミット（実際にはgit archive/repoに書き込む）する前に、構成ファイルの最小ユーザーを構成する必要があります。次に、最初にサブディレクトリ（おそらくtmpfs）で学習してテストする必要があります。 Gitはtarと同じくらい扱いにくい場合があります。
とにかく、コメントが言うように：バックアップは簡単です、難しい部分は復元です。
Gitの短所は、わずかなオーバーヘッド/過剰です。
利点は次のとおりです：git tracks コンテンツとファイル名。差分に基づいて、必要なものだけを保存します（少なくともテキストファイルの場合）。
例
ディレクトリに3つのファイルがあります。 git init、git add .、git commitの後、260Kの.gitディレクトリがあります。
次に、cp -r .git /tmp/abpic.git（バックアップを保存するのに適した場所です）。 154K jpgをrmし、さらに change 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が not に更新されました（タイムスタンプを保持）。 atextの変更は上書きされます。
Repoと（working）dirを再結合するには、コピーして戻します。
]# 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は最後のコミットの前に異なるハッシュを持ち、他の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 .'
]#
では、Your Name Guyが午後2時の直前の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つのファイルが new （追跡されていない）だったために発生しました。それはgit statusで赤く表示されましたが、私が言うようにgitはtarまたはunixよりもトリッキーではありません。
「あなたのデビュタントはあなたが何を必要としているのかを知っていますが、私はあなたが何を望んでいるのかを知っています」（またはその逆。ポイントは常に同じではない）
starはインクリメンタルダンプおよびリストアを確実にサポートすることが確認されているため、インクリメンタルバックアップにはstarをお勧めします。後者は、28年以来宣伝されているにもかかわらず、ディレクトリの名前を変更するときにGNU tarでは機能しません。
http://schilytools.sourceforge.net/man/man1/star.1.html のstar manページをお読みください
増分バックアップに関するセクションは、現在53ページから始まっています。
ソースをダウンロードするには、 http://sourceforge.net/projects/schilytools/files/ からschilytools tarballを取得します。
GNU tarバグの検証については、 フルシステムバックアップにtarを使用することは可能ですか？ を確認してください。
Borg Backup をご覧になることをお勧めします。
これにより、次のバックアップが処理されます。
重複排除されます。これは間接的に差分バックアップになりますが、より多くの利点があります。
- 同じファイルの複数のコピーを処理します
- または、異なるファイル内の同じブロックでも
- （ログのように）増大するファイルに役立ちます
- 名前が変更されたファイルを支援します（一部のローテーション設定のログなど）
圧縮されている
- 通常のリモートファイルシステムのようにマウントできます（以前のバックアップをマウントできます）
「1週間は毎日1つのバックアップ、1か月は1週間のバックアップ、1年は1か月のバックアップ」などのルールを使用して、古いバックアップのプルーニングを管理します。
セットアップと使用は本当に簡単です。
BackupPC を試すことができます。
これにより、増分バックアップが可能になり、それらを実行する頻度、保持する数を決定でき、それらを見ると、それらが統合されているか、実際の増分バックアップのみであるかを確認できます。同じホストまたは異なるホストの異なるバックアップに存在する場合、完全なファイルも重複排除します。
ほとんどの場合、ディストリビューション用にすでにパッケージ化されています。
restic を見てください。重複排除と呼ばれるアルゴリズムを使用して、増分バックアップを実行します。また、非常に使いやすいので、初心者または上級のコマンドラインユーザーに最適です。
これはtarを使用しないため、正確に要求しているものではありません。しかし、それはrsyncを使用し、私にとっては非常にうまく機能しています。私が本当に気に入っている機能の1つは、削除するポイントの前後にポイントを失うことなく、時間の経過とともに増分復元ポイントを削除する機能です。これにより、たとえば、過去2週間の毎日のバックアップを作成し、2週間経過したらそれらを間引きして、2か月間は毎週、さらに四半期または2か月間毎月までさらに間引きすることができます。その後、数年の期間にわたってそれらを約四半期ごとに減らします。私はpythonスクリプトを共有できますが、必要に応じてこれらを自動的にプルーニングできます（明らかに、コンピュータにバックアップを自動的に削除させると少し怖いので、保証はありません）。
私がしていることは、バックアップを保存するためにZFSプールとファイルシステムを使用することです。 （ありがたいことに！）Linuxで使用できるようになったZFSファイルシステムを使用して、スナップショットを作成できます。スナップショットされたファイルシステムに書き込むと、変更されたブロックのみの新しいバージョンが（スマートに）書き込まれるため、増分バックアップが作成されます。さらに簡単なのは、すべてのスナップショットを完全な（読み取り専用）Unixファイルシステムとしてマウントできるため、通常のすべてのツールを使用して、そこから調べたりコピーしたりできることです。そのファイルが2か月前にどのように見えるかを確認したいですか？適切なフォルダーにcdし、lessまたはvimなどを使用してそれを確認します。 （ハッキングされた）wordpressインストールしたバックアップがレールから外れたときを確認したいですか？grep -in /zfsbackup/computername/.zfs/snapshots/*/var/www/html/wp-config.php" "somebadstring"のようなもので識別マークのgrepを実行してください
LinuxのLUKSシステムを使用してディスクの暗号化を行い、マップされたデバイスを「ドライブ」としてZFSに提示して、暗号化されたバックアップを提供することもできます。
バックアップを新しいドライブに移行する必要がある場合は、zfs send＆receiveを使用してファイルシステム全体を移動できます。
セットアップしてから1年または2年になります（増分バックアップを追加し続けるだけで、しばらくの間バックアップドライブをアップグレードする必要はありません）。私と一緒に、あるいはもっと良いことに、それらを編集してください。
最初に、zfs、rsync、およびバックアップを暗号化する場合はLUKSツールがインストールされていることを確認します。
まず、バックアップドライブに必要なパーティションレイアウトを作成します。 （バックアップを実行するためのスクリプトを含む、暗号化されていない小さなパーティションを作成することもできます。）
次に、ディスクの暗号化が必要な場合は、LUKSを使用してパーティションを暗号化します（/ dev/sde1はおそらくスクリプトなので、例では/ dev/sdeのバックアップドライブとパーティション/ dev/sde2を想定しています）。
Sudo cryptsetup luksFormat /dev/sde2
（ニースの強力なパスフレーズを入力してください）。
ディスクの暗号化を行っている場合は、ボリュームを開く必要があります。
Sudo cryptsetup luksOpen /dev/sde2 zfsbackuppart1
（これで、暗号化されていないバージョンのrawデバイスが/ dev/mapper/zfsbackuppart1で利用可能（マップ済み）になっているはずです）。
次に、ZFSプールを作成します（データを保持するドライブのグループ。必要に応じて、複数のドライブ/デバイスをRAIDに使用できます）。
Sudo zpool create zfsbackup /dev/mapper/zfsbackuppart1
これにより、「zfsbackup」という名前のZFSプールが作成されます。
次に、バックアップするマシンごとにファイルシステムを作成します。
Sudo zfs create zfsbackup/machinename
そして、ソースマシンからバックアップするパーティションごとにフォルダを作成します。
Sudo mkdir /zfsbackup/machinename/slash/
Sudo mkdir /zfsbackup/machinename/boot/
次に、rsyncを使用してファイルをそこにコピーします。
Sudo rsync -avx --numeric-ids --exclude .gvfs / /zfsbackup/machinename/slash/ --delete-after
Sudo rsync -avx --numeric-ids --exclude .gvfs /boot/ /zfsbackup/machinename/boot/ --delete-after
スナップショットを撮ります：
zfs snapshot zfsbackup/machinename@`date +%F_%T`
完了したらドライブを切断するには：
zpool export zfsbackup
# Next line, for each underlying encrypted block device, if using encryption:
cryptsetup luksClose zfsbackuppart1
上記のrsyncコマンドの前に、将来別のバックアップを取るときに設定するには：
cryptsetup luksOpen /dev/sde2 zfsbackuppart1
zpool import zfsbackup
このアプローチに関する詳細情報が必要な場合、またはバックアップが以前に戻ったときにバックアップを間引くスクリプトに興味がある場合は、お知らせください。
そして、はい、この方法でシステム全体をバックアップできます-パーティション/ファイルシステムを作成する必要があります（元のレイアウトに合わせる必要はありません-ものを移行するための素晴らしい方法です！）、/ etc/fstabを微調整します。 GRUB＆install GRUB config。
1つの可能性は AMANDA、高度なメリーランド自動ネットワークディスクアーカイバ です。これは、他の機能の負荷の中で、増分バックアップもサポートします。
非常に古いBSD rdumpコマンドは、バックアップレベルを実行します。レベル0はファイルシステム全体をサポートします。レベル1は、ゼロレベル以降に変更されたものをバックアップし、レベル2は、レベル1以降のすべてのバックアップを行います。 Rdumpには、テープに書き込むという不幸があります...
次のシェルスクリプトは、tar、find、egrepを使用して必要な処理を実行します。これは、findの-newerフラグを使用して、「newer」とスクリプトが最後に実行されたときに作成された「touch」を比較します。スクリプトは、1990年代からSolaris 4.3bsdで最後に実行され、Kermitを使用してUNIX開発マシンとラップトップ間でソースファイルをコピーしました。
スクリプトが更新時間ファイルに「触れる」と、tarが失敗した場合、時間ファイルを再作成する必要があるため、スクリプトはかなり脆弱です。 tarファイルには、日付+時間+分+秒の名前が付いています。 `＃！/ bin/sh -vx
echo finding newer files than update ...
cd /home/programs/gis
HOME_LOC=/home/programs/gis/
TAR_FILE=${HOME_LOC}stage/u`date +%m%d%H%M`.tar.bz2
#run find one using the -o (or) syntax
(
find . -newer ${HOME_LOC}/update \
\( -name '*.[hcsf]' -o -name '*.asm' \
-o -name '*.ma*' -o -name '*.cpp' \
-o -name '*.msg' -o -name '*.hpp' \
-o -name 'Makefile' -o -name '*.inl' \
-o -name 'grid*.*' -o -name '*.glb' \) \
-print ) | \
egrep -v 'SCCS|stage|local.h' | tee /usr/tmp/x.$$
echo copying files:
tar -cjhf ${TAR_FILE} `cat /usr/tmp/x.$$`
# rm /usr/tmp/x.$$
if test -r ${TAR_FILE}
then
touch ${HOME_LOC}/update
fi
`
bup の使用を検討してください：
- 完全/増分/減分バックアップの区別について心配する必要はありません。
- バックアップは増分バックアップと同じくらい高速です
- 復元は完全バックアップと同じくらい簡単です
- git のストレージ形式に基づいて、非常に大きなバックアップをサポートするように拡張
- ファイル（およびファイルの一部）、バージョン、およびブランチにわたる完全な重複排除。これは、複数のマシンまたは複数のVMスナップショットをバックアップする必要がある場合に特に役立ちます。
- par2 を使用して、アーカイブにエラー修正コードを追加できます
- ダイレクトコマンドまたはFuseファイルシステムとしてツリーをマウントすることにより、バックアップツリー全体に簡単にアクセス
これまでに見つけた警告：
- まだ若くてアルファ段階（現在のバージョンは0.x）
- Python 2が必要なので、依存関係の点で正確ではありません
bupは、アーカイブフォルダーでファイルロックを使用します。これは、アーカイブをホストするファイルシステムがファイルロックをサポートする必要があることを意味します。これは、SMBシェアの問題です（ただし、NFSは機能します）。- リモートホストとの間のバックアップ（
sshを使用）には、bupをインストールする必要があります。 - バックアップ名（Gitブランチ）には、スラッシュ（
/）を含むものを使用したくなるかもしれません。それはgitの問題ではありませんが、bup lsはそれらによって混乱するので、それを行わないでください。 （それに噛まれたら、適切なgit branch -mコマンドでブランチ名を変更できます。）
上記のすべての優れたソリューションに加えて、もう1つのアプローチがあります。使用しているファイルシステムについて言及していないので、zfsやbtrfsを使用していないことを想定しています。これらのファイルシステムには、ファイルシステム全体のコピーではなく、単なる増分であるスナップショットを実行するための組み込み機能があります。典型的なアプローチはこれです：
- Zfs/btrfsファイルシステムを作成します。
- このファイルシステムですべてのデータ（追跡する必要がある）を見つけます。
- スナップショットを設定する
- スナップショットの保持/ローテーションを設定します（それ以外の場合、スナップショットは増加し続け、ディスク領域を占有します）。
たとえば、5日間の保持を設定した場合、最大5日間前の時刻に戻ることができます。
差分バックアップを実行しようとしているようです。これには過去に7Zipを使用しました（圧縮と暗号化も必要だったため）。 これ のように、利用可能な多くのチュートリアルがあります。
「マイクの便利な回転ファイルシステムスナップショットユーティリティ」を探してください。これは基本的に、ディレクトリの循環増分バックアップを作成するための rsync をラップする便利なスクリプトです。変更されなかったすべてのファイルの以前の増分バックアップにリンクすることにより、メモリ使用量を最小限に抑えます。
完全な概要とその機能の説明については、 LinuxおよびRsyncを使用した簡単な自動スナップショットスタイルのバックアップ を参照してください。