I use BTRFS, so have CoW and snapshots of the entire system which I transfer regularly to a backup box. Before dropping some content in the "working" instance of the repository, I thought to note availability of the keys in some backup snapshot(s) on a backup server. The difficulty is that those all would have the same git-annex UUID (since they are snapshots of the same "working one"), and internally git-annex would have availability marked based on that UUID so I guess that would not work as is.
So I am thinking (didn't try) to do the following dance:
- make a "read-write" copy of the entire backup snapshot
git annex initthe backup copy inthat snapshot to cause regeneration of UUID- run
git annex fsckso git-annex annotates availability of those keys with that new UUID - make read-only snapshot of the read-write snapshot
- add that read-only snapshot host:/path as a remote to the "working" instance.
Would that be "optimal" way or may be there is some feature of git-annex which would allow me to avoid the dance?
Is it possible to mount the snapshot and edit it? If so, you could skip making the CoW copy of it, and just go into it, unset annex.uuid and
git-annex init. Then proceed with the fsck etc.There's no way around needing to fsck, it needs to update its location tracking logs for the new uuid, and fsck is as good a tool as any. (Obviously --fast can be used.)
may be, but I better make (it is cheap) an snapshot of the snapshot with some explicit annotation (e.g.
-4shub-gitannexsuffix) before introducing any changes: after all snapshots are backups and better stay identical to the origin. But gotcha overall -- thank you, will proceed per above plan