> 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.
For the HDD space usage, I simply rely on what my "Host Summary" page is
telling me (Full Size).
[cut]
> > Do you already have some sort of practical suggestion?
>
> iptables -I INPUT -s client_addr -d backuppc_server_addr -p
> tcp --sport 22
>
> (and delete it with the same rule with "-D" instead of "-I").
> Supposing you only have one concurrent backup to one host and
> no other ssh usage. You might prefer to count outgoing
> traffic (well, no, but maybe incoming + outgoing).
> Note that the rule has no target - it's only for accounting.
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.
> > If you talk about the same things I am clueless about
> (skip, create,
> > pool, same, and so on), then I'd be *too* interested in
> some precise definitions.
>
> I can give you some imprecise ones.
>
> same - rsync determined that file matches and does not need
> to be transferred pool - transferred file matched one already
> in the pool create - transferred file did not match any
> existing pool file
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?
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...
> To be honest, I think they're all rather self-explaining. I
> didn't do any research on the answers, it's just what figures
> from observation. 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? Are you saying that "the backup
was taking ages" because it was re-transferring your data?
Thanks for helping,
F.
------------------------------------------------------------------------------
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 AT lists.sourceforge DOT net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
|
