jerry <[email protected]> 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
