Tapelist
Hello, I got a question about the tapelist. If I look inti the file call tapelist This is what I have : 20010228 Backup00 reuse 20010212 DailySet104 reuse 20010212 DailySet103 reuse 20010209 DailySet102 reuse 20010208 DailySet101 reuse 0 Backup52 reuse 0 Backup51 reuse 0 Backup42 reuse 0 Backup41 reuse 0 Backup32 reuse 0 Backup31 reuse 0 Backup22 reuse 0 Backup21 reuse 0 Backup12 reuse 0 Backup11 reuse But What I would like to have is : 0 Backup52 reuse 0 Backup42 reuse 0 Backup32 reuse 0 Backup22 reuse 0 Backup12 reuse 0 Backup51 reuse 0 Backup41 reuse 0 Backup31 reuse 0 Backup21 reuse 0 Backup11 reuse Can I just change it manually or shall I change it somewhere else ? Also I would like to get ride of one tape called backup00 which was use for tests.Can I just wipe it out from this file ? Thanks in advance -- Olivier Collet
Re: Do I get this right ?
Thanks a lot for your explanation. One more question , when I do amcheck and no error are reported, can I trust it 100 % that the backup will work ? regards -- Olivier Collet On Mon, 5 Mar 2001, John R. Jackson wrote: > >I'm in new in this amanda world. > > Welcome! > > >First the cron job on the server launches the amdump > >The amanda checks the disklist and connect to the client via UDP > >The Client answer back via UDP and launches amandad which takes care of > >the transit. > >Is it right ? > > Pretty much, although the actual data transfer of the backup image, > error messages and catalogue (if enabled) is done with TCP. > > It goes like this: > > Amanda Server Amanda Client > = = > send UDP request to client:10082 > inetd sees UDP request and starts > amandad > > amandad reads and decodes packet, > performs security checks and starts > the requested "service" (selfcheck, > sendsize, sendbackup) > > sendbackup creates two or three > TCP sockets (data, messages, > index/catalogue) and sends those > port numbers back to the server in > a UDP packet > > client waits for incoming connections > on the new ports > > get port numbers from client and > connect via TCP > > accepts connections and transfers > data > > >One other question, can soemone tells me which port I have to open on the > >client side ? > > UDP 10080 is the only thing a client needs. The server needs TCP 10082 > and 10083 if you plan on using amrecover. > > When the sendbackup TCP sockets are created on the client and when > the corresponding sockets are created on the server, ports are chosen > first from the range you gave ./configure with --with-portrange (if > you set that at all), then privileged ports (512 .. 1023) are tried, > then any available port. When programs are not running as root (such > as sendbackup), they cannot get a privileged port, so that part does > not apply. > > UDP ports are bound to specific ranges just like TCP ports. Amcheck, > planner and dumper use that so you can limit the values selected to get > through a firewall. > > >I have removed the UDP 10080, TCP 10082 - 10083 from the > >"services" file on the client machine, restarted inetd and amcheck still > >works. Is it normal ? > > I don't know how that could work. After removing those entries from your > services file, inetd should have been unhappy with your configuragion file > and not accepted connections. There must be something else going on here. > > >Olivier Collet > > John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED] >
Re: Do I get this right ?
On Mar 6, 2001, Olivier Collet <[EMAIL PROTECTED]> wrote:
> when I do amcheck and no error are reported, can I trust it 100 %
> that the backup will work?
Well, there's always Murphy's law :-)
If something breaks after amcheck completes, the backup may fail on
the broken host. Also, some host may time out, run out of memory,
etc. Things are very creating in finding ways to fail.
But, in general, as soon as amcheck passes, you can be relatively
confident that things will hopefully work.
--
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: Tapelist
On Mar 6, 2001, Olivier Collet <[EMAIL PROTECTED]> wrote:
> Can I just change it manually
Yep
> Also I would like to get ride of one tape called backup00 which was use
> for tests. Can I just wipe it out from this file ?
Yep. Or amrmtape it.
--
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
amflush bug with multiple config's?
Hi, I had dumps from two different configurations dumped to the same holding disk, but to two directories as usual. Beeing too lazy to sort out what date belongs to what configuration, I decided to flush all directories. I expected Amanda to flush only the directory belonging to the configuration given on the command line and leave the other one alone for a later flush. But both directories disappeared after the first successful flush. I expect my indexes to be messed up now. As the weekly tapes now have files from the daily backups, it went wrong to the better combination. I can live with these bad entries growing out of the indexes, but others might not. What's the remedy for this? I'd like to see amflush asking "Do you really want to flush different config's to the same tape?" in this case. I'm sure there are uses for that "feature" the way it is... Both configurations have identical disk lists (No sym links etc. involved). I use Amanda 2.4.2 on a Linux system (Suse 7.0). My command line was as usual: "amflush woechentlich" (woechentlich=weekly). I could not find a log file of the right date or name. Config files are available at request. I'd like not to repeat this behavior as my server is in production. Johannes Nieß
Re: amflush bug with multiple config's?
On Tue, Mar 06, 2001 at 12:44:33PM +0100, Johannes Niess wrote: > Hi, > > I had dumps from two different configurations dumped to the same > holding disk, but to two directories as usual. Beeing too lazy to sort > out what date belongs to what configuration, I decided to flush all > directories. Why do you use the same directory for both configuration? You should use different directory. > I expected Amanda to flush only the directory belonging > to the configuration given on the command line and leave the other one > alone for a later flush. Amanda don't know the config of a holding image. > But both directories disappeared after the > first successful flush. I expect my indexes to be messed up now. As > the weekly tapes now have files from the daily backups, it went wrong > to the better combination. I can live with these bad entries growing > out of the indexes, but others might not. What's the remedy for this? Move your index from your weekly conf to your daily conf. I'm not sure it will work :-( > I'd like to see amflush asking "Do you really want to flush different > config's to the same tape?" in this case. I'm sure there are uses for > that "feature" the way it is... Amanda can't do that. > > Both configurations have identical disk lists (No sym links > etc. involved). I use Amanda 2.4.2 on a Linux system (Suse 7.0). My > command line was as usual: "amflush woechentlich" > (woechentlich=weekly). I could not find a log file of the right date > or name. Config files are available at request. I'd like not to repeat > this behavior as my server is in production. > > Johannes Nieß Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
RE: Do I get this right ?
> > > when I do amcheck and no error are reported, can I trust it 100 % > > that the backup will work? > > Well, there's always Murphy's law :-) > amcheck doesn't, by default, try to write to the tape. It just reads the label. If, for example, the write-protect tab is set on today's tape, amcheck will succeed, but the backup will fail. (Actually, if you've got sufficient holding disk space, only the flush will fail.) Carey
Re: Full Backups Daily?
> >We would like to change it to FULL backups 5 days a week. > >How would we do this? > > dumpcycle 0 What should runspercycle bet set to ? -- Brad
restiring w/o amanda
Hello, I have a question related to restoring without amanda. According to the docs, the method is just : mt -f /dev/nst0 rewind dd if=/dev/nst0 bs=32 skip=1 | tar xv - but when I use the tar (yes, it's gtar, really) it complains that the file is not a valid archive. I can restore files using amrecover successfully... but not without amanda. While I'm not opposed to having an amanda installation laying around on a hard drive, I'd much rather be able to do without it during crunch time. :o) Any insights/suggestions? Anyone else run into this? Thanks in advance, Jer
Re: restiring w/o amanda
>According to the docs, the method is just : > >mt -f /dev/nst0 rewind >dd if=/dev/nst0 bs=32 skip=1 | tar xv - > >but when I use the tar (yes, it's gtar, really) it complains >that the file is not a valid archive. ... You skipped a step. You have to position the tape with "mt fsf" to the proper file between doing the "rewind" and the "dd". What you did above was read the tape label (the first file on the tape) and pass an empty image to gtar. The obvious question is then, "how do I know what file has the image I need". For that, you'll have to either have an offline listing of some type from each Amanda run (such as setting up lbl-templ in amanda.conf to print a report, running amtoc and sending that file to an alternate machine, etc), or you can scan the tape(s) and generate a catalogue (the following ksh code is untested): mt -f /dev/nst0 rewind integer file=0 while true do echo === $file === if dd if=/dev/nst0 bs=32k count=1 > /tmp/header.$$ then sed 1q < /tmp/header.$$ ((file = file + 1)) else break fi done rm -f /tmp/header.$$ >Jer John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Full Backups Daily?
>> dumpcycle 0 > >What should runspercycle bet set to ? Well, how many runs do you think you can get done in zero days? :-) Just leave it unset. It won't matter. >Brad John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amflush bug with multiple config's?
Jean-Louis Martineau <[EMAIL PROTECTED]> writes: > On Tue, Mar 06, 2001 at 12:44:33PM +0100, Johannes Niess wrote: > > Hi, > > > > I had dumps from two different configurations dumped to the same > > holding disk, but to two directories as usual. Beeing too lazy to sort > > out what date belongs to what configuration, I decided to flush all > > directories. > > Why do you use the same directory for both configuration? > You should use different directory. I used /tmp/amanda-holdingdisk as holding disk entry in both amanda.conf files. /tmp/amanda-holdingdisk/20010301 and /tmp/amanda-holdingdisk/20010302 where created. > > > I expected Amanda to flush only the directory belonging > > to the configuration given on the command line and leave the other one > > alone for a later flush. > > Amanda don't know the config of a holding image. >From the amflush man page: " Amflush will look in the holding disks specified by the amanda.conf file in /etc/amanda/config for any non-empty Amanda work directories. It then prompts you to select a directory or to process all of the directories. The work directories in the holding disks are named by the date at the time amdump was run, e.g. 19910215. " IMHO the tiny word ANY needs bold uppercase letters. Looks like a typical man page written by the programmer himself: it's logically correct but hides the features :-) I've often made the experience that only semi-experts are good at documenting and explaining. Why do I need to give a configuration in the command line? Looks like it's only used to check the tape label. As I said in my first post, I see that as a design error (at least psychologically). [...] > > I'd like to see amflush asking "Do you really want to flush different > > config's to the same tape?" in this case. I'm sure there are uses for > > that "feature" the way it is... > > Amanda can't do that. There should be some bytes left unused in the 32 kB header of dump files, that can get used to write the configuration name to it. I can imagine a complicated restore, where several dump files from several config's are written to the same parent directory before the restore procedure itself. Having the config in them and checks done automatically would greatly reduce chaos and administrator stress. The features are needed for append to tape anyway. The easier approach would be to use /holdingdisk/config/dumpdir, but would not help in restores. In the meanwhile I'll use different directories for holding disks. The current behavior allows to do some usefull stuff: Config A: normal disk list entries etc., but no tapes labeled config B: ditto Config C: no disk list entries, just tapes "amflush C" to write two configs to the same tape by answering "all". Indexes for C could be used in restores. Johannes Niess
Re: restiring w/o amanda
At 11:58 AM 3/6/2001, John R. Jackson wrote: > >According to the docs, the method is just : > > > >mt -f /dev/nst0 rewind > >dd if=/dev/nst0 bs=32 skip=1 | tar xv - > > > >but when I use the tar (yes, it's gtar, really) it complains > >that the file is not a valid archive. ... > >You skipped a step. You have to position the tape with "mt fsf" to the >proper file between doing the "rewind" and the "dd". What you did above >was read the tape label (the first file on the tape) and pass an empty >image to gtar. Someone else email me privately and told me the sequence was as follows. mt -f /dev/nst0 rewind mt -f /dev/nst0 fsf 1 dd if=/dev/nst0 bs=32 skip=1 | tar xvf - When I try the above, the following is output: tar: Hmm, this doesn't look like a tar archive tar: Skipping to next file header dd : /dev/nst0: I/O error 1023+0 records in 1023+0 records out Yuri Pismerov replied and mentioned that some versions of Redhat have a problem with 'skip' and suggested that I try it like so: mt -f /dev/nst0 rewind mt -f /dev/nst0 fsf 1 dd if=/dev/nst0 of=/dev/null bs=32 count=1 dd if=/dev/nst0 bs=32 skip=1 | tar xvf - which outputs a simple: dd: /dev/nst0: I/O error 0+0 records in 0+0 records out Which leads me to wonder about the integrity of my tape... although if I do: mt -f /dev/nst0 rewind dd if=/dev/nst0 bs=32 count=1 I see: AMANDA: TAPESTART DATE 20010227 1+0 records in 1+0 records out so obviously part of the tape is readable... What Giveth!!? Jer
Re: Do I get this right ?
"Carey Jung" <[EMAIL PROTECTED]> writes: > > > > > when I do amcheck and no error are reported, can I trust it 100 % > > > that the backup will work? > > > > Well, there's always Murphy's law :-) > > > > amcheck doesn't, by default, try to write to the tape. It just reads the > label. If, for example, the write-protect tab is set on today's tape, > amcheck will succeed, but the backup will fail. (Actually, if you've got > sufficient holding disk space, only the flush will fail.) Not exactly. Amanda might (/will?) go to degraded mode and do only backup levels >0, if you use the standard configuration without changing the "reserve" parameters. The word "flush" is a bit misleading in this case. A (neglected) reason to have more tapes than used in one dump cycle is being able to use "amcheck -w". The write test is destructive. >From the amcheck man page: " -w Enables a destructive check for write-protection on the tape (which would otherwise cause the subse quent amdump to fail). If the tape is writable, this check causes all data after the tape label to be erased (actually depends on the device driver: there is no portable non-destructive way to check for write-protection). The check implies -t and is only made if the tape is otherwise correct. " Why doesn't Amanda use the following portable, non-destructive write test: read label; amlabel -f config label Does it mess up the indexes? Johannes Niess
Re: restiring w/o amanda
Hi, i hope you tried the command dd if=/dev/nst0 bs=32k skip=1 | tar -xvf - and not the one you have in your mail as you are running linux, try pulling the image to disk with dd if=/dev/nst0 of=file01 and then use dd if=file01 bs=32k skip=1 | tar xvf - on it. dd seems to have problems with some scsi-tapes and the skip option. hope it helps Christoph Jerry Lynde schrieb: > mt -f /dev/nst0 rewind > dd if=/dev/nst0 bs=32 skip=1 | tar xv - --^-- --^-- missing k missing f > > but when I use the tar (yes, it's gtar, really) it complains > that the file is not a valid archive. I can restore files using
Re: restiring w/o amanda
At 12:39 PM 3/6/2001, Christoph Scheeder wrote: >Hi, > >i hope you tried the command > dd if=/dev/nst0 bs=32k skip=1 | tar -xvf - >and not the one you have in your mail > >as you are running linux, try pulling the image to disk with > dd if=/dev/nst0 of=file01 >and then use > dd if=file01 bs=32k skip=1 | tar xvf - >on it. >dd seems to have problems with some scsi-tapes and the skip option. >hope it helps >Christoph > >Jerry Lynde schrieb: > > > mt -f /dev/nst0 rewind > > dd if=/dev/nst0 bs=32 skip=1 | tar xv - > --^-- --^-- >missing k missing f > > > > but when I use the tar (yes, it's gtar, really) it complains > > that the file is not a valid archive. I can restore files using I wasn't using a k...now that I am using the bs=32k it gives me more info on the header which is a good thing but I'm still getting I/O errors on subsequent blocks, aka everything after the first header (the amanda tape label) is this just a flaky tape thing?? I frequently have to relabel tapes due to intermittent I/O errors... have I got a bad tape drive here? Jer
Re: restiring w/o amanda
Jerry Lynde wrote: > > At 12:39 PM 3/6/2001, Christoph Scheeder wrote: > >Hi, > > > >i hope you tried the command > > dd if=/dev/nst0 bs=32k skip=1 | tar -xvf - > >and not the one you have in your mail > > > >as you are running linux, try pulling the image to disk with > > dd if=/dev/nst0 of=file01 > >and then use > > dd if=file01 bs=32k skip=1 | tar xvf - > >on it. > >dd seems to have problems with some scsi-tapes and the skip option. > >hope it helps > >Christoph > > > >Jerry Lynde schrieb: > > > > > mt -f /dev/nst0 rewind > > > dd if=/dev/nst0 bs=32 skip=1 | tar xv - > > --^-- --^-- > >missing k missing f > > > > > > but when I use the tar (yes, it's gtar, really) it complains > > > that the file is not a valid archive. I can restore files using > > I wasn't using a k...now that I am using the bs=32k it gives me > more info on the header which is a good thing > > but I'm still getting I/O errors on subsequent blocks, aka everything after > the first header (the amanda tape label) > > is this just a flaky tape thing?? I frequently have to relabel tapes > due to intermittent I/O errors... have I got a bad tape drive here? Please give us the set of the commands (copy/paste). > > Jer -- Yuri Pismerov, TUCOWS.COM INC. (416) 535-0123 ext. 1352 S/MIME Cryptographic Signature
Re: restiring w/o amanda
Christoph Scheeder wrote: > > Hi, > > i hope you tried the command > dd if=/dev/nst0 bs=32k skip=1 | tar -xvf - > and not the one you have in your mail > > as you are running linux, try pulling the image to disk with > dd if=/dev/nst0 of=file01 What to do if the backup set does not fit the disk partition ? I'd better do the following: dd if=/dev/nst0 of=/dev/null bs=32k count=1 dd if=/dev/nst0 bs=32k | tar ... Other than that it will save time because you do this in a single tape run. > and then use > dd if=file01 bs=32k skip=1 | tar xvf - > on it. > dd seems to have problems with some scsi-tapes and the skip option. > hope it helps > Christoph > > Jerry Lynde schrieb: > > > mt -f /dev/nst0 rewind > > dd if=/dev/nst0 bs=32 skip=1 | tar xv - > --^-- --^-- >missing k missing f > > > > but when I use the tar (yes, it's gtar, really) it complains > > that the file is not a valid archive. I can restore files using -- Yuri Pismerov, TUCOWS.COM INC. (416) 535-0123 ext. 1352 S/MIME Cryptographic Signature
Re: Tapelist
On 06 Mar 2001 06:47:28 -0300 Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Mar 6, 2001, Olivier Collet <[EMAIL PROTECTED]> wrote: > > > Can I just change it manually > > Yep > > > Also I would like to get ride of one tape called backup00 which was use > > for tests. Can I just wipe it out from this file ? > > Yep. Or amrmtape it. I'm in a similar situation. I've taken over someone else's installation of amanda and am just learning about it. I noticed that the tapes in the file tapelist were not in order; in particular the end of the list looked like this: tape1_134 tape1_133 tape1_131 tape1_132 so I moved tape1_131 to the bottom, expecting amanda to look for tape1_131. It wasn't a big deal but when I ran amflush(the previous night's had failed) the message was that it expected tape1_132, but it still ran. So how did it know to expect tape1_132? The other question I have is this: all the lines in the file tapelist say 'reuse'. So how are we expected to know which tapes to keep? Ross -- Ross Macintyre Heriot-Watt University [EMAIL PROTECTED]
Re: restiring w/o amanda
At 01:07 PM 3/6/2001, Yura Pismerov wrote: >Jerry Lynde wrote: > > > > At 12:39 PM 3/6/2001, Christoph Scheeder wrote: > > >Hi, > > > > > >i hope you tried the command > > > dd if=/dev/nst0 bs=32k skip=1 | tar -xvf - > > >and not the one you have in your mail > > > > > >as you are running linux, try pulling the image to disk with > > > dd if=/dev/nst0 of=file01 > > >and then use > > > dd if=file01 bs=32k skip=1 | tar xvf - > > >on it. > > >dd seems to have problems with some scsi-tapes and the skip option. > > >hope it helps > > >Christoph > > > > > >Jerry Lynde schrieb: > > > > > > > mt -f /dev/nst0 rewind > > > > dd if=/dev/nst0 bs=32 skip=1 | tar xv - > > > --^-- --^-- > > >missing k missing f > > > > > > > > but when I use the tar (yes, it's gtar, really) it complains > > > > that the file is not a valid archive. I can restore files using > > > > I wasn't using a k...now that I am using the bs=32k it gives me > > more info on the header which is a good thing > > > > but I'm still getting I/O errors on subsequent blocks, aka everything after > > the first header (the amanda tape label) > > > > is this just a flaky tape thing?? I frequently have to relabel tapes > > due to intermittent I/O errors... have I got a bad tape drive here? > > Please give us the set of the commands (copy/paste). Here's the sequence (same as an earlier email) mt -f /dev/nst0 rewind mt -f /dev/nst0 fsf 1 dd if=/dev/nst0 bs=32k skip=1 | tar xvf - When I try the above, the following is output: tar: Hmm, this doesn't look like a tar archive tar: Skipping to next file header dd : /dev/nst0: I/O error 1023+0 records in 1023+0 records out Yuri Pismerov replied and mentioned that some versions of Redhat have a problem with 'skip' and suggested that I try it like so: mt -f /dev/nst0 rewind mt -f /dev/nst0 fsf 1 dd if=/dev/nst0 of=/dev/null bs=32k count=1 dd if=/dev/nst0 bs=32k skip=1 | tar xvf - which outputs a simple: dd: /dev/nst0: I/O error 0+0 records in 0+0 records out Which leads me to wonder about the integrity of my tape... although if I do: mt -f /dev/nst0 rewind dd if=/dev/nst0 bs=32k count=1 I see: AMANDA: TAPESTART DATE 20010227 1+0 records in 1+0 records out so obviously part of the tape is readable... What Giveth!!? Jer
Re: Tapelist
>so I moved tape1_131 to the bottom, expecting amanda to look for >tape1_131. It wasn't a big deal but when I ran amflush(the previous >night's had failed) the message was that it expected tape1_132, but it >still ran. So how did it know to expect tape1_132? The primary key is the date string, not the VSN. Amanda doesn't care if you label your tapes "larry", "moe" and "curly", so VSN is not a valid sort criteria. The secondary sort key is the position within the file. So to "move" a tape back into what a human wants for order, you need to send it to the bottom and change the datestring to match the previous line. You can test this with "amadmin tape" which will show you the next tape(s) expected. >The other question I have is this: >all the lines in the file tapelist say 'reuse'. So how are we expected >to know which tapes to keep? What do you mean by "which tapes to keep"? The "reuse" flag tells Amanda it may use this tape again when it is the next one in the list. You can tell Amanda to not reuse a tape with "amadmin no-reuse ...". When Amanda looks at that tape it will skip over it. Note that if you mark some tapes as "no-reuse", Amanda will ask for "new" tapes until there are "tapecycle" reusable ones again. >Ross John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Do I get this right ?
>Why doesn't Amanda use the following portable, non-destructive write test: > >read label; amlabel -f config label How do you figure this is non-destructive? It completely clobbers all access to data beyond the label. What if there was some problem and amcheck was happy with the tape but you realized some other way it was not what you wanted to use for the next backups? I'd just as soon defer writing on a tape until the last moment. What's really needed is a non-destructive "can I write on this tape" method, e.g. a test of permissions or access(). But that's (unfortunately) highly OS dependent, if possible at all. G. >Johannes Niess John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: restiring w/o amanda
By the way...how does amanda's software compression factor into this? Jer
Re: restiring w/o amanda
>Someone else email me privately and told me the sequence was as follows. > >mt -f /dev/nst0 rewind >mt -f /dev/nst0 fsf 1 >dd if=/dev/nst0 bs=32 skip=1 | tar xvf - > >When I try the above, the following is output: > >tar: Hmm, this doesn't look like a tar archive Are you using software compression? If so, you need to insert a gunzip in the pipeline: dd if=/dev/nst0 bs=32k skip=1 | gunzip | tar xvf - >Yuri Pismerov replied and mentioned that some versions of Redhat have >a problem with 'skip' and suggested that I try it like so: > >mt -f /dev/nst0 rewind >mt -f /dev/nst0 fsf 1 >dd if=/dev/nst0 of=/dev/null bs=32 count=1 >dd if=/dev/nst0 bs=32 skip=1 | tar xvf - Actually, the correct sequence for any OS would be: (dd of=/dev/null bs=32k count=1 && dd bs=32k) < /dev/nst0 | ... This will work for both SystemV tape semantics and BSD. >which outputs a simple: > >dd: /dev/nst0: I/O error >0+0 records in >0+0 records out > >Which leads me to wonder about the integrity of my tape... Yup. Dd is just reporting what the OS told it, which is that the tape cannot be read. You might try retensioning the tape, if that's an option, or start looking at cables, connections, termination, cleaning the drive, etc. >Jer John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: restiring w/o amanda
Are you sure the tar archive is not compressed (gzipped) ? Try xzvf instead of xvf. Jerry Lynde wrote: > > At 01:07 PM 3/6/2001, Yura Pismerov wrote: > >Jerry Lynde wrote: > > > > > > At 12:39 PM 3/6/2001, Christoph Scheeder wrote: > > > >Hi, > > > > > > > >i hope you tried the command > > > > dd if=/dev/nst0 bs=32k skip=1 | tar -xvf - > > > >and not the one you have in your mail > > > > > > > >as you are running linux, try pulling the image to disk with > > > > dd if=/dev/nst0 of=file01 > > > >and then use > > > > dd if=file01 bs=32k skip=1 | tar xvf - > > > >on it. > > > >dd seems to have problems with some scsi-tapes and the skip option. > > > >hope it helps > > > >Christoph > > > > > > > >Jerry Lynde schrieb: > > > > > > > > > mt -f /dev/nst0 rewind > > > > > dd if=/dev/nst0 bs=32 skip=1 | tar xv - > > > > --^-- --^-- > > > >missing k missing f > > > > > > > > > > but when I use the tar (yes, it's gtar, really) it complains > > > > > that the file is not a valid archive. I can restore files using > > > > > > I wasn't using a k...now that I am using the bs=32k it gives me > > > more info on the header which is a good thing > > > > > > but I'm still getting I/O errors on subsequent blocks, aka everything after > > > the first header (the amanda tape label) > > > > > > is this just a flaky tape thing?? I frequently have to relabel tapes > > > due to intermittent I/O errors... have I got a bad tape drive here? > > > > Please give us the set of the commands (copy/paste). > > Here's the sequence (same as an earlier email) > > mt -f /dev/nst0 rewind > mt -f /dev/nst0 fsf 1 > dd if=/dev/nst0 bs=32k skip=1 | tar xvf - > > When I try the above, the following is output: > > tar: Hmm, this doesn't look like a tar archive > tar: Skipping to next file header > dd : /dev/nst0: I/O error > 1023+0 records in > 1023+0 records out > > Yuri Pismerov replied and mentioned that some versions of Redhat have > a problem with 'skip' and suggested that I try it like so: > > mt -f /dev/nst0 rewind > mt -f /dev/nst0 fsf 1 > dd if=/dev/nst0 of=/dev/null bs=32k count=1 > dd if=/dev/nst0 bs=32k skip=1 | tar xvf - > > which outputs a simple: > > dd: /dev/nst0: I/O error > 0+0 records in > 0+0 records out > > Which leads me to wonder about the integrity of my tape... > although if I do: > > mt -f /dev/nst0 rewind > dd if=/dev/nst0 bs=32k count=1 > > I see: > > AMANDA: TAPESTART DATE 20010227 1+0 records in > 1+0 records out > > so obviously part of the tape is readable... > > What Giveth!!? > > Jer -- Yuri Pismerov, TUCOWS.COM INC. (416) 535-0123 ext. 1352 S/MIME Cryptographic Signature
Re: restiring w/o amanda
On Tue, 6 Mar 2001 at 2:23pm, Jerry Lynde wrote > By the way...how does amanda's software compression factor into this? > Argh. And I had meant to ask that earlier. If you're using software compression, then the images on the tape are gzipped tar files. So you need to throw gzip in the pipe *before* tar. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: amflush bug with multiple config's?
>Why do I need to give a configuration in the [amflush] command line? Looks like >it's only used to check the tape label. ... It's used to find the holding disk, to find the tape drive, to find what tape changer to use, to find the tapelist file, to find the Amanda database directory, to find where to E-mail the report, ... >As I said in my first post, I >see that as a design error (at least psychologically). I don't see any way to do what it needs to do without an amanda.conf, which translates to needing a configuration name. >Johannes Niess John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: restiring w/o amanda
>By the way...how does amanda's software compression factor into this? You have to know if the image is compressed or not and insert the appropriate uncompress command in the pipeline (or, as a special case, use the GNU tar 'z' option, which does that for you). Note that the image header (the first 32 KByte block of the file) tells whether the image is compressed or not. For that matter, it tells you the exact command sequence to use to recover the image. >Jer John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: restiring w/o amanda
At 02:42 PM 3/6/2001, John R. Jackson wrote: > >By the way...how does amanda's software compression factor into this? > >You have to know if the image is compressed or not and insert the >appropriate uncompress command in the pipeline (or, as a special case, >use the GNU tar 'z' option, which does that for you). > >Note that the image header (the first 32 KByte block of the file) tells >whether the image is compressed or not. For that matter, it tells you >the exact command sequence to use to recover the image. Ach!! I am close, I can feel it... I was playing around waiting for replies, and I did the following: mt -f /dev/nst0 rewind dd if=/dev/nst0 bs=32k count=1 dd if=/dev/nst0 bs=32k count=1 dd if=/dev/nst0 bs=32k count=1 the first one showed me: AMANDA: TAPESTART DATE 20010227 TAPE Daily3 1+0 records in 1+0 records out the second gave me: 0+0 records in 0+0 records out and the third produced: AMANDA: FILE 20010227 backup.diligence.com /pkgs lev 0 comp .gz program /bin/gtar To restore, position tape at start of file and run: dd if= bs=32k skip=1 | /usr/bin/gzip -dc | bin/gtar -f... - 1+0 records in 1+0 records out -=BUT=- when I do: mt -f /dev/nst0 rewind mt -f /dev/nst0 fsf 02 I get an I/O error... same as if I "mt -f /dev/nst0 fsf 2" So, then I tried mt -f /dev/nst0 rewind mt -f /dev/nst0 fsf 1 mt -f /dev/nst0 fsf 1 I also get an I/O error... Then I tried to dd the first two to /dev/null and the third time I do dd if=/dev/nst0 bs=32k skip=1 | /usr/bin/gzip -dc | bin/gtar -f... - I see: dd: /dev/nst0: I/O error 0+0 records in 0+0 records out gzip stdin: unexpected end of file Am I going to need to identify the start and end of this file and do it by count? dd if=/dev/nst0 bs=32k skip=1 count=NN | /usr/bin/gzip -dc | bin/gtar -f... - where NN is the number of blocks in the file? Thank the higher powers that I'm dealing with this now as a test run and not later in an emergency...I would have been killed by now :o) Jer
Re: restiring w/o amanda
>Ach!! I am close, I can feel it... I was playing around waiting >for replies, and I did the following: > >mt -f /dev/nst0 rewind >dd if=/dev/nst0 bs=32k count=1 >dd if=/dev/nst0 bs=32k count=1 >dd if=/dev/nst0 bs=32k count=1 First, you need to realize a couple of things: * The system you're on uses BSD tape semantics. That means when you read some blocks, the tape stays positioned in mid-file. If it used SystemV semantics, the tape would auto-fsf to the next file. * The "count=1" parameter reads one **block** (record), not one file. >the first one showed me: > >AMANDA: TAPESTART DATE 20010227 TAPE Daily3 Right. That's the tape label (file 0, block 0). >the second gave me: > >0+0 records in >0+0 records out Right. That's the tape mark (EOF) between the tape label in file 0 and the first backup image. >and the third produced: > >AMANDA: FILE 20010227 backup.diligence.com /pkgs lev 0 comp .gz program >/bin/gtar >... Right. That's the block 0 of file 1 which is an Amanda image header. >when I do: > >mt -f /dev/nst0 rewind >mt -f /dev/nst0 fsf 02 Whoa. Why "fsf 2"? That skips to the second **file**. >I get an I/O error... >... >So, then I tried >... >I also get an I/O error... > >Then I tried to dd the first two to /dev/null Which is the same as: mt -f /dev/nst0 rewind mt -f /dev/nst0 fsf 1 >and the third time I do > >dd if=/dev/nst0 bs=32k skip=1 | /usr/bin/gzip -dc | bin/gtar -f... - > >I see: > >dd: /dev/nst0: I/O error Right. This all fits. Block 1 of file 1 is bad and cannot be read. Period. >Am I going to need to identify the start and end of this file and do it by >count? No. You're going to have to fix the tape drive or abandon trying to get the data back from that tape. It's broken. >Jer John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: restiring w/o amanda
At 03:36 PM 3/6/2001, John R. Jackson wrote: >No. You're going to have to fix the tape drive or abandon trying to >get the data back from that tape. It's broken. Say it ain't so!! Ok, thanks for all your help today, John, Yuri, Joshua and Christoph. :o) I'm going to try using amrecover on a different machine, try using a different tape, and a few other things to make sure this is really a bad tape drive I've got here. It's a HP-T20 Surestore that's about two years old. Hopefully this is just a bad tape :o) thanks again, Jer
