RE: NFS mounted holding disk
Hi Unfortunately the NFS server is a NAS device on which I can not run amanda :-(. Now if amanda could talk NDMP I could use the tape device on the NAS server, but I would still need another box to run amanda and the data would be going in and out of this box. Still that would be better than in, out and back again :-). I would think if I had the same config on the tape server as the holding-disk server up to the tape device, then I could just run amflush on the tape server. >From: "Bort, Paul" <[EMAIL PROTECTED]> >To: "'Anthony Worrall'" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] >Subject: RE: NFS mounted holding disk >Date: Wed, 18 Apr 2001 10:32:03 -0400 >X-Scanner: exiscan *14pt4u-0004vx-00*ccNglIAG/2M* http://duncanthrax.net/exiscan/ > >Here's a bad idea for you: Install Amanda server on both the NFS server and >the tape server; Run amdump on the NFS server using whatever configuration >you'd like, but don't let it dump to tape; use the tape server to back up >the NFS server at level 0 every time; after the tape server is done, tell >the NFS server to amflush to /dev/null. It's not pretty, and restores are >cumbersome, but it would accomplish the mission. > >Of course, so would moving the tape drive(s) to the NFS server. Is that a >possibility? > > >-Original Message- >From: Anthony Worrall [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, April 18, 2001 5:17 AM >To: [EMAIL PROTECTED] >Subject: Re: NFS mounted holding disk > > > >>To: Anthony Worrall <[EMAIL PROTECTED]> >>cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] >>Subject: Re: NFS mounted holding disk >>Date: Tue, 17 Apr 2001 10:51:17 -0400 >>From: Paul Lussier <[EMAIL PROTECTED]> >>X-Scanner: exiscan *14pWpZ-BM-00*1pxFlM.Ffuc* >http://duncanthrax.net/exiscan/ >> >> >>In a message dated: Tue, 17 Apr 2001 10:42:13 BST >>Anthony Worrall said: >> >>>One reason would be the NFS server has a 1Gb interface and the clients and >>>tape server have only 100Mb. >> >>Okay, so now you're saturating the 100Mb interface on the tape server >>twice? I still don't see the advantage in this. > >That is why I would like the clients to dump directly to the holding disk >without the data going via the tape server. > >Even so give the choice between dumping to an NFS mounted holding disk and >dumping directly to tape the former seems to be faster. > > >Of course having a big holding disk on the tape server would be even better. > > >>-- >> >>Seeya, >>Paul >> >> It may look like I'm just sitting here doing nothing, >> but I'm really actively waiting for all my problems to go away. >> >> If you're not having fun, you're not doing it right! >> >> > >Anthony Worrall >The University of Reading, >Department of Computer Science, >Whiteknights, PO Box 225 >Reading, >Berkshire, UK >RG6 6AY >Tel: +44 (0)1189 318610 >Fax: +44 (0)1189 751994 >Email: [EMAIL PROTECTED] Anthony Worrall The University of Reading, Department of Computer Science, Whiteknights, PO Box 225 Reading, Berkshire, UK RG6 6AY Tel: +44 (0)1189 318610 Fax: +44 (0)1189 751994 Email: [EMAIL PROTECTED]
RE: NFS mounted holding disk
Here's a bad idea for you: Install Amanda server on both the NFS server and the tape server; Run amdump on the NFS server using whatever configuration you'd like, but don't let it dump to tape; use the tape server to back up the NFS server at level 0 every time; after the tape server is done, tell the NFS server to amflush to /dev/null. It's not pretty, and restores are cumbersome, but it would accomplish the mission. Of course, so would moving the tape drive(s) to the NFS server. Is that a possibility? -Original Message- From: Anthony Worrall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 18, 2001 5:17 AM To: [EMAIL PROTECTED] Subject: Re: NFS mounted holding disk >To: Anthony Worrall <[EMAIL PROTECTED]> >cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] >Subject: Re: NFS mounted holding disk >Date: Tue, 17 Apr 2001 10:51:17 -0400 >From: Paul Lussier <[EMAIL PROTECTED]> >X-Scanner: exiscan *14pWpZ-BM-00*1pxFlM.Ffuc* http://duncanthrax.net/exiscan/ > > >In a message dated: Tue, 17 Apr 2001 10:42:13 BST >Anthony Worrall said: > >>One reason would be the NFS server has a 1Gb interface and the clients and >>tape server have only 100Mb. > >Okay, so now you're saturating the 100Mb interface on the tape server >twice? I still don't see the advantage in this. That is why I would like the clients to dump directly to the holding disk without the data going via the tape server. Even so give the choice between dumping to an NFS mounted holding disk and dumping directly to tape the former seems to be faster. Of course having a big holding disk on the tape server would be even better. >-- > >Seeya, >Paul > > It may look like I'm just sitting here doing nothing, > but I'm really actively waiting for all my problems to go away. > >If you're not having fun, you're not doing it right! > > Anthony Worrall The University of Reading, Department of Computer Science, Whiteknights, PO Box 225 Reading, Berkshire, UK RG6 6AY Tel: +44 (0)1189 318610 Fax: +44 (0)1189 751994 Email: [EMAIL PROTECTED]
Re: NFS mounted holding disk
>To: Anthony Worrall <[EMAIL PROTECTED]> >cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] >Subject: Re: NFS mounted holding disk >Date: Tue, 17 Apr 2001 10:51:17 -0400 >From: Paul Lussier <[EMAIL PROTECTED]> >X-Scanner: exiscan *14pWpZ-BM-00*1pxFlM.Ffuc* http://duncanthrax.net/exiscan/ > > >In a message dated: Tue, 17 Apr 2001 10:42:13 BST >Anthony Worrall said: > >>One reason would be the NFS server has a 1Gb interface and the clients and >>tape server have only 100Mb. > >Okay, so now you're saturating the 100Mb interface on the tape server >twice? I still don't see the advantage in this. That is why I would like the clients to dump directly to the holding disk without the data going via the tape server. Even so give the choice between dumping to an NFS mounted holding disk and dumping directly to tape the former seems to be faster. Of course having a big holding disk on the tape server would be even better. >-- > >Seeya, >Paul > > It may look like I'm just sitting here doing nothing, > but I'm really actively waiting for all my problems to go away. > >If you're not having fun, you're not doing it right! > > Anthony Worrall The University of Reading, Department of Computer Science, Whiteknights, PO Box 225 Reading, Berkshire, UK RG6 6AY Tel: +44 (0)1189 318610 Fax: +44 (0)1189 751994 Email: [EMAIL PROTECTED]
Re: NFS mounted holding disk
Anthony Worrall <[EMAIL PROTECTED]> writes: > >From: "John R. Jackson" <[EMAIL PROTECTED]> > > > >>Using a NFS mounted holding disk doesn't seem possible ... > > > >I would consider that a feature :-). Why in the world would you drag > >a bunch of dump images across the network to an Amanda server and then > >send them back across the network, using NFS of all things, then turn > >around and drag them back a third time to finally go to tape? Ick. > > > One reason would be the NFS server has a 1Gb interface and the clients and > tape server have only 100Mb. Hi, I'd like to add a positive touch to this thread and suggest other setups: 1) NFS-mounting of everything to the NFS-Server in a "one client setup" So data is copied once from non-amanda clients to the nfs-server. The spindle parameter in the disklist can be used to control network congestion (e. g. dumping one non-amanda client in a collision domain at a time). I guess that the 1Gb/100MBit-Hub is fully switched. The drawback is that the nfs server needs to do all the software compression (if used at all). The holding disk in this setup is still on the tape (and amanda) server. 2) Remote tape Make the nfs server the amanda server and use a remote tape device (e.g. /dev/rmt0 for Linux). I'd like to hear comments if amanda supports that. Clients can use their own horsepower to do software compression. Performance for this setup depends on keeping the tape drive streaming. The speed advantage of a local holding disk might be gone, but a slow tape, clients not eating up all bandwith and a fully switched network might make this possible. 3) Move the tape to a central position and use the nfs server as amanda server with a local tape. I'd use a dedicated holding disk to maintain NFS disk performance during backups. A related idea: Hierarchies of holding disks This can make a lot of sense to backup remote company outlets with a fast LAN and a slower WAN to a centralized amanda server. One holding disk per outlet allows for consistent data backups during the night to the outlet's holding disk. You can then make use of traffic shaping on the WAN router to gracefully move the data to the headquarters amanda server during the next 24 hours. At the moment I'd implement that via a two stage setup: Each outlet has its own amanda server (with local clients) and no tape drive. The holding disk of the local configuration is backed up to the main amanda server (with tape drive). Restores are a painfull two stage process and involve sending the whole holding disk of that day over the WAN. Implementing this directly into Amanda would need more than the rewrite for Amanda 2.5, as we use "relay servers". This resembles to a certain degree the way we do SMB backups. Do some commercial products (like Tivoli or Legato) support hierarchies of holding disks?
Re: NFS mounted holding disk
>In fact I would like it if the clients could dump directly to the NFS mounted >holding disk rather than via the tape server. Seems to me a better plan would be to run amdump on the NFS server and make taper the remote piece. This keeps the single driver controlling all the pieces (and not flooding the system) and taper is the only one who has to deal with the NFS issue. >Anthony Worrall John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: NFS mounted holding disk
In a message dated: Tue, 17 Apr 2001 10:42:13 BST Anthony Worrall said: >One reason would be the NFS server has a 1Gb interface and the clients and >tape server have only 100Mb. Okay, so now you're saturating the 100Mb interface on the tape server twice? I still don't see the advantage in this. -- Seeya, Paul It may look like I'm just sitting here doing nothing, but I'm really actively waiting for all my problems to go away. If you're not having fun, you're not doing it right!
Re: NFS mounted holding disk
>To: Jim Harmon <[EMAIL PROTECTED]> >cc: [EMAIL PROTECTED] >Subject: Re: NFS mounted holding disk >Date: Fri, 13 Apr 2001 12:11:29 -0500 >From: "John R. Jackson" <[EMAIL PROTECTED]> >X-Scanner: exiscan *14o7BR-Mv-00*QV3l7VyiBh2* http://duncanthrax.net/exiscan/ > >>Using a NFS mounted holding disk doesn't seem possible ... > >I would consider that a feature :-). Why in the world would you drag >a bunch of dump images across the network to an Amanda server and then >send them back across the network, using NFS of all things, then turn >around and drag them back a third time to finally go to tape? Ick. > One reason would be the NFS server has a 1Gb interface and the clients and tape server have only 100Mb. In fact I would like it if the clients could dump directly to the NFS mounted holding disk rather than via the tape server. The only way I can think of to do this at the moment is to run amdump on each client and then run amflush on the tape server. The problem apart form managing all the configs is working out what needs to be shared and having to do the flush by hand. What would be nice is an option in the dump type to tell the client to dump directly to the holding disk. Then this information (with chunksize etc) has to be passed to the client either as command line option or as part of the protocol. >That's more or less a rhetorical question. I fully realize (especially >with universities :-) that some "unusual" configurations are attempted. > >>and I don't >>understand exactly why. amdump writes to it fine but when amflush tries >>to write to tape I get: >> >>The dumps were flushed to tape dailies02. >>*** A TAPE ERROR OCCURRED: [[writing file: Bad file number]]. > >You didn't say what version of Amanda this is, but the only reference I >see to that error message (in 2.4.2) says it comes from trying to write >to the tape. > >There should have been more messages from amflush. Did you run it with >the -f (foreground) option? If so, they went to your tty. If not, >there may be an amflush. file, or a /tmp/amanda/amflush*debug file. >It would be interesting to see what it had to say about initially opening >the tape, etc. > >I assume you ran amflush as the Amanda user, i.e. the same user that >ran amdump? > >Did it have anything interesting to say when it showed you what holding >disk areas it found? > >>It's not a bad tape or drive and if the files are on a locally mounted >>file system it's fine. > >So with everything exactly the same except the location of the holding >disk (same Amanda config, same tape drive, etc), it works? > >>Anyone else tried using remote holding disk? > >U, no. :-) > >>Jim Harmon > >John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] Anthony Worrall The University of Reading, Department of Computer Science, Whiteknights, PO Box 225 Reading, Berkshire, UK RG6 6AY Tel: +44 (0)1189 318610 Fax: +44 (0)1189 751994 Email: [EMAIL PROTECTED]
Re: NFS mounted holding disk
>Using a NFS mounted holding disk doesn't seem possible ... I would consider that a feature :-). Why in the world would you drag a bunch of dump images across the network to an Amanda server and then send them back across the network, using NFS of all things, then turn around and drag them back a third time to finally go to tape? Ick. That's more or less a rhetorical question. I fully realize (especially with universities :-) that some "unusual" configurations are attempted. >and I don't >understand exactly why. amdump writes to it fine but when amflush tries >to write to tape I get: > >The dumps were flushed to tape dailies02. >*** A TAPE ERROR OCCURRED: [[writing file: Bad file number]]. You didn't say what version of Amanda this is, but the only reference I see to that error message (in 2.4.2) says it comes from trying to write to the tape. There should have been more messages from amflush. Did you run it with the -f (foreground) option? If so, they went to your tty. If not, there may be an amflush. file, or a /tmp/amanda/amflush*debug file. It would be interesting to see what it had to say about initially opening the tape, etc. I assume you ran amflush as the Amanda user, i.e. the same user that ran amdump? Did it have anything interesting to say when it showed you what holding disk areas it found? >It's not a bad tape or drive and if the files are on a locally mounted >file system it's fine. So with everything exactly the same except the location of the holding disk (same Amanda config, same tape drive, etc), it works? >Anyone else tried using remote holding disk? U, no. :-) >Jim Harmon John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
NFS mounted holding disk
Using a NFS mounted holding disk doesn't seem possible and I don't understand exactly why. amdump writes to it fine but when amflush tries to write to tape I get: The dumps were flushed to tape dailies02. *** A TAPE ERROR OCCURRED: [[writing file: Bad file number]]. It's not a bad tape or drive and if the files are on a locally mounted file system it's fine. Anyone else tried using remote holding disk? Jim Harmon Department of Lingusitics Ohio State University
