Re: Disaster Recovery
On Thu, 11 Mar 2004 at 10:43am, todd zenker wrote > What are the files needed for a Disaster Recovery on the backup server?? I think what you mean is what files do you need in order to save the complete current state and history of the backups, although I'm guessing as your request was overly terse. If that's right, you need: the config dirs (where your amanda.confs are) the "infofile" dirs as defined in your amanda.confs the logdirs as defined in your amanda.confs the indexdirs as defined in your amanda.confs And I think that's it. It also wouldn't hurt to grab client related files if your amanda server is also a client. Those include /etc/amanda*, and the gnutar-lists directory. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Disaster Recovery
Joshua Baker-LePain wrote: I think what you mean is what files do you need in order to save the complete current state and history of the backups, although I'm guessing as your request was overly terse. If that's right, you need: the config dirs (where your amanda.confs are) the "infofile" dirs as defined in your amanda.confs the logdirs as defined in your amanda.confs the indexdirs as defined in your amanda.confs How I deal with it is that I just "rsync" the amanda account home directory to another server periodically. If you wanted to, you could probably set it up as a daily cron job or something. --jonathan
RE: disaster recovery
if you are running a redhat machine or fedora you have: kickstart. This will automate everything
Re: Disaster recovery.
I don't use index files at all. In case of disaster, I expect to have to get a new machine and tape drive, with tons of disk, and put each tape in, reading it from start to finish (streaming) and just write each file to disk. Then, I'll be looking for the most recent 0 of each fs, and the most recent 1, etc., and doing full restores. Or are you concerned about the ability to do restores with indices on regular machines after your tape server explodes? You could perhaps rsync the index files to someplace offsite, too. -- Greg Troxel <[EMAIL PROTECTED]>
Re: Disaster recovery.
Also sprach Gene Heskett (Fri 08 Aug 02003 at 02:16:17PM -0400): > On Friday 08 August 2003 14:00, Ean Kingston wrote: > >I've been starting to work on a DRP plan here and I've run into a > > bit of a catch-22. > > > >If the amanda index (and tape in my case) server is lost and all I > > have left is the tapes. How do I rebuild new index files for my > > tapes so that I can restore? I can't just restore the last set of > > index files from the most recent backup because they would reflect > > the state of the tapes from one day earlier (wouldn't they?). > > > >I can't find a tool that I can feed the collection of tapes so that > > it will rebuild the index files. Is there such a thing. > > Not that I'm aware of, however other amanda experts may well point you > to the correct answer. > > That said, that problem bothered me too, so now my tapesize has been > reduced by about 100megs to make room, and I have a script set that > runs after amdump has been completed. It packs up all the now > unlocked stuffs from the configs and the indexes and appends them to > the end of the tape, thereby giving me the current image of that > stuff as it exists after the dump run that made this tape is > complete. > > I've been threatening to post them, but they are as yet pretty > specific to my install, needing a lot of dressing up to make them > anywhere near universal. Currently working with a changer and a DDS2 > tape drive in it. If you think they might be helpfull though, ask. I may find time to convert what you have to more generic application, should you care to share . . . -- Best Regards, mds mds resource 877.596.8237 - Dare to fix things before they break . . . - Our capacity for understanding is inversely proportional to how much we think we know. The more I know, the more I know I don't know . . . -- pgp0.pgp Description: PGP signature
Re: Disaster recovery.
On Friday 08 August 2003 14:00, Ean Kingston wrote: >I've been starting to work on a DRP plan here and I've run into a > bit of a catch-22. > >If the amanda index (and tape in my case) server is lost and all I > have left is the tapes. How do I rebuild new index files for my > tapes so that I can restore? I can't just restore the last set of > index files from the most recent backup because they would reflect > the state of the tapes from one day earlier (wouldn't they?). > >I can't find a tool that I can feed the collection of tapes so that > it will rebuild the index files. Is there such a thing. Not that I'm aware of, however other amanda experts may well point you to the correct answer. That said, that problem bothered me too, so now my tapesize has been reduced by about 100megs to make room, and I have a script set that runs after amdump has been completed. It packs up all the now unlocked stuffs from the configs and the indexes and appends them to the end of the tape, thereby giving me the current image of that stuff as it exists after the dump run that made this tape is complete. I've been threatening to post them, but they are as yet pretty specific to my install, needing a lot of dressing up to make them anywhere near universal. Currently working with a changer and a DDS2 tape drive in it. If you think they might be helpfull though, ask. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.27% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: Disaster recovery.
[offlist comment about cost of disk for reading tapes to disk] Well, keep in mind that you only need to buy the disks after your building burns down and you need new equipment. THe point is to avoid reading tapes multiple times - you never know when they are going to fail. Post-disaster, tapes become precious, and I like to get the data onto additional media the first time the head passes by the data.
Re: Disaster recovery.
On Friday 08 August 2003 19:16, Gene Heskett wrote: > >If the amanda index (and tape in my case) server is lost and all I > > have left is the tapes. How do I rebuild new index files for my > > tapes so that I can restore? I can't just restore the last set of > > index files from the most recent backup because they would reflect > > the state of the tapes from one day earlier (wouldn't they?). > > > >I can't find a tool that I can feed the collection of tapes so that > > it will rebuild the index files. Is there such a thing. > > Not that I'm aware of, however other amanda experts may well point you > to the correct answer. This has been mentioned before and what I, and a number of others do, is keep a copy of the indices, config file etc. on a different disk / server / building / planet - up to you how far you choose to go. If you use a commercial offsite service, or even a homebrew offsite service, you could also put all that data on a CD-R (or CD-RW) and put it with the tapes. -- Niall
Re: Disaster Recovery--- Thanks
Thanks Joshua. I figured that is what is needed in order to recover my backup server. I'm familiar with Tivoli Disaster Recovery. Thanks again. At 11:01 AM 3/11/2004, Joshua Baker-LePain wrote: On Thu, 11 Mar 2004 at 10:43am, todd zenker wrote > What are the files needed for a Disaster Recovery on the backup server?? I think what you mean is what files do you need in order to save the complete current state and history of the backups, although I'm guessing as your request was overly terse. If that's right, you need: the config dirs (where your amanda.confs are) the "infofile" dirs as defined in your amanda.confs the logdirs as defined in your amanda.confs the indexdirs as defined in your amanda.confs And I think that's it. It also wouldn't hurt to grab client related files if your amanda server is also a client. Those include /etc/amanda*, and the gnutar-lists directory. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University Todd E. Zenker CNE-GSFC NASA Goddard Space Flight Center Raytheon Mailstop 200.1 http://cne.gsfc.nasa.gov https://webdrive.gsfc.nasa.gov
Re: Disaster Recovery Recipe
>I'm trying to put together a procedure to recover data if the amanda >server goes down. Is there a recipe for doing this? I'm mainly >interested in reading amanda tapes without amanda. Have you read docs/RESTORE? Or www.backupcentral.com/amanda.html? Both cover how to read Amanda tapes without Amanda. >Brad John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
RE: Disaster Recovery Recipe
You should be able to read it off by catting /dev/st0 or similar; One question I'd like to add is, is it possible to store the updated indexes on the tape - I ask because in case of disaster, you'd ideally want to be able to know that you need tapes 5,6,7 and no others to bring your system back to it's last backed up state. I haven't looked really hard (and so may be totally in error), but I think that the indexes are stored underneath each configuration, and only updated after a backup (which is fair enough). Can these indexes be written to tape as well, meaning that from the last backup tape, it should be possible to get amanda to tell you which tapes you exactly which tapes you need? Cheers, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bradley Glonka Sent: Thursday, 11 January 2001 00:12 To: [EMAIL PROTECTED] Subject: Disaster Recovery Recipe Hi There, I'm trying to put together a procedure to recover data if the amanda server goes down. Is there a recipe for doing this? I'm mainly interested in reading amanda tapes without amanda. Thanks Brad
RE: Disaster Recovery Recipe
Chris, Following that line of thinking, you would almost want to append the indexes to the end of the tape. This is a bad idea, mainly because of the word 'append', which means different things to different drives and OSes, to put it nicely. If you can't append, you could write your indexes to a separate tape, as a separate backup set. This would work, but has a lot of hardware overhead. You really just care about what level on what disk on what date, right? There is an option to print a tape label after the backup has completed successfully. My favorite size of label is 8.5" by 11". You might find an A4-sized label. It doesn't fit on a tape very well, but if you leave a cheap printer (finally, a use for injets!) plugged into your tape server, and have it print a one-page label every night, you will have the recovery list you're looking for without major hacking. (And a hard-copy record that you're doing backups, and a fast way to find the right tape for user file recovery, and more paperwork to archive (or burn) at the end of the year.) Hope this helps, Paul -Original Message- From: Chris Herrmann [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 10, 2001 4:17 PM To: 'Bradley Glonka'; [EMAIL PROTECTED] Subject: RE: Disaster Recovery Recipe You should be able to read it off by catting /dev/st0 or similar; One question I'd like to add is, is it possible to store the updated indexes on the tape - I ask because in case of disaster, you'd ideally want to be able to know that you need tapes 5,6,7 and no others to bring your system back to it's last backed up state. I haven't looked really hard (and so may be totally in error), but I think that the indexes are stored underneath each configuration, and only updated after a backup (which is fair enough). Can these indexes be written to tape as well, meaning that from the last backup tape, it should be possible to get amanda to tell you which tapes you exactly which tapes you need? Cheers, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Bradley Glonka Sent: Thursday, 11 January 2001 00:12 To: [EMAIL PROTECTED] Subject: Disaster Recovery Recipe Hi There, I'm trying to put together a procedure to recover data if the amanda server goes down. Is there a recipe for doing this? I'm mainly interested in reading amanda tapes without amanda. Thanks Brad
Re: Disaster Recovery Recipe
>... Can these indexes be written to tape as well ... That's a part of the taper rewrite work to be done. It will provide for a "File-1" that is written at the start of each tape and a "File-N" that is written at the end of each tape. What you put in them will be up to you, but the Amanda config/database would be a good example. >Chris John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Disaster Recovery Recipe
"Bort, Paul" wrote: > > If you can't append, you could write your indexes to a separate tape, as a > separate backup set. Or to a MO/Zip/ORB disk. You just have to cp -auv /var/lib/amanda/Set1 It may not be "vital" for the backups to save the index, but I insist on having it doubly copied to MO after each AMANDA run. You can read horror stories about lost backup databases in "Unix backup and recovery" ;-) -- Regards Chris Karakas Don´t waste your cpu time - crack rc5: http://www.distributed.net
RE: Disaster Recovery on Windows
my personal strategy is as follows: - I have Imagecast images for our 4 generic server types (NT/2000 web and db). this allows me to quickly deploy the OS and necessary applications. There are several products like Imagecast out on the market for imaging windows partitions. - change the network configurations on the box by hand - restore critical application and database files backed-up using amanda I've tested this 3 times, and actually did one real DR late one evening. And the lesson I can tell you from years of experience is to test your DR plans early and often - it will pay off when you actually have to perform one with every manager in the company calling you every minute for a status update... Matt +- Matthew Galer Senior Systems Engineer [EMAIL PROTECTED] 770-453-9001 x127 > -Original Message- > From: Jan Boshoff [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 25, 2002 3:58 PM > To: Amanda Users > Subject: Disaster Recovery on Windows > > > Hi all > > I just had a thought and would like to probe the great minds of this > list. Would anyone do a disaster recovery type of restore of a Winbox > that was backed up using smbclient?I'm currently backing up the > complete winbox, but it occured to me that I don't know how I would > restore if something happened to the Winbox that we needed to restore > the complete drive. I mean, you need to have Win installed for > smbclient to talk to it accross the network. > > Any thoughts would be helpful! > Thanks again! > Jan > > -- > > > Jan Boshoff > PhD Student, Chemical Engineering > Univ. of Delaware, DE USA > www.che.udel.edu/research_groups/nanomodeling > > > >
RE: Disaster Recovery on Windows
Backup only the data. Keep a copy of the install CDs and install instructions on site and off site. Practice your re-install. (We can re-install a box in under four hours with Citrix and all apps.) > -Original Message- > From: Jan Boshoff [mailto:[EMAIL PROTECTED]] > Sent: Monday, February 25, 2002 3:58 PM > To: Amanda Users > Subject: Disaster Recovery on Windows > > > Hi all > > I just had a thought and would like to probe the great minds of this > list. Would anyone do a disaster recovery type of restore of a Winbox > that was backed up using smbclient?I'm currently backing up the > complete winbox, but it occured to me that I don't know how I would > restore if something happened to the Winbox that we needed to restore > the complete drive. I mean, you need to have Win installed for > smbclient to talk to it accross the network. > > Any thoughts would be helpful! > Thanks again! > Jan > > -- > > > Jan Boshoff > PhD Student, Chemical Engineering > Univ. of Delaware, DE USA > www.che.udel.edu/research_groups/nanomodeling > > > >
RE: Disaster Recovery on Windows
> > -Original Message- > > From: Jan Boshoff [mailto:[EMAIL PROTECTED]] > > I just had a thought and would like to probe the great minds of this > > list. Would anyone do a disaster recovery type of restore of a Winbox > > that was backed up using smbclient?I'm currently backing up the > > complete winbox, but it occured to me that I don't know how I would > > restore if something happened to the Winbox that we needed to restore > > the complete drive. I mean, you need to have Win installed for > > smbclient to talk to it accross the network. > > Well, my method is, err, non-standard to say the least, but it's *very* nice... None of my users run Windows natively (well, OK, one does, but he's the boss). They all run Windows in VMware on Linux. All user data is kept on their Linux partitions (which Windows/VMware can see transparently), and backed up via standard Amanda. The "C" drive for the Windows "boxes" is a 700MB file (for Win2K -- 400MB for NT4) that I keep a copy of on our RAID. When a Windows "box" hoses itself, a complete reinstall is a 80 second 'cp' away. :) Oh, and did I mention that the Windows "boxes" can't see the net at large, and so are largely safe from the fun of virus infections? It won't work for everybody, and VMware (the company) is getting annoyingly inflexible about their licensing terms and fees, but it does work *very* well for us. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Disaster Recovery on Windows
At 15:58 25-02-2002 -0500, Jan Boshoff wrote: >Hi all > >I just had a thought and would like to probe the great minds of this >list. Would anyone do a disaster recovery type of restore of a Winbox >that was backed up using smbclient?I'm currently backing up the >complete winbox, but it occured to me that I don't know how I would >restore if something happened to the Winbox that we needed to restore >the complete drive. I mean, you need to have Win installed for >smbclient to talk to it accross the network. I have thought about but not yet implemented anything so be advised: This is thought-stuff ;) Use a regular win98 (or perhaps toms rtbt) bootfloppy to partition and format filesystem (not NTFS - but you could convert to NTFS later). Use toms RTBT http://www.toms.net/rb/ to boot a micro linux and mount the filesystem with network support to retrive the image from the server. Toms RTBT has a small tar and gzip that could extract the image. Be sure to have the boot sector backuped up using dd (also on toms RTBT). As I said, not tested yet but I think it should work. If you test something like this please post your findings. best, Kasper
Re: Disaster recovery and amanda-2.6.0b1
On Jan 13, 2008 2:25 PM, Gene Heskett <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] amanda-2.6.0b1-20080111]# su amanda -c "amcheck Daily" > bash: /usr/local/sbin/amcheck: Permission denied > [EMAIL PROTECTED] amanda-2.6.0b1-20080111]# su - amanda > [EMAIL PROTECTED] ~]$ ls > amanda-2.5.2p1-20070713 amanda-2.5.2p1-20070727 > amanda-2.6.0b1-20080111 bacula-2.0.3-1.src.rpm Mail > amanda-2.5.2p1-20070713.tar.gz amanda-2.5.2p1-20070727.tar.gz > amanda-2.6.0b1-20080111.tar.gz delete_old_debug.diff > amanda-2.5.2p1-20070720 amanda-2.5.2p1-20071101 amandahosts > fix-3hole.ps > amanda-2.5.2p1-20070720.tar.gz amanda-2.5.2p1-20071101.tar.gz > amplot-2.5.1.diff gh.cf > [EMAIL PROTECTED] ~]$ amcheck Daily > -bash: /usr/local/sbin/amcheck: Permission denied Perhaps I'm not seeing it here, but what are the permissions on /usr/local/sbin/amcheck? And what is the date -- was it really just installed, or did something go wrong with the install script that you didn't notice? I also notice that gh.cf doesn't do 'make install' . You may also want to add some kind of error handling to the ./configure line: ./configure || exit 1 Dustin -- Storage Software Engineer http://www.zmanda.com
Re: Disaster recovery and amanda-2.6.0b1
On Sunday 13 January 2008, Dustin J. Mitchell wrote: >On Jan 13, 2008 2:25 PM, Gene Heskett <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] amanda-2.6.0b1-20080111]# su amanda -c "amcheck Daily" >> bash: /usr/local/sbin/amcheck: Permission denied >> [EMAIL PROTECTED] amanda-2.6.0b1-20080111]# su - amanda >> [EMAIL PROTECTED] ~]$ ls >> amanda-2.5.2p1-20070713 amanda-2.5.2p1-20070727 >> amanda-2.6.0b1-20080111 bacula-2.0.3-1.src.rpm Mail >> amanda-2.5.2p1-20070713.tar.gz amanda-2.5.2p1-20070727.tar.gz >> amanda-2.6.0b1-20080111.tar.gz delete_old_debug.diff >> amanda-2.5.2p1-20070720 amanda-2.5.2p1-20071101 >> amandahosts fix-3hole.ps >> amanda-2.5.2p1-20070720.tar.gz amanda-2.5.2p1-20071101.tar.gz >> amplot-2.5.1.diff gh.cf >> [EMAIL PROTECTED] ~]$ amcheck Daily >> -bash: /usr/local/sbin/amcheck: Permission denied > >Perhaps I'm not seeing it here, but what are the permissions on >/usr/local/sbin/amcheck? And what is the date -- was it really just >installed, or did something go wrong with the install script that you >didn't notice? An ls -l shows the path and name of that file only in red, all the others look normal. [EMAIL PROTECTED] amanda-2.6.0b1-20080111]# ls -l /usr/local/sbin/am* -rwxr-xr-x 1 amanda disk 15489 2008-01-13 14:04 /usr/local/sbin/amaddclient -rwxr-xr-x 1 amanda disk 83624 2008-01-13 14:04 /usr/local/sbin/amadmin -rwxr-xr-x 1 amanda disk 3205 2008-01-13 14:04 /usr/local/sbin/amaespipe -rwsr-x--- 1 root disk 113204 2008-01-13 14:04 /usr/local/sbin/amcheck -rwxr-xr-x 1 amanda disk 1982 2008-01-13 14:05 /usr/local/sbin/amcheckdb -rwxr-xr-x 1 amanda disk 11975 2008-01-13 14:05 /usr/local/sbin/amcheckdump -rwxr-xr-x 1 amanda disk 8398 2008-01-13 14:05 /usr/local/sbin/amcleanup -rwxr-xr-x 1 amanda disk 1072 2008-01-13 14:04 /usr/local/sbin/amcrypt -rwxr-xr-x 1 amanda disk 1318 2008-01-13 14:04 /usr/local/sbin/amcrypt-ossl -rwxr-xr-x 1 amanda disk 5860 2008-01-13 14:04 /usr/local/sbin/amcrypt-ossl-asym -rwxr-xr-x 1 amanda disk 3500 2008-01-13 14:04 /usr/local/sbin/amcryptsimple etc etc Then I got to thinking that I hadn't added amanda to the group "disk" in the group file, and that fixed it right up. Now I need to fixup the disklist for 2 now missing trees, and three renamed. >I also notice that gh.cf doesn't do 'make install' . That script is run by the user amanda. One must become root to do the make install, so I have always done that separately. >You may also >want to add some kind of error handling to the ./configure line: > ./configure || exit 1 It has been known to bail out as is once or twice, so I hadn't considered it as immediately important. I probably should.. Is there anything in that config driver that I should change for 2.6.0b1? Anyway, while waiting to send this msg, I've cleaned up the errors, made a new LABEL on that 390GB Sata Hitachi deathstar after making it all one BIG partition, cleaned up the rest of the perms problems that seem to go with any new install, and it looks as it is ready for run #1. However, the rest of this system is nowhere near as fine tuned as the FC6 install I lost. I swear, every new release from fedora is rougher around the edges than the version before it. And I'll say it right here and now, Thank God and _this crew_ for amanda. In spite of losing about 110GB of stuff in the dustup, that which was important was recovered. Now, if in all the making of this install, I haven't lost access to the other drive in case I find I've missed something yet, I'll be fat(er), dumb(er) and happier. Many Thanks Dustin. >Dustin -- 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) Great Moments in History: #3 August 27, 1949: A Hall of Fame opened to honor outstanding members of the Women's Air Corp. It was a WAC's Museum.
Re: Disaster recovery and amanda-2.6.0b1
On Jan 13, 2008 9:00 PM, Gene Heskett <[EMAIL PROTECTED]> wrote: > Is there anything in that config driver that I should change for 2.6.0b1? Not that I know of. The changes to note are in the NEWS and ReleaseNotes -- in particular, some new build dependencies, lib and libexec files moved to lib/amanda and libexec/amanda, and /etc/amandates moved to /var/amanda/amandates unless you supply --with-amandates=/etc/amandates. Thanks so much for testing this. Has anyone else had a chance to take it out for a ride? Dustin -- Storage Software Engineer http://www.zmanda.com
Re: Disaster recovery and amanda-2.6.0b1
On Sunday 13 January 2008, Dustin J. Mitchell wrote: >On Jan 13, 2008 9:00 PM, Gene Heskett <[EMAIL PROTECTED]> wrote: >> Is there anything in that config driver that I should change for 2.6.0b1? > >Not that I know of. The changes to note are in the NEWS and >ReleaseNotes -- in particular, some new build dependencies, lib and >libexec files moved to lib/amanda and libexec/amanda, and >/etc/amandates moved to /var/amanda/amandates amcheck fussed about /etc/amandates until I touch'd, and chown'd the file, so that apparently wasn't moved just yet. I just checked, and I didn't spec it. >unless you supply >--with-amandates=/etc/amandates. > >Thanks so much for testing this. Has anyone else had a chance to take >it out for a ride? I'll take it out for a spin in about 2 hours by removing the # in front of it in amanda's crontab. That line: 50 0 * * * /bin/nice /GenesAmandaHelper-0.6/backup.sh Daily Fresh Newsfilm tomorrow sometime. :) I expect some failures because the backups might be bigger than the tapetype setting for /usr/pix and /usr/music when the level 0's are combined. But if she's up to form, that will self heal in a dumpcycle cycle or 3. Wish me luck & keep a couple bags of plasma handy. :) I'm particularly interested in how it handles the niceness, I'm trying to teach tar some manners but it usually most resembles a hungry Poland China Sow at pig slopping time because the niceness isn't always inherited by the scripts children. Yeah, I spent much of my preteen time on a farm in Iowa, and my first 25 years in that state. 60+ years later it still colors my speech occasionally. :) >Dustin -- Cheers Dustin, 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) People are unconditionally guaranteed to be full of defects.
Re: Disaster recovery and amanda-2.6.0b1
On Sunday 13 January 2008, Dustin J. Mitchell wrote: >On Jan 13, 2008 9:00 PM, Gene Heskett <[EMAIL PROTECTED]> wrote: >> Is there anything in that config driver that I should change for 2.6.0b1? > >Not that I know of. The changes to note are in the NEWS and >ReleaseNotes -- in particular, some new build dependencies, lib and >libexec files moved to lib/amanda and libexec/amanda, and >/etc/amandates moved to /var/amanda/amandates unless you supply >--with-amandates=/etc/amandates. > >Thanks so much for testing this. Has anyone else had a chance to take >it out for a ride? > >Dustin Well, this ride ended in a 100% disaster. /tmp/amanda and /tmp/amanda-dbg were used and duly populated with debug files from yesterdays amcheck and amlabel activities, but was unable to make the /tmp/amanda/Daily dir for the rest of it. There isn't anything left in the /dumps holding disk, and the virtual tape it was going to use is empty except for the label file. The /tmp/amanda and /tmp/amanda-dbg dirs do not contain *any* files dated to the start time of the run, only leftovers I had pulled with amrecover, and the amcheck & amlabel runs to set up the new drive that were made last night as I was getting it setup. I've made that missing /tmp/amanda/Daily dir, and touched the gene.log file there and restarted it. It seems to be doing its thing ok now as its generating files in the /tmp/amanda dirs and 1Gb chunk.tmp files are showing up in /dumps, so I'm going back to bed & when I wake up again, I'll fire off my catchup script since it all failed for round one, and about 22 Gb failed for round two according to amstatus. catchup will run about 6 backups in a row & should begin to establish some order. Who would have thought that one missing subdir containing one, constantly over written log file in /tmp/amanda/Daily/gene.log would have screwed things up so bad. My script obviously needs to handle that and didn't. Humm, although it says the first 7.6Gb dle has been taped, the chunk files are still in /dumps, I thought they were cleaned out once they were written to tape? Has this behavior changed? >From amstatus: coyote:/usr/movies0 7672400m finished (2:42:12), PARTIAL What is this 'PARTIAL'? More news later. -- 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) The mosquito exists to keep the mighty humble.
Re: Disaster recovery and amanda-2.6.0b1
On Monday 14 January 2008, Gene Heskett wrote: >On Sunday 13 January 2008, Dustin J. Mitchell wrote: >>On Jan 13, 2008 9:00 PM, Gene Heskett <[EMAIL PROTECTED]> wrote: >>> Is there anything in that config driver that I should change for 2.6.0b1? >> >>Not that I know of. The changes to note are in the NEWS and >>ReleaseNotes -- in particular, some new build dependencies, lib and >>libexec files moved to lib/amanda and libexec/amanda, and >>/etc/amandates moved to /var/amanda/amandates unless you supply >>--with-amandates=/etc/amandates. >> >>Thanks so much for testing this. Has anyone else had a chance to take >>it out for a ride? >> >>Dustin > >Well, this ride ended in a 100% disaster. /tmp/amanda and /tmp/amanda-dbg > were used and duly populated with debug files from yesterdays amcheck and > amlabel activities, but was unable to make the /tmp/amanda/Daily dir for > the rest of it. There isn't anything left in the /dumps holding disk, and > the virtual tape it was going to use is empty except for the label file. > >The /tmp/amanda and /tmp/amanda-dbg dirs do not contain *any* files dated to >the start time of the run, only leftovers I had pulled with amrecover, and >the amcheck & amlabel runs to set up the new drive that were made last night >as I was getting it setup. > >I've made that missing /tmp/amanda/Daily dir, and touched the gene.log file >there and restarted it. It seems to be doing its thing ok now as its >generating files in the /tmp/amanda dirs and 1Gb chunk.tmp files are showing >up in /dumps, so I'm going back to bed & when I wake up again, I'll fire off >my catchup script since it all failed for round one, and about 22 Gb failed >for round two according to amstatus. catchup will run about 6 backups in a >row & should begin to establish some order. > >Who would have thought that one missing subdir containing one, constantly > over written log file in /tmp/amanda/Daily/gene.log would have screwed > things up so bad. My script obviously needs to handle that and didn't. > >Humm, although it says the first 7.6Gb dle has been taped, the chunk files > are still in /dumps, I thought they were cleaned out once they were written > to tape? Has this behavior changed? > >>From amstatus: >coyote:/usr/movies0 7672400m finished (2:42:12), PARTIAL > >What is this 'PARTIAL'? > >More news later. PS, from the amverify run I do after the backup run: --- Volume Dailys-30, Date 20080114023115 ** Error detected (FILE: date 20080114023115 host coyote disk /usr/movies lev 0 comp N program /bin/tar) could not open conf file "/usr/local/etc/amanda/amanda-client.conf": No such file or directory Restoring from tape Dailys-30 starting with file 1. amrestore: 1: restoring FILE: date 20080114023115 host coyote disk /usr/movies lev 0 comp N program /bin/tar /bin/tar: Unexpected EOF in archive /bin/tar: Error is not recoverable: exiting now End-of-Tape detected. -- Which explains what the PARTIAL above might mean, but in all my history with amanda, I don't recall ever needing or having a /usr/local/etc/amanda/amanda-client.conf file. What is this and what does it do? Currently that dir contains the Daily/config files. Another datum point: From an ls -lR of /amandatapes/Dailys: -- /amandatapes/Dailys/slot30: total 177769 -rw--- 1 amanda amanda 32768 2008-01-14 02:41 0.Dailys-30 -rw--- 1 amanda amanda 181284864 2008-01-14 02:42 1.coyote._usr_movies.0 -rw-rw-r-- 1 amanda amanda 0 2008-01-14 03:21 configuration.tar -rw-rw-r-- 1 amanda amanda 0 2008-01-14 03:21 indices.tar - Only 181 megabytes out of 7.4Gb written? This was looked at AFTER a flush session, but the file time is from the end of the backup session, not the flush. And the flush did NOT advance the vtape to #1 as it should have. So the failure also caused the tapelist and the rest of the tally files in /usr/local/etc/amanda/Daily to not be updated.. Houston, we may have a problem here. :-) -- 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) Information Processing: What you call data processing when people are so disgusted with it they won't let it be discussed in their presence.
Re: Disaster recovery and amanda-2.6.0b1
On Monday 14 January 2008, Gene Heskett wrote: >On Sunday 13 January 2008, Dustin J. Mitchell wrote: >>On Jan 13, 2008 9:00 PM, Gene Heskett <[EMAIL PROTECTED]> wrote: >>> Is there anything in that config driver that I should change for 2.6.0b1? >> >>Not that I know of. The changes to note are in the NEWS and >>ReleaseNotes -- in particular, some new build dependencies, lib and >>libexec files moved to lib/amanda and libexec/amanda, and >>/etc/amandates moved to /var/amanda/amandates unless you supply >>--with-amandates=/etc/amandates. >> >>Thanks so much for testing this. Has anyone else had a chance to take >>it out for a ride? >> >>Dustin > >Well, this ride ended in a 100% disaster. /tmp/amanda and /tmp/amanda-dbg > were used and duly populated with debug files from yesterdays amcheck and > amlabel activities, but was unable to make the /tmp/amanda/Daily dir for > the rest of it. There isn't anything left in the /dumps holding disk, and > the virtual tape it was going to use is empty except for the label file. > >The /tmp/amanda and /tmp/amanda-dbg dirs do not contain *any* files dated to >the start time of the run, only leftovers I had pulled with amrecover, and >the amcheck & amlabel runs to set up the new drive that were made last night >as I was getting it setup. > >I've made that missing /tmp/amanda/Daily dir, and touched the gene.log file >there and restarted it. It seems to be doing its thing ok now as its >generating files in the /tmp/amanda dirs and 1Gb chunk.tmp files are showing >up in /dumps, so I'm going back to bed & when I wake up again, I'll fire off >my catchup script since it all failed for round one, and about 22 Gb failed >for round two according to amstatus. catchup will run about 6 backups in a >row & should begin to establish some order. > >Who would have thought that one missing subdir containing one, constantly > over written log file in /tmp/amanda/Daily/gene.log would have screwed > things up so bad. My script obviously needs to handle that and didn't. > >Humm, although it says the first 7.6Gb dle has been taped, the chunk files > are still in /dumps, I thought they were cleaned out once they were written > to tape? Has this behavior changed? > >>From amstatus: >coyote:/usr/movies0 7672400m finished (2:42:12), PARTIAL > >What is this 'PARTIAL'? > >More news later. Back again after reading the email from the flush. It looks as if I have a filesystem maxfilesize problem, this number looks VERY familiar, from that email: --- FAILURE DUMP SUMMARY: driver: FATAL event_register: Invalid file descriptor 4294967295 and later: NOTES: driver: Taper protocol error driver: taper pid 29196 exited with signal 11 and later yet: coyote /usr/movies NO FILE TO FLUSH -- but there's these sitting in /dumps [EMAIL PROTECTED] config-bak]# ls -lR /dumps /dumps: total 16 drwx-- 2 amanda amanda 4096 2008-01-14 03:21 20080114023115 drwx-- 2 amanda amanda 4096 2008-01-14 03:36 20080114033617 /dumps/20080114023115: total 12730908 -rw--- 1 amanda amanda 1073741824 2008-01-14 02:51 coyote._home.0 -rw--- 1 amanda amanda 1073741824 2008-01-14 03:08 coyote._home.0.1 -rw--- 1 amanda amanda 165619638 2008-01-14 03:10 coyote._home.0.2 -rw--- 1 amanda amanda 1073741824 2008-01-14 03:14 coyote._opt.0 -rw--- 1 amanda amanda 1073741824 2008-01-14 03:16 coyote._opt.0.1 -rw--- 1 amanda amanda 478117957 2008-01-14 03:20 coyote._opt.0.2 -rw--- 1 amanda amanda 209625088 2008-01-14 03:20 coyote._usr_dlds.0 -rw--- 1 amanda amanda 18455042 2008-01-14 03:21 coyote._usr_libexec.0 -rw--- 1 amanda amanda 1073741824 2008-01-14 02:35 coyote._usr_movies.0 -rw--- 1 amanda amanda 1073741824 2008-01-14 02:36 coyote._usr_movies.0.1 -rw--- 1 amanda amanda 1073741824 2008-01-14 02:37 coyote._usr_movies.0.2 -rw--- 1 amanda amanda 1073741824 2008-01-14 02:38 coyote._usr_movies.0.3 -rw--- 1 amanda amanda 1073741824 2008-01-14 02:39 coyote._usr_movies.0.4 -rw--- 1 amanda amanda 1073741824 2008-01-14 02:40 coyote._usr_movies.0.5 -rw--- 1 amanda amanda 1073741824 2008-01-14 02:41 coyote._usr_movies.0.6 -rw--- 1 amanda amanda 340606976 2008-01-14 02:41 coyote._usr_movies.0.7 /dumps/20080114033617: total 0 I don't believe it will do me any good to try to run the catchup script, so I'll await your sage advice. This is a stock, most recent, 2.6.23.9 fedora kernel. -- 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) Real Users hate Real Programmers.
Re: Disaster recovery and amanda-2.6.0b1
On Jan 14, 2008 3:53 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: > PS, from the amverify run I do after the backup run: amverify is deprecated -- please use amcheckdump. > driver: FATAL event_register: Invalid file descriptor 4294967295 That's probably not a maxfilesize problem. That's the "unsigned" 32-bit representation of -1, which suggests that someone is passing around an invalid file descriptor somewhere -- definitely a bug. Can you sniff out and send the debug logs from that flush? I think there are a number of problems piling onto one another here, which is going to make debugging difficult if not impossible. Can you try to reduce the complexity a little bit -- maybe limit to one (smallish) DLE, and don't run a flush? Also, it would be great if you (and others!) could run the installchecks on your system. See http://wiki.zmanda.com/index.php/Testing#Running_Installcheck_without_Root please send any failures along in a separate thread. When we get to the bottom of the "Invalid file descriptor" problem, I'll try to invent a new check to replicate it. Dustin -- Storage Software Engineer http://www.zmanda.com
Re: Disaster recovery and amanda-2.6.0b1
On Monday 14 January 2008, Dustin J. Mitchell wrote: >On Jan 14, 2008 3:53 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: >> PS, from the amverify run I do after the backup run: > >amverify is deprecated -- please use amcheckdump. > >> driver: FATAL event_register: Invalid file descriptor 4294967295 > >That's probably not a maxfilesize problem. That's the "unsigned" >32-bit representation of -1, which suggests that someone is passing >around an invalid file descriptor somewhere -- definitely a bug. Can >you sniff out and send the debug logs from that flush? I just looked at the runtar-debug and it looks like we have a version mixing problem, they all say they were generated by 2.5.2p1! Or did someone forget to update an internal version string? Now, I'm thinking that my script which has some of the executables locations hard coded in a config file, might need that config file brought up to date. Once I get some caffiene injected, I need to goto work and won't get get back to this till this evening. As far as testing, I can run the make installcheck without screwing things up as I can re-run the mkvtapes script and re-init the vtapes in a few seconds. A 'make check' seemed to be happy. A 'make installcheck' however bails out from a missing perl module: /usr/bin/perl -I. -e 'use Test::Harness qw(&runtests); runtests(@ARGV);' Amanda_Logfile Amanda_Changer Amanda_Cmdline Amanda_Config Amanda_Types amcheckdump amdevcheck amgetconf Amanda_Logfile...Can't locate Test/More.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at Amanda_Logfile line 19. BEGIN failed--compilation aborted at Amanda_Logfile line 19. Amanda_Logfile...dubious Test returned status 2 (wstat 512, 0x200) Amanda_Changer...Can't locate Test/More.pm in @INC (@INC contains: /usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl/5.8.7 /usr/lib/perl5/site_perl/5.8.6 /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.7/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.6/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl/5.8.7 /usr/lib/perl5/vendor_perl/5.8.6 /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl /usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .) at Amanda_Changer line 19. BEGIN failed--compilation aborted at Amanda_Changer line 19. Amanda_Changer...dubious And repeats that stanza several dozen more times. I'll see if I can get that installed. Mmm, no, I have it but in /root! [EMAIL PROTECTED] amanda-2.6.0b1-20080111]# locate More.pm /root/.cpan/build/CPAN-1.80/inc/Test/More.pm /root/.cpan/build/PathTools-3.14/t/lib/Test/More.pm Thinking that's old FC6 stuff, I fired up yumex, and I have the Perl-Test-Harness installed, but there is not a 'Perl-Test-More' package available. Lemme see if I have the cpan shell.. No, not installed. Will be shortly. Tis now, but it can't find it, and recommends I do an Install Bundle::CPAN cuz the f8 version is precambrian. Doing that now. Then I'll do a 'reload cpan' followed by 'Install Bundle::TEST' and see what I get. I'm getting to hate fedora more and more because they stick us with old software for the 'around the edges shit'. For FC6 the achilles heel was gimp-print, 5 year old code that was long ago replaced with gutenprint, so I had to build my own there too. Jerks. finally, after about ten minutes worth of putzing around taking the default answers everytime it pauses for input, I get this prompt: Writing Makefile for CPAN Unsatisfied dependencies detected during [A/AN/ANDK/CPAN-1.9205.tar.gz] - Test::Harness Test::More Shall I follow them and prepend them to the queue of modules we are processing right now? [yes] Followed in time by this confusing bit of output: BEGIN failed--compilation
Re: Disaster recovery and amanda-2.6.0b1
On Monday 14 January 2008, Dustin J. Mitchell wrote: >On Jan 14, 2008 3:53 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: >> PS, from the amverify run I do after the backup run: > >amverify is deprecated -- please use amcheckdump. > >> driver: FATAL event_register: Invalid file descriptor 4294967295 > >That's probably not a maxfilesize problem. That's the "unsigned" >32-bit representation of -1, which suggests that someone is passing >around an invalid file descriptor somewhere -- definitely a bug. Can >you sniff out and send the debug logs from that flush? I *think* I need a wet warshrag & some of grandma's lie soap. I did all the prep on that drive, and did not reboot, just remounted, so the kernel still *thought* /dev/sdc1 was a 200mb partition I was going to use for a boot partition, no damned wonder it failed, but it chose a poor way too demo that the disk was full. It took df to make me see that. So, I've rebooted to a freshly built 2.6.24-rc7, killed all traces of previous runs, made new vtapes yadda yadda. Humm, it looks as if I'm going to have to re-write my helper scripts to specify the exact path of every utility in the closet, its still using the older runtar from 2.5.2p2. Your moving things around is gnawing on my ankles. I don't think its going to find the amcheckdump thing either. G. So I may as well kill it right now, damn. Hopefully that's fixed, all cleaned up and running again. -- 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) Always leave room to add an explanation if it doesn't work out.
Re: Disaster recovery and amanda-2.6.0b1
On Jan 14, 2008 11:22 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: > I just looked at the runtar-debug and it looks like we have a version mixing > problem, they all say they were generated by 2.5.2p1! Or did someone forget > to update an internal version string? It's updated in HEAD -- try running 'amgetconf build.VERSION'. > Now, I'm thinking that my script which has some of the executables locations > hard coded in a config file, might need that config file brought up to date. > Once I get some caffiene injected, I need to goto work and won't get get back > to this till this evening. Yes, that's quite possible. > As far as testing, I can run the make installcheck without screwing things up > as I can re-run the mkvtapes script and re-init the vtapes in a few seconds. I'm hesitant to promise anything, but actually you're being overly cautious -- installcheck won't run your configuration. It creates its own configuration, TESTCONF, and its own vtapes. So it "shouldn't" mess with your configuration in any way, shape, or form. I just don't want to be responsible for the consequences if I'm wrong about that :) > A 'make check' seemed to be happy. > A 'make installcheck' however bails out from a missing perl module: ... > Amanda_Logfile...Can't locate Test/More.pm in @INC (@INC Hmm -- apparently that should be a prereq for the installchecks. I'll add it to the wiki. > As the user amanda, it fails: > > make[1]: Entering directory > `/home/amanda/amanda-2.6.0b1-20080111/installcheck' > /usr/bin/perl -I. -e 'use Test::Harness qw(&runtests); runtests(@ARGV);' > Amanda_Logfile Amanda_Changer Amanda_Cmdline Amanda_Config Amanda_Types > amcheckdump amdevcheck amgetconf > Amanda_Logfile...ok 1/0Could not create temporary log file at Amanda_Logfile > line 39. > # Looks like your test died just after 2. > Amanda_Logfile...dubious > Test returned status 255 (wstat 65280, 0xff00) > after all the subtests completed successfully > I don't think that should happen. The question is: where is this logfile it > cannot write? From Daily/amanda.conf, its /usr/local/var/amanda which was > owned by amanda:amanda, so I did a chown -R (as root) amanda:disk > on /usr/local/var/amanda, but the installcheck still fails with the above > message. Again, it's not using your config. In this case, it's creating a temporary file in $AMANDA_TMPDIR, which you can see with 'amgetconf build.AMANDA_TMPDIR'. 'amanda' should have permission to create files there. I'll add the filename to that error message, though. Dustin -- Storage Software Engineer http://www.zmanda.com
Re: Disaster recovery and amanda-2.6.0b1
On Monday 14 January 2008, Dustin J. Mitchell wrote: >On Jan 14, 2008 11:22 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: >> I just looked at the runtar-debug and it looks like we have a version >> mixing problem, they all say they were generated by 2.5.2p1! Or did >> someone forget to update an internal version string? > >It's updated in HEAD -- try running 'amgetconf build.VERSION'. > >> Now, I'm thinking that my script which has some of the executables >> locations hard coded in a config file, might need that config file brought >> up to date. Once I get some caffiene injected, I need to goto work and >> won't get get back to this till this evening. > >Yes, that's quite possible. > >> As far as testing, I can run the make installcheck without screwing things >> up as I can re-run the mkvtapes script and re-init the vtapes in a few >> seconds. > >I'm hesitant to promise anything, but actually you're being overly >cautious -- installcheck won't run your configuration. It creates its >own configuration, TESTCONF, and its own vtapes. So it "shouldn't" >mess with your configuration in any way, shape, or form. I just don't >want to be responsible for the consequences if I'm wrong about that :) > >> A 'make check' seemed to be happy. >> A 'make installcheck' however bails out from a missing perl module: > >... > >> Amanda_Logfile...Can't locate Test/More.pm in @INC (@INC > > > >Hmm -- apparently that should be a prereq for the installchecks. I'll >add it to the wiki. > >> As the user amanda, it fails: >> >> make[1]: Entering directory >> `/home/amanda/amanda-2.6.0b1-20080111/installcheck' >> /usr/bin/perl -I. -e 'use Test::Harness qw(&runtests); runtests(@ARGV);' >> Amanda_Logfile Amanda_Changer Amanda_Cmdline Amanda_Config Amanda_Types >> amcheckdump amdevcheck amgetconf >> Amanda_Logfile...ok 1/0Could not create temporary log file at >> Amanda_Logfile line 39. >> # Looks like your test died just after 2. >> Amanda_Logfile...dubious >> Test returned status 255 (wstat 65280, 0xff00) >> after all the subtests completed successfully > > > >> I don't think that should happen. The question is: where is this logfile >> it cannot write? From Daily/amanda.conf, its /usr/local/var/amanda which >> was owned by amanda:amanda, so I did a chown -R (as root) amanda:disk on >> /usr/local/var/amanda, but the installcheck still fails with the above >> message. > >Again, it's not using your config. In this case, it's creating a >temporary file in $AMANDA_TMPDIR, which you can see with 'amgetconf >build.AMANDA_TMPDIR'. 'amanda' should have permission to create files >there. > >I'll add the filename to that error message, though. > >Dustin That test run was successfull, but I had to consult my scripts log to see if amcheckdump was actually ran, which it did. I'm used to getting an email from it and did not. Does it send one if it fails? -- 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) (1) Never draw what you can copy. (2) Never copy what you can trace. (3) Never trace what you can cut out and paste down.
Re: Disaster recovery and amanda-2.6.0b1
Whoops, I meant to send this to the list, too. On Jan 14, 2008 2:59 PM, Gene Heskett <[EMAIL PROTECTED]> wrote: > And note that the fedora 8 repo's have no clue about this added perl stuffs, > it must be obtained from cpan by the rather lengthy procedure I used & > partially logged here AFAIK. This should be an F8 dependency since some will > INSIST on using the *&%#$) and dated rpms. Maybe better yet, to the > configure stage checks & make some noise & bail out if its not there? The > current way was a multi-piece puzzle for sure. :-) A little digging on one of our Fedora boxes shows that it's in perl-Test-Simple: [EMAIL PROTECTED] ~]$ rpm -qf /usr/lib/perl5/5.8.8/Test/More.pm perl-Test-Simple-0.62-23.fc7 I just added that to the wiki. > >Again, it's not using your config. In this case, it's creating a > >temporary file in $AMANDA_TMPDIR, which you can see with 'amgetconf > >build.AMANDA_TMPDIR'. 'amanda' should have permission to create files > >there. > > That would be, for the current Daily amanda.conf, /tmp/amanda and the perms > should have been fine, but I've NDI about the installcheck location. AMANDA_TMPDIR is a build-time constant, so it doesn't matter which configuration you're using. I neglected to remove the file after the checks were done, so that file already existed, owned by you, when you tried to run the checks as 'amanda'. Result: permissions error. I'm adding it to my list of tweaks to the installchecks. > Thanks Dustin, it looks as if I can run my catchup script now. Great! Dustin -- Storage Software Engineer http://www.zmanda.com -- Storage Software Engineer http://www.zmanda.com
Re: Disaster recovery and amanda-2.6.0b1
On Monday 14 January 2008, Dustin J. Mitchell wrote: >On Jan 14, 2008 11:22 AM, Gene Heskett <[EMAIL PROTECTED]> wrote: >> I just looked at the runtar-debug and it looks like we have a version >> mixing problem, they all say they were generated by 2.5.2p1! Or did >> someone forget to update an internal version string? > >It's updated in HEAD -- try running 'amgetconf build.VERSION'. 1. it looks for /amanda.conf in the pwd directory. 2. cd'ing to /usr/local/etc/amanda/Daily it returns: [EMAIL PROTECTED] Daily]$ amgetconf build.VERSION 2.6.0b1-20080111 > >> Now, I'm thinking that my script which has some of the executables >> locations hard coded in a config file, might need that config file brought >> up to date. Once I get some caffiene injected, I need to goto work and >> won't get get back to this till this evening. > >Yes, that's quite possible. Fixed I hope. This past run worked with that changed. >> As far as testing, I can run the make installcheck without screwing things >> up as I can re-run the mkvtapes script and re-init the vtapes in a few >> seconds. > >I'm hesitant to promise anything, but actually you're being overly >cautious -- installcheck won't run your configuration. It creates its >own configuration, TESTCONF, and its own vtapes. So it "shouldn't" >mess with your configuration in any way, shape, or form. I just don't >want to be responsible for the consequences if I'm wrong about that :) Hey, we have to COA. :) > > >Hmm -- apparently that should be a prereq for the installchecks. I'll >add it to the wiki. And blast the wiki's URL out on the error maybe? And note that the fedora 8 repo's have no clue about this added perl stuffs, it must be obtained from cpan by the rather lengthy procedure I used & partially logged here AFAIK. This should be an F8 dependency since some will INSIST on using the *&%#$) and dated rpms. Maybe better yet, to the configure stage checks & make some noise & bail out if its not there? The current way was a multi-piece puzzle for sure. :-) >> As the user amanda, it fails: >> >> make[1]: Entering directory >> `/home/amanda/amanda-2.6.0b1-20080111/installcheck' >> /usr/bin/perl -I. -e 'use Test::Harness qw(&runtests); runtests(@ARGV);' >> Amanda_Logfile Amanda_Changer Amanda_Cmdline Amanda_Config Amanda_Types >> amcheckdump amdevcheck amgetconf >> Amanda_Logfile...ok 1/0Could not create temporary log file at >> Amanda_Logfile line 39. >> # Looks like your test died just after 2. >> Amanda_Logfile...dubious >> Test returned status 255 (wstat 65280, 0xff00) >> after all the subtests completed successfully > > > >> I don't think that should happen. The question is: where is this logfile >> it cannot write? From Daily/amanda.conf, its /usr/local/var/amanda which >> was owned by amanda:amanda, so I did a chown -R (as root) amanda:disk on >> /usr/local/var/amanda, but the installcheck still fails with the above >> message. > >Again, it's not using your config. In this case, it's creating a >temporary file in $AMANDA_TMPDIR, which you can see with 'amgetconf >build.AMANDA_TMPDIR'. 'amanda' should have permission to create files >there. That would be, for the current Daily amanda.conf, /tmp/amanda and the perms should have been fine, but I've NDI about the installcheck location. I already blew all that stuff away unforch. >I'll add the filename to that error message, though. I think that would be helpfull. Concise verbosity is generally welcomed. >Dustin Thanks Dustin, it looks as if I can run my catchup script now. -- 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) Everyone is entitled to my opinion.
Re: Disaster recovery and amanda-2.6.0b1
On Monday 14 January 2008 14:42:44 Gene Heskett wrote: > That test run was successfull, but I had to consult my scripts log to see > if amcheckdump was actually ran, which it did. I'm used to getting an > email from it and did not. Does it send one if it fails? Amcheckdump does not send any e-mail; errors are printed to standard output. Additionally, if no changer is configured, amcheckdump will prompt for new tapes interactively. Cheers, --Ian -- Wiki for Amanda documentation: http://wiki.zmanda.com/
Re: Disaster recovery and amanda-2.6.0b1
On Tuesday 15 January 2008, Ian Turner wrote: >On Monday 14 January 2008 14:42:44 Gene Heskett wrote: >> That test run was successfull, but I had to consult my scripts log to see >> if amcheckdump was actually ran, which it did. I'm used to getting an >> email from it and did not. Does it send one if it fails? > >Amcheckdump does not send any e-mail; errors are printed to standard output. >Additionally, if no changer is configured, amcheckdump will prompt for new >tapes interactively. > >Cheers, > >--Ian Well, its sorta working. The runtar*debug still says its the older runtar, I think because that path spec is still the older one, and it will all die if I change that one. Since I changed the path to include amcheckdump, its apparently working too, its messages do make it to my log. An email would be nicer though :) I'll put the new version of runtar over the old one, probably the best I can do since that invocation is not part of my script, but is invoked by amdump itself. It is pretty much caught up, doing about 5.5GB backups and with a larger drive I can reduce the dumpcycle a day, so while I'm fiddling today I'll probably do that too. Thanks Ian. -- 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) In Tennessee, it is illegal to shoot any game other than whales from a moving automobile.
Re: Disaster/Recovery using amanda and 'dump'
On Mon, 22 Dec 2003 at 2:10pm, Roberto Samarone Araújo (RSA) wrote > I'm using amanda with 'dump', instead of 'tar', to backup my servers. I > would like to know what's the procedures to recovery a backup from a tape if > my amanda server down. It's the same as if you were using tar, but you use 'restore' to pull the files out of the image, rather than 'tar x'. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Disaster/Recovery using amanda and 'dump'
On Monday 22 December 2003 17:10, Roberto Samarone Araújo (RSA) wrote: >Hi, > >I'm using amanda with 'dump', instead of 'tar', to backup my > servers. I would like to know what's the procedures to recovery a > backup from a tape if my amanda server down. > > thanks, > > Robert Getting down to the bare metal, and assuming that you have a working mt, dd, gzip and tar, then Put the first tape of the current dumpcycle in the drive mt -f devicename rewind # just to make sure dd if=non-rewinding-devicename bs=32k count=1 of=instructs now read the instructs file which will tell you how to invoke tar and if required gzip to get the data back. Do it. Do this in a temporary scratch directory with enough disk to contain what you want to do. You can even leave the of= specification off and you see it on your screen as dd will then send it to stdout. Once the first tarball has been recovered, repeat from the dd comamnd above, till you hit the tapes eot. Goto the next tape if its not all on that one. And yes, its drudgery. :-) -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.22% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2003 by Maurice Eugene Heskett, all rights reserved.
Re: Disaster recovery and amanda-2.6.0b1, more info
Greetings;
After last nights run, I thought I'd see if it was using the new versions of
things, but the only routine of those that do report in their debug files
what version they are, is the runtar I copied out
of /usr/local/libexec/amanda/runtar and put in /usr/local/libexec.
Everything else that reports its version in the debug files, is still
reporting its version 2.5.2p1.
Duh... Just remembered. One thing I didn't do after editing the paths for
the 3 items in /etc/xinetd.d/amanda, is restart xinetd. Now that has been
done. Now, amcheck says it can't find amandates in the new location, so I
moved that to the new location & now amcheck is happy again. So that must
have been it, but we'll check the logfiles again tomorrow morning. Damn its
hell to have CRS like this. :)
I'm hesitant to clean out the old stuff in /usr/local/libexec, but will once
all the reported versions are correct.
There was quite a list of routines that do not report in the *.debug logfile,
or at least that version did not report, their internal version. Those that
did not:
amcheck
amcheckdump
amlabel
amlogroll
amreport
chunker
driver
dumper
taper
It might be helpfull if they did have a sign-in of their version at the top of
the generated *.debug logfile.
Also, I'm seeing an selinux denial advisory on screen, naming procmail, for
everytime I think amanda is trying to send me an email. I do the email
activities here as root, but kmail sucks from both the root account and from
the gene account, and I have changed the Mailto: address from [EMAIL PROTECTED]
to [EMAIL PROTECTED]
>From setroubleshoot:
SUMMARY
SELinux is preventing /usr/bin/procmail (procmail_t) "search" to (var_log_t).
Detailed Description
SELinux denied access requested by /usr/bin/procmail. It is not expected that
this access is required by /usr/bin/procmail and this access may signal an
intrusion attempt. It is also possible that the specific version or
configuration of the application is causing it to require additional access.
Allowing Access
Sometimes labeling problems can cause SELinux denials. You could try to
restore the default system file context for , restorecon -v If this does not
work, there is currently no automatic way to allow this access. Instead, you
can generate a local policy module to allow this access - see FAQ Or you can
disable SELinux protection altogether. Disabling SELinux protection is not
recommended. Please file a bug report against this package.
Additional Information
Source Context: system_u:system_r:procmail_t:s0
Target Context: system_u:object_r:var_log_t:s0
Target Objects: None [ dir ]
Affected RPM Packages: procmail-3.22-20.fc8 [application]
Policy RPM: selinux-policy-3.0.8-74.fc8Selinux
Enabled: True
Policy Type: targeted
MLS Enabled: True
Enforcing Mode: Enforcing
Plugin Name: plugins.catchall_file
Host Name: coyote.coyote.den
Platform: Linux coyote.coyote.den 2.6.24-rc7 #1 SMP Mon Jan 14 10:00:40 EST
2008 i686 athlon
Alert Count: 26
First Seen: Wed 09 Jan 2008 05:09:14 AM EST
Last Seen: Wed 16 Jan 2008 05:09:15 AM EST
Local ID: bfec6c3c-7d3b-47f7-9174-a2251b12534a
Line Numbers:
Raw Audit Messages :avc: denied { search } for comm=procmail dev=dm-0 egid=500
euid=500 exe=/usr/bin/procmail exit=-13 fsgid=500 fsuid=500 gid=500 items=0
name=log pid=15219 scontext=system_u:system_r:procmail_t:s0 sgid=0
subj=system_u:system_r:procmail_t:s0 suid=500 tclass=dir
tcontext=system_u:object_r:var_log_t:s0 tty=(none) uid=500
So I'm going to send this part to the selinux list also.
--
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)
Luck can't last a lifetime, unless you die young.
-- Russell Banks
