On 06/05/15 07:08, Tomaž Šolc wrote: > I have read+write keys on machines doing backups. A separate host stores > the delete key and does backup rotation. I rsync tarsnap cache > directories back and forth to keep them synchronized. > > I recently came across this post that says rsyncing basically invalidates > the point of having a separate delete key: > > http://mail.tarsnap.com/tarsnap-users/msg00935.html > > Is this a valid concern? If subverting the cache directory is indeed > possible, it probably requires a much more sophisticated attacker than > one who knows how to do "tarsnap -d".
It's definitely possible, but it does require a more sophisticated attacker. There's other benefits too, e.g., if you have scheduled archive pruning you might detect the server compromise before the tampered-with cache directory can result in data being deleted. > Originally my intention was to avoid doing regular "tarsnap --fsck". > --fsck seems to take several times the time and bandwidth compared to a > regular daily tarsnap backup on my machines. Yes, fsck needs to read metadata for all the currently stored archives, whereas creating an archive only needs to send *new* blocks. But if you only prune periodically (e.g., create a backup every day but only prune them once a week) you may find that the cost of the fsck is low enough. Also note that it's safe to copy the cache directory from the delete-keys system to the write-keys system, so you only need to do the fsck once, not twice. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid
