Re: dump larger than available tape space

mptype configuration in amanda.conf. As suggested in the docs, the value should be set to something reasonable such as 1/10th of the virtual tape size. Thanks again to the Amanda community!! On Mon, 2006-04-17 at 14:52 +0100, Anne Wilson wrote: > On Monday 17 April 2006 06:45, David Leangen wr

dump larger than available tape space

I finally noticed some log files that I never before noticed existed. Apparently, my backup is larger than my tape space. But, shouldn't it span multiple tapes? If I'm not mistaken, this is what happened in earlier versions. I suppose that this explains why my backup suddenly fails now for 2.5.0

Re: Could not open index directory "bla"

> The index would not be created unless a backup had succeeded. > Have you ever succeeded in backing up this DLE? If not, > the problem is likely elsewhere. > No, since I have updated to 2.5.0, I have not. But this is the only error or warning message that I could find. Any ideas where I could

Could not open index directory "bla"

I'm still not able to backup one of my local networked hosts. The only problem I can find in the logs is this: could not open index directory "/usr/adm/amanda/daily/index/host/_home/" Could this be a cause of my problems? I am running the process from my backup server like so: $root: sudo -

Re: Size of holding disk when backing up to HDD

Thank you! I'm still having trouble with my backup on a particular client, but it may be due to another issue... So, I'll start another thread. On Sun, 2006-04-16 at 22:16 -0500, Frank Smith wrote: > David Leangen wrote: > > Hello! > > > > I am backing up to di

Size of holding disk when backing up to HDD

Hello! I am backing up to disk. I thought I put away enough holding space, but apparently not. I get the following warning. WARNING: holding disk /data: only 91831964 KB free (104857600 KB requested) How important is this? Am I taking a big performance hit because of this? Or can I ignore this

A few glitches upgrading to 2.5

Hello! I am working through getting things to work as before with 2.5. One of my hosts is now working correctly, though I had to make some changes to my firewall. I'll discuss this point below. Another host is still causing me problems. The only hint I can find is this, in the amtrmidx log file

Re: Cannot seek to 0: Bad file descriptor

> So this is not the cause of your trouble. > What exactly is the error message that you get for those clients? Hmmm... To recap the problem: backups from my networked machines are not being received by my amanda host since I've updated. I'll dig a bit deeper to see if I can see anything else

Re: Cannot seek to 0: Bad file descriptor

Thank you for the tips. Reply inline. On Tue, 2006-04-04 at 11:33 +0200, Paul Bijnens wrote: > On 2006-04-04 10:48, David Leangen wrote: > > sendsize: debug 1 pid 18503 ruid 503 euid 503: start at Tue Apr 4 > > sendsize[18505]: argument list: /bin/gtar --create --file /dev/null

Cannot seek to 0: Bad file descriptor

Hello! I just upgraded to 2.5.0. Good job!! I am having some problems with my network machines (local machine is ok). This is an extract from my sendsize file: sendsize: debug 1 pid 18503 ruid 503 euid 503: start at Tue Apr 4 17:21:14 2006 sendsize: version 2.4.5 sendsize[18505]: time 0.006

RE: Which ports to open in which direction...

> > http://wiki.zmanda.com/index.php/Configuration_with_iptables > > How does the ip_conntrack_amanda kernel module fits in here? > I think that just using that module simplifies a lot of the setup. > > I'm not sure sure it handles amrecover connections though... Oh! Well... I never even notic

RE: Which ports to open in which direction...

Hello, Kevin, > does your current setup work for you? I guess it should work > most of the time. In your case, it'll fail when it couldn't find an > open port in tcp 5:50100 or in udp 700:710. Actually, I haven't yet had time to see this through all the way. I was hoping that the docs would

Re: Which ports to open in which direction...

Thanks! > There is a document called PORT.USAGE. Available in the source > "docs" directory or at amanda.org. Actually, the precise URL is: http://www.amanda.org/docs/portusage.html Ok, well, I've tried to decipher the doc, but I'm not quite sure about a few things. I started writing a s

Which ports to open in which direction...

