Re: drive compression discovery
On Mon March 10 2003 14:49, Marty Shannon, RHCE wrote: >Eric Sproul wrote: >> Also, my system is Linux, so there >> are no compression-related device names. > >Actually, all Linux Amanda users should read and understand (and > implement) the stinit man page. Once you've built a proper > "/etc/stinit.def" for your drive(s), and make the proper device > nodes, you should never have any issues with compression again. While I agree wholeheartedly Marty, all advice of this nature should be surrounded by qualifiers. In this case the file doesn't exist on this RH8.0 system. And while there is a manpage, attempting to setup the .def file without access to info that is authoritative *about that drive*, rapidly becomes an exersize in futility. Access to such info can be had, this is generally true for the major labels, but when the manual that might explain it in sufficient detail as to allow the intelligent construction of that stinit.def file costs $85, I do not consider it worth the effort and $$. That BTW was the quoted price for service manual on my 4586np, obtained by a phone call to Okla. City. So in this case the qualifier is possession of enough info. Other than word of mouth on this list, many drives are nothing but black boxes, with many good features never used because no one knows about them. Thats what this list is all about, enhancing the possibility of someone else having first hand experience with the particular black box the poster has, and that someone else has known and lived with enough to help the latecomer. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.24% setiathome rank, not too shabby for a WV hillbilly
Re: drive compression discovery
On Mon March 10 2003 14:13, Eric Sproul wrote: >Hi all, >I'm familiar with the general theory of how to "rescue" an AMANDA > tape that's been written with drive compression turned on. > Here's my situation: > >I've completed my first dumpcycle with my current config, and I'm >fairly certain that drive compression has been turned off the > whole time, but I'm not 100% sure. I now have in place a script > that ensures drive compression is off, but it was not put in > place until a number of runs had been done. I want to make sure > all the tapes are uncompressed before I reuse them. > >My question: If I do a dd of some amount of data (like dumping > the first 32K of data as I would if I was saving the label), and > then see (via mt) that the drive's compression is still off, is > it safe to conclude that the tape was written with compression > off? > I believe so. If the drive has a front panel indicator of compression use like mine does, I'd use that for the last word. >I've read posts that indicate a compressed tape will silently set > drive compression back on, but will that change still be visible > to mt? AFAIK, yes. >BTW, the drive has no DIP switches for setting compression-- That would definitely be unusual... The lawyers have attacked the user stuff in the packaging to the point where it may not be mentioned (I mean "Now why would the *user* need to know that?), and I'd come a lot closer to being able to believe that as opposed to its not having any jumpers or dip switches at all to control its powerup defaults. > it is >completely controlled by software. Also, my system is Linux, so > there are no compression-related device names. I am relying > strictly on mt to manipulate the drive outside of AMANDA, so it's > important that I be able to trust its output. How are you interpreting the mt report so as to define if compression is on or off? I don't recall seeing that in plain english in any mt output report since about RH5.2, and it has changed a bit. Its concise to the point of being obtuse IMO. -- Cheers, Gene AMD [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 512M 99.24% setiathome rank, not too shabby for a WV hillbilly
Re: confusion about exclude lists
On Mon, Mar 10, 2003 at 03:53:03PM -0800, Rob Helmer wrote: > Hello, > > > I am backing up Solaris hosts, and I want to use Amanda and > GNUtar to do it, but I am a bit confused about how (in)flexible > exclude lists are with GNUtar .. > > Currently, I have the server set up to back itself up, I have > an exclude.gtar file, and I am backing up the / and /usr/local > slices. > > Is there any way I can have one exclude.gtar for /, and one > for /usr/local ? For example, I may want /etc and not > /usr/local/etc, or vice versa and the exclude list would > look at both as an entry for "etc". >From amanda.conf: #If a relative pathname is specified as the exclude list, #it is searched from within the directory that is #going to be backed up. Thus, each DLE can have its own exclude file. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
confusion about exclude lists
Hello, I am backing up Solaris hosts, and I want to use Amanda and GNUtar to do it, but I am a bit confused about how (in)flexible exclude lists are with GNUtar .. Currently, I have the server set up to back itself up, I have an exclude.gtar file, and I am backing up the / and /usr/local slices. Is there any way I can have one exclude.gtar for /, and one for /usr/local ? For example, I may want /etc and not /usr/local/etc, or vice versa and the exclude list would look at both as an entry for "etc". Or am I going about this the wrong way? Thanks, Rob
Re: Problem with Solaris Amanda Build
On Mon, Mar 10, 2003 at 01:25:17PM -0500, Brian Cuttler wrote: > John, > > I wasn't able to figure out what was wrong with the changer-src > Makefile, however I was able to get around it. > > My fix is rather unorthadox and not recommended and I have no idea > what I might have broken or what now failed to compile so if you > follow this bit of 'programming' you take your chances. > > The affected (aflicted?) section of code as diplayed via > # cat -evt, because Makefiles are touchy about white-space > > uninstall-am: uninstall-info-am uninstall-libexecPROGRAMS \$ > ^Iuninstall-libexecSCRIPTS$ > $ > .PHONY: GTAGS all all-am check check-am clean clean-generic \$ > ^Iclean-libexecPROGRAMS clean-libtool distclean distclean-compile \$ > ^Idistclean-depend distclean-generic distclean-libtool \$ > ^Idistclean-tags distdir dvi dvi-am info info-am install \$ > ^Iinstall-am install-data install-data-am install-exec \$ > ^Iinstall-exec-am install-info install-info-am \$ > ^Iinstall-libexecPROGRAMS install-libexecSCRIPTS install-man \$ > ^Iinstall-strip installcheck installcheck-am installdirs \$ > ^Imaintainer-clean maintainer-clean-generic mostlyclean \$ > ^Imostlyclean-compile mostlyclean-generic mostlyclean-libtool \$ > ^Itags uninstall uninstall-am uninstall-info-am \$ > ^Iuninstall-libexecPROGRAMS uninstall-libexecSCRIPTS$ > $ > ^I^I^Ichg-null$ > > I was unable to figure out what was wrong with this code, specifically > the error seemed to be on the line ending "distclean-compile \$" > > ...so I deleted the entire section ie the ".PHONY:" tag down to the > next white line. > > Like I said, I don't know what I broke along the way, make run from > the root ran to completion though. I'm pretty certain the real culprit is "chg-null" line after the ".PHONY" line. Either delete that or comment it out and the compile succeeds on my Solaris 9 system. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: drive compression discovery
On Mon, 2003-03-10 at 14:49, Marty Shannon, RHCE wrote: > Eric Sproul wrote: > > Also, my system is Linux, so there > > are no compression-related device names. > > Actually, all Linux Amanda users should read and understand (and implement) the > stinit man page. Once you've built a proper "/etc/stinit.def" for your > drive(s), and make the proper device nodes, you should never have any issues > with compression again. Actually, as I found out, the Debian mt-st package's init script only runs stinit if st support is compiled into the kernel. If you use modules, you need to set up a 'post-install' command in modules.conf, so when modprobe loads the module, it will run this command. Debian uses an additional mechanism for customizing modules.conf, so users of other distros may just be able to directly modify modules.conf with the post-install command listed. Also check your mt's man page for the particular commands it accepts. I previously used GNU mt, but have switched to mt-st, version 0.7. For Debian: I entered the following line in /etc/modutils/actions post-install st mt -f /dev/nst0 compression off Then I ran update-modules(8), which integrated this change into my modules.conf. I did an 'rmmod st' and verified with lsmod and dmesg that the st module was no longer loaded. Then I did a 'modprobe st'. Using tapeinfo(1) from the mtx package, I saw that the drive was initialized with compression off, thanks to the post-install command. Eric
Re: drive compression discovery
On Mon, 2003-03-10 at 14:49, Marty Shannon, RHCE wrote: > Eric Sproul wrote: > > Also, my system is Linux, so there > > are no compression-related device names. > > Actually, all Linux Amanda users should read and understand (and implement) the > stinit man page. Once you've built a proper "/etc/stinit.def" for your > drive(s), and make the proper device nodes, you should never have any issues > with compression again. Marty, Sounds like a great plan. I got the Debian 'mt-st' package, replacing the GNU mt that comes with the cpio package. I checked out the example definition file, and I have a question not answered in the man page. Must I define all modes even if I only ever want to use one? I plan to always use blocksize=0 and compression=0, so should I just define 'mode1'? Thanks, Eric
Re: drive compression discovery
On Mon, 10 Mar 2003 at 2:13pm, Eric Sproul wrote > I've read posts that indicate a compressed tape will silently set drive > compression back on, but will that change still be visible to mt? This all depends on the type of drive. > BTW, the drive has no DIP switches for setting compression-- it is > completely controlled by software. Also, my system is Linux, so there > are no compression-related device names. I am relying strictly on mt > to manipulate the drive outside of AMANDA, so it's important that I be > able to trust its output. The 'tapeinfo' tool bundled with mtx will actually give you more info than mt. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: drive compression discovery
Eric Sproul wrote: > Also, my system is Linux, so there > are no compression-related device names. Actually, all Linux Amanda users should read and understand (and implement) the stinit man page. Once you've built a proper "/etc/stinit.def" for your drive(s), and make the proper device nodes, you should never have any issues with compression again. -- Marty Shannon, RHCE (@ home) mailto:[EMAIL PROTECTED]
drive compression discovery
Hi all, I'm familiar with the general theory of how to "rescue" an AMANDA tape that's been written with drive compression turned on. Here's my situation: I've completed my first dumpcycle with my current config, and I'm fairly certain that drive compression has been turned off the whole time, but I'm not 100% sure. I now have in place a script that ensures drive compression is off, but it was not put in place until a number of runs had been done. I want to make sure all the tapes are uncompressed before I reuse them. My question: If I do a dd of some amount of data (like dumping the first 32K of data as I would if I was saving the label), and then see (via mt) that the drive's compression is still off, is it safe to conclude that the tape was written with compression off? I've read posts that indicate a compressed tape will silently set drive compression back on, but will that change still be visible to mt? BTW, the drive has no DIP switches for setting compression-- it is completely controlled by software. Also, my system is Linux, so there are no compression-related device names. I am relying strictly on mt to manipulate the drive outside of AMANDA, so it's important that I be able to trust its output. Thanks, Eric
Re: Problem with Solaris Amanda Build
John, I wasn't able to figure out what was wrong with the changer-src Makefile, however I was able to get around it. My fix is rather unorthadox and not recommended and I have no idea what I might have broken or what now failed to compile so if you follow this bit of 'programming' you take your chances. The affected (aflicted?) section of code as diplayed via # cat -evt, because Makefiles are touchy about white-space uninstall-am: uninstall-info-am uninstall-libexecPROGRAMS \$ ^Iuninstall-libexecSCRIPTS$ $ .PHONY: GTAGS all all-am check check-am clean clean-generic \$ ^Iclean-libexecPROGRAMS clean-libtool distclean distclean-compile \$ ^Idistclean-depend distclean-generic distclean-libtool \$ ^Idistclean-tags distdir dvi dvi-am info info-am install \$ ^Iinstall-am install-data install-data-am install-exec \$ ^Iinstall-exec-am install-info install-info-am \$ ^Iinstall-libexecPROGRAMS install-libexecSCRIPTS install-man \$ ^Iinstall-strip installcheck installcheck-am installdirs \$ ^Imaintainer-clean maintainer-clean-generic mostlyclean \$ ^Imostlyclean-compile mostlyclean-generic mostlyclean-libtool \$ ^Itags uninstall uninstall-am uninstall-info-am \$ ^Iuninstall-libexecPROGRAMS uninstall-libexecSCRIPTS$ $ ^I^I^Ichg-null$ I was unable to figure out what was wrong with this code, specifically the error seemed to be on the line ending "distclean-compile \$" ...so I deleted the entire section ie the ".PHONY:" tag down to the next white line. Like I said, I don't know what I broke along the way, make run from the root ran to completion though. --- Brian R Cuttler [EMAIL PROTECTED] Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773 > John, > > Good news/bad news. > > I found that some of the files in the changer-src tree where > owned by someone else and I was unable to set the protections > from the non-priv account I was building from. > > Once that was corrected I was able to complete the build. > > Unfortunately I was able to reproduce the problem after downloaded > 2.4.4 (again, for some reason I thought there was an update) but > am finding that the original solution is not the problem but soemthing > else - I haven't had the time to unravel it but will try again in > the next day or so. > > I'll let people know what I've found out, even if its just me > being dense again. > > Brian > > > I am having the same problem your describe in the amanda user list. > > I looked through the archive, but could find no answer. Did you > > come across a solution to the problem? > > > > Here is a the output from the make file... > > > > Making all in changer-src > > make: Fatal error in reader: Makefile, line 531: Unexpected end of > > line seen > > Current working directory /usr/local/src/amanda-2.4.4/changer-src > > *** Error code 1 > > make: Fatal error: Command failed for target `all-recursive' > > > > Please use my NOAA address when responding > > > > John Allen > > IT Specialist > > NOAA Fisheries > > [EMAIL PROTECTED] > >
RE: Xinetd not starting amanda
>Hallo all
>when checking if amanda is listening on the correct ports.
>netstat -a | grep -i amanda
>
>any ideas how I can trouble shoot further?
>According to me evereything there must work
Can you do a chkconfig --list and see the amanda services listed under xinetd based
services and are they turned on? Do you have amanda, amandaidx and amidxtape files in
your xinetd.d directory, and do they all look something like this (respectively):
service amanda
{
protocol= udp
socket_type = dgram
wait= yes
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amandad
}
service amandaidx
{
protocol= tcp
socket_type = stream
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amindexd
}
service amidxtape
{
protocol= tcp
socket_type = stream
wait= no
user= amanda
group = disk
groups = yes
server = /usr/local/libexec/amidxtaped
}
And the amanda services are listed in /etc/services? What version of RedHat are you
using?
compiling 2.4.4 on Mac OS X
amanda 2.4.3 compiles fine for me on Mac OS X (10.2.4), while 2.4.4 does not. Not urgent, but thought I should report it somewhere. Details: Configured with ./configure --with-user=amanda --with-group=wheel --prefix=/usr/local --without-server --with-config='backupset' --with-gnutar=/usr/local/hfstar/bin/tar Make fails almost immediately with: [raven:~/amanda-2.4.4] amanda% make Making all in configmake all-am make[2]: Nothing to be done for `all-am'. Making all in common-src source='alloc.c' object='alloc.lo' libtool=yes \ depfile='.deps/alloc.Plo' tmpdepfile='.deps/alloc.TPlo' \ depmode=gcc /bin/sh ../config/depcomp \ /bin/sh ../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src-g -O2 -c -o alloc.lo `test -f 'alloc.c' || echo './'`alloc.c mkdir .libs gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -g -O2 -c alloc.c -Wp,-MD,.deps/alloc.TPlo -fno-common -DPIC -o .libs/alloc.lo In file included from alloc.c:33: amanda.h:905: conflicting types for `initgroups' /usr/include/unistd.h:175: previous declaration of `initgroups' make[1]: *** [alloc.lo] Error 1 make: *** [all-recursive] Error 1
Tapetype entry for HP DLT7000 library
define tapetype DLT7000 {
comment "HP SureStore DLT7000 Autoloader A5501A"
length 33642 mbytes
filemark 33 kbytes
speed 1840 kps
}
--
John Oliver, CCNAhttp://www.john-oliver.net/
Linux/UNIX/network consulting http://www.john-oliver.net/resume/
*** sendmail, Apache, ftp, DNS, spam filtering ***
Colocation, T1s, web/email/ftp hosting
FW: iGuard Archive AMANDA MAIL REPORT FOR March 8, 2003
Hello! I've had backups occurring for a few weeks now without any hitches. We have a schedule of Daily backups with an archive (level 0 all around) done every other weekend. Last Saturday (the 8th) was such a weekend. One of the machines had a problem: > FAILED AND STRANGE DUMP DETAILS: > > /-- iguard /db lev 0 FAILED [nak error:amandad busy] > \ The other 5 partitions on this machine were archived without a problem. This partition (/db) is the data partition for a PostgreSQL database. This partition has been archived in the past without incident -- anybody have possible causes for this error? -- David Olbersen iGuard Engineer 11415 West Bernardo Court San Diego, CA 92127 1-858-676-2277 x2152 > -Original Message- > From: Dump Account [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 08, 2003 12:18 PM > To: iGuard Backup List > Subject: iGuard Archive AMANDA MAIL REPORT FOR March 8, 2003 > > > These dumps were to tapes Archive000, Archive001, Archive002. > Tonight's dumps should go onto 6 tapes: a new tape, a new > tape, a new tape, a new tape, a new tape, a new tape. > > FAILURE AND STRANGE DUMP SUMMARY: > iguard /db lev 0 FAILED [nak error:amandad busy] > > > STATISTICS: > Total Full Daily > > Dump Time (hrs:min)9:18 8:30 0:00 (0:07 > start, 0:41 idle) > Output Size (meg) 29404.229404.20.0 > Original Size (meg) 63050.863050.80.0 > Avg Compressed Size (%)46.6 46.6-- > Tape Used (%) 255.7 255.70.0 > Filesystems Dumped 37 37 0 > Avg Dump Rate (k/s) 397.1 397.1-- > Avg Tp Write Rate (k/s) 983.0 983.0-- > > > > FAILED AND STRANGE DUMP DETAILS: > > /-- iguard /db lev 0 FAILED [nak error:amandad busy] > \ > > > > NOTES: > planner: Adding new disk wipeout:/. > planner: Adding new disk wipeout:/usr. > planner: Adding new disk wipeout:/var. > planner: Adding new disk wipeout:/db. > planner: Adding new disk wipeout:/work. > planner: Adding new disk longboard:/. > planner: Adding new disk longboard:/usr. > planner: Adding new disk longboard:/var. > planner: Adding new disk longboard:/data. > planner: Adding new disk longboard:/home. > planner: Adding new disk longboard:/work. > planner: Adding new disk longboard:/software. > planner: Adding new disk intergate:da0a. > planner: Adding new disk intergate:/usr. > planner: Adding new disk intergate:/var. > planner: Adding new disk tidal:/. > planner: Adding new disk tidal:/usr. > planner: Adding new disk tidal:/data. > planner: Adding new disk tidal:/mail. > planner: Adding new disk tidal:/var. > planner: Adding new disk tidal:/web. > planner: Adding new disk big-kahuna:/. > planner: Adding new disk big-kahuna:/usr. > planner: Adding new disk big-kahuna:/var. > planner: Adding new disk big-kahuna:/db. > planner: Adding new disk big-kahuna:/work. > planner: Adding new disk wammer:/. > planner: Adding new disk wammer:/usr. > planner: Adding new disk wammer:/var. > planner: Adding new disk iguard:/. > planner: Adding new disk iguard:/usr. > planner: Adding new disk iguard:/var. > planner: Adding new disk iguard:/work. > planner: Adding new disk iguard:/db. > planner: Adding new disk iguard:/db/wal. > planner: Adding new disk ns2:/. > planner: Adding new disk ns2:/usr. > planner: Adding new disk ns2:/var. > taper: tape Archive000 kb 11988576 fm 31 writing file: No > space left on device > taper: retrying longboard:/software.0 on new tape: [writing > file: No space left on device] > taper: tape Archive001 kb 12010912 fm 6 writing file: No > space left on device > taper: retrying wammer:/usr.0 on new tape: [writing file: > No space left on device] > taper: tape Archive002 kb 7456928 fm 2 [OK] > > > > DUMP SUMMARY: > DUMPER STATS > TAPER STATS > HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS > KB/s MMM:SS KB/s > -- > -- -- > big-kahun / 05206922144 42.53:12 > 115.40:22 1005.7 > big-kahun /db0 4662649 2082112 44.7 234:37 > 147.9 34:45 998.7 > big-kahun /usr 0 1936878 596544 30.8 101:38 > 97.8 10:04 987.3 > big-kahun /var 03866917376 44.95:15 > 55.20:18 955.5 > big-kahun /work 0 1249917 509856 40.8 103:48 > 81.98:23 1013.5 > iguard/ 04391619584 44.60:08 > 2474.60:20 962.2 > iguard/db0 FAILED > > iguard/db/wal0 26323068896 26.20:37 > 1867.81:1
Re: files changing during backup
On Mon, Mar 10, 2003 at 10:19:17AM -0600, Bryan Ramirez wrote: > Hi, > > I just started using amanda, and the level 0 backup of some of my users' > directories has taken longer than expected. It > is likely that a significant number of files have changed while they > were being backed up. I'm using gtar as the backup method. My question > is: Will the next level 1 backup these files, or are my backups going to > be vulnerable to corruption for the next 4 weeks (my dumpcycle)? Each level 1 backs up all changes since the last level 0. So an attempt will be made again to back up those files. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Xinetd not starting amanda
On Mon, 2003-03-10 at 06:44, Mozzi wrote:
> Hallo all
> when checking if amanda is listening on the correct ports.
> netstat -a | grep -i amanda
>
> any ideas how I can trouble shoot further?
> According to me evereything there must work
Here are some thoughts - I hope they help you. I'm making many rash
assumptions here, like your operating system (!) and exactly *what* your
problem is!!! It would be helpful to have had a bit more info to go
on...
1) First, compare your xinetd startup-file with mine (I'm using
RedHat8.0, and my file is /etc/xinetd.d/amanda):
[EMAIL PROTECTED]:/root-> cat /etc/xinetd.d/amanda
# default: on
# description: Amanda tape backup
service amanda
{
disable = no
socket_type = dgram
protocol= udp
user= amanda
group = backup
server = /usr/local/libexec/amandad
wait= yes
}
2) Restart xinetd, mostly just for good measure. As root, on my
RedHat8.0 system, this goes like:
/sbin/service xinetd restart
If you issue "ps aux" (again, RH8.0 and similar) you should see a line
that looks something like:
root 544 0.0 0.3 2100 912 ?SMar04 0:00 xinetd
-stayalive -reuse -pidfile /var/run/xinetd.pid
This shows that xinetd is running. Remember, xinetd is a
'super-server', which launches other programs (like amandad). Your
"netstat" command will NOT show amanda listening, because it's not; it's
xinetd that listens and starts amanda.
3) Verify that xinetd is able to "see" your amanda. For me, I invoke a
console-based configuration tool, and simply see that amanda shows up in
the listing:
ntsysv
4) At this point, you should be ready to try amcheck. Read the
documentation. Find where your amanda logs are stored and read them.
On my RH8.0 system, my amandad lives in /usr/local/libexec, and I find
it handy to use this to see if amandad is getting started by xinetd:
ls -ul /usr/local/libexec/amandad
The time that shows will be the last access-time; if it doesn't match
when you just tried your amcheck run, then it's not amanda that's
failing - it's not even getting started! Check (or temporarily remove)
firewalling. If you're using tcpwrappers, take those out of the picture
too (ie blank /etc/hosts.allow and /etc/hosts.deny).
There - I've tried to help you. But again, it's hard when you don't
provide your OS, and your problem!! Usually I would simply hit "delete"
upon seeing a posting like yours...
-Gord
--
Gordon Pritchard, P.Eng. | Institute of Electrical and
Research Labs Manager| Electronics Engineers
Simon Fraser University, Surrey | Quarter Century Wireless Ass'n
[EMAIL PROTECTED] | Telephone Pioneers of America
phone: 604.586.6186
Re: ACLs
On Mon, 10 Mar 2003, Adam Smith wrote: > On FreeBSD 5.0 with UFS2 + ACLs, what is my best method for backing up my > ACLs along with my files? > > I am only experimenting with Amanda at this point, but it seems to use the > native tar utility, however tar does not support the backing up of ACLs. > Can anyone show me what I need to do? I don't have a 5.0 system to look at, but looking briefly at the CVS tree, it appears their ACL system is designed to not require special consideration. There seems to be more explanation of the UFS1 implementation, which requires more manual setup, than the UFS2 implementation, which is "natively available". Do your filesystems have a special directory at their root? Possibly .attribute ? (This is the name documented for UFS1.) If this is there then this is where your ACLs are stored and if you're backing up those dirs then you're getting the ACLs. -Mitch
files changing during backup
Hi, I just started using amanda, and the level 0 backup of some of my users' directories has taken longer than expected. It is likely that a significant number of files have changed while they were being backed up. I'm using gtar as the backup method. My question is: Will the next level 1 backup these files, or are my backups going to be vulnerable to corruption for the next 4 weeks (my dumpcycle)? Thanks! -Bryan
Re: Xinetd not starting amanda
I'm assuming that you are running this on a linux box.. so here are some things to check: 1. In the xinetd service file, disable should = no 2. If There is an 'id' field it has to match up with the name of the service in /etc/services. 3. If there is not an 'id' field the name of your file has to match the name of the above-mentioned service. 4. You can run xinetd with a '-d' option for debugging. 5. type 'ipchains -L' and 'iptables -L'. If there are any lines that show up as REJECT or DENY you may have to change your firewall rules on the machine. A message that this isn't supported by your kernel is okay. 6. If you do have firewall rules, make sure you are also allowing connections to port 111. Hope this helps.. -Bryan On Monday, March 10, 2003, at 08:44 AM, Mozzi wrote: Hallo all when checking if amanda is listening on the correct ports. netstat -a | grep -i amanda any ideas how I can trouble shoot further? According to me evereything there must work Mozzi
Re: Xinetd not starting amanda
On Mon, 2003-03-10 at 08:44, Mozzi wrote: > Hallo all > when checking if amanda is listening on the correct ports. > netstat -a | grep -i amanda > > any ideas how I can trouble shoot further? > According to me evereything there must work > Do you have "disable = no" in your amanda service config? --a > > Mozzi
Re: please reply immediately
classic nigerian 419 scam ;-) http://home.rica.net/alphae/419coal/ http://www.419fraud.com/ Mozzi On Saturday 08 March 2003 18:44, Abdulahi Mohammed wrote: > Abdulahi Mohammed > InterGlobe bank plc. > lagos, Nigeria > [EMAIL PROTECTED] > tel: 234 803 3061041 > > Dear Sir, > > My name is Alhaji Abdulahi Mohammed. I am the head of credit and accounts > department of InterGlobe Bank Plc., Western District, Nigeria. > > I write you in respect of a foreign customer who has a Domicilliary accuont > in my bank. His name is EngineerJoseph Schultzman. He was among those who > died in aplane crash here in Nigeria during the reign of lateGeneral Sani > Abacha. > > Since the demise of this our customer, Engineer Joseph Schultzman, who was > an oil merchant/contractor, I have kept a close watch of the deposit > records andaccounts and since then nobody has come to claim themoney in > this a/c as next of kin to the late engineer.He had only Six million united > states dollars(USD6,000,000.00) in his a/c and the a/c iscoded. It is only > an insider that could produce thecode or password of the deposit > particulars. > > As it stands now, there is nobody in that position toproduce the needed > information other than my very selfconsidering my position in the > bank.Based on the reason that nobody has come forward toclaim the deposit > as next of kin, I hereby ask foryour co operation in using your name as the > next ofkin to the deceased to send these funds out to aforeign offshore > bank a/c for mutual sharing between myself and you. > > At this point I am the only one withthe information because I have removed > the depositfile from the safe .By this doing, what is required of you is > to send anapplication laying claims of the deposit as next of kin to the > late Engineer. I will need your full nameand address, company > orresidential, so that i cancomputerize them to tally with next of kin > column inthe certificate of deposit. > > Finally i want you to understand that the request fora foreigner as the > next of kin is occassioned by thefact that the customer was a foreigner and > for thatreason alone a local cannot represent as next of kin.When you > contact me, then we shall discuss on how themoney will be split between us. > > Trusting to hear from you, > > I remain Respectfully yours, > > Abdulahi Mohammed > tel: 234 803 3061041 > > > > _ > http://www.latinmail.com. Gratuito, latino y en español.
Xinetd not starting amanda
Hallo all when checking if amanda is listening on the correct ports. netstat -a | grep -i amanda any ideas how I can trouble shoot further? According to me evereything there must work Mozzi
Re: ACLs
Check your acl package to see if it supports recursive fetch/restore. If it does, just before dump time, do a recursive getfacl , redirected to a file. After a tar restore, you can use your listed acls file to restore the acls. I currently don't use this method ( on RH7.3) , but I'm headed that way. -- toby bluhm philips medical systems, it support, mr development, cleveland ohio [EMAIL PROTECTED] 440-483-5323 Adam Smith <[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 03/09/2003 06:55 PM Please respond to adam.smith To: [EMAIL PROTECTED] cc: (bcc: Tobias Bluhm/CLE/MS/PHILIPS) Subject:ACLs Classification: On FreeBSD 5.0 with UFS2 + ACLs, what is my best method for backing up my ACLs along with my files? I am only experimenting with Amanda at this point, but it seems to use the native tar utility, however tar does not support the backing up of ACLs. Can anyone show me what I need to do? Regards, -- Adam Smith Information Technology Officer SAGE Automation Ltd. [EMAIL PROTECTED] http://www.sageautomation.com
Re: ACLs
On Mon, 10 Mar 2003 at 10:25am, Adam Smith wrote > On FreeBSD 5.0 with UFS2 + ACLs, what is my best method for backing up my > ACLs along with my files? > > I am only experimenting with Amanda at this point, but it seems to use the > native tar utility, however tar does not support the backing up of ACLs. > Can anyone show me what I need to do? Amanda will use tar or the appropriate fs-specific 'dump' program provided by your vendor, depending on what's in the dumptype. If there's a dump program that will handle those ACLs, amanda will use it if you tell it to. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
