BackupPC-users

[BackupPC-users] exclude file problem-- its fine now

2009-08-01 06:15:10
Subject: [BackupPC-users] exclude file problem-- its fine now
From: "Benedict simon" <simon AT kmun.gov DOT kw>
To: "Holger Parplies" <wbppc AT parplies DOT de>
Date: Sat, 1 Aug 2009 13:14:51 +0300 (AST)
> Hi,
>
> Adam Goryachev wrote on 2009-07-31 18:11:47 +1000 [Re: [BackupPC-users]
> exclude file problem]:
>> Benedict simon wrote:
>> > Dear All,
>> >
>> > I am new to backuppc [...]
>
> are you sure? My mail folder seems to remember you posting here
> occasionally
> for over a year ;-).
>
sorry for late reply
yes u r right . im sorry for mentioning new.
actually i was jus in the pahes of implementing backuppc and even got a
server n tested out one or 2 machins quite sometime back but had to phase
of the project since i was tranferred to a our remote branch office for
over a year
now i am back to our HO and started again fresh with backup pc
i did backup 2 windows based XP pcs and had a query with 2 linux machines
about the exclude

now you solution about the exclude worked jus great without any hitch
thnks a million
but the earlier solution by adam specifying the rsync arguments did not
work . infact enitre backup was failing

really once again apprecite and thanks so muc.
i m staill now getting more deeper into backup pc with other options


regards

simon

>> > [...] how i could exclude the directory
>> > "/var/named/chroot/proc/
>> > since i dont wanna backup the proc directory
>> >
>> > part of my pc conf file is here below
>> >
>> > $Conf{RsyncShareName} = [
>> >   '/home',
>> >   '/etc',
>> >   '/var/mail',
>> >   '/var/named',
>> >   '/var/www/html
>> >
>> > $Conf{BackupFilesExclude} = {
>> >         '*' => [
>> >   '/var/named/chroot/proc'
>> > ]
>> > };
>
> Just for completeness, the excludes are relative to the share name. You
> would
> want
>
>       $Conf{BackupFilesExclude} = {
>           '/var/named' => [
>               '/chroot/proc'
>           ]
>       };
>
> or
>
>       $Conf{BackupFilesExclude} = {
>           '*' => [
>               '/chroot/proc'
>           ]
>       };
>
> What you had before would have in fact excluded (among others)
> '/var/named/var/named/chroot/proc', had that existed.
>
>> Personally, I make the following change instead:
>> $Conf{RsyncArgs} = [
>>             '--numeric-ids',
>>             '--perms',
>>             '--owner',
>>             '--group',
>>             '--devices',
>>             '--links',
>>             '--times',
>>             '--block-size=2048',
>>             '--recursive',
>>          '--checksum-seed=32761',
>>          '--one-file-system',
>>          '-D',
>>          '--bwlimit=64',
>> ];
>
> You should change '--devices' to '-D' instead of adding '-D', but that's
> probably only cosmetic. '--bwlimit' and '--checksum-seed' are really
> unrelated
> to the matter of excludes. You may or may not want to --bwlimit your
> transfer
> - that totally depends on your circumstances. As for --checksum-seed, it
> introduces the possibility of leaving pool file corruption undetected (or
> rather of linking to corrupt pool files instead of making a new correct
> copy
> of the file). It is off by default, which, I believe, is a good choice
> because
> it is conservative. You can turn it on if you want - many people do - but
> you
> should be advised that it *is* a tradeoff. You are introducing a margin of
> error, if only a small one, and you should be aware of that.
>
>> ie, remove the backupfilesexclude, and instead set rsyncargs, in
>> particular, the option that is useful here is "--one-file-system"
>> because any proc will always be a different filesystem.
>
> ... as will any NFS mounts or temporary local mounts (USB disks, CDROMs,
> ...),
> which you would typically also want to exclude from your backups. You
> might
> even have sysfs mounted on /var/named/chroot/sys or udev on
> /var/named/chroot/dev (which you also wouldn't want to backup). Generally,
> backup sets seem to map well to (lists of) file systems, though your
> physical
> file system layout may differ from what you'd logically prefer to choose
> for
> good reasons (eg. /var/named/chroot is really an independant FS, but you
> might
> want to hardlink to files on /, so you may have kept it on your root
> partition). So, there are good reasons for using --one-file-system, and
> you may
> still need BackupFilesExclude and/or BackupFilesOnly to fully describe
> your
> backup set. And, as always, your requirements (or preferences) may differ
> from
> mine.
>
>> However, if you
>> have a number of different mountpoints (different drives) then you will
>> need to specify each mount point you need to backup in RsyncShareName.
>
> I believe it is still a good exercise to be clear about what you actually
> *want* in your backups. It becomes cumbersome (and error prone) if you
> have
> many hosts with different layouts (but the same backup set), and/or
> layouts
> that change frequently.
>
> Looking at $Conf{RsyncShareName} quoted above, chances are that
> --one-file-system does exactly what you want without further changes (but
> I'm
> just guessing), and it may even guard against future surprises (USB sticks
> mounted below /home at backup time or such).
>
>> You can copy the default rsyncargs from your config.pl and add the
>> modified version to your clienthost.pl or else just modify it in the
>> config.pl directly.
>
> ... depending on whether it should be the default for all hosts or just a
> special case for one host.
>
> BackupPC 3.2.0beta0 introduced the option $Conf{RsyncArgsExtra} to allow
> for
> easier per-client modifications. So you could use
>
>       $Conf {RsyncArgsExtra} = [ '--one-file-system' ];
>
> in clienthost.pl to add the option just for that one host (provided you
> are
> using 3.2.0beta0, that is! You probably aren't now, but you might be at
> some
> point in the future).
>
>
> To sum it up, I agree with Adam's recommendation of using
> --one-file-system,
> but it's not the only way you can do it.
>
> Regards,
> Holger
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>


-- 
Network ADMIN
-------------
KUWAIT MUNICIPALITY:


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
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>
  • [BackupPC-users] exclude file problem-- its fine now, Benedict simon <=