Hi,
Boniforti Flavio wrote on 2009-05-19 08:53:31 +0200 [RE: [BackupPC-users]
[SUGGESTION] "Duration/mins" not in decimal format]:
> > Depending on whether you want to entertain bored users, bill
> > your clients for bandwidth, or conduct scientific
> > measurements, the answers are likely to be vastly different.
>
> I need to give my customers statistics about how much data has been
> transferred each month, which means summing up day-by-day the
> transferred amount of data.
so it's the "entertain bored users" case :-). Your definition leaves room for
interpretation. For instance, if that number is more readily available, you
could sum up the uncompressed data streams. On the other hand, you could leave
iptables accounting rules in place all the time and just read out the counters
(and zero them) once a month (assuming your BackupPC server doesn't reboot).
Aside from that, you will probably be counting in GB, not in bytes.
> > > Do you already have some sort of practical suggestion?
> >
> > iptables -I INPUT -s client_addr -d backuppc_server_addr -p
> > tcp --sport 22
> > [...]
> Well, I'm having concurrent backups, but they use different TCP ports,
> thus I can "--sport 8873" and "--sport 8874" and so on for my clients.
Even better. Those ports will not be used for maintainance, I suppose? Even if
so, I guess counting that traffic wouldn't strictly be wrong ...
> What I interpreted was that "same" and "skip" have the same meaning:
> file is not getting transferred. Why then using *two* words to define a
> seamingly identical behaviour?
I can't actually find "skip" in my XferLOGs. Probably because it only appears
with logLevel >= 2 (at least for rsync). Strange. You always seem to find
issues which, when looking at the code, disappear. There is one issue though:
your logLevel is set too high (unless you are actually tracking a problem,
which, in my experience, is not the case). I bet an 'ls -l' of your pc/
directories doesn't show as nicely which backups are full and which are
incremental. With mine it's really obvious from the XferLOG files.
skip - unchanged file skipped in incremental
same - file that would normally have been transferred (full backup or
attribute change) turns out to be identical to reference file,
no transfer needed
You obviously won't get "same" for tar/smb backups (nor will you get "skip",
because the files are skipped by the sender without notice to BackupPC).
> The "create" was clear to me, but the "pool" one not so clear: I had in
> "Incr Backup 16" a "create" statement for a big file (2.7GB). The
> subsequent backup (Incr Backup 17) the same file (which has *not* been
> changed in any way, because it's a static ZIP file that was added before
> backup 16) was indicated as "pool": would this be meaning that the file
> had been transferred again and only after being transferred, BackupPC
> recognized that it was already in the pool (and matching)? This is the
> part I don't understand actually...
By default, that is normal. Read about how incremental backups work, in
particular, which backups they are based on.
There are, of course, cases where this would not be normal, but I've run out
of motivation for going into details about hypothetical problems.
> > [...] In particular, on my "import backup from
> > local source" quest, I was really worried when I got lots of
> > "pool" lines on the first remote backup where it should have
> > read "same". That explained rather well why the backup was
> > taking ages.
>
> So your case was the same as mine above?
No.
> Are you saying that "the backup
> was taking ages" because it was re-transferring your data?
Yes.
Regards,
Holger
------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
