Re: ? amrecover doesn't see index contents
Thanks, Frank. What's the meaning of leadining number in the path ? Allen Liu - Original Message - From: "Frank Smith" <[EMAIL PROTECTED]> To: "Allen Liu --- work" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, March 01, 2004 4:20 PM Subject: Re: ? amrecover doesn't see index contents > --On Monday, March 01, 2004 16:11:47 -0500 Allen Liu --- work <[EMAIL PROTECTED]> wrote: > > > I'm running amrecover trying to restore files. > > > > After I started amrecover and set target dis and date, it said no records > > found like below: > > > > amrecover> ls > > Must select a disk before listing files > > amrecover> setdisk /test-ama1 > > Scanning /dumps/amanda... > > 200 Disk set to /test-ama1. > > No index records for disk for specified date > > If date correct, notify system administrator > > amrecover> setdate ---01 > > 200 Working date set to 2004-03-01. > > No index records for cwd on new date > > Setting cwd to mount point > > amrecover> ls > > > > I can see there is index files in the index dir and the .gz file was > > extracted when amrecover setdisk to this disk. The extracted text file has > > file list inside: > > -- > > spike:root:#ls -l > > total 4 > > -rw--- 1 amanda sys 142 Mar 1 16:00 20040301_0 > > -rw--- 1 amanda sys 83 Mar 1 15:58 20040301_0.gz > > spike:root:#more 20040301_0 > > 10020721223/./cfgadm > > 10020721223/./chroot > > 10020721223/./clri > > 10020721223/./coreadm.conf > > 10020721223/./crash > > 10020721223/./cron > > 10020721732/./ > > BAD version of tar, make sure you are using at least 1.13.19. > However, one person on the list had success by manually editing out > the leading numbers from the paths and then running amrecover. > > Frank > > > spike:root:# > > spike:root:#pwd > > /myapp/am/etc/amanda/fst/index/pete/_test-ama1 > > - > > > > The funny thing is that I have another SAMBA disk with same dumpetype which > > works fine with amrecover. > > > > > > Thanks > > > > Allen Liu > > > > > > -- > Frank Smith [EMAIL PROTECTED] > Sr. Systems Administrator Voice: 512-374-4673 > Hoover's Online Fax: 512-374-4501 >
Re: fake install path
Thanks,Paul. It works as you directed. Allen Liu IP Application Design and Engineering Bell Canada (613) 781-7368, [EMAIL PROTECTED] 1240 -160 Elgin St, Ottawa,ON, K2P 2C4 - Original Message - From: "Paul Bijnens" <[EMAIL PROTECTED]> To: "Brandon D. Valentine" <[EMAIL PROTECTED]> Cc: "Jonathan Dill" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Monday, March 01, 2004 7:08 PM Subject: Re: fake install path > Brandon D. Valentine wrote: > > On Mon, Mar 01, 2004 at 10:10:13PM +0100, Paul Bijnens wrote: > > > >>Jonathan Dill wrote: > >> > >>>make install VARIABLE=/tmp/amanda-2.4.4p2 > >> > >>The prefix= can be specified to override the configure prefix > >>like: > >> > >> make install prefix=/tmp/amanda-2.4.4p2 > > > > > > This is not what you want, Jonathan. DESTDIR is the correct variable to > > overload for package building at the make install stage. PREFIX is > > defined at configure time as the install location. DESTDIR will be > > prepended to PREFIX at make install time. > > Thanks for correcting me. I also found a decent explanation: > > http://sources.redhat.com/autobook/autobook/autobook_107.html > > > -- > Paul Bijnens, XplanationTel +32 16 397.511 > Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 > http://www.xplanation.com/ email: [EMAIL PROTECTED] > *** > * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * > * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * > * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * > * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * > * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* > * ... "Are you sure?" ... YES ... Phew ... I'm out * > ***
Re: ? amrecover doesn't see index contents
Allen Liu --- work wrote: What's the meaning of leadining number in the path ? ... spike:root:#more 20040301_0 10020721223/./cfgadm That number is the bug. It shouldn't be there. -- Paul Bijnens, XplanationTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, F6, * * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ...* * ... "Are you sure?" ... YES ... Phew ... I'm out * ***
gnutar in configure
I installed gnutar 1.13.25 which generate : /usr/local/bin/tar When I configure amanda 2.4.4p2, it could not find gnutar : ./configure --with-user=amanda --with-group=sys --prefix=/myapp/am1 ... checking for grep... /usr/bin/grep checking for gtar... no checking for gnutar... no checking for tar... /usr/local/bin/tar checking for smbclient... /usr/local/samba/bin/smbclient checking for gzip... /usr/bin/gzip ... My questions are: - when I specify dumptype with program=GNUTAR, does it use /usr/local/bin/tar ? - how to make ./configure recognize gnutar ? Thanks Allen Liu IP Application Design and Engineering Bell Canada (613) 781-7368, [EMAIL PROTECTED] 1240 -160 Elgin St, Ottawa,ON, K2P 2C4
Re: gnutar in configure
--On Tuesday, March 02, 2004 13:34:19 -0500 Allen Liu --- work <[EMAIL PROTECTED]> wrote: > I installed gnutar 1.13.25 which generate : > /usr/local/bin/tar > > When I configure amanda 2.4.4p2, it could not find gnutar : > > ./configure --with-user=amanda --with-group=sys --prefix=/myapp/am1 > ... > checking for grep... /usr/bin/grep > checking for gtar... no > checking for gnutar... no > checking for tar... /usr/local/bin/tar > checking for smbclient... /usr/local/samba/bin/smbclient > checking for gzip... /usr/bin/gzip > ... > > My questions are: > - when I specify dumptype with program=GNUTAR, does it use > /usr/local/bin/tar ? Not sure. > - how to make ./configure recognize gnutar ? Run configure with --with-gnutar=/path/to/your/gnutar Frank > > Thanks > > Allen Liu > > IP Application Design and Engineering > Bell Canada > (613) 781-7368, [EMAIL PROTECTED] > 1240 -160 Elgin St, Ottawa,ON, K2P 2C4 -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Re: gnutar in configure
- Original Message - From: "Frank Smith" <[EMAIL PROTECTED]> To: "Allen Liu --- work" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, March 02, 2004 1:59 PM Subject: Re: gnutar in configure > > > --On Tuesday, March 02, 2004 13:34:19 -0500 Allen Liu --- work <[EMAIL PROTECTED]> wrote: > > > I installed gnutar 1.13.25 which generate : > > /usr/local/bin/tar > > > > When I configure amanda 2.4.4p2, it could not find gnutar : > > > > ./configure --with-user=amanda --with-group=sys --prefix=/myapp/am1 > > ... > > checking for grep... /usr/bin/grep > > checking for gtar... no > > checking for gnutar... no > > checking for tar... /usr/local/bin/tar > > checking for smbclient... /usr/local/samba/bin/smbclient > > checking for gzip... /usr/bin/gzip > > ... > > > > My questions are: > > - when I specify dumptype with program=GNUTAR, does it use > > /usr/local/bin/tar ? > > Not sure. > > > - how to make ./configure recognize gnutar ? > > Run configure with --with-gnutar=/path/to/your/gnutar I installed tar-1.13.25 . There is no such thing 'gnutar' generated. It only generated 'tar' and installed it in /usr/local/bin. > > Frank > > > > > Thanks > > > > Allen Liu > > > > IP Application Design and Engineering > > Bell Canada > > (613) 781-7368, [EMAIL PROTECTED] > > 1240 -160 Elgin St, Ottawa,ON, K2P 2C4 > > > > -- > Frank Smith [EMAIL PROTECTED] > Sr. Systems Administrator Voice: 512-374-4673 > Hoover's Online Fax: 512-374-4501 >
Re: gnutar in configure
--On Tuesday, March 02, 2004 14:09:06 -0500 Allen Liu --- work <[EMAIL PROTECTED]> wrote: >> > - how to make ./configure recognize gnutar ? >> >> Run configure with --with-gnutar=/path/to/your/gnutar > I installed tar-1.13.25 . There is no such thing 'gnutar' generated. It only > generated 'tar' and installed it in /usr/local/bin. Then you can run configure --with-gnutar=/usr/local/bin/tar, and make sure that that path exists on your clients, and is gnu tar of the proper version on all of them as well. Frank >> > >> > Thanks >> > >> > Allen Liu > -- Frank Smith [EMAIL PROTECTED] Sr. Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501
Amanda/MTX/SGI/Jukebox
Hello Amanda users,
Sorry that I don't have a better defined question...
I think mtx is working correctly but I've got some odd
results - most likely my glue config.
the cross post.
I've installed amanda 2.4.2p2
mtx1.3.8
sgi6.5.19
on a system with a jukebox (8 slot) and a single SDLT 320.
I apparently haven't glued everything together quite right
since I can't get the glue script right I can't get amanda
to run correctly.
Ignoring for a moment the lack of a work area and the fact that
gtar isn't yet installed (I'm going to segment a .88 TBytes disk drive,
probably by username/directory at the top of the partition).
samar 46% /usr/local/sbin/amcheck samar
Amanda Tape Server Host Check
-
ERROR: log dir /amanda/samar: not writable
amcheck-server: could not get changer info: badly formed result from changer:
"info[6]: test: argument expected"
Amanda Backup Client Hosts Check
ERROR: samar: [host samar: port 1129 not secure]
Client check: 1 host checked in 0.147 seconds, 1 problem found
(brought to you by Amanda 2.4.2p2)
samar 50% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inquiry
Product Type: Medium Changer
Vendor ID: 'BDT '
Product ID: 'ThinStor AutoLdr'
Revision: 'T16r'
Attached Changer API: No
Oddly inventory gives no output.
samar 51% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inventory
Oops, maybe its because the end-users pillaged the tapes...
samar 52% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 status
Storage Changer /dev/scsi/sc1d4l0:1 Drives, 8 Slots ( 0 Import/Export )
Data Transfer Element 0:Full (Storage Element 1 Loaded)
Storage Element 1:Empty
Storage Element 2:Empty
Storage Element 3:Empty
Storage Element 4:Empty
Storage Element 5:Empty
Storage Element 6:Empty
Storage Element 7:Empty
Storage Element 8:Empty
I'll see to getting the tapes reloaded, in the mean time I suspect
the following output is abnoral.
samar 53% /usr/local/libexec/chg-zd-mtx -info
info[6]: test: argument expected
8 1 1
samar 62% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 unload 1
Unloading drive 0 into Storage Element 1...done
samar 63% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inventory
samar 64% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 load 1
Loading media from Storage Element 1 into drive 0...done
samar 65% /usr/local/sbin/amlabel samar SAMAR01
labeling tape in slot loadslot[8]: (test: argument expected):
rewinding
amlabel: no tape online
samar 67% more chg-zd-mtx.conf
firstslot=1
lastslot=8
#cleanslot=3
AUTOCLEAN=0
autocleancount=99
havereader=1
offlinestatus=0
OFFLINE_BEFORE_UNLOAD=0
max_drive_wait=300
Extracted from amanda.conf
--
tapetype SDLT # what kind of tape it is (see tapetypes below)
labelstr "^SAMAR[0-9][0-9]*$" # label constraint regex: all tapes must match
# columnspec variable allowed in v2.4.2p2 -ck
columnspec "HostName=0:7,Disk=1:14,OrigKB=1:9,OutKB=1:9,DumpRate=1:6,TapeRate=1:
6"
runtapes 3 # number of tapes to be used in a single run of amdump
tpchanger "chg-zd-mtx" # the tape-changer glue script
tapedev "/dev/sdlt" # the no-rewind tape device to be used
rawtapedev "/dev/null" # the raw device to be used (ftape only)
changerfile "/usr/local/etc/amanda/samar/chg-zd-mtx"
changerdev "/dev/scsi/sc1d4l0"
# the sdlt tapetype is just a guess
define tapetype SDLT {
comment "QUAMTUM SDLT320"
length 160 mbytes
filemark 100 kbytes # don't know a better value
speed 100 kbytes# dito
}
Thanks in advance,
Brian
---
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
Re: Amanda/MTX/SGI/Jukebox
* Brian Cuttler <[EMAIL PROTECTED]> [20040302 15:19]:
>
> Hello Amanda users,
>
> Sorry that I don't have a better defined question...
> I think mtx is working correctly but I've got some odd
> results - most likely my glue config.
> the cross post.
>
> I've installed amanda 2.4.2p2
>mtx1.3.8
>sgi6.5.19
> on a system with a jukebox (8 slot) and a single SDLT 320.
I've got all that running on irix-6.5.19 with slightly
different versions of mtx (1.2.16rel) and
amanda 2.4.4p1-20031120 and 2.4.4-20030428
I suspect you have a bad chg-zd-mtx script.
Which version?
HTH,
jf
>
> I apparently haven't glued everything together quite right
> since I can't get the glue script right I can't get amanda
> to run correctly.
>
> Ignoring for a moment the lack of a work area and the fact that
> gtar isn't yet installed (I'm going to segment a .88 TBytes disk drive,
> probably by username/directory at the top of the partition).
>
> samar 46% /usr/local/sbin/amcheck samar
> Amanda Tape Server Host Check
> -
> ERROR: log dir /amanda/samar: not writable
> amcheck-server: could not get changer info: badly formed result from changer:
> "info[6]: test: argument expected"
>
> Amanda Backup Client Hosts Check
>
> ERROR: samar: [host samar: port 1129 not secure]
> Client check: 1 host checked in 0.147 seconds, 1 problem found
>
> (brought to you by Amanda 2.4.2p2)
>
> samar 50% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inquiry
> Product Type: Medium Changer
> Vendor ID: 'BDT '
> Product ID: 'ThinStor AutoLdr'
> Revision: 'T16r'
> Attached Changer API: No
>
> Oddly inventory gives no output.
>
> samar 51% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inventory
>
> Oops, maybe its because the end-users pillaged the tapes...
>
> samar 52% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 status
> Storage Changer /dev/scsi/sc1d4l0:1 Drives, 8 Slots ( 0 Import/Export )
> Data Transfer Element 0:Full (Storage Element 1 Loaded)
> Storage Element 1:Empty
> Storage Element 2:Empty
> Storage Element 3:Empty
> Storage Element 4:Empty
> Storage Element 5:Empty
> Storage Element 6:Empty
> Storage Element 7:Empty
> Storage Element 8:Empty
>
> I'll see to getting the tapes reloaded, in the mean time I suspect
> the following output is abnoral.
>
> samar 53% /usr/local/libexec/chg-zd-mtx -info
> info[6]: test: argument expected
> 8 1 1
>
> samar 62% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 unload 1
> Unloading drive 0 into Storage Element 1...done
>
> samar 63% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inventory
>
> samar 64% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 load 1
> Loading media from Storage Element 1 into drive 0...done
>
> samar 65% /usr/local/sbin/amlabel samar SAMAR01
> labeling tape in slot loadslot[8]: (test: argument expected):
> rewinding
> amlabel: no tape online
>
> samar 67% more chg-zd-mtx.conf
> firstslot=1
> lastslot=8
> #cleanslot=3
> AUTOCLEAN=0
> autocleancount=99
> havereader=1
> offlinestatus=0
> OFFLINE_BEFORE_UNLOAD=0
> max_drive_wait=300
>
> Extracted from amanda.conf
> --
>
> tapetype SDLT # what kind of tape it is (see tapetypes below)
> labelstr "^SAMAR[0-9][0-9]*$" # label constraint regex: all tapes must match
>
> # columnspec variable allowed in v2.4.2p2 -ck
> columnspec "HostName=0:7,Disk=1:14,OrigKB=1:9,OutKB=1:9,DumpRate=1:6,TapeRate=1:
> 6"
>
> runtapes 3 # number of tapes to be used in a single run of amdump
> tpchanger "chg-zd-mtx" # the tape-changer glue script
> tapedev "/dev/sdlt" # the no-rewind tape device to be used
> rawtapedev "/dev/null" # the raw device to be used (ftape only)
> changerfile "/usr/local/etc/amanda/samar/chg-zd-mtx"
> changerdev "/dev/scsi/sc1d4l0"
>
> # the sdlt tapetype is just a guess
>
> define tapetype SDLT {
> comment "QUAMTUM SDLT320"
> length 160 mbytes
> filemark 100 kbytes # don't know a better value
> speed 100 kbytes# dito
> }
>
> Thanks in advance,
>
> Brian
>
> ---
>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
--
Take away the things I dream
One time one place one more
Re: gnutar in configure
If you're backing up more than one architecture, I find that it's nice to set things up so that you can have the same path to gnutar on all of the architectures. That way, you can run amrecover on any machine and it will find a valid path to gnutar. Normally, I just create a symbolic link to the "real" path to gnutar in /usr/local/etc/amanda/bin and use --with-gnutar=/usr/local/etc/amanda/bin/tar If you're only backing up one architecture, and this suggestion causes a brain hemmorhage, then forget about it and just stick to what you were doing. Maybe it seems a bit esoteric, but in practice I have found it to be very useful. Very often, I have restored files for an IRIX workstation to the holding disk of the amanda server, which is Linux, and then pick and choose which files I really want to transfer to the workstation with rsync, rather than just restoring everything to the IRIX workstation directly. That way, I can be careful not to overwrite files, or force overwriting corrupt files with newer timestamps, whatever it is that I need to do. I think it gives me an extra level of control to help avoid making a mistake. On another note, maybe things have changed, but I once found that gnutar incremental backups sucked performance-wise, would make machines pretty much unusable during estimates and dumps. Normally, this would not matter, but you're talking University with eccentric grad students working at 3am and such who complain about these things. I have migrated most things to XFS filesystem and use xfsdump on Linux and IRIX--a process that I started when XFS went Open Source (around Red Hat 7.0) and I got tired of waiting for the problems with dump for ext2fs to get sorted out. Machines are still very usable with xfsdump and software compression running in the background, and finish faster than gnutar dumps. xfsdump estimates are very fast, comparatively speaking. However, with faster CPUs, faster disk interfaces, and filesystems like Rieserfs, perhaps the performance of gnutar has improved. --jonathan Frank Smith wrote: Then you can run configure --with-gnutar=/usr/local/bin/tar, and make sure that that path exists on your clients, and is gnu tar of the proper version on all of them as well.
Re: Amanda/MTX/SGI/Jukebox
Jean-Francois,
Not certain that there are specific versions of chg-zd-mtx,
the headers read
# Contributed by Eric DOUTRELEAU <[EMAIL PROTECTED]>
# This is supposed to work with Zubkoff/Dandelion version of mtx
#
# Modified by Joe Rhett <[EMAIL PROTECTED]>
# to work with MTX 1.2.9 by Eric Lee Green http://mtx.sourceforge.net
#
# Modified by Jason Hollinden <[EMAIL PROTECTED]> on 13-Feb-2001
# to work with MTX 1.2.10, >9 slots, has barcode support, and works with
# multiple configs at once.
# NOTE: Only tested the 2 additions with an ADIC Scalar 100.
so it doesn't seem to be new. This is the unmodified version that
came with mtx 1.3.8. I'm also recalling some issue about the shell
that the script runs, it is written to use /bin/sh but on my Solaris
system I'd changed it to /bin/ksh at the recommendation of someone
on this (the amanda) list.
I'll give that a shot... it wouldn't disimprove the current result any.
What does your glue script look like ?
Do you think amanda could be taught to use the SGI native "stacker" command ?
thanks,
Brian
> * Brian Cuttler <[EMAIL PROTECTED]> [20040302 15:19]:
> >
> > Hello Amanda users,
> >
> > Sorry that I don't have a better defined question...
> > I think mtx is working correctly but I've got some odd
> > results - most likely my glue config.
> > the cross post.
> >
> > I've installed amanda 2.4.2p2
> >mtx1.3.8
> >sgi6.5.19
> > on a system with a jukebox (8 slot) and a single SDLT 320.
>
> I've got all that running on irix-6.5.19 with slightly
> different versions of mtx (1.2.16rel) and
> amanda 2.4.4p1-20031120 and 2.4.4-20030428
>
> I suspect you have a bad chg-zd-mtx script.
> Which version?
>
> HTH,
> jf
>
> >
> > I apparently haven't glued everything together quite right
> > since I can't get the glue script right I can't get amanda
> > to run correctly.
> >
> > Ignoring for a moment the lack of a work area and the fact that
> > gtar isn't yet installed (I'm going to segment a .88 TBytes disk drive,
> > probably by username/directory at the top of the partition).
> >
> > samar 46% /usr/local/sbin/amcheck samar
> > Amanda Tape Server Host Check
> > -
> > ERROR: log dir /amanda/samar: not writable
> > amcheck-server: could not get changer info: badly formed result from changer:
> > "info[6]: test: argument expected"
> >
> > Amanda Backup Client Hosts Check
> >
> > ERROR: samar: [host samar: port 1129 not secure]
> > Client check: 1 host checked in 0.147 seconds, 1 problem found
> >
> > (brought to you by Amanda 2.4.2p2)
> >
> > samar 50% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inquiry
> > Product Type: Medium Changer
> > Vendor ID: 'BDT '
> > Product ID: 'ThinStor AutoLdr'
> > Revision: 'T16r'
> > Attached Changer API: No
> >
> > Oddly inventory gives no output.
> >
> > samar 51% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inventory
> >
> > Oops, maybe its because the end-users pillaged the tapes...
> >
> > samar 52% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 status
> > Storage Changer /dev/scsi/sc1d4l0:1 Drives, 8 Slots ( 0 Import/Export )
> > Data Transfer Element 0:Full (Storage Element 1 Loaded)
> > Storage Element 1:Empty
> > Storage Element 2:Empty
> > Storage Element 3:Empty
> > Storage Element 4:Empty
> > Storage Element 5:Empty
> > Storage Element 6:Empty
> > Storage Element 7:Empty
> > Storage Element 8:Empty
> >
> > I'll see to getting the tapes reloaded, in the mean time I suspect
> > the following output is abnoral.
> >
> > samar 53% /usr/local/libexec/chg-zd-mtx -info
> > info[6]: test: argument expected
> > 8 1 1
> >
> > samar 62% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 unload 1
> > Unloading drive 0 into Storage Element 1...done
> >
> > samar 63% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 inventory
> >
> > samar 64% /usr/local/sbin/mtx -f /dev/scsi/sc1d4l0 load 1
> > Loading media from Storage Element 1 into drive 0...done
> >
> > samar 65% /usr/local/sbin/amlabel samar SAMAR01
> > labeling tape in slot loadslot[8]: (test: argument expected):
> > rewinding
> > amlabel: no tape online
> >
> > samar 67% more
Re: gnutar in configure
On Tue, 2 Mar 2004 at 3:48pm, Jonathan Dill wrote > On another note, maybe things have changed, but I once found that gnutar > incremental backups sucked performance-wise, would make machines pretty > much unusable during estimates and dumps. Normally, this would not > matter, but you're talking University with eccentric grad students > working at 3am and such who complain about these things. I have > migrated most things to XFS filesystem and use xfsdump on Linux and > IRIX--a process that I started when XFS went Open Source (around Red Hat > 7.0) and I got tired of waiting for the problems with dump for ext2fs to > get sorted out. Machines are still very usable with xfsdump and > software compression running in the background, and finish faster than > gnutar dumps. xfsdump estimates are very fast, comparatively speaking. XFS and xfsdump are indeed very nice. But filesystems like this: [EMAIL PROTECTED] jlb]$ df -h FilesystemSize Used Avail Use% Mounted on . . . $SERVER0:/data 535G 518G 18G 97% /data $SERVER1:/moredata 1.8T 1.2T 621G 66% /moredata $SERVER2:/emfd 2.0T 779G 1.3T 39% /emfd make tar rather necessary (those are all XFS on Linux servers BTW). For the record, estimates on those servers go *very* fast (<5 min). I *do* have one server with a 1T XFS filesystem that takes a *long* time to estimate one particular direcotory (~90 minutes). But I'm pretty sure that's due to an inordinately large number of tiny files and subdirectories in there (about which I'm beating up the user). -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
backing up to disk(s)
[IMPORTANT! This message has been blind-carbon-copied to you. Do not reply-to-all or forward it without the author's permission.] with SATA disks becoming cheaper, it becomes very attractive to use USB2.0 connected disks as backup medium rather than tapes. The $/MB are almost even these days and are likely to go in favour of the disks with higher capacities in the future, while I do not see tape media becoming much cheaper in the long run. That poses the question, how easy it is to use a disk as backup medium for AMANDA. I am envisioning use several disks as follows: Daily01:on DISK1 Daily02:on DISK2 Daily03:on DISK3 Daily04:on DISK4 Daily05:on DISK1 Daily06:on DISK2 ... This can be accomplished by either partitioning each of these disks into several partitions with a fixed size each (to emulate a tape), one for each medium, or to just create directories and have more flexibility sizewise. I envision that one could make a chg-script to link the 'tepdev' device to the correct partition (eg ln -s /dev/hdd4 /dev/tape for Daily04). or similar stuff for directories What changes would be required to amtape/mt(?)/etc to support writing to partitions (raw?) or multiple files ? Has anyone done something like this? Mathias
Re: backing up to disk(s)
Hi, you don't have to change anything. the actual release of manda supports the backup to disk aproach, just read the docs about the "file:" driver. If you combine it with something hotplug-manager and automount you'll get what you want quite easyly. Christoph Mathias Koerber schrieb: [IMPORTANT! This message has been blind-carbon-copied to you. Do not reply-to-all or forward it without the author's permission.] with SATA disks becoming cheaper, it becomes very attractive to use USB2.0 connected disks as backup medium rather than tapes. The $/MB are almost even these days and are likely to go in favour of the disks with higher capacities in the future, while I do not see tape media becoming much cheaper in the long run. That poses the question, how easy it is to use a disk as backup medium for AMANDA. I am envisioning use several disks as follows: Daily01:on DISK1 Daily02:on DISK2 Daily03:on DISK3 Daily04:on DISK4 Daily05:on DISK1 Daily06:on DISK2 ... This can be accomplished by either partitioning each of these disks into several partitions with a fixed size each (to emulate a tape), one for each medium, or to just create directories and have more flexibility sizewise. I envision that one could make a chg-script to link the 'tepdev' device to the correct partition (eg ln -s /dev/hdd4 /dev/tape for Daily04). or similar stuff for directories What changes would be required to amtape/mt(?)/etc to support writing to partitions (raw?) or multiple files ? Has anyone done something like this? Mathias
