BackupPC-users

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

2009-05-19 11:40:05
Subject: Re: [BackupPC-users] [SUGGESTION] "Duration/mins" not in decimal format
From: Adam Goryachev <mailinglists AT websitemanagers.com DOT au>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Wed, 20 May 2009 01:35:28 +1000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Boniforti Flavio wrote:
> Hallo Holger,
> 
>>> 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).
> 
> I *really* think I'll be collecting iptables data...
> 
>>> 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 ...
> 
> Nothing else than ssh-tunnelled BackupPC dumps.
> 
>>> 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). 
> 
>>> Are you saying that "the backup
>>> was taking ages" because it was re-transferring your data?
>> Yes.
> 
> OK, still a bit confused... Will eventually come back on this issue
> later on...

- From my reading of the mailing list, and usage of backuppc, I think it
works something like this:

A full backup (level 0) will backup all files, using rsync, only
modified portions of existing files, and new files are transferred.

An incremental backup (level 1 - 9) will backup all new files, and
modified files since the last backup of a lower level.

In older versions, (I think 2.x) there was only one "level" of
incremental backups, hence all incremental backups would re-transfer all
modified/new data compared to the last full backup. Even if the file has
not changed since the last incremental backup. This would explain what
you saw, the file was transferred again for each incremental backup
(slow backup times) but after transfer, backuppc decided a matching file
already existed in the pool, and so it was discarded and linked to the
pool file.

In newer versions, it is possible to configure (optional) different
levels of backup (1 - 9). Thus, if you set IncrLevels = [1,2,3,4] and
you have four incrementals between each full backup, then you will never
re-transfer a file which rsync could know has not changed since the most
recent backup unless the filename/path has changed. However, this
increases the cpu of the backuppc because it needs to merge the full
backup plus up to 3 incremental backups to complete the fourth incremental.

I think you should find more definitive (and correct) documentation in
the changelog or documentation if you search for IncrLevel/IncrLevels
for where this feature was introduced.

I also recall (but could be wrong) that the next version of backuppc
would also (possibly) apply the same logic for a second backup of the
SAME level. In effect, IncrLevels = [1,2,3,4] would become the same as
IncrLevels = [1,1,1,1] (which is the same as IncrLevels = [1]).

To me, especially with rsync/rsyncd backups, this seemed to make a lot
of sense, though I can't comment on the effects this might have if using
smb/tar/ftp/etc...

So, in short, this is why I currently use IncrLevels = [1,2,3] and do
full backups after every 3rd incremental.... If anyone thinks the above
is grossly incorrect, please feel free to correct me before someone
follows my totally wrong random ramblings... If anyone wants to
implement or follow the above, I strongly suggest you find corroborating
evidence elsewhere first.

Regards,
Adam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkoS0bwACgkQGyoxogrTyiXhsACguJxxmVd7pkX2zlHWmxgUfgA8
OjAAnAhNxHMZx6fOG8R2kaNpZmTixPmR
=vkZT
-----END PGP SIGNATURE-----

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