new client backup problems--zfs?

2010-06-11 Thread myron
I added a new client to amanda and it won't back up. I don't add clients often, but I think I got everything right. I have a feeling this is because the filesystem is zfs--my first--everything else I back up is ufs. I'm going to put a ufs filesystem on the client today and see if that backs

Re: new client backup problems--zfs?

2010-06-11 Thread Brian Cuttler
Myron, You made all necesary changes to amanda.conf to allow for a gtar based dumper ? (there being no such things and zfsdump as an analog to ufsdump). What do the /tmp/amanda logs on the client tell you, are you getting through the estimate phase and failing the actual sendfile phase ? On Fri

Re: new client backup problems--zfs?

2010-06-11 Thread myron
It's been a while since I set up amanda. I didn't make any changes in amanda.conf. The only relevant line that I see in that file references dumptypes.conf. I think what you're telling me is that I should have used comp-root- tar, which uses guntar, instead of comp-root. The .rig* file tha

Re: The canary just died again

2010-06-11 Thread Dustin J. Mitchell
On Fri, Jun 11, 2010 at 12:10 AM, Gene Heskett wrote: > At the end of the install, it falls over with: > make[1]: Leaving directory `/home/amanda/amanda-3.2.0alpha.svn.3147' > bash: /usr/local/sbin/amcheck: Permission denied > > And sure enough, when I go check, amcheck is owned by root, not amand

Re: Can't recover with 2.6.1p2 client from 3.1.0 server

2010-06-11 Thread Dustin J. Mitchell
On Fri, Jun 11, 2010 at 3:49 AM, Marc Muehlfeld wrote: > header on 'KDD174' file 29 does not match expectations: got partnum '0'; > expected '1' > Got no header and data from server, check in amidxtaped.*.debug and > amandad.*.debug files on server Ah, this is completely different error, but you'

Re: Can't recover with 2.6.1p2 client from 3.1.0 server

2010-06-11 Thread Dustin J. Mitchell
On Fri, Jun 11, 2010 at 1:41 PM, Dustin J. Mitchell wrote: > Ah, this is completely different error, but you've given me enough > info to replicate and fix it.  I've attached a source-level patch that > you can apply, but the better fix is at the C level (and will be in > 3.1.1). For those follow

Re: The canary just died again

2010-06-11 Thread Gene Heskett
On Friday 11 June 2010, Dustin J. Mitchell wrote: >On Fri, Jun 11, 2010 at 12:10 AM, Gene Heskett wrote: >> At the end of the install, it falls over with: >> make[1]: Leaving directory `/home/amanda/amanda-3.2.0alpha.svn.3147' >> bash: /usr/local/sbin/amcheck: Permission denied >> >> And sure eno

Re: The canary just died again

2010-06-11 Thread Dustin J. Mitchell
On Fri, Jun 11, 2010 at 2:25 PM, Gene Heskett wrote: > Ok, but todays 3156 just fell over, same perms problem. Right, I haven't fixed it yet. > Are you sure you want to change how that works? Yes - chowning everything to amanda is actually *less* secure (since it means that someone who compromi

Re: The canary just died again

2010-06-11 Thread Gene Heskett
On Friday 11 June 2010, Dustin J. Mitchell wrote: >On Fri, Jun 11, 2010 at 2:25 PM, Gene Heskett wrote: >> Ok, but todays 3156 just fell over, same perms problem. > >Right, I haven't fixed it yet. > >> Are you sure you want to change how that works? > >Yes - chowning everything to amanda is actua

Re: amanda-backup_client conflicts with amanda-backup_server-3.1.0-1.rhel5.i386

2010-06-11 Thread Dan Locks
Yeah, I missread how dependencies are processed. Updated rpms, and a source tarball are available for download at http://www.zmanda.com/download-amanda.php Make sure you're using 3.1.0-2, and let me know how it goes. Dan On 06/08/2010 12:48 PM, Charles Curley wrote: I just did a brand new i