これが私が見つけたこのリクエストの古い化身です：＃555

+1

また、これは本当に便利な機能だと思います。

要約すると、 restic backup /mnt/backup-snapshotを実行しているので、スナップショットではファイル/mnt/backup-snapshot/fooは/mnt/backup-snapshot/fooが、 /foo 。 あれは正しいですか？

現在のディレクトリを変更し、 cd /mnt/backup-snapshotを実行してからrestic backup .実行するだけで、restic> 0.9.0でこれを実現できます。

それはあなたのために働きますか？

cwd変更は機能しますが、包含/除外にファイルを使用すると、不快な副作用があることに気付きました。 絶対パスがそこに配置されている場合、 cwd変更するときにそれらはスキップされるようです。 絶対パスも使用したいのですが、今のところはおそらくchrootパスを使用しますが、 tar -Cフラグに似たものがある方がよいと思います。 。

この偽のルートオプションは便利な機能だと思います。 cdhowieと同じですが、macOSでapfsスナップショットを使用したいと思います。 読み取り専用のapfsスナップショットにアクセスするには、それらをどこかにマウントする必要があります。 ただし、復元するときは、「元の」パスをスナップショットに保存されている正規のパスにします。

StdExclusions.plist（macOS標準バックアップ除外リスト）から収集された絶対パスがたくさん（125）あり、mdfindがcom_apple_backup_excludeItem属性セットで見つけることができるすべてのファイルとフォルダーがあるため、cdトリックは残念ながら最適ではありません。

/ mntをignore-fileに入れ、/ mnt / fs-snapshotからバックアップを開始すると、問題が残り、それ自体が除外されます。

さらに、cd $ path && resticbackup。 スナップショットのパスは/ベースですが、スナップショットの概要には引き続き$ pathが表示されます。

私はprootの回避策を見つけました。

また、パスプレフィックスを削除する方法を見つけたいと思いました。 私のユースケースは少し異なります-私はzfsスナップショット（ fs@$(date +%s) ）を作成していて、マウントせずにこれをバックアップしたいと思っていました（ /path/to/mount/.zfs/snapshots/${TS} ）-この方法でうまくいけば私は持っていませんスナップショットがアンマウントされず、何かがクラッシュした場合に永遠にぶらぶらすることを心配する必要があります。

このためのrestic forget出力は、スケジュール（毎日/毎週など）に従って、異なるパスのスナップショットが忘れられないことを私に思わせます。

@blurayneからのprootコメントは良い出発点でした、私は同じ結論に達したと思います：

$snap_path="/path/to/where/snapshot/is/accessible"
$orig_fs="/path/to/filesystem"
proot -b "${snap_path}":"${orig_fs}" restic backup "${orig_fs}"

これはうまく機能し、すべてのスナップショットが同じパスを持ち、 cdまたはpushd必要ありません。 また、prootはユーザースペースで利用できるため、バックアップがrootとして実行されない場合でも、可能です。

私の使用例：データベースデータを/ tmp / tmpzmn28r02（mktempまたはpythonのmkdtemp（）を介して取得）などの一時ディレクトリにダンプしてからバックアップします。
このメソッドは、2つのスナップショット間のすべてのファイルを異なるものとしてマークします。 したがって、一時ディレクトリプレフィックスを完全に無視するようにresticに指示する方法が必要です。
別の考えられる使用例：今日はすべての写真を「/ mnt / something / pictures」に入れていますが、明日は同じコンテンツが「/ mnt / external / pictures-from-home」（異なるパーティションスキーム/その他）の下にあります。

また、同じ実行でresticを使用して複数のディレクトリをバックアップする場合、同じスナップショットを使用するために、これはさらに複雑になります。

修正が完了するまで、「proot」プロポーザルを使用します-@ blurayneと@

こんにちは！ 私も似たようなケースがあります。 たとえば、私はフォルダを持っています

/srv/my/long/server1/path/data (with many subfolders and dozen of files)
/path/to/dump.sql
/path/certbot.tar.gz

だから私は次のようなバックアップを取りたい

/data
/dump.sql
/certbot.tar.gz

別のパス（相対）で他のサーバー（以前のフォルダー構造についてはわかりません）に復元する機能を取得します。

この些細な課題を解決するための熱心なアイデアはありません。 Resticは素晴らしいツールですが、エンドユーザーにとってなぜそれほど難しいのでしょうか。

事前定義されたバックアップフォルダ（/ backup）に必要なものをすべてコピーし、そこでResticバックアップを（CD経由で）実行します。 ただし、このソリューションは少量のデータに対してのみ機能します。

テンプレートの直後に（またはこのマスクを含めて）-includeサブフォルダーを使用して機能を復元できると便利です。 元。：
restic restore --include data --target /my/new/path
結果として取得します
/my/new/path/data

proot -b /path/i/wanted:./path_in_repo restic backup .で解決してくれてありがとう@ whi-tw-それは私のために働きます。

私のユースケースは、スナップショットを他のバックアップソリューションからrestic（私の場合はTime Machineとディスクイメージ）に移行することです。

TMによって作成されたスナップショットのイメージまたはサブディレクトリをマウントする場所からそれらを移行します。これは非常に長くなる可能性があります（例： /Volumes/TimeMachine-Backups/Backups.backupdb/MacBook Pro/2019-05-22-185113/Macintosh SSD/ 。

cdソリューションは、 restic mountとrestic restoreと機能しますが、 restic snapshotsを実行すると、元のスナップショットの絶対パスが表示されます。

移行されたスナップショットなので、元のスナップショットが作成された場所からのパスにもなります。 それとは別に、パスが長いと、 restic snapshots出力も少しうるさくなります。

代替プレフィックスを設定するフラグは私にとっても理想的です。

これはうまく機能し、すべてのスナップショットが同じパスを持ち、 cdまたはpushd必要ありません。 また、prootはユーザースペースで利用できるため、バックアップがrootとして実行されない場合でも、可能です。

これは良い回避策prootが、 PRootはMacOSXで動作しますか？

頭に浮かぶ別の回避策はありますか？

私の使用例：データベースデータを/ tmp / tmpzmn28r02（mktempまたはpythonのmkdtemp（）を介して取得）などの一時ディレクトリにダンプしてからバックアップします。
このメソッドは、2つのスナップショット間のすべてのファイルを異なるものとしてマークします。

とにかく、ファイルはおそらく_異なる_ことに注意してください。 データベースのバックアップには通常、最初の数行にタイムスタンプが含まれています。

データベースダンプコマンドを調整して、動的コメントを除外し、主キーで並べ替えることができますが、変化の遅いデータを実際に重複排除可能にすることができます。

更新：「proot」は、私にとっては1台のマシンでのみ機能し、別のマシンではsegfaultsで機能しました。
それに代わるもの（新しい）-バブルラップ
同じ '-b'パラメーターで動作するラッパーを追加しました（添付）。 これまでのところうまくいくようです。 ニーズとディレクトリの場所によっては、ラッパーを少し変更する必要がある場合があることに注意してください。
お役に立てば幸いですが、restic自体のサポートを楽しみにしています。

proot.sh.txt

prootを試しました。 追加機能（https://restic.readthedocs.io/en/stable/080_examples.html#full-backup-without-root）を使用して、非ルートとしてresticを実行する機能を壊しているようです。 少なくとも、 prootなしでresticを実行した場合には発生しなかったscan: Open: open /.pulse: permission deniedエラーが発生しました。

bwrap同じ問題が発生します。

したがって、私には、restic自体のパスプレフィックスを削除することは依然として有用であるように思われます。

この欠落している機能により、VMのバックアップが必要以上に困難になります。
私のVMスナップショットは、一時フォルダーに保存されてから、resticによってバックアップされます。
これにより、次のようになります。

ID        Time                 Host         Tags        Paths
--------------------------------------------------------------------------------------
02c536db  2020-04-10 14:28:27  resolver-02              /tmp/tmp.vOFFxxly9O/config.xml
c5709aed  2020-04-10 14:28:29  resolver-02              /tmp/tmp.vOFFxxly9O/sdb.img
a88cc1e7  2020-04-10 14:36:22  resolver-02              /tmp/tmp.FoY1j5JPIZ/config.xml
7c44e6ee  2020-04-10 14:36:24  resolver-02              /tmp/tmp.FoY1j5JPIZ/sdb.img
65456111  2020-04-10 14:37:48  resolver-02              /tmp/tmp.vjtI9JE3Iz/config.xml
eaced756  2020-04-10 14:37:49  resolver-02              /tmp/tmp.vjtI9JE3Iz/sdb.img
8eccec2c  2020-04-10 16:04:30  resolver-02              /tmp/tmp.YtLYRd0rNI/config.xml
34c897e1  2020-04-10 16:04:31  resolver-02              /tmp/tmp.YtLYRd0rNI/sdb.img
99b67b97  2020-04-10 16:07:53  resolver-02              /tmp/tmp.aWaEDqAaTq/config.xml
cad2c9d8  2020-04-10 16:07:54  resolver-02              /tmp/tmp.aWaEDqAaTq/sdb.img
--------------------------------------------------------------------------------------

