Re: Tarsnap GUI shows 0 data archived or backed up
On Thu, Sep 7, 2017 at 11:55 AM, Garance AE Drosehn <gadc...@earthlink.net> wrote: > >> On Sep 7, 2017, at 4:21 AM, a...@sdf.org wrote: >> >>> So, can I make it smaller than 1.07 GB? Am I doing something wrong? I can >>> explain what kind data are part of those 1.45 GB (can give a breakup too >>> if needed). >>> >>> Can I compress it more, make de-duplication more aggressive? I have used >>> the default config that came with the app. >> >> Or should I ask it in a separate thread? Or rather shoot a mail to Tarsnap >> support? (But I see Graham is CCed in this mail thread). >> >> Thanks. > > There is one thing to note about de-duplication in tarsnap, compared to some > other services. Tarsnap can only de-duplicate across the files *you* are > backing up, on a single specific machine you are backing up. This is a > side-effect of all the privacy and encryption that tarsnap guarantees. > > De-duplication works great in some other situations because the other service > is de-duplicating files across (say) 20 different Windows machines. So the > first machine may use up 10-gig of space, but all of the rest of the machines > might have less than a gig of additional unique files per machine. Tarsnap > cannot do that kind of optimization across multiple machines. Depending on just how paranoid you are, and how disciplined you are, you can have multiple machines deduplicate to a common store, as long as you only have one running at a time. What you wrote does not preclude that from happening, I just wanted to point it out in case others might be interested in something like that. -- Scott Robison
Re: humanizing the control t function?
Just an idea, but perhaps ^T could display something along the lines of "2.1 GB / 3.0 GB (2100123456 / 3000123456)" if --humanize-numbers is specified. On Mon, Jun 6, 2016 at 10:45 AM, Graham Percival <gperc...@tarsnap.com> wrote: > Yes, I can confirm that --humanize-numbers does not affect the SIGINFO > output. > > I have added this as an issue: > > https://github.com/Tarsnap/tarsnap/issues/164 > > > > I agree that it may be difficult to see progress with large files; it could > > very plausibly display "2.1 GB / 3.0 GB" multiple times. But I think it's > > less surpring to users if they see human output when they specified > > --humanize-numbers, rather than human output for some numbers and raw > output > > for other numbers. > > > > Cheers, > > - Graham > > > > On Mon, Jun 06, 2016 at 03:21:40PM +0100, Bob Eager wrote: > > > Yes, but that doesn't affect the Control-T function (perhaps it > > > should?). > > > > > > Control-T ought, however, to show if there is ANY progress - difficult > > > if the numbers are humanized. > > > > > > On Mon, 06 Jun 2016 13:42:59 + > > > Diego Veríssimo Lakatos <diegovlaka...@gmail.com> wrote: > > > > > > > Hello, I think that you are looking for the "--humanize-numbers" > > > > > > > > user@host:~$ sudo tarsnap --print-stats --humanize-numbers > > > >Total size Compressed size > > > > All archives 295 GB 220 GB > > > > (unique data)8.7 GB 6.4 GB > > > > > > > > > > > > > > > > Em sáb, 4 de jun de 2016 às 19:52, Sarah Alawami <marri...@gmail.com> > > > > escreveu: > > > > > > > > > I forgot what signal that sends to tarsnap but is there a way to > > > > > humanize that set of numbers? I'm horrible with byte calculation. I > > > > > can approximate to a point but still. Is there a way to make those > > > > > numbers read a bit more friendly? With out giving the file name the > > > > > example would be. 4456448 / 11044528 bytes) > > > > > > > > > > Is there a way to make that look better let's say kb or even mb? > > > > > Depending on the number shown? I dunno if this would make > > > > > tarsnap consume more memory especially on slower machines or what > > > > > not. But just a thought. > > > > > > > > > > hope that helps a bit. Loving the program so far. > > > > > > > > > > Blessings and happy Saturday > > > > > > > > > -- Scott Robison
Re: Unique files
On Sun, Oct 26, 2014 at 4:20 PM, Colin Percival cperc...@tarsnap.com wrote: On 10/26/14 06:52, jerry wrote: On 10/25/2014 12:21, Scott Robison wrote: Is there a means to determine what is new between two full archives? I do a full archive of an entire partition each day, and am a little surprised by how much new data exists. I would like to diff *** Do you have the noatime option on your filesystem? Without that, the filesystem will track, for each file, not only when it is modified, but when it is *read*. So every read anywhere produces a write. This is for Linux, I don't know if it holds for other OS's. Tarsnap defaults to not storing file access times, so this shouldn't be the issue (unless Scott is using the --store-atime option). I am not using the --store-atime option, as I am only concerns with file contents, not metadata. I am using whatever default configuration exists in my Ubuntu 14.04 VPN with regard to updating atime, which appears to be noatime for all the mounts in fstab. Thanks to all for the thoughts / info. -- Scott Robison
Unique files
Is there a means to determine what is new between two full archives? I do a full archive of an entire partition each day, and am a little surprised by how much new data exists. I would like to diff the two archives, and am hoping there is something built in that is relatively more efficient than a brute force approach. I can brute force it if need be, but would rather not. Thanks! -- Scott Robison
