Re: Tape removed with amrmtape but amcheck complains
Well, an attempt to load the tape drive from slot 7 gives an error: -bash-3.00$ mtx -f /dev/sg3 load 7 mtx: Request Sense: Long Report=yes mtx: Request Sense: Valid Residual=no mtx: Request Sense: Error Code=70 (Current) mtx: Request Sense: Sense Key=Aborted Command mtx: Request Sense: FileMark=no mtx: Request Sense: EOM=no mtx: Request Sense: ILI=no mtx: Request Sense: Additional Sense Code = 08 mtx: Request Sense: Additional Sense Qualifier = 00 mtx: Request Sense: BPV=no mtx: Request Sense: Error in CDB=no mtx: Request Sense: SKSV=no MOVE MEDIUM from Element Address 7 to 81 Failed -bash-3.00$ On Fri, Feb 15, 2008 at 12:08 AM, FL <[EMAIL PROTECTED]> wrote: > > > On Thu, Feb 14, 2008 at 4:29 PM, Jon LaBadie <[EMAIL PROTECTED]> wrote: > > > On Thu, Feb 14, 2008 at 01:28:52PM -0500, FL wrote: > > > AMANDA is complaining about a tape (Daily07) that has been removed > > from > > > the database: > > > > Did that drop the number of active tapes in the tapelist > > file below the tapecycle value? > > > It did -- I changed that. Still the same mtx error. > > > > > > > > > -bash-3.00$ amcheck Daily > > > Amanda Tape Server Host Check > > > - > > > Holding disk /var/lib/amanda/holdingdisk: 60351844 KB disk space > > available, > > > that's plenty > > > amcheck-server: fatal slot 7: mtx: Request Sense: Long Report=yes > > > ERROR: new tape not found in rack > > >(expecting a new tape) > > > > This is typically the message seen when the tapelist does > > not contain at least tapecycle number of active tapes. > > > > Now it reports this error: > Amanda Tape Server Host Check > - > Holding disk /var/lib/amanda/holdingdisk: 60352244 KB disk space > available, that's plenty > amcheck-server: fatal slot 7: mtx: Request Sense: Long Report=yes > ERROR: label Daily11 or new tape not found in rack >(expecting tape Daily11 or a new tape) > > > > > > ... > > > > > > This is the status from mtx: > > > > > > -bash-3.00$ mtx -f /dev/sg3 status > > > Storage Changer /dev/sg3:1 Drives, 24 Slots ( 1 Import/Export ) > > > Data Transfer Element 0:Empty > > > Storage Element 1:Full :VolumeTag=A2 > > > Storage Element 2:Full :VolumeTag=A3 > > > Storage Element 3:Full :VolumeTag=A4 > > > Storage Element 4:Full :VolumeTag=A5 > > > Storage Element 5:Full :VolumeTag=A6 > > > Storage Element 6:Full :VolumeTag=A7 > > > Storage Element 7:Full :VolumeTag=A8 > > > > Something is there. > > > > jl > > > It's not in the drive element--there is an AMANDA labelled tape > at SLOT 7 (unfortunately the bar code is one higher, but this is > immaterial). > > Now this is odd: I just labeled Daily 7, and it's not > in the tapelist: > > -bash-3.00$ more tapelist > 20080213 Daily23 reuse > 20080212 Daily14 reuse > 20080203 Daily10 reuse > 20080202 Daily09 reuse > 20080201 Daily08 reuse > 20080129 Daily06 reuse > 20080128 Daily05 reuse > 20080115 Daily04 reuse > 20080114 Daily03 reuse > 20080111 Daily02 reuse > 20080110 Daily01 reuse > 20080106 Daily11 reuse > 0 Daily22 reuse > 0 Daily21 reuse > 0 Daily20 reuse > 0 Daily19 reuse > 0 Daily18 reuse > 0 Daily17 reuse > 0 Daily16 reuse > 0 Daily15 reuse > 0 Daily13 reuse > 0 Daily12 reuse > -bash-3.00$ > > FL > > > > > > > >
Re: Tape removed with amrmtape but amcheck complains
On Thu, Feb 14, 2008 at 4:29 PM, Jon LaBadie <[EMAIL PROTECTED]> wrote: > On Thu, Feb 14, 2008 at 01:28:52PM -0500, FL wrote: > > AMANDA is complaining about a tape (Daily07) that has been removed from > > the database: > > Did that drop the number of active tapes in the tapelist > file below the tapecycle value? It did -- I changed that. Still the same mtx error. > > > > > -bash-3.00$ amcheck Daily > > Amanda Tape Server Host Check > > - > > Holding disk /var/lib/amanda/holdingdisk: 60351844 KB disk space > available, > > that's plenty > > amcheck-server: fatal slot 7: mtx: Request Sense: Long Report=yes > > ERROR: new tape not found in rack > >(expecting a new tape) > > This is typically the message seen when the tapelist does > not contain at least tapecycle number of active tapes. > Now it reports this error: Amanda Tape Server Host Check - Holding disk /var/lib/amanda/holdingdisk: 60352244 KB disk space available, that's plenty amcheck-server: fatal slot 7: mtx: Request Sense: Long Report=yes ERROR: label Daily11 or new tape not found in rack (expecting tape Daily11 or a new tape) > > ... > > > > This is the status from mtx: > > > > -bash-3.00$ mtx -f /dev/sg3 status > > Storage Changer /dev/sg3:1 Drives, 24 Slots ( 1 Import/Export ) > > Data Transfer Element 0:Empty > > Storage Element 1:Full :VolumeTag=A2 > > Storage Element 2:Full :VolumeTag=A3 > > Storage Element 3:Full :VolumeTag=A4 > > Storage Element 4:Full :VolumeTag=A5 > > Storage Element 5:Full :VolumeTag=A6 > > Storage Element 6:Full :VolumeTag=A7 > > Storage Element 7:Full :VolumeTag=A8 > > Something is there. > > jl It's not in the drive element--there is an AMANDA labelled tape at SLOT 7 (unfortunately the bar code is one higher, but this is immaterial). Now this is odd: I just labeled Daily 7, and it's not in the tapelist: -bash-3.00$ more tapelist 20080213 Daily23 reuse 20080212 Daily14 reuse 20080203 Daily10 reuse 20080202 Daily09 reuse 20080201 Daily08 reuse 20080129 Daily06 reuse 20080128 Daily05 reuse 20080115 Daily04 reuse 20080114 Daily03 reuse 20080111 Daily02 reuse 20080110 Daily01 reuse 20080106 Daily11 reuse 0 Daily22 reuse 0 Daily21 reuse 0 Daily20 reuse 0 Daily19 reuse 0 Daily18 reuse 0 Daily17 reuse 0 Daily16 reuse 0 Daily15 reuse 0 Daily13 reuse 0 Daily12 reuse -bash-3.00$ FL > > >
Re: 2.6.0b2 amrecover question
Your xinetd config doesn't have the correct path for the amandad binary. Jean-Louis Paul Crittenden wrote: Thanks to Jean-Louis I got backup working but when I try to do an amrecover I get another error: # amrecover AMRECOVER Version 2.6.0b2. Contacting server on maple.simpson.edu ... 220 maple AMANDA index server (2.5.2p1) ready. Setting restore date to today (2008-02-14) 200 Working date set to 2008-02-14. 501 Could not read config file /usr/local/etc/amanda/Daily/amanda.conf! amrecover> First, the amanda.conf file is in the path it says it can’t find it in. Second, why does it think my index server is 2.5.2p1? I have never upgraded before, since I am new to Amanda, so that is probably part of the reason I don’t know the answer. Paul Crittenden Computer Systems Manager Simpson College Phone: 515-961-1680 Email: [EMAIL PROTECTED]
Re: Backing up VMware-VMs
Greets, Jon ;) Jon LaBadie schrieb: > Brainstorming: > > what are vmware's scripting capabilities? http://www.vmware.com/pdf/Scripting_API_215.pdf ;) > is there a distinction between dumping an image of a current vm > versus creating an installable vm from an existing vm? errm, I am not sure if I fully understand. Could you explain in more detail or other words? > for your needs is the distinction important? > > can vmware be scripted to start and stop on demand? Yep. # vmware-cmd start # vmware-cmd stop Even "suspend" would work, if the guest OS behaves accordingly. > can it be scripted to dump either type of image above? > does it need to be running or stopped for either? > if it is already running, how do you know it is safe > to stop it? The VMs here are inactive during the night because the users leave office at the evening. That is somehow defined. At least for most of the VMs so we can assume this as a basic assumption for the given task. Stefan
Re: 2.6.0b2 amrecover question
On Thu, Feb 14, 2008 at 5:46 PM, Paul Crittenden <[EMAIL PROTECTED]> wrote: > Amazing, when you point it to the correct place it will work. So, have > the setup instructions been changed to reflect that those files are now > in /usr/local/libexec/amanda instead of /usr/local/libexec? It is in the NEWS and ReleaseNotes files, but not yet on the wiki (since it hasn't been released yet). Dustin -- Storage Software Engineer http://www.zmanda.com
RE: 2.6.0b2 amrecover question
Amazing, when you point it to the correct place it will work. So, have the setup instructions been changed to reflect that those files are now in /usr/local/libexec/amanda instead of /usr/local/libexec? Paul Crittenden Computer Systems Manager Simpson College Phone: 515-961-1680 Email: [EMAIL PROTECTED] -Original Message- From: Jean-Louis Martineau [mailto:[EMAIL PROTECTED] Sent: Thursday, February 14, 2008 4:30 PM To: Paul Crittenden Cc: amanda-users@amanda.org Subject: Re: 2.6.0b2 amrecover question Your xinetd config doesn't have the correct path for the amandad binary. Jean-Louis Paul Crittenden wrote: > > Thanks to Jean-Louis I got backup working but when I try to do an > amrecover I get another error: > > # amrecover > > AMRECOVER Version 2.6.0b2. Contacting server on maple.simpson.edu ... > > 220 maple AMANDA index server (2.5.2p1) ready. > > Setting restore date to today (2008-02-14) > > 200 Working date set to 2008-02-14. > > 501 Could not read config file /usr/local/etc/amanda/Daily/amanda.conf! > > amrecover> > > First, the amanda.conf file is in the path it says it can't find it > in. Second, why does it think my index server is 2.5.2p1? I have never > upgraded before, since I am new to Amanda, so that is probably part of > the reason I don't know the answer. > > Paul Crittenden > > Computer Systems Manager > > Simpson College > > Phone: 515-961-1680 > > Email: [EMAIL PROTECTED] > -- BEGIN-ANTISPAM-VOTING-LINKS -- NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible. Teach CanIt if this mail (ID 19924542) is spam: Spam: https://storm.simpson.edu/canit/b.php?i=19924542&m=87ca9cdf51be&c=s Not spam: https://storm.simpson.edu/canit/b.php?i=19924542&m=87ca9cdf51be&c=n Forget vote: https://storm.simpson.edu/canit/b.php?i=19924542&m=87ca9cdf51be&c=f -- END-ANTISPAM-VOTING-LINKS
Re: [Up and running] RE: SAS/Fibre Channel interface for LTO4
> Last thing to fix is: Amanda Backup Client Hosts Check WARNING: server7: selfcheck request failed: timeout waiting for ACK WARNING: server1: selfcheck request failed: timeout waiting for REP Client check: 6 hosts checked in 90.064 seconds, 2 problems foun Debian ;-) Always a problem..
Re: Tape removed with amrmtape but amcheck complains
On Thu, Feb 14, 2008 at 01:28:52PM -0500, FL wrote: > AMANDA is complaining about a tape (Daily07) that has been removed from > the database: Did that drop the number of active tapes in the tapelist file below the tapecycle value? > > -bash-3.00$ amcheck Daily > Amanda Tape Server Host Check > - > Holding disk /var/lib/amanda/holdingdisk: 60351844 KB disk space available, > that's plenty > amcheck-server: fatal slot 7: mtx: Request Sense: Long Report=yes > ERROR: new tape not found in rack >(expecting a new tape) This is typically the message seen when the tapelist does not contain at least tapecycle number of active tapes. ... > > This is the status from mtx: > > -bash-3.00$ mtx -f /dev/sg3 status > Storage Changer /dev/sg3:1 Drives, 24 Slots ( 1 Import/Export ) > Data Transfer Element 0:Empty > Storage Element 1:Full :VolumeTag=A2 > Storage Element 2:Full :VolumeTag=A3 > Storage Element 3:Full :VolumeTag=A4 > Storage Element 4:Full :VolumeTag=A5 > Storage Element 5:Full :VolumeTag=A6 > Storage Element 6:Full :VolumeTag=A7 > Storage Element 7:Full :VolumeTag=A8 Something is there. jl -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 12027 Creekbend Drive (703) 787-0884 Reston, VA 20194 (703) 787-0922 (fax)
[Up and running] RE: SAS/Fibre Channel interface for LTO4
> >> Our fibre channel devices show up as scsi devices on both Tru64 UNIX and >> HP-UX. I would expect most UNIX systems to behave the same. The >> underlying drivers are the same, as I understand it (FC being a >> serialized version of SCSI). >> >> Best wishes with the implementation. >> > > OK, now price is the next thing to decide on, which will dictate the > interface ;-) > > Thanks all. Just a quick one to say our client is now running: Dell TL2000 LTO4 and a Dell SAS5e/i card and Amanda 2.5.2p1 on Centos 5.1: [EMAIL PROTECTED] ~]# mtx -f /dev/sg4 inquiry Product Type: Medium Changer Vendor ID: 'IBM ' Product ID: '3573-TL ' Revision: '4.50' Attached Changer: No [EMAIL PROTECTED] ~]# mtx -f /dev/sg3 inquiry Product Type: Tape Drive Vendor ID: 'IBM ' Product ID: 'ULT3580-TD4 ' Revision: '74H6' Attached Changer: No They are backing up 6 servers, with the first run tonight and a 3 tape span initial trial (we haven't bother to work out a total backup capacity requirement yet ;-) ). 2.4TB should be enough to test for one run as there is no way that much to backup. Last thing to fix is: There are 7 clients, including the amanda server itself, ranging from Centos 4.1, 5.1, Suse Ent 9, 1 Windows Box and Ubuntu 6.01 LTS. We did have a bit of a panic because the card wasn't seeing the library, but turned out to be a duff cable. Lastly, we are using the chg-zd-mtx changer but had a problem in that it wouldn't find mt or mtx! Had to edit and provide full paths to them like so: [EMAIL PROTECTED] ~]# cat /usr/lib/amanda/chg-lib.sh # You may want to customize these values # These are the defaults discovered by configure when Amanda was installed. # They can be overridden here, or by by 'mt_binary' and 'mtx_binary', # respectively, in the changerfile (currently only for chg-zd-mtx.sh and # chg-manual.sh). MT=/bin/mt MTX=/usr/sbin/mtx Thanks all, and I hope this reassures someone else that the latest and greatest LTO hardware works perfectly (as expected) with Amanda. Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E [EMAIL PROTECTED] Open Source. Open Solutions(tm). http://www.suretecsystems.com/
2.6.0b2 amrecover question
Thanks to Jean-Louis I got backup working but when I try to do an amrecover I get another error: # amrecover AMRECOVER Version 2.6.0b2. Contacting server on maple.simpson.edu ... 220 maple AMANDA index server (2.5.2p1) ready. Setting restore date to today (2008-02-14) 200 Working date set to 2008-02-14. 501 Could not read config file /usr/local/etc/amanda/Daily/amanda.conf! amrecover> First, the amanda.conf file is in the path it says it can't find it in. Second, why does it think my index server is 2.5.2p1? I have never upgraded before, since I am new to Amanda, so that is probably part of the reason I don't know the answer. Paul Crittenden Computer Systems Manager Simpson College Phone: 515-961-1680 Email: [EMAIL PROTECTED] <>
Re: Backing up VMware-VMs
[EMAIL PROTECTED] schrieb: > > There is a (moderately good) howto by me and an excellent one by Paul > Bijnens at this location : http://www.amanda.org/docs/howto-wrapper.html > > I use it to shut down Lotus Domino and Oracle databases. Thanks, Bert, I know that howto, edited it by myself for putting it there ... I didn't make it clear enough that I want to know how people handle the shutting down and starting up of the various VMs. My other reply to Patrick's posting maybe explains this better. Stefan
Re: Backing up VMware-VMs
There is a (moderately good) howto by me and an excellent one by Paul Bijnens at this location : http://www.amanda.org/docs/howto-wrapper.html I use it to shut down Lotus Domino and Oracle databases. Bert "Stefan G. Weichinger" <[EMAIL PROTECTED]> 02/14/08 07:13 PM Please respond to [EMAIL PROTECTED] To "Amanda user's group" cc Subject Backing up VMware-VMs Greets to all of you, just before I try to reinvent the wheel: For a client I have to dump VMware-VMs with amanda, they should be shut down by a wrapper script (using vmware-cmd), dumped and restarted, one VM after the other. I can imagine the solution already, shouldn't be too hard, but I am curious if someone here is already successfully doing this, and if he or she might want to share knowledge or even the script itself ;) Thanks in advance, Stefan
Re: Tape removed with amrmtape but amcheck complains
On Thu, Feb 14, 2008 at 1:28 PM, FL <[EMAIL PROTECTED]> wrote: > Storage Element 7:Full :VolumeTag=A8 > I don't know why AMANDA would be complaining about slot 7, when Daily07, > which is in slot 7, was removed... It looks like it's still in the changer, or the changer is mixed up. Dustin -- Storage Software Engineer http://www.zmanda.com
RE: Backing up VMware-VMs
Patrick is right - all manner of problems can ensue trying to restore a vm backed up from the host. Treat them as physical machines and DR is much more reliable. You may get away with it but you can end up with an inoperable VM because things weren't in sync on disk, or your snapshots were being accessed or some voodoo was happenning at the time. Barry -Original Message- From: Patrick M. Hausen <[EMAIL PROTECTED]> Sent: 14 February 2008 19:54 To: Stefan G. Weichinger <[EMAIL PROTECTED]> Cc: Amanda user's group Subject: Re: Backing up VMware-VMs Hi! > For a client I have to dump VMware-VMs with amanda We install Amanda inside the VM's OS, most of the time FreeBSD. I don't see a fundamental difference from a backup point of view between a virtual and a "real" server. If you backup VMs from the outside, you are bound to copy the virtual disk in its entirety to the backup medium at every run, even with incrementals, because the virtual disk file will have changed. I can imagine implementing your scheme with rsync's capability to create incrementals of single files, not only of DLEs. With dump or tar, you are simply wasting a lot of backup media. HTH, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285
Re: Backing up VMware-VMs
Stefan G. Weichinger schrieb: > - amanda-wrapper stops, dumps and restarts every of these DLEs I mean: stops vmx, dumps DLE, starts vmx sorry ...
Re: Backing up VMware-VMs
Beste Grüsse, Patrick, von Österreich nach Deutschland ;) Patrick M. Hausen schrieb: > We install Amanda inside the VM's OS, most of the time FreeBSD. > I don't see a fundamental difference from a backup point of view > between a virtual and a "real" server. > > If you backup VMs from the outside, you are bound to copy > the virtual disk in its entirety to the backup medium at > every run, even with incrementals, because the virtual disk > file will have changed. Yes ... You are right, but I have specific needs here. This will be a very dynamic environment, with VMs created, copied, moved, and it isn't possible to install amanda to each new or copied VM (and track the IPs and hostnames and stuff ) So I think of something like - find every vmx below /mnt/vmware - create a new DLE for each corresponding directory, if it doesn't already exist - amanda-wrapper stops, dumps and restarts every of these DLEs > I can imagine implementing your scheme with rsync's capability > to create incrementals of single files, not only of DLEs. > > With dump or tar, you are simply wasting a lot of backup media. LTO-4 changer robot, no problem so far ;) Thanks, Stefan
Re: Backing up VMware-VMs
Hi! > For a client I have to dump VMware-VMs with amanda We install Amanda inside the VM's OS, most of the time FreeBSD. I don't see a fundamental difference from a backup point of view between a virtual and a "real" server. If you backup VMs from the outside, you are bound to copy the virtual disk in its entirety to the backup medium at every run, even with incrementals, because the virtual disk file will have changed. I can imagine implementing your scheme with rsync's capability to create incrementals of single files, not only of DLEs. With dump or tar, you are simply wasting a lot of backup media. HTH, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH * Vorholzstr. 25 * 76137 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 [EMAIL PROTECTED] http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285
Re: ????Cleaning up old amanda files because you've moved them, and an amplot bug
On Thursday 14 February 2008, Dustin J. Mitchell wrote: >On Thu, Feb 14, 2008 at 11:47 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: >> If its any condolence, I can't use seamonkey on this box cuz that font >> used in the address bar and such is microscopic and unreadable on a >> 1680x1050 screen even with a magnifying lens. >> >> I haven't done anything to the fonts install here other than grabbing >> some nice cursive stuff from goldenweb. >> >> Is it spec'd someplace in the build, but not screen dpi adjusted maybe? >> We are finer than the default 75 dpi here. > >I would suspect that this is an FC8 font problem, or at least a >gnuplot problem. If you run one of the gnuplot examples >(http://www.duke.edu/~hpgavin/gnuplot.html), I expect you'll have the >same problem. If not, then maybe there's a problem in amplot.gp. > >Dustin The example plot shown about 2/3rds of the way down that page shows the same relative sized font as I see it here, which is very very close to being too big, saved only by the title area being about 90% less busy than amplots output format is. A font size choice 40% of the one used would be about right for an output as busy as amplots is. Fooling around, I see it is supposed to be able to generate a .ps file too, but when output to a .ps, only the graph is drawn, nothing outside the box makes it to the display except the characters associated with the tic marks. A very tall, sparsely populated portrait format results. So there is bug #2 for amplot. I should let that dog sleep, now its barking will keep me awake nights & I'm not smart enough to fix it. I don't speak awk. :-( -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "Hardware simply does not work like the manual says and no amount of Zen contemplation will ever make you at one with a 3c905B ethernet card." - Alan Cox
Tape removed with amrmtape but amcheck complains
AMANDA is complaining about a tape (Daily07) that has been removed from the database: -bash-3.00$ amcheck Daily Amanda Tape Server Host Check - Holding disk /var/lib/amanda/holdingdisk: 60351844 KB disk space available, that's plenty amcheck-server: fatal slot 7: mtx: Request Sense: Long Report=yes ERROR: new tape not found in rack (expecting a new tape) NOTE: skipping tape-writable test NOTE: info dir /etc/amanda/Daily/curinfo/speech10.gc.cuny.edu/_home_flengyel_911_WDC1: does not exist NOTE: index dir /etc/amanda/Daily/index/speech10.gc.cuny.edu/_home_flengyel_911_WDC1: does not exist NOTE: info dir /etc/amanda/Daily/curinfo/speech10.gc.cuny.edu/_home_flengyel_911_Pentagon4: does not exist NOTE: index dir /etc/amanda/Daily/index/speech10.gc.cuny.edu/_home_flengyel_911_Pentagon4: does not exist NOTE: info dir /etc/amanda/Daily/curinfo/speech10.gc.cuny.edu/_home_flengyel_911_Pentagon2: does not exist NOTE: index dir /etc/amanda/Daily/index/speech10.gc.cuny.edu/_home_flengyel_911_Pentagon2: does not exist NOTE: info dir /etc/amanda/Daily/curinfo/speech10.gc.cuny.edu/_home_flengyel_911_Pentagon1: does not exist NOTE: index dir /etc/amanda/Daily/index/speech10.gc.cuny.edu/_home_flengyel_911_Pentagon1: does not exist NOTE: info dir /etc/amanda/Daily/curinfo/speech10.gc.cuny.edu/_home_flengyel_911_NYC4: does not exist NOTE: index dir /etc/amanda/Daily/index/speech10.gc.cuny.edu/_home_flengyel_911_NYC4: does not exist Server check took 6.477 seconds Amanda Backup Client Hosts Check Client check: 4 hosts checked in 10.062 seconds, 0 problems found (brought to you by Amanda 2.4.4p3) -bash-3.00$ -bash-3.00$ This is the status from mtx: -bash-3.00$ mtx -f /dev/sg3 status Storage Changer /dev/sg3:1 Drives, 24 Slots ( 1 Import/Export ) Data Transfer Element 0:Empty Storage Element 1:Full :VolumeTag=A2 Storage Element 2:Full :VolumeTag=A3 Storage Element 3:Full :VolumeTag=A4 Storage Element 4:Full :VolumeTag=A5 Storage Element 5:Full :VolumeTag=A6 Storage Element 6:Full :VolumeTag=A7 Storage Element 7:Full :VolumeTag=A8 Storage Element 8:Full :VolumeTag=A9 Storage Element 9:Full :VolumeTag=A00010 Storage Element 10:Full :VolumeTag=A00011 Storage Element 11:Full :VolumeTag=A00012 Storage Element 12:Full :VolumeTag=A00013 Storage Element 13:Full :VolumeTag=A00014 Storage Element 14:Full :VolumeTag=A00015 Storage Element 15:Full :VolumeTag=A00016 Storage Element 16:Full :VolumeTag=A00017 Storage Element 17:Full :VolumeTag=A00018 Storage Element 18:Full :VolumeTag=A00019 Storage Element 19:Full :VolumeTag=A00020 Storage Element 20:Full :VolumeTag=A00021 Storage Element 21:Full :VolumeTag=A00022 Storage Element 22:Full :VolumeTag=A00023 Storage Element 23:Full :VolumeTag=A00024 Storage Element 24 IMPORT/EXPORT:Full :VolumeTag=CLNA01 -bash-3.00$ I don't know why AMANDA would be complaining about slot 7, when Daily07, which is in slot 7, was removed...
Re: ????Cleaning up old amanda files because you've moved them, and an amplot bug
On Thu, Feb 14, 2008 at 11:47 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: > If its any condolence, I can't use seamonkey on this box cuz that font used > in > the address bar and such is microscopic and unreadable on a 1680x1050 screen > even with a magnifying lens. > > I haven't done anything to the fonts install here other than grabbing some > nice cursive stuff from goldenweb. > > Is it spec'd someplace in the build, but not screen dpi adjusted maybe? We > are finer than the default 75 dpi here. I would suspect that this is an FC8 font problem, or at least a gnuplot problem. If you run one of the gnuplot examples (http://www.duke.edu/~hpgavin/gnuplot.html), I expect you'll have the same problem. If not, then maybe there's a problem in amplot.gp. Dustin -- Storage Software Engineer http://www.zmanda.com
Backing up VMware-VMs
Greets to all of you, just before I try to reinvent the wheel: For a client I have to dump VMware-VMs with amanda, they should be shut down by a wrapper script (using vmware-cmd), dumped and restarted, one VM after the other. I can imagine the solution already, shouldn't be too hard, but I am curious if someone here is already successfully doing this, and if he or she might want to share knowledge or even the script itself ;) Thanks in advance, Stefan
Re: ????Cleaning up old amanda files because you've moved them, and an amplot bug
On Thursday 14 February 2008, Jean-Louis Martineau wrote: >The files are installed in /usr/local/libexec/amanda if gnuplot is found >at configure time. I got that grokked as I indicted, gnuplot wasn't installed. >I don't know why the font are big on fc8. > If its any condolence, I can't use seamonkey on this box cuz that font used in the address bar and such is microscopic and unreadable on a 1680x1050 screen even with a magnifying lens. I haven't done anything to the fonts install here other than grabbing some nice cursive stuff from goldenweb. Is it spec'd someplace in the build, but not screen dpi adjusted maybe? We are finer than the default 75 dpi here. >Jean-Louis > >Gene Heskett wrote: >> Greetings; >> >> Has amplot and friends been removed from amanda? >> >> The reason I ask is that when I got done cleaning up duplicated files here >> (I have installed and tested just about every snapshot since early >> January), I have in /usr/local/libexec, the files: >> amcat.awk >> amplot.awk >> amplot.g >> amplot.gp >> >> left, which all carry a Jan 5 date, whereas the most recently built and >> installed files all carry todays date as there we installed Amanda >> 2.6.0b2-20080213 about 15 minutes before the run this morning. >> >> Humm, I take it amplot was not being built as gnuplot wasn't installed by >> the default F8 install, which I had to do right after new years because >> something wiped LSN0 on my boot drive clean, zeroed it out. So I have >> installed gnuplot now, and it runs, but the fonts are huge, resulting in >> an unreadable display. I'll make clean, reconfigure and re-install. That >> now installed new versions of the above files in the new locations so I >> nuked the older ones. But the font used by amplot is still way too big >> and needs scaled down by 50% to be usable. >> >> So call this a bug report, amplot's font is too big and overlaps itself. >> IIRC, this has been a long standing problem here, but I can't find >> anything else to fuss about this morning. :-) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Try not to have a good time ... This is supposed to be educational. -- Charles Schulz
Re: ????Cleaning up old amanda files because you've moved them, and an amplot bug
The files are installed in /usr/local/libexec/amanda if gnuplot is found at configure time. I don't know why the font are big on fc8. Jean-Louis Gene Heskett wrote: Greetings; Has amplot and friends been removed from amanda? The reason I ask is that when I got done cleaning up duplicated files here (I have installed and tested just about every snapshot since early January), I have in /usr/local/libexec, the files: amcat.awk amplot.awk amplot.g amplot.gp left, which all carry a Jan 5 date, whereas the most recently built and installed files all carry todays date as there we installed Amanda 2.6.0b2-20080213 about 15 minutes before the run this morning. Humm, I take it amplot was not being built as gnuplot wasn't installed by the default F8 install, which I had to do right after new years because something wiped LSN0 on my boot drive clean, zeroed it out. So I have installed gnuplot now, and it runs, but the fonts are huge, resulting in an unreadable display. I'll make clean, reconfigure and re-install. That now installed new versions of the above files in the new locations so I nuked the older ones. But the font used by amplot is still way too big and needs scaled down by 50% to be usable. So call this a bug report, amplot's font is too big and overlaps itself. IIRC, this has been a long standing problem here, but I can't find anything else to fuss about this morning. :-)
Re: Test 2.6.0b2 backup failed
Paul Crittenden wrote: FAILURE DUMP SUMMARY: maple.simpson.edu /export/home/pdc/Patches RESULTS MISSING driver: FATAL schedule line 1: syntax error (bad estimated time) This is strange, can you send me the amdump.X log file and the planner.*.debug files. Jean-Louis
Re: Test 2.6.0b2 backup failed
On Thursday 14 February 2008, Paul Crittenden wrote: >This is my 3rd attempt to send this, hopefully it works. I am not going >to include the logs this time just the error. > > > >I am testing 2.6.0b2 on Solaris 9. It compiled and installed just fine. >I was able to label a tape and amcheck ran with no errors. When I try to >do an amdump I get the following error: > > > >*** THE DUMPS DID NOT FINISH PROPERLY! > > > >Hostname: maple > >Org : Maple Backup > >Config : Daily > >Date: February 13, 2008 > > > >The next tape Amanda expects to use is: a new tape. > >The next new tape already labelled is: Daily-1. > > Paul: Search for 'etimeout' and dtimeout' in your amanda.conf. It may be that you'll need to increase the amount of time it waits for a requested estimate (etimeout) to come back, and that might mean you will also need to increase the allowed 'dtimeout' variable. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) We may not return the affection of those who like us, but we always respect their good judgement.
????Cleaning up old amanda files because you've moved them, and an amplot bug
Greetings; Has amplot and friends been removed from amanda? The reason I ask is that when I got done cleaning up duplicated files here (I have installed and tested just about every snapshot since early January), I have in /usr/local/libexec, the files: amcat.awk amplot.awk amplot.g amplot.gp left, which all carry a Jan 5 date, whereas the most recently built and installed files all carry todays date as there we installed Amanda 2.6.0b2-20080213 about 15 minutes before the run this morning. Humm, I take it amplot was not being built as gnuplot wasn't installed by the default F8 install, which I had to do right after new years because something wiped LSN0 on my boot drive clean, zeroed it out. So I have installed gnuplot now, and it runs, but the fonts are huge, resulting in an unreadable display. I'll make clean, reconfigure and re-install. That now installed new versions of the above files in the new locations so I nuked the older ones. But the font used by amplot is still way too big and needs scaled down by 50% to be usable. So call this a bug report, amplot's font is too big and overlaps itself. IIRC, this has been a long standing problem here, but I can't find anything else to fuss about this morning. :-) -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) "At least they're ___EXPERIENCED incompetents"
Test 2.6.0b2 backup failed
This is my 3rd attempt to send this, hopefully it works. I am not going
to include the logs this time just the error.
I am testing 2.6.0b2 on Solaris 9. It compiled and installed just fine.
I was able to label a tape and amcheck ran with no errors. When I try to
do an amdump I get the following error:
*** THE DUMPS DID NOT FINISH PROPERLY!
Hostname: maple
Org : Maple Backup
Config : Daily
Date: February 13, 2008
The next tape Amanda expects to use is: a new tape.
The next new tape already labelled is: Daily-1.
FAILURE DUMP SUMMARY:
maple.simpson.edu /export/home/pdc/Patches RESULTS MISSING
driver: FATAL schedule line 1: syntax error (bad estimated time)
STATISTICS:
Total Full Incr.
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%) 0.00.00.0
Filesystems Taped 0 0 0
Chunks Taped 0 0 0
Avg Tp Write Rate (k/s) -- -- --
NOTES:
planner: tapecycle (1) <= runspercycle (1)
planner: Adding new disk maple.simpson.edu:/export/home/pdc/Patches.
DUMP SUMMARY:
DUMPER STATS TAPER
STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS
KB/s
-- -
-
maple.simpso -dc/Patches MISSING
---
(brought to you by Amanda version 2.6.0b2)
Paul Crittenden
Computer Systems Manager
Simpson College
Phone: 515-961-1680
Email: [EMAIL PROTECTED]
<>
Re: amreport takes long to complete - BogusMonth
Paul Bijnens wrote: On 2008-02-14 09:56, Theodotos Andreou wrote: Since a month ago I have the following problem appearing: When amdump is completed amreport takes long to complete. When it finally finishes it won't send any mail. Running amreport manually results in a mail with subject: It takes so long because the dump file contains lots of "strange" lines probably. "Strange" = not expected in the normal output of tar: Amanda collects those messages, prepends a '?' to it and displays them in the mailreport. Amanda then leaves it up to you to decide if that is bad, or harmless. Because there are so many lines, generating the report takes very long. And probably when sending the mail, it is refused by the mailserver because the message is too large. If it happens to be a full dump with many files, then the mail was too large; when it contains only an incremental dump, it is not that large, and you get the report. I always force a full backup Org DailyJob AMANDA MAIL REPORT FOR BogusMonth 0, 0 and body: *** THE DUMPS DID NOT FINISH PROPERLY! even though amstatus reports that all is OK. I even verified that the images are present with amrestore. Yes, but are all the images intact, and do they contain all the data that was on the disk? Some DLE at least flagged as "not good enough". Or maybe the filesystem containing the amdump.XX log file was full resulting in amreport not finding the normal log lines indicating a good backup. According to amstatus all DLEs have the status finish but I will try to verify some of them if they are correct It is also peculiar that the problem is intermittent, It happens most of the time but not always. I was not able to figure out what triggers it. I am using amanda 2.5.0p2 on CentOS 5. I tried to strace on the running amreport and I got some strange results: read(3, "Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/uriloader/nsDocLoader.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: Is this maybe related to: https://bugzilla.redhat.com/431879 Did you recently upgraded tar, which generates a warning for each file where se_linux context is not defined? This could be the problem. Yum logs show an upgraded tar on Jan 18 and the problems started on Jan 31. -- Best Regards Theodotos Andreou System Administrator PrimeTel PLC, Cyprus www.prime-tel.com
Re: amreport takes long to complete - BogusMonth
On 2008-02-14 09:56, Theodotos Andreou wrote: Since a month ago I have the following problem appearing: When amdump is completed amreport takes long to complete. When it finally finishes it won't send any mail. Running amreport manually results in a mail with subject: It takes so long because the dump file contains lots of "strange" lines probably. "Strange" = not expected in the normal output of tar: Amanda collects those messages, prepends a '?' to it and displays them in the mailreport. Amanda then leaves it up to you to decide if that is bad, or harmless. Because there are so many lines, generating the report takes very long. And probably when sending the mail, it is refused by the mailserver because the message is too large. If it happens to be a full dump with many files, then the mail was too large; when it contains only an incremental dump, it is not that large, and you get the report. Org DailyJob AMANDA MAIL REPORT FOR BogusMonth 0, 0 and body: *** THE DUMPS DID NOT FINISH PROPERLY! even though amstatus reports that all is OK. I even verified that the images are present with amrestore. Yes, but are all the images intact, and do they contain all the data that was on the disk? Some DLE at least flagged as "not good enough". Or maybe the filesystem containing the amdump.XX log file was full resulting in amreport not finding the normal log lines indicating a good backup. It is also peculiar that the problem is intermittent, It happens most of the time but not always. I was not able to figure out what triggers it. I am using amanda 2.5.0p2 on CentOS 5. I tried to strace on the running amreport and I got some strange results: read(3, "Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/uriloader/nsDocLoader.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: Is this maybe related to: https://bugzilla.redhat.com/431879 Did you recently upgraded tar, which generates a warning for each file where se_linux context is not defined? -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
amreport takes long to complete - BogusMonth
Since a month ago I have the following problem appearing: When amdump is completed amreport takes long to complete. When it finally finishes it won't send any mail. Running amreport manually results in a mail with subject: Org DailyJob AMANDA MAIL REPORT FOR BogusMonth 0, 0 and body: *** THE DUMPS DID NOT FINISH PROPERLY! even though amstatus reports that all is OK. I even verified that the images are present with amrestore. It is also peculiar that the problem is intermittent, It happens most of the time but not always. I was not able to figure out what triggers it. I am using amanda 2.5.0p2 on CentOS 5. I tried to strace on the running amreport and I got some strange results: read(3, "Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/uriloader/nsDocLoader.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/uriloader/nsIContentHandler.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/uriloader/nsIDocumentLoader.h: Wa"..., 4096) = 4096 read(3, "clude/webbrwsr/nsIContextMenuListener2.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/webbrwsr/nsIEmbeddingSiteWindow.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/webbrwsr/nsIEmbeddingSiteWindow2.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-li"..., 4096) = 4096 read(3, "vailable\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/widget/nsGUIEvent.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/widget/nsIAppShell.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/widget/nsIBaseWindow.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./i"..., 4096) = 4096 read(3, "ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/widget/nsIMenuBar.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/widget/nsIMenuItem.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/widget/nsIMenuListener.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4"..., 4096) = 4096 read(3, " ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/windowwatcher/nsPIWindowWatcher.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/xmlextras/nsIDOMParser.h: Warning: Cannot fgetfilecon: No data available\n ? gtar: ./ionc/environment/3.4.old/kreatel/adk/mipsel-kreatel-linux-gnu/mozilla/include/xmlextras/nsIDOMSerializer.h: Warning: Cannot fgetfilecon: No data availabl"..., 4096) = 4096 Any idea/help would be highly appreciated. -- Best Regards Theodotos Andreou System Administrator PrimeTel PLC, Cyprus www.prime-tel.com
Re: Tape Length Problems
On 2008-02-14 04:16, Nigel Allen wrote: Hi I have a client running FC6 with an HP StorageWorks DAT72 USB internal tape drive which according to the documentation can do 36G native and up to 72G compressed. We are trying to use Amanda to just back up the server so it is configured as both server and client. We ran amtapetype on it which suggested a tape size of around 32GB. [...] > FAILURE AND STRANGE DUMP SUMMARY: > mail..com.au mapper/VolGroup00-LogVol00 lev 0 FAILED [dump larger than available tape space, 53330360 KB, but cannot incremental dump new disk] Indeed 53 Gbyte backup image does not fit in 32 Gbyte tape. The disklist looks like this: > mail..com.aumapper/VolGroup00-LogVol00 high-tar > mail..com.ausda1high-tar (sidenote: when using tar, why do you use device names? not not directory names?) and current disk usage is: > FilesystemSize Used Avail Use% Mounted on > /dev/mapper/VolGroup00-LogVol00 > 225G 52G 162G 25% / > /dev/sda1 99M 11M 83M 12% /boot > tmpfs 252M 0 252M 0% /dev/shm I'm obviously missing something here - I understood that amanda would take the compression into consideration. Should I be using software compression or hardware? If software, how do I turn of compression on the tape device? I think you missed to configure the correct tapetype definition to 72 Gbyte in the experiment. Find if Amanda thinks the same about the config you changed: amgetconf DailySet1 tapetype note the output: this is the tapetype that Amanda will use; let's assume the output was "DAT72"; then try: amgetconf DailySet1 tapetype:DAT72:length And Amanda shows the output in Kilobytes. But the real solution: If you have the CPU-power, then software compression is surely better than hardware compression when using DAT72 tapes. But, make sure you have the hardware compression disabled, otherwise you actually loose 20% capacity by the dumb hw-comp algorithm on those tapedrives that expands uncompressable data. To disable hardware compression, see: http://wiki.zmanda.com/index.php/Hardware_compression When estimating, Amanda makes a dummy backup, and notices the output of tar indicating the total bytes output. For compression, it assumes a ratio learned from the previous dumps. When no history exists, Amanda assumes a ratio, that you configure in amanda.conf with the "comprate" parameter, which defaults to 0.50 (= compression to half). If this is indeed the first backup ever of that DLE (as the message says "...cannot incremental dump new disk"), then you have to figure out why Amanda thinks "53 Gbyte * comprate" is more than 32 GByte. Look carefully in the parameters like "comprate" from: amadmin DailySet1 disklist mail..com.au mapper/VolGroup00-LogVol00 For DLE's that had already some backups run, you can find out the historical data that Amanda uses to compute the comprate with: amadmin DailySet1 info somehost /some/disk -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
