BackupPC-users

Re: [BackupPC-users] [SUGGESTION] "Duration/mins" not in decimal format

2009-05-18 18:33:18
Subject: Re: [BackupPC-users] [SUGGESTION] "Duration/mins" not in decimal format
From: Holger Parplies <wbppc AT parplies DOT de>
To: Boniforti Flavio <flavio AT piramide DOT ch>
Date: Tue, 19 May 2009 00:30:11 +0200
Hi,

Boniforti Flavio wrote on 2009-05-18 22:14:50 +0200 [Re: [BackupPC-users] 
[SUGGESTION] "Duration/mins" not in decimal format]:
> Il 18.05.09 17:34, "Adam Goryachev" <mailinglists AT websitemanagers.com DOT 
> au> ha
> scritto:
> [...]

the question I believe should have been asked long ago is: What problem are
you trying to solve? Is there even one, or are you just trying to make
use/sense of numbers that are displayed somewhere?

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.

> You are quite right... I didn't want to put that stuff in our thread, but it
> *has* to be mentioned that rsync + ssh (and YES I am using -C compression!)
> does meanfully change the amount of data transferred.

Depending on what you want, that may or may not be relevant. You can just as
well bill your clients for your disk wear (and CPU usage), regardless of the
bandwidth savings ssh compression and rsync algorithm gain you. In fact,
bandwidth savings will probably not mean that you can do more concurrent
backups.

> > A simply pre/post script which sets up the iptables entry, and then
> > records the result and deletes the entry would probably be the quickest
> > solution for a couple of simple bash scripts.....
> 
> 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.

> > Still, this doesn't address the meanings of the various bits of data
> > which *are* kept by backuppc. Did someone manage to find the
> > documentation on the meaning of the data recorded in the backups files?

Use the force, read the source :)

> 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

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.

But, again, this is a *completely* different topic from counting bytes with
iptables. You should first find out what you want, then ask for help finding a
solution. Discussing all possible problems might be something people enjoy
that have an abundance of free time. These people should spend more time on
the BackupPC wiki ;-).

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

<Prev in Thread] Current Thread [Next in Thread>