Holger Parplies wrote:
> Hi all,
>
<<snipped by Matthias>>
>
>> $Conf{FullCntYearly} will allow to make the first backup of a year as an
>> full backup and save this full backups an amount of years.
>
> That could be useful for some people, but why limit it to "first backup in
> a year"? You might just as well need the first backup of a month, a
> quarter of a year, or the first sunday in a year to be a full backup (and
> retained specially). You can probably get all of that from a cron job
> triggering a full backup and doing some magic to prevent its deletion.
> Along the lines of Jeffrey's suggestion, introducing a new backup
> attribute "no-autodelete" and allowing to pass that along with the
> "manual" backup request from cron seems like a far more general solution.
Because of regulary requirements it is necessary to store important data at
least 10 years. Therefore personally I need a solution for yearly backups.
Feel free to change or improve it ;-)
>
> In your implementation, does $Conf{FullCntYearly}=0 prevent the first
> backup in a year from being treated specially (compatibility mode, so to
> say), i.e. make it a full or incremental as determined by the normal
> schedule?
Yes, sure.
> Hmm, it apparently does, but it also seems to schedule the
> backup for all hosts with $Conf{FullCntYearly} > 0 for the *first* wakeup
> in the new year, regardless of how old the previous backup is. That would
> mean all hosts to which this applies run concurrent full backups at the
> beginning of a year (and presumably keep in sync pending manual
> intervention)? Fireworks? :-)
>
No. If a client is configured to make one backup a week and the last backup
is from December, 30 than it's yearly backup will be startet at January, 6.
$Conf{FullCntYearly} will not change the scheduling-strategy of BackupPC.
>
>> I've extracted the patch with "diff -ruN <new-file> <original-file>" but
>
> Well, as would be expected, that produces the changes for *removing* your
> patch (differences from new to old), which is the wrong way around. This
> error is so common that patch detects it and offers to apply the reversed
> patch.
>
> Hint: in the patch, lines you added should be indicated by a "+" at the
> beginning, not a "-" ;-).
>
>> I've never applied this patch => Be carefull.
>
> Why not? It's not difficult. Presuming you have the original files in a
> tree like you normally would. If you plan to patch a tree of files, you
> would probably be best off to do something like ...
>
> % cd /usr/share
> % cp -dpr backuppc backuppc.orig
>
> ... edit the files you want to change in the directory backuppc
> ...
>
> % diff -Nru backuppc.orig backuppc
>
> ... instead of creating directories named "_original" and copying files
> whenever you start changing them (hopefully not forgetting so). It also
> greatly simplifies *creating* the patch, and you can easily *verify* it:
>
> % cd backuppc.orig
> % patch -p3 --verbose --dry-run --global-reject-file=../oops.rej <
> ../b4u-partial+yearly.patch
>
> (presuming you want to strip 3 path components -- usr/share/backuppc in
> this case; the diff generated by the command above would need a '-p1'
> instead).
Thanks for the hint. It was my very first patch. So hopefully you will
excuse me :-)
At least for future patches I will work like recommended. But I am not sure
when I'm be able to redeploy the actual patch.
>
> Aside from that, you shouldn't submit patches reflecting the debian
> package's installation layout. Get the source tarball and generate a patch
> relative to that. It's really just a matter of matching up files and
> verifying that the debian package does not introduce any changes your
> patch depends upon. Either you do that work or [possibly several] others
> have to, and it's probably easier for you to resolve or rule out any
> conflicts, because it's your code changes.
But I like the Debian version of BackupPC. I like the rrdtool grafik about
storage usage.
>
> Additionally, you avoid the problem of having two starting directories
> (/usr/share/doc/backuppc and /usr/share/backuppc).
Yes, that is an advantage
>
> All of that said, your patch applies cleanly (with reversed chunks, that
> is) to the files from the Sourceforge tarball [erm, well, from the
> .orig.tar.gz from Debian, but let's hope that is identical ;-] - once the
> files are moved into the places where the patch expects them). On Debian
> installations with BackupPC 3.1.0 installed, it should apply as is, but
> I'd really recommend building a patched .deb and installing that rather
> than patching the installed package.
Why that? I doesn't see an advantage.
I believe I have to decide if I will use the debian package furthermore.
As you outlined before I should develop my patch(es) against the original
BackupPC Sourceforge tarball. If I would do that there are no reasons for
further usage of the Debian packages (up to the rrdtools picture).
>
>
> Sorry if that should sound negative. Just trying to point out some things
> that seem important to me.
Yes, it was negative and it had not at all. We already discussed the topic
(partial backups) in July 2009.
At that time like today I do not have the impression you are interessted at
partial backups or you have a problem with the current solution.
But the patch is designed to let the decision of using this partial-
enhancement at the user. Even if the patch will be part of BackupPC, you and
anybody else should feel free to using it or not.
>
> Regards,
> Holger
>
br
Matthias
--
Don't Panic
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
BackupPC-devel mailing list
BackupPC-devel@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-devel
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
