Hi,
Mark Sopuch wrote on 22.05.2007 at 17:54:06 [Re: [BackupPC-users] incremental
doesn't stay within filter]:
> Holger Parplies wrote:
> >Maybe you could post the output of
> >
> > egrep '^ *\$Conf *\{Smb' config.pl pc/gromit.pl | grep -v Passwd
> >
> >
> super-user@@tomato - /etc/BackupPC >egrep '^ *\$Conf *\{Smb' config.pl
> pc/gromit.pl | grep -v Passwd
> config.pl:$Conf{SmbShareName} = [
ok, my fault :-).
> >or
> > pcregrep '^\s*\$Conf\s*\{Smb(?!SharePasswd)' config.pl pc/gromit.pl
> >
> >
> super-user@@tomato - /etc/BackupPC >pcregrep '^\s*\$Conf\s*\{Smb(?)'
> config.pl pc/gromit.pl
I guess your shell ate up the important part of the negative lookahead :).
> Username change between backups is my doing. I changed it to instead of
> running as my elevated account to use the dedicated backup account.
Ok, so that explains that part.
> I also ran the level 1 incremental several times and pruned the backup
> data and logs in between each attempt. I did this to easily see if the
> incremental polluted the browse tree with stuff from outside of the
> filter. I guess I could have just used the Xfer logs alone for that.
Hmm, so you did not re-run the full backup? What I'm still wondering about
is why the filter worked with that one. Maybe a 'C$' key in the
BackupFilesOnly hash at that point which later changed to 'c' or 'c$'?
Not that it's of much importance at this point, except maybe for peace of
mind.
> It'd be great to see a safer version of a backup expunger in BackupPC
> than my hand in a shell.
I agree with that. Some day I'll write something like that ...
> I suspect my actions could have implication into deduplicated data masters
> in that backup becoming unavailable would it? (I haven't studied the dedupe
> aspect yet)
No, that should be fine. Files you deleted that are still present in other
backups are in fact not deleted from disk (as there are still hard links to
the same data). Files that are not present in other backups will be deleted
on the next BackupPC_nightly run (because the pool files have a link count
of 1, meaning they are not referenced from a backup, only from the pool).
> I will probably need to confirm for myself the combinations of c, C, c$,
> C$ for support to actually see where BackupPC or indeed smbclient get
> fussy - or not.
BackupPC uses the share name to index the hash, so it needs to be exactly
identical. Apparently, you can also use a key of '*' in BackupFilesOnly and
BackupFilesExclude meaning "these apply for all shares that don't have an
explicit setting".
I don't know if the SMB protocol differentiates between 'c', 'C', 'c$' and
'C$'. My guess would be that it's case insensitive.
> Spotting the empty $filelist command arg value when filters are expected
> to be applied and finding a target share and filter share of different
> names creates the situation. Is that the main lesson here?
I guess so.
Regards,
Holger
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/backuppc-users
http://backuppc.sourceforge.net/
