Re: Backup Restore (Was: Re: Getting started with Tarsnap)
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 sc...@directededge.com wrote: On Feb 13, 2014, at 6:19 PM, Daniel Staal dst...@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
Re: Backup Restore (Was: Re: Getting started with Tarsnap)
On Feb 14, 2014, at 11:26 PM, Nick Sivo n...@ycombinator.com wrote: 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. That’s arguable if you’re not dealing with massive amounts of data (which I don’t consider 35 GB of uncompressed data to be). Network speed over a compressed tunnel would let us restore in under 20 minutes, compared to the (projected) 53 hours with Tarsnap. If our servers catch on fire, anything under an hour for a complete restore would be fine-ish. Tarsnap isn’t anywhere close to that. My point was rather that Tarsnap’s slowness isn’t intrinsic to it being a internet-based backup. Even for an off-site network backup, it’s extremely slow. -Scott
Backup Restore (Was: Re: Getting started with Tarsnap)
This really should be started in a new thread... --As of February 13, 2014 6:09:57 PM +0530, Vijay Barnwal is alleged to have said: I have a problem with restore a particular directory from tarsnap backup. Its taking too much time to restore a directory from archive backup. Please Help me to resolve this. My command is tarsnap -x -f backup backupPath Please tell me the command for fast restore. --As for the rest, it is mine. Define 'too much time': How fast is the restore going? 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. There are a couple options which can slow down your restore, but you'd have to set them in the config file for them to being slowing you down, so I doubt there are any options you could set that could significantly speed things up. Daniel T. Staal --- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ---
