増分バックアップ用のLinuxバックアップユーティリティ

Question 1

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"

または、参照リンクをサポートするファイルシステムを使用している場合でも、これを行うことができます。参照リンクは新しいinodeを生成しますが、ソースファイルと同じブロックを参照してCOWサポートを有効にすることによって実行されます。データの読み書きは行われず、余分なスペースも必要ないため、通常のコピーよりも高速です[1]。

cp --reflink -av \
  "$dst/2020-02-16--05-10-45--testdir" \
  "$dst/2020-02-17--03-24-16--testdir"

とにかく、そのようなことをした後は、通常のrsyncコピーdiffを実行できます。

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をパイプすることです。

はandの略です-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]厳密に言えば、ファイル名などの重複メタデータの形で追加のスペースを使用します。しかし、誰でもこれを些細なものと考えると思います。

Answer

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"

または、参照リンクをサポートするファイルシステムを使用している場合でも、これを行うことができます。参照リンクは新しいinodeを生成しますが、ソースファイルと同じブロックを参照してCOWサポートを有効にすることによって実行されます。データの読み書きは行われず、余分なスペースも必要ないため、通常のコピーよりも高速です[1]。

cp --reflink -av \
  "$dst/2020-02-16--05-10-45--testdir" \
  "$dst/2020-02-17--03-24-16--testdir"

とにかく、そのようなことをした後は、通常のrsyncコピーdiffを実行できます。

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をパイプすることです。

はandの略です-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]厳密に言えば、ファイル名などの重複メタデータの形で追加のスペースを使用します。しかし、誰でもこれを些細なものと考えると思います。

Question 2

増分モードがありますが、tar操作を実行できるより包括的なツールがあります。

増分バックアップをサポートするだけでなく、完全バックアップが必要なスケジュールを簡単に構成できます。たとえば、duplicity：duplicity --full-if-older-than 1Mはフルバックアップが実行されていることを確認します。また、特定のファイルに時間をさかのぼる機能もサポートしています。通常のtarでは、正しいファイルを含むファイルが見つかるまで、すべてのデルタファイルを繰り返す必要があります。

また、さまざまなバックエンド（SFTP、BLOBリポジトリなど）の暗号化とアップロードもサポートしています。明らかに暗号化している場合は、キーをセカンダリバックアップにバックアップすることを忘れないでください。

もう1つの重要な側面は、たとえばを使用してバックアップの整合性を確認して復元できることですduplicity verify。

私はGitベースのバックアップ戦略について否定的なアドバイスをしたいと思います。大規模な復元には時間がかかります。

Answer

増分モードがありますが、tar操作を実行できるより包括的なツールがあります。

増分バックアップをサポートするだけでなく、完全バックアップが必要なスケジュールを簡単に構成できます。たとえば、duplicity：duplicity --full-if-older-than 1Mはフルバックアップが実行されていることを確認します。また、特定のファイルに時間をさかのぼる機能もサポートしています。通常のtarでは、正しいファイルを含むファイルが見つかるまで、すべてのデルタファイルを繰り返す必要があります。

また、さまざまなバックエンド（SFTP、BLOBリポジトリなど）の暗号化とアップロードもサポートしています。明らかに暗号化している場合は、キーをセカンダリバックアップにバックアップすることを忘れないでください。

もう1つの重要な側面は、たとえばを使用してバックアップの整合性を確認して復元できることですduplicity verify。

私はGitベースのバックアップ戦略について否定的なアドバイスをしたいと思います。大規模な復元には時間がかかります。

Question 3

そしてなぜあなた自身について考えないのですかgit？

1回のフルバックアップと2回の増分バックアップの後に説明する戦略は、進むにつれて複雑になります。間違えやすく、できる変化に応じて、効率は非常に非効率的になる可能性があります。時々、新しいフルバックアップを実行する循環が必要です。その後、以前のバックアップを維持しますか？

与えられた布材"testdir"ディレクトリには、次の内容が含まれています。プロジェクト（ファイルとサブディレクトリ） - デフォルトでは、gitデータ.gitの隠しサブディレクトリを作成します。これはローカルであり、追加です。バージョン管理特徴。バックアップの場合は、メディアにアーカイブ/コピーしたり、ネットワーク経由で複製したりできます。

これ改訂管理要求せずに得ることはgit diffリポジトリの副作用です。

すべての分岐/分岐などを省略できます。これは、「マスター」というブランチがあることを意味します。

