Re: Vote

[Colin Percival <cperciva@tarsnap.com>]

On 10/27/11 06:26, Clive Cox wrote:
> I would vote for faster tarsnap restores.

Yep, that's my highest priority right now.  (Not to say it will happen before
anything else -- there's a lot of things which are essentially "en route" to
getting that -- but it's the issue I think is most urgent.)

> We've had to use tarsnap
> restore for real when a machine corrupted its RAID. We started a restore
> of the system and it looked like it would take at least a week to get it
> all restored (the initial backup a few months before took an hour or so
> to push to tarsnap) - the machine was in a data centre with fast network
> access, BTW. In the end, our server expert was able to fix the discs by
> hand so we could reboot the machine, so the restores weren't needed!
> (public thanks to Chris Webb at Arachsys/Elastichosts)
> 
> If anyone has any best practices I would be grateful to hear, e.g. do
> several backups of logical parts of the system and then 1 full system
> backup (as I understand it that would take no more space on tarsnap due
> to not storing duplicate blocks and might ease logical restores of parts
> of the system?).

The best way to speed up tarsnap extracts is to find a way to do them in
parallel -- using multiple small archives which you can extract independently,
or by having each tarsnap process extract a different sub-tree from an archive.
(Unless you have a huge number of small files, tarsnap will be fast at skipping
over the files it's not extracting, so there isn't much difference between the
two options).

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