RE: Amanda install reality check
On Wed, 6 Feb 2002 at 4:26pm, Bort, Paul wrote 1. REBDA (Read Everything Before Doing Anything) Where Everything is at least the chapter at www.backupcentral.com and docs/INSTALL (plus anything else relevant in docs, like SAMBA). 1a. Read it again. ;) Really. Wrapping your head around AMANDA can take a bit, but it's well worth it. 2. Be prepared to run the configure/install process a few times until you get it the way you want. 2a. Start with a config named Testing or something like that. Set record no. Play with it. Break it. Fix it. Any other suggestions from the list? 9. Watch out for firewalls you may not expect to be there, e.g. ipchains in default RedHat installs. 10. Restart (x)inetd. Yes, again. ;) 11. If/when you ask the list for help, be as detailed as possible about the problem. We're a friendly (usually), helpful bunch, but we ain't mind readers. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Amanda install reality check
Use debian, can't go wrong with the installation. All you'll have to do is custom build your config and make sure that your hosts.allow allow amandad connection to go through. Total installation Time for Amanda on Debian was 5 minutes. Total installation time for Debian, 5 hours =) But its worth it in the end, and you'll get faster and faster. At 03:09 PM 2/6/2002 -0500, KEVIN ZEMBOWER wrote: For-what-it's-worth dept.: In the year that I've been a full-time Unix system administrator, I guess I've installed 40-50 different packages, mostly from source. Amanda was the second most time-consuming and difficult; only Xwindows was harder for me. -Kevin Zembower - E. Kevin Zembower Unix Administrator Johns Hopkins University/Center for Communications Programs 111 Market Place, Suite 310 Baltimore, MD 21202 410-659-6139 gene [EMAIL PROTECTED] 02/06/02 01:49PM snip I seem to be really struggling to get this to work. I did think it would be easier than this ;-) /snip Gene
RE: Amanda install reality check
On Wed, 6 Feb 2002 at 4:26pm, Bort, Paul wrote 1. REBDA (Read Everything Before Doing Anything) Where Everything is at least the chapter at www.backupcentral.com and docs/INSTALL (plus anything else relevant in docs, like SAMBA). 1a. Read it again. ;) Really. Wrapping your head around AMANDA can take a bit, but it's well worth it. 2. Be prepared to run the configure/install process a few times until you get it the way you want. 2a. Start with a config named Testing or something like that. Set record no. Play with it. Break it. Fix it. Any other suggestions from the list? 9. Watch out for firewalls you may not expect to be there, e.g. ipchains in default RedHat installs. 10. Restart (x)inetd. Yes, again. ;) 11. If/when you ask the list for help, be as detailed as possible about the problem. We're a friendly (usually), helpful bunch, but we ain't mind readers. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Amanda install reality check
The reality check point of the poster who started this thread is very valuable for the amanda community. It is true: amanda *is* complicated. Given that it does not cost anything, there is no point in complaining of course and that is not what I intend to do. However in my opinion the awareness of this problem is too low. I find it hard to believe that most standard amanda using unix system operators suggest ways to install amanda this way (quote is meant as an example for the common sense of list members / amanda operators): 1. REBDA (Read Everything Before Doing Anything) This hint is so vague that it really does not help much. You should read some files from the amanda source distribution, I agree, but where is the starting point *which* files to read, given you have a certain amount of backup technology knowledge? And what will you learn? What will you have to learn? In fact, there are only hints for reading. There is no official guide how to install amanda in a standard environment although of course standard environments exist or at least can be described. 2. Be prepared to run the configure/install process a few times until you get it the way you want. Inacceptable. Why the hell should OS software installs work the try and error way only? After reading the right documents (1.) I should be able to run configure, make and make install the correct way, maybe with a few options to configure, but not more. [...] 8. Build your own. Whoever made the RPM or DEB didn't have your network in mind. Most of the knowledge put into RPM spec files by for example RedHat is exactly what is missing for amanda newbies. No you can call your amanda user amanda and the group amanda, or use group disk, but make sure the permissions for the block devices, or let the amanda user be operator, but this is not recommended, and ..., where you *will* get messages like must be run as amanda; instead decisions which are unnecessary for the end user done by the RPM packager (we use amanda/disk and it works), the correct list of chown and chmod commands in the install script and so on. It is all defined by the vendor (RedHat here), and there is basically no reason to ever change these definitions. If the RPMs do not work the way they should, fix them and provide the fix to RedHat, but saying do not use RPMs is the hard way. We use both the amanda server and client RPMs from RH 7.1 and are happy with them. Moritz
Re: Amanda install reality check
On Thu, 7 Feb 2002 22:13, Moritz Both spake thus: The reality check point of the poster who started this thread is very valuable for the amanda community. It is true: amanda *is* complicated. Given that it does not cost anything, there is no point [snip] [...] 8. Build your own. Whoever made the RPM or DEB didn't have your network in mind. Most of the knowledge put into RPM spec files by for example RedHat is exactly what is missing for amanda newbies. No you can call your [snip] them and provide the fix to RedHat, but saying do not use RPMs is the hard way. Generally .deb's have worked very well for me with a range of complicated software: Postfix, Apache+PHP, even tho' later I may've gone on to compile them for various reasons. Amanda deb's caused lots of pain, and no quick ramp up to compiling. The fact that packages are ignored/not specifically documented (10 lines for debian specific stuff, the rest the standard amanda doc's) made it overly difficult for me to get Amanda going, and I had to learn by bug-tracking and painful doco scouring to fix the packaged install because the standard documentation mislead me, and the package did not document adequately. The debian package installs with user=backup, group=backup. So far so good. The doco says to put .amandahosts in $HOME. I couldn't understand why my hosts file had no effect until I clicked that the $HOME for user backup is /var/backup, and that the debian package symlinks /var/backup.amandahosts - /etc/amandahosts. Also the user doco and the chapter on backup central says cut and paste these lines into your /etc/inetd.conf. I couldn't see why I was getting user amanda cannot connect as backup@hostname, where a client had a compiled version (it was a messy Mandrake box for which dependencies were broken and compiling seemed easier). Of course you have to put the user name that the inetd service will be run as in the inetd.conf line: amanda dgram udp wait backup /usr/sbin/tcpd /usr/lib/amanda/amandad If you're busy and you don't have huge amounts of experience with the inetd.conf format the significance of the word backup as being the user to run that amandad daemon under just doesn't jump out at you. Some interactive post install scripts for the debian packages which put sensible defaults in and explained why, would save hours of agony. -- --- Sarah Hollings [EMAIL PROTECTED] --- IT ManagerPh +61 7 3365 6080 Fax +61 7 3365 6171 Key Centre for Human Factors and Applied Cognitive Psychology The University of Queensland, Saint Lucia, QLD 4072 Australia
Re: Amanda install reality check
Moritz Both [EMAIL PROTECTED] wrote:
I find it hard to believe that most standard amanda using unix
system operators suggest ways to install amanda this way (quote is
meant as an example for the common sense of list members / amanda
operators):
1. REBDA (Read Everything Before Doing Anything)
This hint is so vague that it really does not help much. You should
read some files from the amanda source distribution, I agree, but
where is the starting point *which* files to read, given you have a
certain amount of backup technology knowledge? And what will you
learn? What will you have to learn?
A different paradigm.
When I did an evaluation of available backup solutions some time ago,
it stunned me how vendors clouded up their basic concepts in marketing
must sound different hogwash. While there is still not much more than
{full,incremental,differential} backups, it takes time and effort to
make out who is doing what.
Amanda, too, comes with her own special terminology. Watch the number of
beginners stumbling into amanda-users with How can I schedule full
backups for the weekends...?.
In fact, there are only hints for reading. There is no official
guide how to install amanda in a standard environment although of
course standard environments exist or at least can be described.
There are the UofM papers that started the whole thing, and give the
general idea. Then there is a set of how-to docs and man pages. Print
them all out, duplex, two-up, bind them as you will want them anyway
when your server is down.
2. Be prepared to run the configure/install process a few times until
you get it the way you want.
Inacceptable. Why the hell should OS software installs work the try
and error way only? After reading the right documents (1.) I should
be able to run configure, make and make install the correct way, maybe
with a few options to configure, but not more.
Inacceptable? It's about getting a feeling for what's going on.
Backup/Restore is essential, and time for trying out and getting
familiar with essential tools is never wasted.
When you need the tool most, you may find yourself with a server
half-down, having to manually reconfigure/fix permissions etc.
[...]
8. Build your own. Whoever made the RPM or DEB didn't have your network
in mind.
[...]
If the RPMs do not work the way they should, fix
them and provide the fix to RedHat, but saying do not use RPMs is
the hard way.
We use both the amanda server and client RPMs from RH 7.1 and are
happy with them.
Huh.
Amanda as she stands is very much a unix administrators' tool. Five
machines are fine, fifteen even better. That is a setup in which an
administrator who cannot work himself out of a paper bag without a set
of shiny rpms will eventually find himself in trouble.
My 0.02 EUR,
hauke
--
Hauke Fath /~\The ASCII
tangro software components GmbH \ / Ribbon Campaign
D-69115 Heidelberg X Against
Ruf +49-6221-13336-0, Fax -21 / \ HTML Email!
Re: Amanda install reality check
On Thu, 7 Feb 2002, Hauke Fath wrote: Amanda as she stands is very much a unix administrators' tool. Five machines are fine, fifteen even better. That is a setup in which an administrator who cannot work himself out of a paper bag without a set of shiny rpms will eventually find himself in trouble. I think amanda falls under the qmail/smtpd category. If you have trouble installing it, maybe you should rethink whether you are qualified to implement the backup procedure. I'm not trying to be rude or take the elite attitude, but there are some systems that should only be admined by qualified individuals; to do otherwise is to create an environment for disaster. Amanda is a backup solution. Backup is a key element to any network setup, it is not something one should just implement and forget about. This is why so many are fed up with many of the commercial backup products, those products tend to hide as much of the details as possible. But knowing those details can at times mean the difference between huge data loss or saving the day yet again. Amanda may take a bit of effort to install, but in the process one learns quite a bit about how it works and what to expect. And once learned, further amanda installs are like falling off a log. $.02 Bill Carlson -- Systems Programmer[EMAIL PROTECTED] | Anything is possible, Virtual Hospital http://www.vh.org/ | given time and money. University of Iowa Hospitals and Clinics | Opinions are mine, not my employer's. |
RE: Amanda install reality check
--On Wednesday, February 06, 2002 22:20:47 -0600 W. D. [EMAIL PROTECTED] wrote: At 16:46 2/6/2002, Frank Smith, wrote: Forget about all fulls on weekend, incrementals weekdays Does this mean do full backups each time? No. it just means you might need to change your mindset from 'traditional' backup methods, where you might run full backups on Friday night (or the 1st of the month or whatever) and incrementals on other nights, to letting Amanda intermingle full and incrementals on each run, thereby getting better use out of your tape capacity. We use amanda for our 'traditional' backups, via multiple configs and cron. It works just fine, but OTOH, we aren't hurting for tape space. I've toyed with the idea of letting amanda just do its thing, but if more efficient tape use is the only advantage then I can't really justify the time/effort/pain it would take to configure and tweak it. Are there any other reasons to move away from our traditional ways? --Chris
Re: Amanda install reality check
--On Thursday, February 07, 2002 13:13:37 +0100 Moritz Both [EMAIL PROTECTED] wrote: 2. Be prepared to run the configure/install process a few times until you get it the way you want. Inacceptable. Why the hell should OS software installs work the try and error way only? After reading the right documents (1.) I should be able to run configure, make and make install the correct way, maybe with a few options to configure, but not more. I agree with you, but Amanda has way too much config information compiled in that (in my opinion) is better suited for the config file. If the paths/users/portranges/etc were read from the config file then there would be little need for recompiling. Frank -- Frank Smith [EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: Amanda install reality check
Bill Carlson [EMAIL PROTECTED] wrote: [...] I think amanda falls under the qmail/smtpd category. If you have trouble installing it, maybe you should rethink whether you are qualified to implement the backup procedure. Well... I think if you don't have trouble installing amanda for the first time, you are either using very good step by step instructions stating how it is done within your organization... or you are God :) I'm not trying to be rude or take the elite attitude, but there are some systems that should only be admined by qualified individuals; to do otherwise is to create an environment for disaster. Totally agreed. I also agree backups are a key element not only of networks, but of corporations. But this does not qualify as a reason why amanda installation must be complicated and can't be done using RPM. It is also true that the (approx.) month of work time that passes before your amanda backups are safe and in production in a let's say 10 client environment is valuable for the person who does it. You are getting very good knowledge of the internal processes of amanda almost automatically by studying the /tmp/amanda/* and amdump files. However, this will not help your organization when you are gone. Another guy will start learning it (installing, supervising, restoring) all over unless you have written the detailed step by step instructions mentioned above. But if you *have* written these instructions for all amanda tasks for your organization so you are replaceable, they will certainly contain shell scripts which install etc. - close to the same scripts that are in the RPM package. By the way, I do not believe in every network is different. Every network is similar. There are many more common things in all networks than differences. Greetings, Moritz
Re: Amanda install reality check
First I want to say thanks to the folks contributing to this thread. I'll be the first to admit the Amanda documentation could use more work (of course, I'd be the first to say that about almost *any* software :-). I'm watching the comments go by and will try to incorporate as much as possible. To save some time (which translates to getting things improved faster), I would ask that specific examples be cited where possible. Saying the whole thing sucks gets the point across :-) but doesn't help figure out how to make it better. It's much more helpful to suggest a specific paragraph or reference would be better if it said XXX. We use amanda for our 'traditional' backups, via multiple configs and cron. ... Are there any other reasons to move away from our traditional ways? I think you answered your own question :-). Look at the effort you had to put in (multiple configs, multiple cron entries) to bend Amanda into doing things the traditional way. Reduced effort is another reason for letting Amanda do its thing. That being said, though, comfort is a very important thing when it comes to backups. If you understand your setup and it works for you, that's by far the most important thing. --Chris John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Amanda install reality check
For-what-it's-worth dept.: In the year that I've been a full-time Unix system administrator, I guess I've installed 40-50 different packages, mostly from source. Amanda was the second most time-consuming and difficult; only Xwindows was harder for me. -Kevin Zembower - E. Kevin Zembower Unix Administrator Johns Hopkins University/Center for Communications Programs 111 Market Place, Suite 310 Baltimore, MD 21202 410-659-6139 gene [EMAIL PROTECTED] 02/06/02 01:49PM snip I seem to be really struggling to get this to work. I did think it would be easier than this ;-) /snip Gene
Re: Amanda install reality check
Any hints, tips or gotchas that would be helpful for the 'uninitiated'? (Especially FreeBSD HP SureStore DAT 40) At 14:09 2/6/2002, KEVIN ZEMBOWER, wrote: For-what-it's-worth dept.: In the year that I've been a full-time Unix system administrator, I guess I've installed 40-50 different packages, mostly from source. Amanda was the second most time-consuming and difficult; only Xwindows was harder for me. -Kevin Zembower - E. Kevin Zembower Unix Administrator Johns Hopkins University/Center for Communications Programs 111 Market Place, Suite 310 Baltimore, MD 21202 410-659-6139 gene [EMAIL PROTECTED] 02/06/02 01:49PM snip I seem to be really struggling to get this to work. I did think it would be easier than this ;-) /snip Gene Start Here to Find It Fast!© - http://www.US-Webmasters.com/start.htm
RE: Amanda install reality check
1. REBDA (Read Everything Before Doing Anything) 2. Be prepared to run the configure/install process a few times until you get it the way you want. 3. Remember to do both the server setup and client setup on the server. 4. Start by just backing up the backup server. 5. Start by changing tapes by hand. Add the changer once all the clients are working. 6. /tmp/amanda/*debug 7. Yes it's a complex install, but the reward is industrial-strength cross-platform backup and restore that you can hack to your specifications. (No Backup Exec bitterness here, no.) 8. Build your own. Whoever made the RPM or DEB didn't have your network in mind. Any other suggestions from the list? -Original Message- From: W. D. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 06, 2002 4:03 PM To: [EMAIL PROTECTED] Cc: KEVIN ZEMBOWER Subject: Re: Amanda install reality check Any hints, tips or gotchas that would be helpful for the 'uninitiated'? (Especially FreeBSD HP SureStore DAT 40) At 14:09 2/6/2002, KEVIN ZEMBOWER, wrote: For-what-it's-worth dept.: In the year that I've been a full-time Unix system administrator, I guess I've installed 40-50 different packages, mostly from source. Amanda was the second most time-consuming and difficult; only Xwindows was harder for me. -Kevin Zembower - E. Kevin Zembower Unix Administrator Johns Hopkins University/Center for Communications Programs 111 Market Place, Suite 310 Baltimore, MD 21202 410-659-6139 gene [EMAIL PROTECTED] 02/06/02 01:49PM snip I seem to be really struggling to get this to work. I did think it would be easier than this ;-) /snip Gene Start Here to Find It Fast!© - http://www.US-Webmasters.com/start.htm
RE: Amanda install reality check
Forget about all fulls on weekend, incrementals weekdays Check your index files for Big Numbers. Make sure you can do a restore. Use Amanda in parallel with your existing backups until you are comfortable with your ability to restore your data. Frank --On Wednesday, February 06, 2002 16:26:44 -0500 Bort, Paul [EMAIL PROTECTED] wrote: 1. REBDA (Read Everything Before Doing Anything) 2. Be prepared to run the configure/install process a few times until you get it the way you want. 3. Remember to do both the server setup and client setup on the server. 4. Start by just backing up the backup server. 5. Start by changing tapes by hand. Add the changer once all the clients are working. 6. /tmp/amanda/*debug 7. Yes it's a complex install, but the reward is industrial-strength cross-platform backup and restore that you can hack to your specifications. (No Backup Exec bitterness here, no.) 8. Build your own. Whoever made the RPM or DEB didn't have your network in mind. Any other suggestions from the list? -Original Message- From: W. D. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 06, 2002 4:03 PM To: [EMAIL PROTECTED] Cc: KEVIN ZEMBOWER Subject: Re: Amanda install reality check Any hints, tips or gotchas that would be helpful for the 'uninitiated'? (Especially FreeBSD HP SureStore DAT 40) At 14:09 2/6/2002, KEVIN ZEMBOWER, wrote: For-what-it's-worth dept.: In the year that I've been a full-time Unix system administrator, I guess I've installed 40-50 different packages, mostly from source. Amanda was the second most time-consuming and difficult; only Xwindows was harder for me. -Kevin Zembower - E. Kevin Zembower Unix Administrator Johns Hopkins University/Center for Communications Programs 111 Market Place, Suite 310 Baltimore, MD 21202 410-659-6139 gene [EMAIL PROTECTED] 02/06/02 01:49PM snip I seem to be really struggling to get this to work. I did think it would be easier than this ;-) /snip Gene Start Here to Find It Fast!© - http://www.US-Webmasters.com/start.htm -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
RE: Amanda install reality check
At 16:46 2/6/2002, Frank Smith, wrote: Forget about all fulls on weekend, incrementals weekdays Does this mean do full backups each time? Check your index files for Big Numbers. Big files? Make sure you can do a restore. Use Amanda in parallel with your existing backups until you are comfortable with your ability to restore your data. Frank --On Wednesday, February 06, 2002 16:26:44 -0500 Bort, Paul [EMAIL PROTECTED] wrote: 1. REBDA (Read Everything Before Doing Anything) 2. Be prepared to run the configure/install process a few times until you get it the way you want. 3. Remember to do both the server setup and client setup on the server. 4. Start by just backing up the backup server. 5. Start by changing tapes by hand. Add the changer once all the clients are working. 6. /tmp/amanda/*debug 7. Yes it's a complex install, but the reward is industrial-strength cross-platform backup and restore that you can hack to your specifications. (No Backup Exec bitterness here, no.) 8. Build your own. Whoever made the RPM or DEB didn't have your network in mind. Any other suggestions from the list? -Original Message- From: W. D. [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 06, 2002 4:03 PM To: [EMAIL PROTECTED] Cc: KEVIN ZEMBOWER Subject: Re: Amanda install reality check Any hints, tips or gotchas that would be helpful for the 'uninitiated'? (Especially FreeBSD HP SureStore DAT 40) At 14:09 2/6/2002, KEVIN ZEMBOWER, wrote: For-what-it's-worth dept.: In the year that I've been a full-time Unix system administrator, I guess I've installed 40-50 different packages, mostly from source. Amanda was the second most time-consuming and difficult; only Xwindows was harder for me. -Kevin Zembower - E. Kevin Zembower Unix Administrator Johns Hopkins University/Center for Communications Programs 111 Market Place, Suite 310 Baltimore, MD 21202 410-659-6139 gene [EMAIL PROTECTED] 02/06/02 01:49PM snip I seem to be really struggling to get this to work. I did think it would be easier than this ;-) /snip Gene Start Here to Find It Fast!© - http://www.US-Webmasters.com/start.htm -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501 Start Here to Find It Fast!© - http://www.US-Webmasters.com/start.htm
RE: Amanda install reality check
--On Wednesday, February 06, 2002 22:20:47 -0600 W. D. [EMAIL PROTECTED] wrote: At 16:46 2/6/2002, Frank Smith, wrote: Forget about all fulls on weekend, incrementals weekdays Does this mean do full backups each time? No. it just means you might need to change your mindset from 'traditional' backup methods, where you might run full backups on Friday night (or the 1st of the month or whatever) and incrementals on other nights, to letting Amanda intermingle full and incrementals on each run, thereby getting better use out of your tape capacity. Check your index files for Big Numbers. Big files? No, big numbers in front of each line in the index file, i.e.: 16230523 /export/home/myjunk instead of: /export/home/myjunk The numbers in front of each line are a result of using a bad version of tar, and if your index files contain them then you probably will be unable to restore much (if any) of your data. So if you see them, you better quickly get a known working version of tar and force a full backup of the affected filesystems ASAP. Frank -- Frank Smith [EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
