Re: Monitor ongoing upload?

[Jamie Landeg-Jones <jamie@dyslexicfish.net>]

jerry <jerry@tr2.com> wrote:

> OK,
>
>     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.
>
>    I'm not sure exactly how much of the 19-gig I'm actually
> transferring, because there is a substantial excludes file.  Yeah, I
> could write a script to du -sb all the excludes, add them up and
> subtract from the total.  Maybe later.

Don't forget that tarsnap compresses and dedupes client side, so you
may be pleasantly surprised!

>    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.

That's the problem with 'live' backups.

But use your system normally. Assume your first backup is a bit incoherent.
Your subsequent backups will be better because of the vastly reduce time
creating them!

Also, don't forget the 'checkpoint' functionality, along with the SIGUSR2
signal - these let you abort a backup without losing any of the backed up
data... From the man page:

 | --checkpoint-bytes bytespercheckpoint
 |              (c mode only) Create a checkpoint after every bytespercheckpoint
 |              bytes of uploaded data.  The value bytespercheckpoint must be at
 |              least 1000000, and a higher value is recommended since creating a
 |              checkpoint in an archive can take a few seconds and several hun-
 |              dred kB of bandwidth.
 |
 | --recover
 |              Recover a partial archive from a checkpoint if such an archive
 |              exists.  This is also done automatically the next time an archive
 |              is created or deleted.
 |
 |      SIGUSR2  On receipt of the SIGUSR2 signal, if tarsnap is creating an ar-
 |               chive (mode c), it will create a checkpoint at the current posi-
 |               tion.

> 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?

There is an option to control this. From the man page:

 | --snaptime file
 |              (c mode only) This option MUST be specified when creating a
 |              backup from a filesystem snapshot, and file must have a modifica-
 |              tion time prior to when the filesystem snapshot was created.
 |              (This is necessary to prevent races between file modification and
 |              snapshot creation which could result in tarsnap failing to recog-
 |              nize that a file has been modified.)

Cheers, Jamie