Hello! I'm having some trouble getting data from a remote host. Amanda works fine on the local network, just not remotely. I believe that the problem is due to my firewall, so I'm hoping that somebody can explain which ports need to be opened in which direction (unless there is doc somewhere tha

Re: Problems with canonical names from an ADSL provider

Florian, Jon, > > then why not define an entry in your hosts file on the client > > of the form > When using /etc/hosts, make sure you /etc/nsswitch.conf file > has something like: > > hosts: files dns Thanks! That was simple and it did the trick. I now understand better how the l

Problems with canonical names from an ADSL provider

Hello! This may be slightly beyond the scope of Amanda, but I thought I'd try asking anyway... Both my Amanda server and (one) backup host are connected to the Internet via ADSL. It seems that when Amanda on the backup host does a DNS lookup for my Amanda server, it sees something like: [EMAI

Re: about --with-tcpportrange --with-udpportrange

Just make sure that the ports are not already in use. Check your /etc/services file for "usually" reserved ports. Also try: # netstat -a and note which ports are being used already. Ports that are defined in /etc/services will be listed by name, while ports not defined in the file will be l

Re: File owner changed upon recovery

Thank you for the quick replies! I am using gnu-tar. When I recover files, the owner of certain >>files is changed. Of course, this is not good... Are you using root to recover ? Yes. Are you waiting until the restore process is complete before coming to this conclusion? Yes. Are y

File owner changed upon recovery

Hello! I noticed a strange thing... I am using gnu-tar. When I recover files, the owner of certain files is changed. Of course, this is not good... Any ideas why this happens? Thanks!

Re: ACLs in inode #bla won't be dumped

Thanks again for all your help. Comments inline. Well, I guess I'm convinced to try out tar Setting up tar was a snap, and there were no errors! One more perhaps silly question, but just something I'd like to verify... I assume that the tar program is run on the client machine, so that mea

RE: Amanda/firewall --with-portrange

I recently had similar issues. Look for a post in the archives about 2 weeks ago that discussed the same topic. A few people gave very helpful replies already that should apply in your case, too. Brief summary: - --with-tcp-portrange is not needed - you must configure the same values on both c

Re: ACLs in inode #bla won't be dumped

Well, I guess I'm convinced to try out tar, but not to play the devil's advocate, I'm just curious... I don't (didn't) use tar at Purdue, in general, because it > changes the access time on the files it backs up. That's a > very bad thing. Why is this such a bad thing? If we suppose that (

Re: ACLs in inode #bla won't be dumped

Interesting... Ok, so I tried a few things, but it seems that things are only getting worse... Ok, I'll check that out. Maybe it has something to do with SELinux... Good possibility. One of the first things a "secure" unix system generally does is remove the notion of a "super-user". A

RE: ACLs in inode #bla won't be dumped

Thank you for all the replies! Comments inline... > >sendbackup : time xxx.xxx : normal(|) DUMP+ ACLs in inode #xxx wont't be > >dumped sendbackup : time xxx.xxx : index tee cannot write [Broken pipe] > Offhand, it sounds like a permissions problem but what do I know? > Just a WAG, perhaps some

ACLs in inode #bla won't be dumped

Hello! I am getting something like the following in my logs, and somehow it doesn't seem right... sendbackup : time xxx.xxx : normal(|) DUMP+ ACLs in inode #xxx wont't be dumped sendbackup : time xxx.xxx : index tee cannot write [Broken pipe] Any ideas what all this about? Thanks! Dave

RE: Compilation quirks

Thanks for the tips! > I've not had to specify portranges (no firewall), but IIRC the comments > on the list have said both the client and the server must be configured > similarly. > Shouldn't be needed, just use tcpportrange (and udpportrange if needed).

RE: Compilation quirks (was: Problems with port ranges)

> Is your config.site file affecting your configure at all? Other than the --without-server option, the other options seem to be working... Cheers, Dave

Re: Compilation quirks

Just for the archives, in case anybody else has the same problem... > I compiled both my client and server with the options: > > --with-portrange=5,50100 --with-udpportrange=512,520 > > > However, when I run amdump, on my client machine, apparently > > it is attempting to use a di

Compilation quirks (was: Problems with port ranges)

Just out of curiosity... Is this the right place to be asking questions about compilation? Or should I be doing that on the dev list? Also... I noticed another quirk when compiling. If I put the following in my config.site file, I get compilation errors: NO_SERVER_MODE=true However, if

Compilation quirks (was: Problems with port ranges)

Just out of curiosity... Is this the right place to be asking questions about compilation? Or should I be doing that on the dev list? Also... I noticed another quirk when compiling. If I put the following in my config.site file, I get compilation errors: NO_SERVER_MODE=true However, if

Problems with port ranges

Hello! I compiled both my client and server with the options: --with-portrange=5,50100 --with-udpportrange=512,520 However, when I run amdump, on my client machine, apparently it is attempting to use a different port (see log file below). Is there something I'm doing wrong? Thank yo