この問題を報告していただきありがとうございます。これはバグだと思います。

おそらく、トップレベルのディレクトリが同じ名前である場合はいつでも発生します。 フルパスは復元されないため、最上位ディレクトリのみが復元されます。

解決策は、復元時にフルパスを再構築し、各ツリーをフルパスに復元することです。 したがって、結果のパスは/tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/ようになります。 許容できると思います。

パッチは復元の一部として実装する必要がありますか？
または、フルパスコンポーネントを含む別のトップレベルツリーを構築することにより、バックアップ中に実行する必要があるのでしょうか。

私もこれが事実だと思います。 現時点では、resticは次のように機能します。

restic backup A/foo B/fooとして呼び出されると、次のようなツリー構造がリポジトリに作成されます。

├── foo
└── foo

したがって、引数からbackupコマンドへの最後のパスコンポーネントのみが取得されます。これにより、このようなスナップショットを復元するときに問題が発生します。

これを修正するために、 tarと同じ動作を実装することを提案します。この場合、次のツリーが作成されます。

.
├── A
│   └── foo
└── B
    └── foo

これには、resticのアーカイバ部分での作業が必要になります。 復元に触れる必要はまったくないと思います。

588同じことを報告しました。 しかし、それはあなたが使用できるテストケースを持っています。

@ fd0バックアップターゲットの完全な「実際の」パスを明示的に格納するバックアップオプション（--store-full-path）も含めることを提案します。

その理由は、tarの場合、および他のいくつかのバックアップツールを使用すると、少し複雑な復元ツリーを取得できるためです。 これは適切なデフォルトですが、復元がホストバックアップ用の元のファイルシステムのレイアウト全体に似ている場合は、個人的に希望します。 （復元によってホスト名を復元場所の前に付けることもできればさらに良いです）

@trbsデフォルトでは、相対パスを使用する特別な場合のスイッチを使用して、フルパスを格納する必要があると思います。 relパスは予期しない動作や未定義の動作を生成する可能性がありますが、absは生成できないという理由です。 プレフィックスやその他の形式のパスマングリングを要求する場合は、まったく別の問題であることをお勧めします。

私はこれについて考えましたが、常にフルパス（コマンドラインで指定）が保存されるように、バックアップの動作を変更する必要があると思います。 それがtar機能であり、非常にうまく機能します。 残念ながら、これは、resticの開発の初期段階での悪い設計決定の遺物です。

--store-full-path +1

+1は嫌いですが、このバグの解決策にも非常に興味があります。 このバグが残念ながら目を見張るような、resticの保留中のインストールがいくつかあります。

これに取り組んでくれた@ fd0に感謝します、私は今リラックスするのは簡単ではないことを理解しています。

--store-full-path場合--strip-components <N>を使用してパーツを取り除くことを望んでいます。 これは、完全なデータが常にバックアップで利用可能であることを意味し、ユーザーが復元時にパスからあまりにも多くのコンポーネントを削除してサブディレクトリを組み合わせると、回復可能なユーザーエラーになります。

ホスト名をバックアップ場所の前に付けることに関しては、ほとんどの人が事前にどのホストから復元するかを知っているので、これはコマンドラインから簡単に実行できるようです:)

あなたがまだ1.0になっていないことを考えると、理想的な修正のために重大な変更を加える必要がある場合は、先に進んで、後でではなく早く行うことを投票します。

@mholt同意します、私はすでにこれに取り組んでいます。 私が言ったように、これは早い段階での悪い設計決定によって引き起こされ、修正する必要があります。

ちょっと@ fd0-ちょうど0.7がリリースされたのを見た。 これ（および＃910と＃909）は0.7.1のマップにありますか？

たぶん0.7.1ではなく、0.8.0かそこらです。 私はすでにそれに取り組んでいます。 少し背景があるかもしれません：これは、resticに存在する最も古いコードであるアーカイバコードが原因です。 残念ながら（私は2013/2014年にGo backを学び始めたばかりだったので）、アーカイバコードは非常に複雑で、多くの初心者のミスを犯しました（並行性が多すぎ、チャネルが多すぎます）。 また、まったく問題にならないことが心配で、問題になったもの（インデックスの取り扱いなど）を見落としていました。

そのため、アーカイバコードを完全に再実装し始めました。並行性を使用するのは、意味がある場合（つまり、個々のチャンクを処理する場合）のみで、ディスクから20個のファイルを並行して読み取ることはありません。 このコードには適切なディレクトリウォーキングも含まれており、完全なパスをリポジトリに挿入します。

幸いなことに、これは実際に触れる必要のあるアーカイバにすぎません。残りのコードは（resticとリポジトリの設計のおかげで）引き続き正常に機能します。

この変更は既存のリポジトリに影響しますか？もしそうなら、どのように影響しますか？

「新しいバックアップの構造は少し異なります」という点で「影響」はありますが、それだけです。 migrateなどは必要ありません。

そのため、＃1209がマージされ、名前の競合を検出して（名前を変更して）解決することで状況が改善されましたが、この問題はまだ完全には解決されていません。 私はそれに取り組んでいます:)

@ fd0完全な元のパスを含むスナップショットがいつ期待されるか考えてみてください。 現在、resticを使用したバックアップと復元の自動化に取り組んでいます。

復元を自動化する場合、ソースパスをそのままにしておくことが不可欠です。

