Re: MT
On Sat, 2 Dec 2000, Joi Ellis wrote: On Sat, 2 Dec 2000, John R. Jackson wrote: [snip] ... mt is missing from my system. Before I reinstalled 2.4.2 the second time, due to it not installing over 2.4.1p1 cleanly the first time, I used turbopkg to remove 'amanda, amanda-client, amanda-server and taper' all listed under a broader heading of 'System - Backup'. Do you know which of these removed mt as well? ... [snip] If I had to guess, it would be "taper". I would have thought what Amanda calls taper would be part of amanda-server. On my Red Hat systems, mt is provided by its own RPM. It isn't bundled with amanda. mt is not in 6.2's taper package, either. Taper is a completely different little backup program. I tried it some ages ago and dropped it immediately as it seems it couldn't handle very large backups (I don't remember wheather it was data size or the amount of files but anyway). It shouldn't have anything to do with mt, tar or amanda (except that it *maybe* uses mt..).
Error on Screen
After I installed Amanda and seemed to have it working the computer started throwing the following error: Unusual System Events =-=-=-=-=-=-=-=-=-=-= Dec 2 00:45:18 kernel: (scsi0:0:5:0) Invalid SCB during SEQINT 0x71, SCB_TAG 80. Dec 2 00:45:18 kernel: (scsi0:-1:-1:-1) CMDCMPLT with invalid SCB index 80 Dec 2 01:00:18 kernel: scsi : aborting command due to timeout : pid 2115197, scsi0, channel 0, id 5, lun 0 Mode Sense 00 00 00 0c 00 Dec 2 00:45:00 xinetd[22089]: START: amanda pid=30116 from=127.0.0.1 Dec 2 01:00:33 xinetd[22089]: START: amanda pid=30135 from=127.0.0.1 Dec 2 01:00:48 xinetd[22089]: START: amanda pid=30144 from=127.0.0.1 Would this be caused by amanda??? or is it another problem and just a coincidence.
nfs mounts
I have amanada client with nfs mounts, does amanda backup nfs mounts also. If it does is there a way to exlude it based on file system type. Shakaib Sayyid
Re: help pls: Additional information
Hi all,
after some problems .. finally I managed to install and make run Amanda
using the rpms given with RedHat7.0
As you saw reading teh posts in this mailing list I had several
problems. Most of them were caused by my poor experience with backup
tools, but a couple of them were caused by the RedHat distribution. What
follows is a short review of the problems that I found ... I hope that
it can be helpful to some reader of this mailing list.
I installed the following 3 rpm files :
amanda-2.4.1p1-18.i386.rpm
amanda-client-2.4.1p1-18.i386.rpm
amanda-server-2.4.1p1-18.i386.rpm
using the command "rpm -i amanda"
The problems were :
1) the rpm files don't create a file amandad in /etc/xinetd.d, so you
have to create one :
#xinetd.d file = amandad#
# default: off
#
# description: Part of the Amanda server package
service amanda
{
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = disk
server = /usr/lib/amanda/amandad
disable = no
}
after this you have to create an entry in hosts.allows as well ... I
added the following line on the server PC:
ALL: localhost 127.0.0.1 128.197.61.90
2) All the files are installed using the user "operator" ... the problem
is that his home directory is /root ... I strongly advice to create a
separate home directory for the user "operator", change the /etc/passwd
accordingly and move the file /root/.amandahosts to the newly created
directory, changing the permissions accrodingly.
3) Some of the files and directories needed by amanda are not created
upon installation of the rpm files and have to be created (you can
easily trace which file/directory is missing reading the output of
amcheck!!).
4) I used the following amandaidx amidxtape files :
#xinetd.d file = amandaidx#
# default: off
#
# description: Part of the Amanda server package
service amandaidx
{
socket_type = stream
protocol= tcp
wait= yes
user= operator
group = disk
server = /usr/lib/amanda/amindexd
disable = no
}
#xinetd.d file = amidxtape#
# default: off
#
# description: Part of the amanda server package
#
service amidxtape
{
socket_type = stream
protocol= tcp
wait= no
user= operator
group = disk
server = /usr/lib/amanda/amidxtaped
disable = no
}
I hope that this will help!!!
Bye, Antonino Casile
Re: Error on Screen
After I installed Amanda and seemed to have it working the computer started throwing the following error: ... Would this be caused by amanda??? or is it another problem and just a coincidence. Amanda cannot cause hardware errors. It's a simple user level program. It can, however, exercise your system in ways that hadn't been tested before (e.g. streaming data to your tape) and in the process shake out a hardware problem. John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: nfs mounts
I have amanada client with nfs mounts, does amanda backup nfs mounts also. If it does is there a way to exlude it based on file system type. You're asking the wrong question. Amanda does not back up anything. It runs some other program that does the backups. So it would depend on what program you told Amanda to use. However, all system dump programs (e.g. ufsdump, dump, vxdump) only do a single file system and would not cross into another file system, NFS mounted or not. If you use GNU tar, Amanda passes it the option to do the same thing, i.e. not cross into a file system other than the one it starts out in. So unless you use GNU tar and explicitly tell it to back up one of those NFS mount points, I'd say they will be ignored. Shakaib Sayyid John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Error on Screen
"Joe Prochazka" [EMAIL PROTECTED] writes: After I installed Amanda and seemed to have it working the computer started throwing the following error: Unusual System Events =-=-=-=-=-=-=-=-=-=-= Dec 2 00:45:18 kernel: (scsi0:0:5:0) Invalid SCB during SEQINT 0x71, SCB_TAG 80. Dec 2 00:45:18 kernel: (scsi0:-1:-1:-1) CMDCMPLT with invalid SCB index 80 Dec 2 01:00:18 kernel: scsi : aborting command due to timeout : pid 2115197, scsi0, channel 0, id 5, lun 0 Mode Sense 00 00 00 0c 00 Dec 2 00:45:00 xinetd[22089]: START: amanda pid=30116 from=127.0.0.1 Dec 2 01:00:33 xinetd[22089]: START: amanda pid=30135 from=127.0.0.1 Dec 2 01:00:48 xinetd[22089]: START: amanda pid=30144 from=127.0.0.1 Would this be caused by amanda??? or is it another problem and just a coincidence. Looks like a SCSI error (termination?).
Re: Completely Stuck :-(
... In fact, on further investigation, *nothing* works from inetd unless its running as root! ... Yikes. After you send inetd a HUP (and wait a minute), is there anything of interest in /var/adm/messages? Do you actually have a user "amanda" (or whatever) defined? Is it local (/etc/passwd) or are you one of those silly NIS people? :-) If none of this helps, the next thing I'd try is starting a truss on inetd itself and making a connection that does not work, then look at that output. - John John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda to blame for NT crashes?
On Mon, 4 Dec 2000, Harri Haataja wrote: Date: Mon, 4 Dec 2000 09:28:57 +0200 (EET) From: Harri Haataja [EMAIL PROTECTED] Cc: "[EMAIL PROTECTED]" [EMAIL PROTECTED] Subject: Re: amanda to blame for NT crashes? On 2 Dec 2000, Marc SCHAEFER wrote: Fynnily enough I have some first hand information (that I can't cite =) that says opposite. M$ has a very fine-grained, big-budget, efficient (?) testing scheme but somehow that doesn't seem to do the job. Not all bugs are discovered by testing. With the mess M$ has made of the smb protocols, it's a wonder it still works at all. Every release of windows has come with a changed protocol. There's all sorts of oddness in each version to allow it to talk smb-like with all previous versions. It's a horrible mess. (An ex-Microserf told me this.) I'm surprised Samba works at all! I presume you mean windos clients are used to test smb shares? This is quite likely to be a culprit. But then again m$ has a history of breaking standards and protocols on purpose and always blaming the other end. This thread (the start) seems to have proven that the idea has gone through very well -- their users have absolute faith in them and always blame someone (-thing) else. Boy, can I tell you some stories about Microsoft re-writing email internet standards! And F77 language standards, too... Nevertheless, I agree that if windows crashes, windows has a bug/flaw/lacking (depending on wheather what made it crash was use/unexpected_use/downright_cruel_use) there. Yes. But then, M$ has never felt that a GPF was anything to avoid. :p -- Joi Ellis [EMAIL PROTECTED], http://www.visi.com/~gyles19/
Re: amanda to blame for NT crashes?
It happened this one time. I spent about an hour looking for more info, but was unable to find any. If it crashes again, I'll dig deeper into the issue. --- Eric On Fri, 1 Dec 2000, Joi Ellis wrote: On Fri, 1 Dec 2000, John R. Jackson wrote: Date: Fri, 01 Dec 2000 18:31:07 -0500 From: John R. Jackson [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Eric Wadsworth [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: amanda to blame for NT crashes? [ My apologies in advance for the following. I normally brag about how little heat there is on this mailing list, but I'm sure going to break that mold below. If it helps, pretend I'm trying to be funny. --JJ ] ... My co-workers are saying that it is amanda's fault ... I just searched through samba.org's mail archive, and there are reports there of NT blue-screening during a smbtar pull from Unix hosts. I haven't come across a response to that, someone who has more time may want to search harder through the archives for an answer. -- Joi Ellis [EMAIL PROTECTED], http://www.visi.com/~gyles19/
Re: amanda to blame for NT crashes?
Alexandre Oliva wrote: I don't care if the mechanisms are out of AMANDA's influence - this is a design issue. Indeed. Amanda is designed to be a backup manager, that knows how to use a couple of existing backup tools. If none of them fit your needs, well, then you just have to go find some backup program capable of backing up stuff you need and plug it into Amanda. See? It's not Amanda's fault. I see. I will have to devise something myself to help me out of this. I admit I had not expect this. If you say that AMANDA can backup SAMBA shares, people will believe it and be happy. And they can believe it. I do it every day. Many others do it. Just because it fails for some unlucky souls, it doesn't mean it doesn't work at all. Most likely, it's some detail in these souls' setups that can be easily fixed. That "detail" might be writing a wrapper script, computing datestamps, redesigning the wheel...:-) The case that does not work is when you have a dual boot system (Win/Linux) and the SAMBA shares you are trying to backup with AMANDA (when running Linux) are the vfat partitions of Windows. Ok, so how about this idea: get Plex86 or VMWare, boot Windows atop GNU/Linux, share the disks you want to back up and tell Amanda to back them up using Samba. Then, wait for the blue screens :-) :-) I am glad I had the same idea before I read your answer (see my other posting) ;-) Believe me, I would try it, but for the moment it is out of the question because of the computing power needed by VMware (the backup server is a 486DX-133...). Except for this minor detail people keep forgetting, which is that Amanda just *manages* backups, it doesn't *create* them. I will have to make this statement my daily mantra, until I get it. Thanks for all the input. -- Regards Chris Karakas Dont waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
"John R. Jackson" wrote:
You understand a chance as a curse: AMANDA _has_ the qualities to become
a real, integrative, superlative backup tool. ...
So explain to me exactly what you think Amanda should do to solve this.
And keep in mind that the design philosophy is that it uses other tools
and that it does **not** do the work itself.
Separate "estimator programs" from "backup programs". As it is now, if I
decide to use tar for my backups, it will also be used for the
estimation phase (which is where my problem is: estimation of
incrementals). But tar may not be estimating correctly in my case,
although it may be perfect in backing up.
So the idea is to give us the chance to write our own "estimator
function": a script that gets a filename, a date and/or a backup level
(and perhaps also other parameters) as input and gives a boolean as
output ("yes, it should be backed up" or "no, it shouldn't"). This
script will have a "default" code in it: if tar is used, then tar is
invoked to determine if the file should be backed up, if dump is used,
then dump is invoked for the estimation, otherwise...a custom code
should go here. If the user decides to put custom code in there, he
should comment the default coding. He can then check the file's inodes,
ctimes, the phase of the moon or whatever else he deems aproppriate to
decide whether it should be backed up or not, in the given incremental
level and/or date.
The way it is now, I have to change tar itself, writing a wrapper around
it, taking into account who started it, whether it was for estimation,
backup, or restore etc. This makes the task more formiddable than it
already is (for unskilled programmers like me).
By the way: Why shouldn't I be able to use dump for the estimations and
tar for the backups (and vice-versa)? This solution (assuming it is one,
i.e. assuming that dump estimates correctly where tar does not), is less
general than the above, but should take you only another parameter in
amanda.conf and some case checking to implement with the existing code.
--
Regards
Chris Karakas
Dont waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
Jon LaBadie wrote: On Sat, Dec 02, 2000 at 03:28:49AM +0100, Chris Karakas wrote: If you say that AMANDA can backup SAMBA shares, people will believe it and be happy. People like me (a mathematician...) will believe it so much, that they will eventually construct a case that does not work - and will get a problem. The case that does not work is when you have a dual boot system (Win/Linux) and the SAMBA shares you are trying to backup with AMANDA (when running Linux) are the vfat partitions of Windows. Just because exceptions confirm the rules, does not mean that we should not point them out. I'm missing something here. If I have it correct you have some client systems that run windows (maybe some linux clients too). Your amanda backup host runs linux, but is also bootable into windows. Further, it is the windows partitions on the backup host you are having difficulties with. Am I correct? Yes. If so, I don't understand where samba comes into play. Window's is not running to share the vfat partitions so you must be simply mounting them as vfat file systems under linux. In that case I would think normal tar would work. It does for me on my dual-boot Solaris box with windows partitions mounted under that os. No need for samba or smbtar or ... I've been trying for 6 months now to get the Windows partitions on the backup server to be backed up correctly while running Linux and AMANDA. I first tried it as follows: I told AMANDA to backup the SAMBA shares that a SAMBA server made available on the backup server. The SAMBA server got those shares from as mounted vfat partitions. This is where SAMBA came into play. It did not work - incrementals were almost as big as full backups. Then I said myself "why have this SAMBA stuff at all? Just mount the vfat partitions and tell AMANDA to use tar and backup the mount point directory". This did not work either for the same reason. I am still looking for a solution. You understand a chance as a curse: AMANDA _has_ the qualities to become a real, integrative, superlative backup tool. Some would say it already is :)) Well, maybe for many people, but still not for me, because it cannot handle the above situation sufficiently. And, now that all this discussion is going on, I know I am not alone - another participant said he gave up on backing up Windows partitions just because of this. Be aware that amanda is NOT a backup program. It is a backup manager. There are no backup programs nor recovery programs supplied with it. Only interfaces to other, non-supplied programs. It was also created as a unix backup manager, not for windows, samba, oracle, mvs, or anything else. That it can and has been used for these purposes is a compliment to its design. To suggest that the people who maintain amanda should be responsible for the programs that it schedules and manages is analogous to saying the people who wrote the cron deamon on unix are responsible for debugging the programs cron kicks off. O.K, I have understood that. Now I want you to understand that I have a problem (the above one) and I cannot find a solution with AMANDA. When I read the "AMANDA chapter" on backupcentral.com, stating that "Recent versions can also use SAMBA to back up Microsoft Windows (95/98/NT/2000)-based hosts", I thought "Fine! That's the _ultimate_ solution!". It turned out that the above statement may be technically correct, but somewhat misleading to the unaware: when you use SAMBA for the vfat partitions of your dual boot system, it does not work. It seems that either you have to run Windows on those partitions the same time that you run Linux and AMANDA to back them up (which is impossible on a dual boot system...eh, OK, maybe VMware could solve this "detail") or run the SMB shares that you want to backup on ext2, not vfat, filesystems (also impossible for a dual boot system, as long as Windows does not run on ext2 ;-)). It does not work even if you abandon SAMBA and just try to backup a vfat directory. The problem is estimating the incrementals and has more to do with tar, vfat, the kernel, or whatever, than AMANDA itself but I insist on refining the above statement by pointing out this - admittedly very special - case, where it is just not true. Believe me, I will be very happy to find out that this refinement is not necessary and that I was wrong after all ;-) -- Regards Chris Karakas Dont waste your cpu time - crack rc5: http://www.distributed.net
Re: GNU tar estimates for vfat filesystems (Was: How do I checklevel 1 sizes?)
Alexandre Oliva wrote: I don't know how different it would be, but, if you eventually find out it's too much, tell Amanda to use a wrapper script instead of GNU tar in which you check whether the directory being backed up is in a vfat filesystem, then replace the `--listed-incremental filename' arguments with `--incremental'. However, you'll still be missing the `--newer' flag, that is passed when GNUTAR_LISTED_INCREMENTAL_DIR is used. You may have to work around this problem by reading/storing timestamps in the `filename' argument. Thank you, I will have to try all this out. -- Regards Chris Karakas Dont waste your cpu time - crack rc5: http://www.distributed.net
Re: amanda to blame for NT crashes?
On Mon, 4 Dec 2000, Chris Karakas wrote: I've been trying for 6 months now to get the Windows partitions on the backup server to be backed up correctly while running Linux and AMANDA. I first tried it as follows: I told AMANDA to backup the SAMBA shares that a SAMBA server made available on the backup server. The SAMBA server got those shares from as mounted vfat partitions. This is where SAMBA came into play. It did not work - incrementals were almost as big as full backups. Then I said myself "why have this SAMBA stuff at all? Just mount the vfat partitions and tell AMANDA to use tar and backup the mount point directory". This did not work either for the same reason. I am still looking for a solution. My amamda server is an Intel box which dual-boots NT and Linux Red hat 6.2. /dev/hda1 is the NT C: boot partition /dev/hda5 is the NT D: extended partition However, I have the mounted RO on the linux side because I often use them with VMWare from Linux, effectively multi-booting my box. ;) Mounted RO, Gnu tar sees them as /mnt/doscb and /mnt/dosdb. I could have accessed them via samba instead, since my VMWare appears to my Linux personality as a completely separate system with its own Hostname and IP Address. I played with this and it does work, but I don't use it because I rarely leave VMWare running for long periods of time. (It consumes half my ram and degrades my native Linux JBuilder application, which also consumes half my ram. Running them both causes my machine to start swapping heavily, and since I spend most of my time doing Java development, I launch VMWare only when I need to do excel stuff.) You could try a VMWare-hosted smbtar backup. -- Joi Ellis [EMAIL PROTECTED], http://www.visi.com/~gyles19/
Woody problems
Hello, We have an office full of machines mostly running Storm Linux (Debian Potato based). Our Amanda server is running Amanda version 2.4.1p1. Several people in the office have upgraded their machines to Debian Woody and Amanda no longer backs them up. An example of the error message in the daily mail report is as follows: /-- nheron /home/nheron lev 0 FAILED [/sbin/dump returned 1] sendbackup: start [nheron:/home/nheron level 0] sendbackup: info BACKUP=/sbin/dump sendbackup: info RECOVER_CMD=/bin/gzip -dc |/sbin/restore -f... - sendbackup: info COMPRESS_SUFFIX=.gz sendbackup: info end ? You can't update the dumpdates file when dumping a subdirectory sendbackup: error [/sbin/dump returned 1] \ The clients are running amanda-client version 2.4.1p1-12 and dump version 0.4b20-1. I notice the dump version is different between Woody and Potato (0.4b16-1) but even downgrading to the Potato version didn't help. There are lots of strange things that happen when upgrading to Woody but everything seems to be running fine now. There is probably something that should be running that is not, however, and I don't have much experience running Amanda and don't know where else to look to solve the problem. Any help anyone could offer would be greatly appreciated. Thanks very much, Owain -- | Owain Davies| Storm Linux| | Internal Systems Administrator | Its time to close the Windows | | Stormix Technologies Inc. | http://www.stormix.com/| --
Re: amanda to blame for NT crashes?
So explain to me exactly what you think Amanda should do to solve this. And keep in mind that the design philosophy is that it uses other tools and that it does **not** do the work itself. Separate "estimator programs" from "backup programs". ... If you find an estimator program that works, you can get Amanda to call it by faking the GNU tar that is used. See: ftp://gandalf.cc.purdue.edu/pub/amanda/gtar-wrapper.* ... Why shouldn't I be able to use dump for the estimations and tar for the backups ... Because they may (and in fact do) have different ideas of how big the image will be. Backing up **exactly** the same files with both will give you different sized images because the format is wildly different. So it's pointless to use one for the other. Why not syntax check your code with Fortran and then actually compile it with C? However, if you want to do something like this, feel free to implement the Amanda DUMPER-API, which should allow for such strange things. Chris Karakas John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amflush wait for amdump to finish?
Should I wait until amdump finishes before I do an amflush? ... You have to. It will report an error otherwise. The flush would be of the stuff that amdump is currently dumping to. Huh? Are you deliberatly trying to write it to two tapes? Eric Wadsworth John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda to blame for NT crashes?
On Dec 4, 2000, Chris Karakas [EMAIL PROTECTED] wrote:
So the idea is to give us the chance to write our own "estimator
function": a script that gets a filename, a date and/or a backup level
(and perhaps also other parameters) as input and gives a boolean as
output ("yes, it should be backed up" or "no, it shouldn't").
That's exactly what the `sendsize' program is. You'll even find hooks
for a `calcsize' program in there. Of course, you can modify it so as
to call whatever other program you want, but using the wrapper script
suggested by JJ is far easier, at least before the DUMPER API is
implemented.
Note that you don't have to replace GNU tar with the script: just
configure Amanda so that it uses your replacement script as if it were
GNU tar and you're done.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: amlabel
On Dec 3, 2000, Clement Kumah [EMAIL PROTECTED] wrote:
rewinding, reading label DailySet101, tape is active
rewinding, writing label DailySet101, checking label, done.
amlabel in free(): warning: junk pointer, too high to make sense.
I recall having introduced a bug in 2.4.2-beta1 while introducing the
ability to verify labels (which also tests whether you're using a
non-rewinding device). The bug has been corrected in 2.4.2 final.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
