BackupPC-users

Re: [BackupPC-users] Exponential full backups not working as expected (I think)

2009-05-22 23:20:42
Subject: Re: [BackupPC-users] Exponential full backups not working as expected (I think)
From: Holger Parplies <wbppc AT parplies DOT de>
To: "Jeffrey J. Kosowsky" <backuppc AT kosowsky DOT org>
Date: Sat, 23 May 2009 05:14:58 +0200
Hi,

Jeffrey J. Kosowsky wrote on 2009-05-22 18:29:55 -0400 [[BackupPC-users] 
Exponential full backups not working as expected (I think)]:
> I have now been running BackupPC for about 6 months now and I don't
> think I'm getting the exponential series of full backups I was looking
> for.

I'll check again, but I believe they are working as expected for me (can't do
that from here right now).

> I was hoping to have full backups done every 2 weeks with 1 saved
> exponentially every 2 weeks, 4 weeks, 8 weeks, 16 weeks, 32 weeks, and
> then approximately yearly (actually every 63 weeks) for a 100 years.

Last time I checked, 32 * 2 was 64 ;-).

> [...]
> I set the following variables:
>   $Conf{FullPeriod} = 13.97;
>   $Conf{FullKeepCnt} = [1, 1, 1, 1, 1, 100];
> [...]
> However, while the incrementals seems to be working just fine, I don't
> seem to be getting the expected exponential series of full
> backups. Here is what I get on various machines (where first column is
> backup number and second column is the date). Note some machines are
> laptops so they may miss backups if they are not online.

That (and not knowing which) doesn't make looking for a pattern any easier. In
fact, I could imagine that to be the cause of getting unexpected (or even
incorrect) results. Do you mean "missing backups" as in "sometimes they're a
day or two off" or as in "they'll occasionally be gone for a month or two"?

> Machine 1:
> 16  11/18
> 127 3/12
> 183 5/7   
> 196 5/20 
> [...]
> 
> I'm not sure I even see the pattern here...

I'm sure I don't, but that might be because I find the date format confusing.

> I would have thought I would on average have a backup now that is
> most recent then going back from that a total of 2 weeks, 6 weeks, 10
> weeks, and 18 weeks (since the oldest backup is now just 26 weeks old).

I would have expected something like

        0 weeks,              # +  2 weeks =
        2 weeks,              # +  4 weeks =
        6 weeks,              # +  8 weeks =
        14 weeks,             # + 16 weeks =
        30 weeks,             # + 32 weeks =
        62 weeks, 126 weeks, 190 weeks, 254 weeks ...

(just to give you the picture). Note the time deltas given as comments.

Let's see how that comes to be. After six weeks, you've got three full backups:

        (c) 0 weeks,
        (b) 2 weeks,
        (a) 4 weeks

Backup (c) is the first two-week backup, backup (b) has depending incrementals
(and is thus kept as first four-week backup), backup (c) has no preceeding
backup to compare its age with. All are kept. Two weeks later:

        (d) 0 weeks,
        (c) 2 weeks,
        (b) 4 weeks, (a) 6 weeks

Backup (b) moves to the 8-weeks slot, but it's only 2 weeks younger than
backup (a), so backup (b) is deleted. Two weeks after that, backup (c) is
deleted for the same reason and another two weeks later backup (d). Six weeks
after the picture above, we have:

        (g) 0 weeks,
        (f) 2 weeks,
        (e) 4 weeks,
        (a) 12 weeks

Backup (e) survived, because the distance to the previous remaining full
backup (a) is 8 weeks.
Note that the four-weeks slot is special in that it is filled by the second
youngest full backup, because it can't be deleted due to dependant
incrementals. It is really too young for this slot. "Normally", each second
backup moving to each new slot would be deleted, but we see that the 8-weeks
slot discards three backups and keeps one, taking over the job of the 4-weeks
slot, which doesn't discard any. Let's see what happens eight weeks later:

        (k) 0 weeks,
        (j) 2 weeks,
        (i) 4 weeks,
        (e) 12 weeks, (a) 20 weeks

Backup (i) survived the 8-weeks slot, pushing backup (e) into the 16-weeks
slot. (e) is only 8 weeks younger than backup (a), though, so it's deleted.
Tough luck. Further 8 weeks later, the next one (i) survives:

        (o) 0 weeks,
        (n) 2 weeks,
        (m) 4 weeks,
        (i) 12 weeks,
        (a) 28 weeks

I'm gradually running out of letters to label the backups, so I'll stop boring
you at this point. The estimation above was (roughly) what I had expected, the
description of the development is from reading the source code and what I
think it does. It does seem to match the documentation.

Let's just roll the last state back two weeks though, to see what you should
have:

        (n) 0 weeks,
        (m) 2 weeks,
        (i) 10 weeks,
        (a) 26 weeks

That doesn't seem to be unreasonably different from your figures, does it?
At least with machine 1, I can roughly find this pattern. The others might be
distorted by having missed backups and/or incrementals forcing more full
backups to be kept (a too young backup in the 8-weeks slot with a larger gap
to the oldest backup, for instance). Machine 3 seems to have been added later.

Hope that helps.

Regards,
Holger

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, & 
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com 
_______________________________________________
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>