Re: samba excludes and includes

2003-10-31 Thread Archie Warnock
Jon LaBadie wrote:
Though I've not looked at the code, it seems like enabling
the include feature would require nearly the same changes
that went into adding exclude.  Is there any reason,
aside for lack of interest in the past, that the include
feature was not added?
I wouldn't know about the implementation history, but my own use would 
actually indicate that an include capability would be more useful.  When 
I do backups, I know what directories need to be copied - they're the 
ones that have irreplaceable data in them, and I know which ones they 
are.  Seems to me that's an easier call than going through all of the 
directories on a volume and ruling out the ones that don't need to be 
backed up - and even in that case, being able to handle only a single 
exclude pattern seems counter-intuitive.  Obviously, others will have 
different needs, but it's hard to imagine why both shouldn't be available.

I'm pursuing the idea of special Samba backup shares as a hack to get 
around the lack of includes, but I'd really prefer to put my 
backup-specific details in my backup program configuration...

--
Archie
-- Archie Warnock   Internet: [EMAIL PROTECTED]
-- A/WWW Enterpriseshttp://www.awcubed.com
--   As a matter of fact, I _do_ speak for my employer.


Re: Backing up certain directories within an SMB share

2003-10-29 Thread Archie Warnock
Paul Bijnens wrote:
In other words, I've got a share called //matt/c$, but what I'd really 
like to do is have Amanda backup only the directory 
//matt/c$/Inetpub/wwwroot, instead of the actual share c$.

Is there any way to accomplish this?
What's wrong with creating an addition share on that directory?
I've got the same issue, and speaking for myself I suppose there's 
nothing wrong with that except for proliferating shares through Samba to 
do something Amanda ought to be able to do itself.

I'm not sure I understand why it's preferable to have to reconfigure my 
Samba shares every time I add a new directory that needs to be backed 
up, rather than just reconfiguring my backup program.  Is there some 
subtle benefit that I'm not understanding?

--
Archie
-- Archie Warnock   Internet: [EMAIL PROTECTED]
-- A/WWW Enterpriseshttp://www.awcubed.com
--   As a matter of fact, I _do_ speak for my employer.


Re: Amanda & Samba

2003-10-13 Thread Archie Warnock
Martin wrote:
I have the same issue and what I do is create exclude lists for Windows
clients. That way you can exclude entire directories and certain files.
Specify them in amanda.conf . For example:
I'll give that a try.  It would be a bit more convenient to have an 
"include" capability, since I know what directories have to be backed up 
(excluding all but the useful ones isn't quite as intuitive), but I can 
probably make this work.

Thanks.

--
Archie
-- Archie Warnock   Internet: [EMAIL PROTECTED]
-- A/WWW Enterpriseshttp://www.awcubed.com
--   As a matter of fact, I _do_ speak for my employer.


Amanda & Samba

2003-10-10 Thread Archie Warnock
It appears to me that amanda can only back up entire Samba shares - not 
individual subdirectories of the shares.  At least, I can't find a way 
to specify specific subdirectories in cases when the entire share is too 
big to back up.  Any tips on how to finesse the size issue?  I'm kinda 
resisting the notion of making each subdirectory a separate share, just 
for backup purposes...

--
Archie
-- Archie Warnock   Internet: [EMAIL PROTECTED]
-- A/WWW Enterpriseshttp://www.awcubed.com
--   As a matter of fact, I _do_ speak for my employer.


Re: Odd Samba problem

2003-08-14 Thread Archie Warnock
Jon LaBadie wrote:
If I understand it correctly, this is a limitation in the "amanda-valid"
passwords and is not correctable by quoting etc.
Ugh...  OK - thanks.

--
Archie
-- Archie Warnock   Internet: [EMAIL PROTECTED]
-- A/WWW Enterpriseshttp://www.awcubed.com
--   As a matter of fact, I _do_ speak for my employer.


Re: Odd Samba problem

2003-08-14 Thread Archie Warnock
Jon LaBadie wrote:
That appears to terminate at the octothorpe (formal name for #).
Thus your password would not be foo#bar but foo.
If I understand it correctly, this is a limitation in the "amanda-valid"
passwords and is not correctable by quoting etc.
Just to finish the thread, I managed to finesse the problem by using the 
administrator account in amandapass instead of the share owner.  Works fine.

It would be really nice to remove this limitation at some point, I would 
think.

--
Archie
-- Archie Warnock   Internet: [EMAIL PROTECTED]
-- A/WWW Enterpriseshttp://www.awcubed.com
--   As a matter of fact, I _do_ speak for my employer.


Odd Samba problem

2003-08-14 Thread Archie Warnock
I'm configuring amanda for the first time and it's almost working.  I'm 
getting a failure from amcheck on one of the two Samba shares I have set 
up in my disklist.  The only real difference I can see in the setup is 
that the password (in /etc/amandapass) for the one that fails contains a 
# character.  The password works perfectly if I log in to that share 
with smbclient - is there something I ought to know about quoting 
special characters in amandapass?

My disklist contains these:
burgundy /home comp-user-tar
burgundy //pommard/MyDocuments comp-user-tar
burgundy //maranges/PrisDocs comp-user-tar
where burgundy is the SMB server.  When I run amcheck, it has no problem 
accessing the share //maranges/PrisDocs (or with /home on burgundy) but 
fails on //pommard/MyDocuments.  The entries in /etc/amandapass look 
like this (obviously scrambled to protect real passwords):

//pommard/MyDocuments me%foo#bar
//maranges/PrisDocs metoo%foobar
Note that this command works fine:

smbclient //pommard/MyDocuments foo#bar -U me

I'm guessing that the # sign in foo#bar is being treated as the start of 
a comment when /etc/amandapass gets read.  I sure don't want to change a 
working password to get a backup, though.  What am I missing?

TIA

--
Archie
-- Archie Warnock   Internet: [EMAIL PROTECTED]
-- A/WWW Enterpriseshttp://www.awcubed.com
--   As a matter of fact, I _do_ speak for my employer.