これはrestic forget壊します。これは、同じファイルであると認識せず、すべてのインスタンスのスナップショットを保持するためです。 既知のプレフィックスを削除する方法、または相対パスのみを保存する方法があり、絶対的な方法がない場合は、この方法をお勧めします。
私はすでに相対パスを使用してresticを呼び出しており、一時フォルダーを変更しています。 悲しいことに助けにはなりません、そして私はこれのためにbindmountsを使用する必要がないことを望みます。

これはrestic forget壊します。これは、同じファイルであると認識せず、すべてのインスタンスのスナップショットを保持するためです。

これにも遭遇しますが、解決策は非常に簡単です。バックアップするファイルに基づいて、各バックアップにタグを付けます。

たとえば、ここでタグconfig.xmlとsdb.imgます。 その後、追加--group-by host,tags実行するときにrestic forget 。

この機能の実装が非常に難しいのはなぜですか？ スナップショットメタデータの基本的な文字列フィルタリングと同じではありませんか？ それがもたらす価値は計り知れません。 ええ、タグ付けで回避できますが、パスフィールドがあり、使用できる可能性があります...

この機能の実装が非常に難しいのはなぜですか？

私自身開発者として話すと（resticではなく、他のオープンソースプロジェクト）：多くの場合、それを実装するのを妨げるのは機能の複雑さではなく、時間の不足、モチベーション、または単に「現実の生活」などのありふれたことです...

もちろん、私の目的は批判的ではなく、潜在的な貢献者の複雑さを真に計画することでした。

こんにちは、私はこの「カスタムルート」関数の実装に取り​​組み始めました。 実装自体は一見シンプルに見えましたが、以前はC＃しか知らなかったgolangを学ぶ必要がありました...とにかく、これは2年前の2018年に由来するため、この問題がまだどのようなサポートを持っているかを測定しようとしています。 誰かがgolangで私を助けたいと思ったら、すぐにhttps://github.com/TheRealVincentVanGogh/restic/tree/2092-feature-custom-path-prefixにコミットし

@TheRealVincentVanGogh Goについては学習しませんが、この機能にはまだ熱心であり、この問題のために、まだresticに移植したいバックアップがたくさんあります。 動作しているように見えるものができたらPRを開き、ここにリンクを投稿します。重いテストを行います。

@TheRealVincentVanGogh計画されている実装はPR＃2010とどのように関連していますか？

@TheRealVincentVanGogh計画されている実装はPR＃2010とどのように関連していますか？

@MichaelEischerああシュート！ 誰かがすでに私を殴ったようです。 ええ、PR＃2010はまさに私が真っ只中にいるものです...再達成...くそー。 おそらく@cdhowieは、PR＃2010をこの問題にリンクして、将来の混乱を避けるのに

@themightychrisここにそのPRへのリンクがあります。 開発者も2018年に脱落したようです...好奇心が強いです。

編集：

スナップショットファイルVSからパスプレフィックスを削除することの間には、いくらかのあいまいさがあります。 すべてのファイル構造+スナップショットファイルからパスプレフィックスを削除します。 PR＃2010は前者のみを対象としているようです。 OPは「バックアップされたすべてのファイルのパスからこの先頭のパスを取り除く」 （別名、ファイル構造レベルのパス修正）を探していたので、

それでもないし！ @MichaelEischer私の意図は常に、Restic（長い機能/文である人）でファイル構造+スナップショットレベルのパスプレフィックススライスの実装を取得することでした。 ですから、おそらくPR＃2010の既存のコードから作業を開始します。これにより、実装がスピードアップするはずです。

PS私は最近かなり忙しいので、仕事はしばらく遅いかもしれません。 もちろん、皆さんと共有する価値のあるものがあると思ったら、PRを投稿します！ みんな安全に！ 😄