BackupPC-users

Re: [BackupPC-users] Designing a BackupPC install over a WAN - minimising Full backups

2009-01-23 00:37:07
Subject: Re: [BackupPC-users] Designing a BackupPC install over a WAN - minimising Full backups
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: Fri, 23 Jan 2009 16:35:09 +1100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter Wright wrote:
> On 21/01 10:48:50, Tino Schwarze wrote:
>> On Wed, Jan 21, 2009 at 02:08:31PM +0900, Peter Wright wrote:
>>>> An incremental backup will transfer changed data from the
>>>> previous full or incremental of a lower level.
>>> Can backuppc be configured to transfer changed data from the previous
>>> incremental of the *same* level, or would this require a patch?
>> Why would you want to do that? The previous incremental of the same
>> level is a lot older and you'd need to transfer a lot more changes.
>
> Take my words in the context of responding to Adam - though perhaps I
> could have put it more clearly :).
>
> Adam stated that "An incremental backup will transfer changed data
> from the previous full or incremental of a lower level."
>
> What I was thinking is that if my highest priority was minimising
> bandwidth per backup, why shouldn't I be able to configure backuppc to
> *only* do incrementals and consider them all to be the same "level"?

Since "previous full or incremental of a lower level" is not the same as
"all incremental on the *same* level"... Each transfer would in effect
be compared to the previous full, which will get progressively worse
(based on your goal of bandwidth usage minimisation).

> But I suspect I've probably misunderstood one or more key backuppc
> principles, especially re: what the "levels" really mean.
>
>> In default configuration (IIRC), your backups with weekly full would
>> look like this:
> [ snip description ]
>> The second level-1 incremental will transfer all changes since the
>> full backup.
>
> Thanks for the clarification - that was how I thought it worked, but
> it's good to make sure.
>
> My key issue is that if I'm interested in bandwidth minimisation above
> all else, why would I want to do anything other than
> incremental-since-the-most-recent-previous-incremental, regardless of
> the "level" concept?

Actually, it is the opposite. If bandwidth minimisation is your only
concern, then every backup should be a full..... Since each backup will
only transfer the changed portions of existing files, or new files,
compared to the previous (full) backup. This will minimise your
bandwidth usage.

> As I understand Holger's earlier response, the major (only?) downside
> is the cost of building the backup view - and I can certainly see how
> that'd become significant after a while.
>
> I suspect I've got my brain too hooked into the rsnapshot model
> (http://www.rsnapshot.org/) and I'm not quite understanding the
> different philosophy of backuppc.

I presume you were doing a "full" backup each and every time using
rsnapshot... ie, you didn't tell rsync to ignore files based on the
modification date/time. So rsnapshot doesn't have any concept of
full/incremental, since every backup is a full. You just need to carry
that idea forward, and ignore the additional "feature" of incremental
backups that backuppc offers.

Hope that helps...

Personally, I have a backuppc which never deletes a backup, it currently
has over 800 backups for each host. I started with your mistake, of
doing a full + forever incremental, but once I realised my error, now do
a full, 3 incrementals, and another full, etc... The incremental's are
done to reduce the load (and hence time) on the machines being backed up.

Regards,
Adam

- --
Adam Goryachev
Website Managers
www.websitemanagers.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkl5Vw0ACgkQGyoxogrTyiUnMwCeNVe//jNblflY9VUOh308hYmV
yD0An3BGkobWWxEfmVJ8n3K2jnF7y52p
=0xFd
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
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/