2つの「データ」ディレクトリがバックアップされているサーバーがある場合（これは理論的ではありませんが、バックアップが必要なConfluenceおよびJIRA「データ」ディレクトリを持つサーバーがいくつかあります）-復元プロセスはどちらを知る必要がありますデータディレクトリはConfluenceに属し、どのデータディレクトリがJIRAに属します。 'data'や 'data-1'のような名前は、明らかにここではカットされません。

今のところ最善の回避策は、データディレクトリを個別のスナップショットでバックアップし、それらに「JIRA」または「Confluence」のタグを付けることだと思いますか？

タイムラインはありません、ごめんなさい。

今のところ最善の回避策は、データディレクトリを個別のスナップショットでバックアップし、それらに「JIRA」または「Confluence」のタグを付けることだと思いますか？

はい。ただし、＃1225により、後でそれらを1つのリポジトリに簡単にマージすることはできません。

オプション--store-full-path ： rsyncはこのオプションがあります： -R 、 --relative 。
たぶん、resticに同じオプション名を使用しますか？

フルシステムバックアップについては、ここで回避策を説明しました： https ：

このバグは私を少し心配させました、しかし私は提供されたステップで0.8.3でそれを再現することができません。 これはまだ未解決の問題ですか？

はい、残念ながらこれはまだ問題です。

うーん、どういうわけか問題を再現できないので、何をしているのかわかりません。 テストスクリプトを添付しました。

test_restic_549.zip

あなたはそれをこのように再現することができます：

$ mkdir dir1/subdir
$ echo foo > dir1/subdir/foo

$ mkdir dir2/subdir
$ echo bar > dir2/subdir/bar

$ restic backup dir1/subdir dir2/subdir
password is correct
scan [/home/user/dir1/subdir /home/user/dir2/subdir]
scanned 2 directories, 2 files in 0:00
/home/user/dir2: name collision for "subdir", renaming to "subdir-1"
[...]
snapshot f6138d06 saved

2つのサブディレクトリの場合、resticはサブディレクトリのベース名をリポジトリの最上位ディレクトリとして使用するため、 dir1/subdirとdir2/subdirのどちらでも、両方ともsubdirになります。これが原因です。衝突。

最新のスナップショットを一覧表示すると、次のようになります。

$ restic ls latest
password is correct
snapshot f6138d06 of [/home/user/dir1/subdir /home/user/dir2/subdir] at 2018-03-21 20:38:33.58232292 +0100 CET):
/subdir
/subdir/foo
/subdir-1
/subdir-1/bar

テストケースでは、 $TESTDIR/dir1と$TESTDIR/dir2のベース名が異なるため（ dir1とdir2 ）、バグは発生しません。

バージョン0.9のリリースノートから：

このリリースのresticを使用した最初のバックアップでは、すべてのファイルがローカルで再読み取りされる可能性が高いため、時間がかかります。 その後の次のバックアップは再び高速になります。

私はあなたにいくつかの統計を与えたいだけです：

最初のバックアップ：

-------------------------------------------------------------
Start: Do 24. Mai 05:15:01 CEST 2018
437 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:38
snapshot f724ff21 saved

Files:         556 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 556 files, 914.493 GiB in 2:15:29
snapshot 3c0e0f1b saved

Files:       11570 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 11570 files, 66.044 GiB in 16:21
snapshot 312fd29c saved

Files:        2309 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 2309 files, 163.332 GiB in 24:13
snapshot 2baab573 saved

Files:         312 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 312 files, 1.503 TiB in 4:48:23
snapshot 02dfe40c saved

Files:       743172 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      84.927 MiB

processed 743172 files, 89.131 GiB in 2:48:59
snapshot dcee3e70 saved

Files:         441 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added:      719 B

processed 441 files, 727.575 GiB in 1:56:36
snapshot 676adc45 saved
End:   Do 24. Mai 17:46:46 CEST 2018
Duration: 12h:31m:45s
-------------------------------------------------------------

二つ目：

-------------------------------------------------------------
Start: Fr 25. Mai 05:15:01 CEST 2018
444 snapshots

Files:           0 new,     0 changed, 40524 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 40524 files, 14.805 GiB in 1:42
snapshot 9c7cf320 saved

Files:           0 new,     0 changed,   556 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 556 files, 914.493 GiB in 0:15
snapshot 533e2155 saved

Files:           0 new,     0 changed, 11570 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 11570 files, 66.044 GiB in 0:17
snapshot 1c1235c3 saved

Files:           0 new,     0 changed,  2309 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 2309 files, 163.332 GiB in 0:13
snapshot d5ef168d saved

Files:           0 new,     0 changed,   312 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 312 files, 1.503 TiB in 0:16
snapshot 76e94946 saved

Files:         292 new,     0 changed, 743172 unmodified
Dirs:            0 new,     2 changed,     0 unmodified
Added:      32.790 MiB

processed 743464 files, 89.163 GiB in 1:06
snapshot 12fa66e8 saved

Files:           0 new,     0 changed,   441 unmodified
Dirs:            0 new,     0 changed,     2 unmodified
Added:      0 B

processed 441 files, 727.575 GiB in 0:15
snapshot ab2d29bb saved
End:   Fr 25. Mai 05:19:12 CEST 2018
Duration: 0h:4m:11s
-------------------------------------------------------------

とても長い、つまりずっと長い:-)
これからもいい結果を出し続けてください！ 👍

@ fd0 、素晴らしい仕事です！ 本当にありがとう！ あなたのバックアップツールは、私のすべてのオフサイトバックアップ（b2を使用）で私のお気に入りになりました:-)