Re: Monitor ongoing upload?

[Colin Percival <cperciva@tarsnap.com>]

On 06/29/14 07:48, jerry wrote:
>    I started up a "real" tarsnap backup.  du -sb = 19 gigabytes.  Maybe I should
> have done some arithmetic
> before starting.  At an upchuck-DSL speed of 85 kilobytes per second, that's 2.6
> days.  Not to mention that it's probably longer than that, because of the
> significant value that tarsnap is adding to the process.

Probably a bit less than that due to compression (and excludes, as you mention).
 While Tarsnap does a significant amount of CPU work, it isn't
significant when you're only talking about 85 kBps of data.

>   I do understand that I pay the time penalty only once, and subsequent backups
> will be more or less the difference.

Right.  Or more precisely, "the bits which are new".

>   The real problem here is that I really shouldn't change the data set while
> backing it up, right?  I really can't afford to have this data sit without write
> access for multiple days.  Totally impossible.

You can change the data while Tarsnap is reading it.  Tarsnap may get an
inconsistent view of the data, but any files which aren't changing will be
backed up perfectly, and you'll still get all the "most of the data was
previously backed up" benefits of deduplication the next time you create an
archive.

> If I copy a snapshot off to another device or tar file, and then tarsnap off of
> that, will the transfer-only-changes feature still work when I do subsequent
> tarsnaps of the original data?

It will still work; the deduplication works on the backup data, not on the
file names (except to the extent that file names are stored in archive
headers, of course).

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid