Re: amlabel problem - reading chunks from holding area
Brian Cuttler schrieb: > Chris, > > I _so_ love amanda! Nice to hear that ;) Stefan
Re: amlabel problem - reading chunks from holding area
Chris, I _so_ love amanda! thank you! On Fri, Feb 29, 2008 at 02:43:50PM -0500, Chris Hoogendyk wrote: > > > Brian Cuttler wrote: > >Stefan, et al, > > > >We have decided that the standalone tape drive has failed, it > >will not read nor write known good tapes. > > > >We are thinking of allocating a large NFS partition (I know, bad > >mojo and performace but apparently/supposedly its going to be temporary) > >and just letting the files live in the "amanda work area". > > > >The question then becomes one of file restores. > > > >How do you restore data from holding area chunks ? > >Do I just cat them together (is there an easy way to get > >them in order ?), if there a good method of reading them ? > >Or can I create readable files that aren't chunked ? > > Amanda will restore files from dle's that are still on the holding disk > just as easily as from tapes, only faster. Same procedure. Amanda knows > where they are and that they haven't been flushed to tape yet. I've done > it before just to see. > > > --- > > Chris Hoogendyk > > - > O__ Systems Administrator > c/ /'_ --- Biology & Geology Departments > (*) \(*) -- 140 Morrill Science Center > ~~ - University of Massachusetts, Amherst > > <[EMAIL PROTECTED]> > > --- > > Erd?s 4 > > --- 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 IMPORTANT NOTICE: This e-mail and any attachments may contain confidential or sensitive information which is, or may be, legally privileged or otherwise protected by law from further disclosure. It is intended only for the addressee. If you received this in error or from someone who was not authorized to send it to you, please do not distribute, copy or use it or any attachments. Please notify the sender immediately by reply e-mail and delete this from your system. Thank you for your cooperation.
Re: amlabel problem - reading chunks from holding area
Brian Cuttler wrote: Stefan, et al, We have decided that the standalone tape drive has failed, it will not read nor write known good tapes. We are thinking of allocating a large NFS partition (I know, bad mojo and performace but apparently/supposedly its going to be temporary) and just letting the files live in the "amanda work area". The question then becomes one of file restores. How do you restore data from holding area chunks ? Do I just cat them together (is there an easy way to get them in order ?), if there a good method of reading them ? Or can I create readable files that aren't chunked ? Amanda will restore files from dle's that are still on the holding disk just as easily as from tapes, only faster. Same procedure. Amanda knows where they are and that they haven't been flushed to tape yet. I've done it before just to see. --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology & Geology Departments (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst <[EMAIL PROTECTED]> --- Erdös 4
Re: amlabel problem - reading chunks from holding area
Stefan, et al,
We have decided that the standalone tape drive has failed, it
will not read nor write known good tapes.
We are thinking of allocating a large NFS partition (I know, bad
mojo and performace but apparently/supposedly its going to be temporary)
and just letting the files live in the "amanda work area".
The question then becomes one of file restores.
How do you restore data from holding area chunks ?
Do I just cat them together (is there an easy way to get
them in order ?), if there a good method of reading them ?
Or can I create readable files that aren't chunked ?
I know that the right way is to build a new version of amanda,
using vtapes, and install it on the server that has the large
partition - but that machine too is scheduled to move offsite.
Big investment in time for a solution that is about to walk out
of the door, but I have to at least try and get backups done for
the machines our site will retain.
thanks,
Brian
On Fri, Feb 29, 2008 at 11:13:06AM -0500, Brian Cuttler wrote:
>
> Stefan,
>
> I didn't realize the amlabel command wrote a log, I have it,
> unfortunately not as informative as one might like in these
> circumstances.
>
> samar 5# more amlabel.20080229105753.debug
> amlabel: debug 1 pid 873486 ruid 0 euid 0: start at Fri Feb 29 10:57:53 2008
> amlabel: writing label: Invalid argument
> amlabel: pid 873486 finish time Fri Feb 29 10:57:53 2008
>
> The change from the jukebox to the standalone drive involved
> these changes to amanda.conf.
>
> samar 11# diff amanda.conf amanda.conf-20080221-jukebox
> 93,95c93,94
> < #runtapes 2 # number of tapes to be used in a single run of amdump
> < runtapes 1# number of tapes to be used in a single run of amdump
> < #tpchanger "chg-zd-mtx" # the tape-changer glue script
> ---
> > runtapes 2# number of tapes to be used in a single run of amdump
> > tpchanger "chg-zd-mtx"# the tape-changer glue script
> 97,98c96
> < #tapedev "/dev/sdlt2" # the no-rewind tape device to be used
> < tapedev "/dev/sdlt" # the no-rewind tape device to be used
> ---
> > tapedev "/dev/sdlt2" # the no-rewind tape device to be used
> 101,102c99,100
> < #changerfile "/usr5/amanda/chg-zd-mtx"
> < #changerdev "/dev/scsi/sc7d1l0"
> ---
> > changerfile "/usr5/amanda/chg-zd-mtx"
> > changerdev "/dev/scsi/sc7d1l0"
>
> Apparently I didn't change the tape type, I probably should have
> but I don't know that the tapes differ except for capacity as the
> current drive is an SDLT 220.
>
> samar 13# mt -f /dev/sdlt status
> Controller: SCSI
> Device: QUANTUM: SuperDLT1 3737?7
> Status: 0x20262
> Drive type: unknown
> Media : READY, writable, at BOT
>
> samar 14# mt -f /dev/sdlt2 status
> Controller: SCSI
> Device: QUANTUM: SDLT320 3838?8
> Status: 0xa00
> Drive type: unknown
> Media : Not READY
>
> From amanda.conf, the tapetype definition. Nothing terribly odd
> here I don't think.
>
> define tapetype SDLT {
> comment "QUAMTUM SDLT320"
> length 16 mbytes
> filemark 100 kbytes # don't know a better value
> speed 100 kbytes# dito
> }
>
>
> And again, I was able to label and write the first several tapes
> without addititional changes to the config.
>
> I was also unable to dump or tar to the drive, I wonder if we
> don't have a general failure.
>
> I will ask a user to see if they can access the drive properly
> with whatever tapes they normally use in this drive (it was used
> for user data archiving before I commendeered it.
>
> thanks,
>
> Brian
>
>
>
> On Fri, Feb 29, 2008 at 09:57:07AM +0100, Stefan G. Weichinger wrote:
> > Brian Cuttler schrieb:
> > > Hello Amanda users,
> > >
> > > I had the jukebox I use on one of my SGI/IRIX Amanda servers fail
> > > and we reverted to the attached standalone SDLT 220.
> > >
> > > I modified amanda.conf to use the different tape drive and to
> > > not use any changer config.
> > >
> > > I was able to label (one/day) a few tapes (and write them that evening),
> > > but I'm having difficulty with subsequent tapes.
> > >
> > > samar 8# /usr/local/sbin/amlabel -f samar SAMAR30
> > > rewinding, reading label, reading label: Invalid argument
> > > rewinding, writing label SAMAR30
> > > amlabel: writing label: Invalid argument
> >
> > So you use another tapetype.
> > What does it look like? Any specific settings in there?
> > Using some unusual blocksize or something?
> >
> > Also browse the log- and debugfiles for anything related.
> >
> > Stefan
> ---
>Brian R Cuttler [EMAIL PROTECTED]
>Computer Systems Support(v) 518 486-1697
>Wadsworth Center(f) 518 473-6384
>NYS Department of HealthHelp Desk 518 47
Re: selfcheck request failed: timeout waiting for ACK (with secondary addr on eth0 only)
Thanks, that did the trick (added bind address)... >Force the listen address in the relevant xinetd.d file. This will do the > trick. -- Luc Lalonde, analyste - Département de génie informatique: Éole polytechnique de Montréal (514) 340-4711 x5049 [EMAIL PROTECTED] - If God intended people to be naked, they would be born that way. -- Oscar Wilde -
Re: amlabel problem
Stefan,
I didn't realize the amlabel command wrote a log, I have it,
unfortunately not as informative as one might like in these
circumstances.
samar 5# more amlabel.20080229105753.debug
amlabel: debug 1 pid 873486 ruid 0 euid 0: start at Fri Feb 29 10:57:53 2008
amlabel: writing label: Invalid argument
amlabel: pid 873486 finish time Fri Feb 29 10:57:53 2008
The change from the jukebox to the standalone drive involved
these changes to amanda.conf.
samar 11# diff amanda.conf amanda.conf-20080221-jukebox
93,95c93,94
< #runtapes 2 # number of tapes to be used in a single run of amdump
< runtapes 1# number of tapes to be used in a single run of amdump
< #tpchanger "chg-zd-mtx" # the tape-changer glue script
---
> runtapes 2# number of tapes to be used in a single run of amdump
> tpchanger "chg-zd-mtx"# the tape-changer glue script
97,98c96
< #tapedev "/dev/sdlt2" # the no-rewind tape device to be used
< tapedev "/dev/sdlt" # the no-rewind tape device to be used
---
> tapedev "/dev/sdlt2" # the no-rewind tape device to be used
101,102c99,100
< #changerfile "/usr5/amanda/chg-zd-mtx"
< #changerdev "/dev/scsi/sc7d1l0"
---
> changerfile "/usr5/amanda/chg-zd-mtx"
> changerdev "/dev/scsi/sc7d1l0"
Apparently I didn't change the tape type, I probably should have
but I don't know that the tapes differ except for capacity as the
current drive is an SDLT 220.
samar 13# mt -f /dev/sdlt status
Controller: SCSI
Device: QUANTUM: SuperDLT1 3737?7
Status: 0x20262
Drive type: unknown
Media : READY, writable, at BOT
samar 14# mt -f /dev/sdlt2 status
Controller: SCSI
Device: QUANTUM: SDLT320 3838?8
Status: 0xa00
Drive type: unknown
Media : Not READY
>From amanda.conf, the tapetype definition. Nothing terribly odd
here I don't think.
define tapetype SDLT {
comment "QUAMTUM SDLT320"
length 16 mbytes
filemark 100 kbytes # don't know a better value
speed 100 kbytes# dito
}
And again, I was able to label and write the first several tapes
without addititional changes to the config.
I was also unable to dump or tar to the drive, I wonder if we
don't have a general failure.
I will ask a user to see if they can access the drive properly
with whatever tapes they normally use in this drive (it was used
for user data archiving before I commendeered it.
thanks,
Brian
On Fri, Feb 29, 2008 at 09:57:07AM +0100, Stefan G. Weichinger wrote:
> Brian Cuttler schrieb:
> > Hello Amanda users,
> >
> > I had the jukebox I use on one of my SGI/IRIX Amanda servers fail
> > and we reverted to the attached standalone SDLT 220.
> >
> > I modified amanda.conf to use the different tape drive and to
> > not use any changer config.
> >
> > I was able to label (one/day) a few tapes (and write them that evening),
> > but I'm having difficulty with subsequent tapes.
> >
> > samar 8# /usr/local/sbin/amlabel -f samar SAMAR30
> > rewinding, reading label, reading label: Invalid argument
> > rewinding, writing label SAMAR30
> > amlabel: writing label: Invalid argument
>
> So you use another tapetype.
> What does it look like? Any specific settings in there?
> Using some unusual blocksize or something?
>
> Also browse the log- and debugfiles for anything related.
>
> Stefan
---
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
IMPORTANT NOTICE: This e-mail and any attachments may contain
confidential or sensitive information which is, or may be, legally
privileged or otherwise protected by law from further disclosure. It
is intended only for the addressee. If you received this in error or
from someone who was not authorized to send it to you, please do not
distribute, copy or use it or any attachments. Please notify the
sender immediately by reply e-mail and delete this from your
system. Thank you for your cooperation.
Re: amflush and splitted disk entry
Dustin J. Mitchell wrote: On Thu, Feb 28, 2008 at 11:36 AM, julien brule <[EMAIL PROTECTED]> wrote: Scanning /Data/amanda/amanda-hold... 20080227004501: found Amanda directory. skipping cruft directory, perhaps you should delete it. skipping system directory skipping system directory Could not find any valid dump image, check directory. but all the host._disk.part is in the holding directory. What is the output of find /Data/amanda/amanda-hold -type f -ls 531726343 41984044 -rw--- 1 amandabackup disk 42949672960 fév 27 22:45 /Data/amanda/amanda-hold/20080227004501/mesopl-si._data2.0.5 531726338 41984044 -rw--- 1 amandabackup disk 42949672960 fév 27 16:24 /Data/amanda/amanda-hold/20080227004501/mesopl-si._data2.0.1 531726346 21147348 -rw--- 1 amandabackup disk 21633728512 fév 28 03:14 /Data/amanda/amanda-hold/20080227004501/mesopl-si._data2.0.8 531726341 41984044 -rw--- 1 amandabackup disk 42949672960 fév 27 19:17 /Data/amanda/amanda-hold/20080227004501/mesopl-si._data2.0.3 531726342 41984044 -rw--- 1 amandabackup disk 42949672960 fév 27 20:55 /Data/amanda/amanda-hold/20080227004501/mesopl-si._data2.0.4 531726339 41984044 -rw--- 1 amandabackup disk 42949672960 fév 27 14:57 /Data/amanda/amanda-hold/20080227004501/mesopl-si._data2.0 531726345 41984044 -rw--- 1 amandabackup disk 42949672960 fév 28 02:24 /Data/amanda/amanda-hold/20080227004501/mesopl-si._data2.0.7 531726344 41984044 -rw--- 1 amandabackup disk 42949672960 fév 28 00:33 /Data/amanda/amanda-hold/20080227004501/mesopl-si._data2.0.6 531726340 41984044 -rw--- 1 amandabackup disk 42949672960 fév 27 17:50 /Data/amanda/amanda-hold/20080227004501/mesopl-si._data2.0.2 42156034 41984044 -rw--- 1 amandabackup disk 42949672960 fév 29 11:41 /Data/amanda/amanda-hold/20080228190001/mesopl-si._data.0.7.tmp 42172417 41984044 -rw--- 1 amandabackup disk 42949672960 fév 29 07:51 /Data/amanda/amanda-hold/20080228190001/mesopl-si._data.0.5.tmp 101056513 41984044 -rw--- 1 amandabackup disk 42949672960 fév 29 00:59 /Data/amanda/amanda-hold/20080228190001/mesopl-si._data.0.1.tmp 42172418 41984044 -rw--- 1 amandabackup disk 42949672960 fév 29 09:50 /Data/amanda/amanda-hold/20080228190001/mesopl-si._data.0.6.tmp 42156035 6790068 -rw--- 1 amandabackup disk 6946226176 fév 29 11:59 /Data/amanda/amanda-hold/20080228190001/mesopl-si._data.0.8.tmp 369426433 41984044 -rw--- 1 amandabackup disk 42949672960 fév 29 06:05 /Data/amanda/amanda-hold/20080228190001/mesopl-si._data.0.4.tmp 168099841 41984044 -rw--- 1 amandabackup disk 42949672960 fév 29 04:26 /Data/amanda/amanda-hold/20080228190001/mesopl-si._data.0.3.tmp 101056514 41984044 -rw--- 1 amandabackup disk 42949672960 fév 28 23:14 /Data/amanda/amanda-hold/20080228190001/mesopl-si._data.0.tmp 109379585 41984044 -rw--- 1 amandabackup disk 42949672960 fév 29 02:46 /Data/amanda/amanda-hold/20080228190001/mesopl-si._data.0.2.tmp thanks Dustin
Re: amlabel problem
Brian Cuttler schrieb: > Hello Amanda users, > > I had the jukebox I use on one of my SGI/IRIX Amanda servers fail > and we reverted to the attached standalone SDLT 220. > > I modified amanda.conf to use the different tape drive and to > not use any changer config. > > I was able to label (one/day) a few tapes (and write them that evening), > but I'm having difficulty with subsequent tapes. > > samar 8# /usr/local/sbin/amlabel -f samar SAMAR30 > rewinding, reading label, reading label: Invalid argument > rewinding, writing label SAMAR30 > amlabel: writing label: Invalid argument So you use another tapetype. What does it look like? Any specific settings in there? Using some unusual blocksize or something? Also browse the log- and debugfiles for anything related. Stefan
Re: DLT8000 vs. VS80
Aaron J. Grier schrieb: > On Tue, Feb 26, 2008 at 10:16:14AM +0200, Toomas Aas wrote: >> From my experience I would say the seller is correct. I haven't tried >> using DLTVS80 tapes with DLT8000, but I know for a fact that the >> opposite can't be done - tapes that were written with DLT8000 cannot >> be read with DLTVS. The only way to re-use them would be to degauss >> them first, but I don't have that kind of equipment so I haven't >> tried. > > http://seer.support.veritas.com/docs/276506.htm indicates that the 8000 > has higher magnetic strength writes than VS80, so while VS80 cannot > overwrite tapes written by 8000, I would assume that 8000 would be able > overwrite VS80 tapes. > > if anybody wants to find out for sure, I'm happy to have someone send me > a VS80-written tape in one of my DLT8000s and see if I can overwrite it. Same here, I would give it a try. For now I canceled my eBay-buy because of this uncertainty. Greets, Stefan
