> 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 <[email protected]> wrote: > On Feb 13, 2014, at 6:19 PM, Daniel Staal <[email protected]> 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
