Re: Backup Restore (Was: Re: Getting started with Tarsnap)

[Nick Sivo <nick@ycombinator.com>]

> I can't recommend Tarsnap to others as a viable primary backup tool.

Primary backups should always be on-premises, no? Nothing will be
faster than locally attached storage.

-Nick

On Fri, Feb 14, 2014 at 2:02 PM, Scott Wheeler <scott@directededge.com> wrote:
> On Feb 13, 2014, at 6:19 PM, Daniel Staal <DStaal@usa.net> wrote:
>
>> Tarsnap is *online* backups - it has to download the data to do a restore. The problem could be your connection, the server, something upstream, etc. It's possible there's a problem Colin can/should fix, but that can't be determined from your posting.  We need to know exactly what you are seeing.
>
> This is definitely a Tarsnap issue.  Restores are extremely slow.  I usually see around 1.5 Mbit/s on a 100 Mbit connection, which jives with what Vijay reported (~1.3 Mbit/s).  I brought this up with Colin a couple years ago and he said that it's an issue of "a lack of pipelining in Tarsnap's archive reading".  You can however run multiple extractions in parallel.
>
> This remains my biggest pain point with Tarsnap -- it would still take us an unseemly amount of time to restore our customer data set (~35 GB -- which would take approximately 53 hours to restore without split up the restores) in a disaster scenario.  As such we currently have a snapshot that gets overwritten daily and Tarsnap for the sequential daily backups, but this issue remains the reason that I can't recommend Tarsnap to others as a viable primary backup tool.
>
> -Scott