Re: limited keys (-r, -w), remote pruning

[Colin Percival <cperciva@tarsnap.com>]

Andreas Olsson wrote:
> (Yes, one workaround is to rsync the cache folder from the prune machine to 
> the machine being backed up. Still, that doesn't feel like a stable solution 
> in the long run if you want your backups to continue automatically.)

Probably not the best option -- a failed rsync could result in Tarsnap thinking
that the cache directory is up to date when it isn't.

> cperciva: Or would it perhaps be possible to add an option to tarsnap, 
> allowing the rebuild of a cache folder without having the delete permission? 
> Merely working on the local cache folder wouldn't require anything else than a 
> read permission against the tarsnap archives, would it?

Yep.  This is on my to-do list and will probably happen fairly soon.  When I
first implemented --fsck during Tarsnap development it served to delete any
broken archives or orphaned bits from the server, which is why it needs the
delete key; but AFAIK it has never needed to do this (it's very hard to get
the Tarsnap client to do anything which would corrupt the server state) so
--fsck has turned into a "reconstruct the cache directory" command.

I think I'll make --fsck do a read-only fsck (reconstruct the cache directory
and error out if there's anything broken on the server) and add a new command
(--fsck-y, perhaps?) which needs the delete key and can clean things up on the
Tarsnap server.

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid