fetching idx from target with varying disks on /mnt

[Greg Troxel]

bup stores the index-cache by path. This doesn't seem great for
removal storage mounted on the same place. One might have N disks, all
similar, and rotate every week doing bup to one of them. Being
old-school Unix, they'd be mounted on /mnt.

I am seeing a very long time fetching idx/midx/etc. I should look into
this more but I am wondering if bup is emoving files from the other
disks, or maybe I just have a lot new.

It strikes me that a bup repo should have a UUID and index-cache should
function by that.

But I guess if the idx files from the "other /mnt" disks just sit there,
and there's no rm/fetching as I rotate, it's ok.

Thoughts?

[Johannes Berg]

On Tue, 2024-02-20 at 12:55 -0500, Greg Troxel wrote:
>
> It strikes me that a bup repo should have a UUID and index-cache should
> function by that.

https://github.com/jmberg/bup/commit/301113cf4844e375f658d94fbfbc3a4e3666c743

;-)

johannes

[Nix]

On 20 Feb 2024, Greg Troxel stated:

> bup stores the index-cache by path. This doesn't seem great for
> removal storage mounted on the same place. One might have N disks, all
> similar, and rotate every week doing bup to one of them. Being
> old-school Unix, they'd be mounted on /mnt.

Indeed not -- I have to rotate my index caches whenever I swap out my
offsite backup drives (all mounted on the same path).

You should probably mount routinely-used backups on distinct paths to
avoid this problem, for now, until Johannes's UUID thing lands.

--
NULL && (void)