コミットする前に（実際にgitアーカイブ/ストアに書き込む）前に、プロファイルの最小ユーザーを設定する必要があります。その後、まずサブディレクトリ（おそらくtmpfs）で研究してテストする必要があります。時々、Gitはtarほどトリッキーかもしれません。

とにかく、コメントでわかるように、バックアップは簡単で、難しい部分は復元です。

gitの欠点は、オーバーヘッドがほとんどなく、ダメージが多すぎるということです。

利点は次のとおりです。レパートリー内容とファイル名。違いによって必要なものだけを保存します（少なくともテキストファイルの場合）。

はい

私のディレクトリには3つのファイルがあります。その後、git init260Kディレクトリがgit add .あります。git commit.git

それから私はcp -r .git /tmp/abpic.git（バックアップを保存するのに最適な場所です：）。私のものはrm154K jpgです。変化テキストファイル。私も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

コミットで時間を元に戻すには：

]# 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ファイルを手動で追加するのではなく、メッセージと日付（および作成者）を使用してコミットします。これらのコミットには、ファイルのリストとコンテンツが論理的に添付されます。

SimpleはgitSimpleより20％複雑tarですが、決定的に50％多くの機能を得ることができます。

OPの3番目の変更を作成したいと思います。 1つのファイルと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時の直前に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ショートカットしようとしましたが、2つのgit add .ファイルが新しい（追跡されていません）赤で表示されていますが、git status前述したように、gitはtarやunixよりもトリッキーではありません。

「あなたのデビュー作はあなたに必要なものだけを知っていますが、私はあなたが望むものを知っています」（またはその逆です。ポイントは常に同じではないということです）

Answer

そしてなぜあなた自身について考えないのですかgit？

1回のフルバックアップと2回の増分バックアップの後に説明する戦略は、進むにつれて複雑になります。間違えやすく、できる変化に応じて、効率は非常に非効率的になる可能性があります。時々、新しいフルバックアップを実行する循環が必要です。その後、以前のバックアップを維持しますか？

与えられた布材"testdir"ディレクトリには、次の内容が含まれています。プロジェクト（ファイルとサブディレクトリ） - デフォルトでは、gitデータ.gitの隠しサブディレクトリを作成します。これはローカルであり、追加です。バージョン管理特徴。バックアップの場合は、メディアにアーカイブ/コピーしたり、ネットワーク経由で複製したりできます。

これ改訂管理要求せずに得ることはgit diffリポジトリの副作用です。

すべての分岐/分岐などを省略できます。これは、「マスター」というブランチがあることを意味します。

コミットする前に（実際にgitアーカイブ/ストアに書き込む）前に、プロファイルの最小ユーザーを設定する必要があります。その後、まずサブディレクトリ（おそらくtmpfs）で研究してテストする必要があります。時々、Gitはtarほどトリッキーかもしれません。

とにかく、コメントでわかるように、バックアップは簡単で、難しい部分は復元です。

gitの欠点は、オーバーヘッドがほとんどなく、ダメージが多すぎるということです。

利点は次のとおりです。レパートリー内容とファイル名。違いによって必要なものだけを保存します（少なくともテキストファイルの場合）。

はい

私のディレクトリには3つのファイルがあります。その後、git init260Kディレクトリがgit add .あります。git commit.git

それから私はcp -r .git /tmp/abpic.git（バックアップを保存するのに最適な場所です：）。私のものはrm154K jpgです。変化テキストファイル。私も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

コミットで時間を元に戻すには：

]# 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ファイルを手動で追加するのではなく、メッセージと日付（および作成者）を使用してコミットします。これらのコミットには、ファイルのリストとコンテンツが論理的に添付されます。

SimpleはgitSimpleより20％複雑tarですが、決定的に50％多くの機能を得ることができます。

OPの3番目の変更を作成したいと思います。 1つのファイルと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時の直前に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ショートカットしようとしましたが、2つのgit add .ファイルが新しい（追跡されていません）赤で表示されていますが、git status前述したように、gitはtarやunixよりもトリッキーではありません。

「あなたのデビュー作はあなたに必要なものだけを知っていますが、私はあなたが望むものを知っています」（またはその逆です。ポイントは常に同じではないということです）

Question 4

修正する:

ここでいくつかの考慮事項を参照してください。システム全体のバックアップに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はデルタアーカイブです。

Answer

修正する:

ここでいくつかの考慮事項を参照してください。システム全体のバックアップに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はデルタアーカイブです。

増分バックアップ用のLinuxバックアップユーティリティ

答え1

tarを使用して変更をアーカイブするのとどのように比較されますか？

答え2

答え3

はい

答え4

関連情報