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
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 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
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, 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
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 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 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 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, 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 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 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 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 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 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 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
Disaster recovery and amanda-2.6.0b1
Greetings all; I had something zero out the partition table on my boot drive about 2 weeks ago, and had to reinstall from scratch, but put fedora 8 on. Then I used dd to recover the last full backup of /home and used that to rebuild and reinstall 2.5.2p1. I'm still using that version of amrecover to pick out the stuff that's missing from time to time. And other than PEBKAC type problems because I was rusty, that has worked well. What I want to do is to use 2.6.0 with a new drive, which I will mount at the same mount point as the old one by suitable editing of fstab. I don't foresee that as being a problem as long as I do the new drive, a 372 GB Hitachi/ibm sata drive on its own card, bought to be the F8 drive, but on this mobo, it cannot be made bootable as the bios doesn't see it. The cards bios does, and it mounts and works just fine, but I don't think I need 2 huge drives just for F8 and I don't dual boot this box. Using my original gh.cf to configure and build 2.6.0b1 went without visible errors, so I was rather surprised to see this after the root install step: [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 So obviously I've 'screwed the moose' somehow, and a rather cursory look at the readme's, install's, news and ChangeLog didn't warn me that something important had been changed. A run of ldconfig didn't help either. Has the install protocol changed? Or is my config script now bogus: -- #!/bin/sh # since I'm always forgetting to su amanda... if [ `whoami` != 'amanda' ]; then echo echo " Warning " echo "Amanda needs to be configured and built by the user amanda," echo "but must be installed by user root." echo exit 1 fi make clean rm -f config.status config.cache ./configure --with-user=amanda \ --with-group=disk \ --with-owner=amanda \ --with-gnu-ld \ --prefix=/usr/local \ --with-tapedev="FILE:/amandatapes" \ --with-debugging=/tmp/amanda-dbg/ \ --with-tape-server=coyote \ --with-bsdtcp-security --with-amandahosts \ --with-configdir=/usr/local/etc/amanda \ --with-config=Daily \ --with-gnutar=/bin/tar make Thanks. -- 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) It occurred to me lately that nothing has occurred to me lately.
Re: Backup server disaster recovery
> Dear all, > > say your amanda backup server itself dies, and you need to > reinstall/recreate it from scratch. > > You want the new backup server to have available the information needed to > find and restore data from tapes, i.e. the info you get when running: > amadmin config find server_name disk > or like when you restore something from a specific date, when the server > tells you which tapes you need to do the restore (while using amrecoger). > > What do you need to back up on the current backup server to enable you to > get the new server to this state? I understand that you are interested in the possibility to reuse the back-up on tape, not by restoring the amanda server. I assume that you'd know how to rebuild an Amanda server from scratch, but then you'd need all the previous tape to be usable (that's how I set-up the strategy we are currently using). What we keep up is: - Amanda index database (from amanda user home directory/Daily-Setxxx) - Amanda config files (from usuall /usr/local/etc/amanda?) I do that by: - rsync'ing the above mentionned directories to another machine - emailing to Amanda operators the result of amadmin export See: https://wwws.cs.ait.ac.th/amanda/operator.shtml#database The command amdatabase is a home coocked script. Best regards, Olivier
Re: Backup server disaster recovery
On Fri, Jul 21, 2006 at 04:32:04PM -0400, Ronald Vincent Vazquez wrote: > > On Fri, July 21, 2006 3:57 pm, Jon LaBadie wrote: > > On Fri, Jul 21, 2006 at 02:44:30PM -0400, Ronald Vincent Vazquez wrote: > >> > >> Hello: > >> > >> Here is what we have done at our site. We re-mastered DSL (Damn Small > >> Linux) with all the tools we need (and some we won't ever need). The > >> bootable CD includes: ssh, netcat, etc., SCSI modules for our card, raid > >> stuff, and most important, Amanda client. > >> > >> As a test, we trashed the drives on the backup server rendering it > >> un-bootable and after the restoration a few minutes later the server was > >> running again. What I did was, boot from the CD, fdisk the drives, > >> create > >> the file systems, enable mirroring, mount the partitions, and restore > >> the > >> last level 0 to the drive. I didn't have to mess with any incrementals > >> because part of my test included a level 0 right before destroying the > >> server. The only other thing I did was to copy /dev from the CD to the > >> drive and mount /proc in order to install lilo on the hard drives. > >> > >> In short, if you could invest the time in creating a "Live CD" with > >> amanda > >> client now, it will pay good dividends later. You would need nothing > >> more > >> than the CD and a cup of coffee. > >> > > > > Great sounding system. Couple of questions if I might: > > > > 1. The resulting live CD, is it limited to the restoration of a single > >host, presumably the amanda server. And within that limit, if it > >exists, is the live CD in anyway tied to specific amanda configs? > > > > 2. Over the years/months, what sorts of things would necessitate a > >rebuild of the CD? Change of OS release? Update of any specific > >packages on the host? hardware changes? amanda config changes? > >amanda updates? > > > > 3. How scriptable might creating such a CD be? I'm thinking of two > >scenarios. An "automated" build would be useful if regular remakes > >of the CD were needed (question 2 above). And it would be a nice > >distributable script. Give instructions for how to get DSL and > >how to put together any of the extra pieces (netcat, etc.) into a > >form/location the script can use. Then setup a config file that > >says where the pieces are and anyother params needed. > > > >After they've done those steps, even neophytes of building a live CD, > >might be able to run the script and create a .iso to burn as their > >rescue/recovery disk. > > > > Thanks, > > jon > > -- > > Jon H. LaBadie [EMAIL PROTECTED] > > JG Computing > > 4455 Province Line Road(609) 252-0159 > > Princeton, NJ 08540-4322 (609) 683-7220 (fax) > > > Hello Jon: > > 1. Actually, the resulting CD is universal, we could restore any of our > x86 machines here. Our CD displays a prompt where you can choose form a > series of options: 1. Restore a cluster node, 2. Restore the backup server > itself (will drive the changer), 3. Restore any of our servers, 4. Obtain > a "bash" shell. All you do to restore any of the other servers is > configure your ethernet interface and ssh to the backup server or use > netcat. > > 2. The only reason I see which will force us to re-master the CD soon will > be to upgrade amanda itself from vers 2.4.X to 2.5.X. Other than that all > I can think is that you may want your "universal" CD to perform a new > task. In that case, another 20 cents and 5 minutes of your time... ;-) > > 3. The process of creating the disk can be turned into a script very > easily. For the software we add to the CD, we are compiling it on another > machine and then moving the binaries and libaries to the chrooted > environment manually. > > Let me see if I have enough time this weekend to "cook" a document in > order to share our efforts. > > That would be great. I have a spare box totally unused with a small disk. I'll try to use it to trash and recreate from a live CD based on your docs. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Backup server disaster recovery
On Fri, July 21, 2006 3:57 pm, Jon LaBadie wrote: > On Fri, Jul 21, 2006 at 02:44:30PM -0400, Ronald Vincent Vazquez wrote: >> >> Hello: >> >> Here is what we have done at our site. We re-mastered DSL (Damn Small >> Linux) with all the tools we need (and some we won't ever need). The >> bootable CD includes: ssh, netcat, etc., SCSI modules for our card, raid >> stuff, and most important, Amanda client. >> >> As a test, we trashed the drives on the backup server rendering it >> un-bootable and after the restoration a few minutes later the server was >> running again. What I did was, boot from the CD, fdisk the drives, >> create >> the file systems, enable mirroring, mount the partitions, and restore >> the >> last level 0 to the drive. I didn't have to mess with any incrementals >> because part of my test included a level 0 right before destroying the >> server. The only other thing I did was to copy /dev from the CD to the >> drive and mount /proc in order to install lilo on the hard drives. >> >> In short, if you could invest the time in creating a "Live CD" with >> amanda >> client now, it will pay good dividends later. You would need nothing >> more >> than the CD and a cup of coffee. >> > > Great sounding system. Couple of questions if I might: > > 1. The resulting live CD, is it limited to the restoration of a single >host, presumably the amanda server. And within that limit, if it >exists, is the live CD in anyway tied to specific amanda configs? > > 2. Over the years/months, what sorts of things would necessitate a >rebuild of the CD? Change of OS release? Update of any specific >packages on the host? hardware changes? amanda config changes? >amanda updates? > > 3. How scriptable might creating such a CD be? I'm thinking of two >scenarios. An "automated" build would be useful if regular remakes >of the CD were needed (question 2 above). And it would be a nice >distributable script. Give instructions for how to get DSL and >how to put together any of the extra pieces (netcat, etc.) into a >form/location the script can use. Then setup a config file that >says where the pieces are and anyother params needed. > >After they've done those steps, even neophytes of building a live CD, >might be able to run the script and create a .iso to burn as their >rescue/recovery disk. > > Thanks, > jon > -- > Jon H. LaBadie [EMAIL PROTECTED] > JG Computing > 4455 Province Line Road(609) 252-0159 > Princeton, NJ 08540-4322 (609) 683-7220 (fax) > Hello Jon: 1. Actually, the resulting CD is universal, we could restore any of our x86 machines here. Our CD displays a prompt where you can choose form a series of options: 1. Restore a cluster node, 2. Restore the backup server itself (will drive the changer), 3. Restore any of our servers, 4. Obtain a "bash" shell. All you do to restore any of the other servers is configure your ethernet interface and ssh to the backup server or use netcat. 2. The only reason I see which will force us to re-master the CD soon will be to upgrade amanda itself from vers 2.4.X to 2.5.X. Other than that all I can think is that you may want your "universal" CD to perform a new task. In that case, another 20 cents and 5 minutes of your time... ;-) 3. The process of creating the disk can be turned into a script very easily. For the software we add to the CD, we are compiling it on another machine and then moving the binaries and libaries to the chrooted environment manually. Let me see if I have enough time this weekend to "cook" a document in order to share our efforts. RV / Ronald Vincent Vazquez Senior Unix Systems Administrator Senior Network Manager Christ Tabernacle Church Ministries http://www.ctcministries.org (301) 540-9394 Home (240) 401-9192 Cell For web hosting solutions, please visit: http://www.spherenix.com/
Re: Backup server disaster recovery
On Fri, Jul 21, 2006 at 06:16:38AM -0700, Joe Donner (sent by Nabble.com) wrote: > > Dear all, > > say your amanda backup server itself dies, and you need to > reinstall/recreate it from scratch. http://www.charlescurley.com/Linux-Complete-Backup-and-Recovery-HOWTO.html This does not cover Amanda; see Jon's reply for that. -- Charles Curley /"\ASCII Ribbon Campaign Looking for fine software \ /Respect for open standards and/or writing? X No HTML/RTF in email http://www.charlescurley.com/ \No M$ Word docs in email Key fingerprint = CE5C 6645 A45A 64E4 94C0 809C FFF6 4C48 4ECD DFDB pgpP7txUFbjt4.pgp Description: PGP signature
Re: Backup server disaster recovery
On Fri, July 21, 2006 9:16 am, Joe Donner (sent by Nabble.com) wrote: > > Dear all, > > say your amanda backup server itself dies, and you need to > reinstall/recreate it from scratch. > > You want the new backup server to have available the information needed to > find and restore data from tapes, i.e. the info you get when running: > amadmin config find server_name disk > or like when you restore something from a specific date, when the server > tells you which tapes you need to do the restore (while using amrecoger). > > What do you need to back up on the current backup server to enable you to > get the new server to this state? > > Will appreciate your insight. > > Joe > -- > View this message in context: > http://www.nabble.com/Backup-server-disaster-recovery-tf1980202.html#a5433481 > Sent from the Amanda - Users forum at Nabble.com. > Hello: Here is what we have done at our site. We re-mastered DSL (Damn Small Linux) with all the tools we need (and some we won't ever need). The bootable CD includes: ssh, netcat, etc., SCSI modules for our card, raid stuff, and most important, Amanda client. As a test, we trashed the drives on the backup server rendering it un-bootable and after the restoration a few minutes later the server was running again. What I did was, boot from the CD, fdisk the drives, create the file systems, enable mirroring, mount the partitions, and restore the last level 0 to the drive. I didn't have to mess with any incrementals because part of my test included a level 0 right before destroying the server. The only other thing I did was to copy /dev from the CD to the drive and mount /proc in order to install lilo on the hard drives. In short, if you could invest the time in creating a "Live CD" with amanda client now, it will pay good dividends later. You would need nothing more than the CD and a cup of coffee. Later, / Ronald Vincent Vazquez Senior Unix Systems Administrator Senior Network Manager Christ Tabernacle Church Ministries http://www.ctcministries.org (301) 540-9394 Home (240) 401-9192 Cell For web hosting solutions, please visit: http://www.spherenix.com/
Re: Backup server disaster recovery
On Fri, Jul 21, 2006 at 06:16:38AM -0700, Joe Donner (sent by Nabble.com) wrote:
>
> Dear all,
>
> say your amanda backup server itself dies, and you need to
> reinstall/recreate it from scratch.
>
> You want the new backup server to have available the information needed to
> find and restore data from tapes, i.e. the info you get when running:
> amadmin config find server_name disk
> or like when you restore something from a specific date, when the server
> tells you which tapes you need to do the restore (while using amrecoger).
>
> What do you need to back up on the current backup server to enable you to
> get the new server to this state?
>
Top of head list
(some may overlap,
some may not be needed for basic recovery):
amanda_user home directory
amanda config directory
config files not in config directory
(ex. I breakout dumptypes, tapetypes, and others
into a common directory for all configs)
logfile directory
index directory
curinfo directory
gnutar-lists directory
/etc/amandates
/etc/dumpdates
.amandahosts
{x}inetd config
crontab entries
/???/bin/
/???/sbin/
/???/libexec/
/???/lib/
/???/lib/
?? system tape and changer config file ??
(ex. on Solaris I've modified st.conf and
sgen.conf, on Fedora I've modified stinit.def)
exclude or include list files
?? holding disk in case what you want is not flushed ??
You might bundle these with tar and transfer to a different
host for safe-keeping after each amdump. An alternative
advocated by at least one is to append the bundle to the
end of the tape just used by amdump. So it would be a
tape file after all the amanda tape files. Easy to locate,
advance to end and backup one file. This assumes sufficient
space on tape (testable).
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Backup server disaster recovery
Dear all, say your amanda backup server itself dies, and you need to reinstall/recreate it from scratch. You want the new backup server to have available the information needed to find and restore data from tapes, i.e. the info you get when running: amadmin config find server_name disk or like when you restore something from a specific date, when the server tells you which tapes you need to do the restore (while using amrecoger). What do you need to back up on the current backup server to enable you to get the new server to this state? Will appreciate your insight. Joe -- View this message in context: http://www.nabble.com/Backup-server-disaster-recovery-tf1980202.html#a5433481 Sent from the Amanda - Users forum at Nabble.com.
OT - solaris disaster recovery
Sorry for the non-amanda topic posting. Disaster recover, i.e. bare metal restore, is not one of amanda's strong points. For those using Solaris, I came across an interesting article on sun.com/bigadmin about using 'flash archives' for disaster recovery. http://www.sun.com/bigadmin/content/submitted/flash_archive.html -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
RE: disaster recovery
if you are running a redhat machine or fedora you have: kickstart. This will automate everything
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--- 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
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
Disaster Recovery
What are the files needed for a Disaster Recovery on the backup server?? Thanks in Advance... 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 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 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
Disaster/Recovery using amanda and 'dump'
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
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.
[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.
Disaster recovery.
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. Ean Kingston ([EMAIL PROTECTED]) Analyst Kanetix Ltd. (www.kanetix.com) Phone: (416) 599-9779 x216
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.
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.
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]>
Disaster recovery & dump cycles
Hi, I'm just starting to figure out Amanda and I have a few questions, hopefully not too stupid. My main goal is disaster recovery for a few servers, which to me means having the most recent complete set of backups off-site. I'm curious how that would work with Amanda dump cycles. If, for instance, I have a dump cycle of 7 days, would I be guaranteed that I have a full set of data if I have the 7 most recent tapes off-site? Assuming all my backups worked properly, of course. And since things don't always work properly, would it make sense to have 3 dump cycles in my tape cycle (I hope I'm getting the terminology correct) and keep the most recent 2 dump cycles off-site? Now lets say I wanted to be able to restore users' mistakenly deleted files as well. Would it be possible to keep a copy of the most recent dump cycle on-line using the file: driver without having the backup data collected twice? I.e. grab /usr, spool it to tape, and save it on disk. I hope I'm asking reasonable questions. I'm just trying to be really clear on how this stuff works before I buy all my equipment. Thanks for your time, - Bruce
Disaster recovery guide and plannings for a specialized system.
Hello, we like to have a more reliable, fast and easy way to do a disaster recovery with amanda. For this we have done two things, which you find both in the appended document: - write a (less tested) disaster recovery guide - start plannings for a specialized amanda disaster recovery system We like to create such a specialized system or to partizipate in a similar project. It will be nice, if you read through the document and give us your annotations and ideas. We like to know: - what we can make better - if there is someone working one something similar - if there is anybody how like to participate in our project. It is planed to publish everything under the GPL, but we can discuss about a similar license. Every feedback is welcome, Bernd Harmsen ds-DATASYSTEME PS: If you want I can send you a PDF, PS, LYX by private mail, which is much nicer to read. === Planning for an Amanda Disaster Recovery System === Bernd Harmsen [EMAIL PROTECTED] www.datasysteme.de Contents 1 Introduction 1.1 Why we need a specialized Amanda Disaster Recovery System? 2 Goals 3 Disaster recovery with native tools and possible optimizations. 3.1 Provide working Hardware and Emergency System 3.2 Restore a Linux-Backup-Client 3.3 Restore Linux-Backup-Server 3.4 Make the System bootable 4 Starting points for optimization 4.1 Essential Backup Tool 4.1.1 Easy Amanda Database export / import 4.2 Specialized Amanda Recovery System on CD 4.2.1 Remote Access 4.2.2 Full automatic partitioning, formating and mounting 4.2.3 Amrestore Scripts -- 1 Introduction -- This document was written to provide information about how to do a disaster recovery with Amanda and to plan a specialized disaster recovery system for Amanda. We (ds-DATASYSTEME) are a small company, specialized on Linux networks that provide Amanda backup system to our customers. We think that Amanda is a great backup tool, very fast, reliable and with low hardware recommendations. But we also think, that Amanda is lacking some features for recovery. Recovery is more complicated than backup. This is normal, because during a recovery you have to deal with an undefined, unknown situation. (E.g. a customer who want to get some files back normally only knows parts of the filename.) But, this is OK. The real problem for us is the case of a disaster recovery. In case the harddisk of an importand server is broken (or the server is completely lost) there are high costs, less time and impatient customers. For this we need a more secure, reliable and fast way to get the system working again. We like to create a specialized Amanda Disaster Recovery System, maybe together with other members of the Amanda community, or to participate in an existing system. We like to publish this system under the GPL or a similar license. 1.1 Why we need a specialized Amanda Disaster Recovery System? -- Because the disaster recovery process as described in Chapter [Disater Recovery naitive] is to complicated (less reliable because of human errors) and to slow. A disaster recovery consist of many different steps that all need time and care. On the other hand there are customers who want their server back. The following timesheet shows what we think about the maximum time we have for a disaster recovery 0.0h A server fails 0.5h The customer call the support. A member of the support team do a diagnostic talk with the customer and pack some hardware for replacement. 1.5h Now the support is on the way to the customer 2.0h The support member arrived at the customer, analyzes the problem and repairs the system. 3.0h The hardware is working again. Now the support member starts to recover the data from the Amanda backups. For this we plan: 1.5h Active work with the recovery tools. 2.0h Data transport over the network. 6.5h The system is mostly working again. 8.0h The system is well tested. All the upcoming small problem are solved. As you can see, it takes a whole working day to get the system up and running again. This is very long and we should try to save some time at some points. But this timesheet is also optimistic. We think that it is hard to meet its deadlines without a specialized disaster recovery system. It assumes that the support worker makes no bigger errors. With a less trained worker it can even take 16 hours. --- 2 Goals --- What are the goals of an specialized Amanda Disaster Recovery System. 1. Make the Disaster Recovery more easy and reliable (less affected from human errors). 2. Make the Disaster Recovery more fast. - 3 Disaster recovery with native tools and possible optimizations
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 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
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
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: Amanda Disaster Recovery...
hi. If you're running Linux and want to buy a disaster recovery cdrom that includes amanda, the book _Linux Problem Solver_ by Brian Ward, No Starch Press, includes one. george herson Nicki Messerschmidt wrote: > > Hi folks, > I'm runnig several Amanda hosts and an Amanda server. Everything works fine, > but... > theres one thing I really don't know how to do the simplest possible way: > How to revocer an Amanda Client if the whole disk is corrupt and I have to > replace it. > Is there a simple method without installing a complete new linux and then > amanda? > I know how to restore files with amrecover and amrestore, never done it via > dd... > > In hope for a positive answer > Nicki Messerschmidt
Re: Amanda Disaster Recovery...
On Wed, 9 May 2001, Nicki Messerschmidt wrote: > I'm runnig several Amanda hosts and an Amanda server. Everything works fine, > but... > theres one thing I really don't know how to do the simplest possible way: > How to revocer an Amanda Client if the whole disk is corrupt and I have to > replace it. > Is there a simple method without installing a complete new linux and then > amanda? > I know how to restore files with amrecover and amrestore, never done it via > dd... What you want is a bootable CD which contains the tools to format a disk and tar/restore from the amanda dump. linuxcare provides an image for a bootable CD http://open-projects.linuxcare.com/BBC/ Or maybe you can use the CD you installed linux from. Since the crashed machine almost never has a tape driver, you'll end up doing something like rsh amandahost amrestore -p host filesystem | tar xf - I use dump/restore (yes, I hear the groans) and have had problems rsh'ing to restore, so I usually amrestore the archive to a file and then extract from that via nfs mount or copying the file to the machine. Amanda documentation describes the command. And you'll need to fiddle with lilo to the make the drive bootable. You should find a guinea pig machine and try this! One surprise I had with the linuxcare CD was that it created a filesystem which was a slightly newer version of ext2. The restore went fine, but afterward dump failed, complaining that the filesystem was a newer version than the dump version. Replacing dump with a newer version fixed that. Good luck, Ron [EMAIL PROTECTED]
Amanda Disaster Recovery...
Hi folks, I'm runnig several Amanda hosts and an Amanda server. Everything works fine, but... theres one thing I really don't know how to do the simplest possible way: How to revocer an Amanda Client if the whole disk is corrupt and I have to replace it. Is there a simple method without installing a complete new linux and then amanda? I know how to restore files with amrecover and amrestore, never done it via dd... In hope for a positive answer Nicki Messerschmidt
Re: New question on disaster recovery with amanda
* John R. Jackson <[EMAIL PROTECTED]> (Sat, Feb 24, 2001 at 12:14:38PM -0500) > The list of tapes needed may be maintained several ways: > * You could set up lbl-templ in amanda.conf to (e.g.) 3hole.ps and > save the paper copies Amanda will generate after every run. The exa,dat,LTO .ps files only list host, filesystem and dumplevel. They do not list which tapeimage is which, *and the listing is sorted alphabetically, not per dumpimage*. 3hole does list them though. Currently listening to: 05-PlanetTelex Gerhard, <@jasongeo.com> == The Acoustic Motorbiker == -- __O Some say the end is near. =`\<, Some say we'll see armageddon soon (=)/(=) I certainly hope we will I could use a vacation
Re: New question on disaster recovery with amanda
>... what if I need to completely restore a machine from
>backups? Looking at the amanda utilities, they're too big for a boot
>floppy.
One of the truly beautiful things about Amanda is that you don't
need it to do a restore. The images are self documenting and may be
recovered with only standard system tools. See "the book chapter" at
www.amanda.org. It has a section on the tape format and how to do this.
So in general, recovering a machine goes like this.
* You need the previous disk layout.
* You need a list of what tapes have the backup images you need (see
below).
* Load the OS from original media (e.g. CD) to the point you can
run commands and the disks are partitioned as needed.
* Get the restore program (e.g. GNU tar or "restore") and tape
manipulation commands ("mt" and "dd") installed. You may also
need to have the decompression program if you're compression your
dump images. These programs may come with the base OS load, or may
need a separate package.
* Restore the system areas. This may also require other OS specific
steps. For instance, on Solaris you need to run installboot to
update the boot sector (the OS load probably set things up in a
workable way, but they may not be what you were actually running if
you've done upgrades).
* Restore the non-system areas (e.g. home directories).
The list of tapes needed may be maintained several ways:
* I rdist the Amanda curinfo database after every amdump/amflush from
my tape server machine to at least one alternate that has a full
Amanda installation. With that, I can run "amadmin find
".
* You could run amtoc after every amdump/amflush and save those
files someplace safe.
* You could set up lbl-templ in amanda.conf to (e.g.) 3hole.ps and
save the paper copies Amanda will generate after every run.
* It's probably not a good idea to depend on Amanda backing up its
own areas. There will almost certainly be other clients/disks dumped
after Amanda dumps itself, so the database would not be complete
or consistent. There are plans in the works to handle this better.
Even if you don't have any of this, you can scan the tapes with mt/dd
and find out where things are (although that would be a last resort).
If you have space to save one thing on removable media, I'd make it
the amrestore program (and whatever shared libraries it needs, etc).
That's the basic tool used to read an Amanda tape and having it will
make your life a lot easier.
There are other tips, depending on how serious you want to get about this.
For instance, if you've kept the base OS area (/, or whatever else is
required to boot) a reasonable size, you might have Amanda always do a
full dump of that (dumpcycle 0) so you only need to reload one tape to
have that part restored. If you also include the Amanda programs in
that area, then you'll be well on your way to starting the restore.
>Ivan
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
New question on disaster recovery with amanda
I'm currently using Amanda 2.4.2, running on a FreeBSD server, with a DLT autoloader, backing up a mixture of FreeBSD and Linux machines. Amanda itself is running fine, the clients are all getting backed up and I've been able to restore some files. My question is: what happens if I were to completely lose a machine. I'm fairly new to all this and have been feeling my way around, but what if I need to completely restore a machine from backups? Looking at the amanda utilities, they're too big for a boot floppy. What are people using for disaster recovery with amanda? What are the plans/theory of doing something like this? Any information would be extremely appreciated. Ivan _ Get your FREE download of MSN Explorer at http://explorer.msn.com
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 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
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
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
>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]
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
