On Fri, Jul 21, 2006 at 06:22:38AM -0700, gil naveh wrote:
> Thanks much for the support. Eventually I was able to restore some of the
> missing files but I still have some open questions.
> 1) I was able to restore the files on the Server where Amanda
> server was initially installed. However, I could not restore the tape from a
> different server (ServerB) with similar operating system (Solaris 9). The
> mystery about the restore process was that I successfully run the
> commands(on serverB):
>
> a. mt -f /dev/rmt/0cn rewind
>
> b. mt -f /dev/rmt/0cn fsf 1
> But when I run the command:
>
> dd if=/dev/rmt/0cn bs=32k skip=1
> It gave me the following error message:
> read: Invalid argument
> 0+0 records in
> 0+0 records out
> Does anybody know why?
> 2) When I restored the data using the command:
>
> dd if=/dev/rmt/0cn bs=32k skip=1 | gzip -d | /usr/sbin/ufsrestore -ivf -
> I was only able to restore files that were saved - level 0 on that
> particular tape; Yet I also restored a folder on Amanda ? that folder was
> lastly restored on run level-1.
> But need to restore certain files from that folder without restoring
> the whole folder ? is this possible using the ufsrestore tool? In the past I
> was able to do so with the amrestore utility.
>
> Thanks,
> gil
> gil naveh <gilnaveh1 AT yahoo DOT com> wrote: Thanks Jon,
> Regarding your comments/questions:
> 1) You keep using a blocksize of 64k for dd, why? Amanda normally uses 32k
> I tried both for 32K and 64k (part of try and error trial I did to recover
> the data) - anyway thanks, now I am confident that amanda uses 32k.
>
> 2)Have you read the docs refered to above for how to recover?
> I read those documents many times - I hate asking questions before doing
> my research - but when I tried to follow the instructions the recover
> failed!
>
> 3)Following an mt rewind, the first thing a dd should see is
> the tape label header file. Your output is certainly NOT
> an amanda tape label. Are you certain this is a valid
> amanda tape? Or you showed the sequence of commands accurately?
> I am 100% sure, it is an Amanda tape label - I only backed up those tapes
> with Amanda and restore the data from them using amrestore!
> Ignore my previous comment regarding reading file from /tmp/data - I just
> realized that I read those files from the HD instead from the tape.
>
> 4)Solaris has a fine file(1) command. What does "file /tmp/data"
> tell you about what dd pulled from the tape? - ignore my privious comment
> regarding reading file from /tmp/data - I just realized that I read those
> files from the HD instead from the tape.
>
> At this stage I just can't recover files from the tape! When running dd I
> keep getting the message:
> read: Invalid argument
> 0+0 records in
> 0+0 records out
>
>
> Thx,
> gil
>
> Jon LaBadie <jon AT jgcomp DOT com> wrote: On Wed, Jul 19, 2006 at
> 02:07:42PM -0700, gil naveh wrote:
> > Thanks for all the help, but I have a problem to restore the files.
> > When I type:
> > root@ # dd if=/dev/rmt/0n ibs=64k | ufsrestore if -
> > I recieve the following error message:
> > read: Invalid argument
> > 0+0 records in
> > 0+0 records out
> > Volume is not in dump format
> >
> > But as far as I know it should be in a dump format!!! ? because in the
> > Amanda.conf I defined the backup as:
> >
> > define dumptype daily {
> > global
> > # program "DUMP" # the default
> > # record yes # the default
> > comment "daily"
> > compress client fast
> > priority high
> > # dumpcycle 5 # should be obtained from dumpcycle above
> > index yes
> > }
> >
> >
> > I also tried the following:
> > % mt -f /dev/rmt/0n rewind
> > % dd if=/dev/rmt/0n of=/tmp/data bs=64k count=2
> > % od -c /tmp/data | head
> >
> > And received the following output:
> > 0000000 \0 002 P 022 \0 \f \0 001 . \0 \0 \0 \0 003 242 Q
> > 0000020 \0 \f \0 002 . . \0 \0 \0 002 P 023 001 350 \0 006
> > 0000040 n e w b c k \0 \0 \0 \f \0 003 b c k \0
> > 0000060 \0 \0 \0 \0 001 320 \0 006 n e w b c k \0 \0
> > 0000100 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
> > *
> > 0001000
> >
> > Can one deduct the dump format from the above output?
> >
> > Many thanks,
> > gil
> > Paul Bijnens
> wrote:
> > On 2006-07-19 17:35, gil naveh wrote:
> > > Thanks for the help.
> > > I am familiar with the Amrestore command.
> >
> > Then you understand that you can replace "amrestore" with a
> > "mt" and "dd".
> >
> >
> ...
> > The docs in http://www.amanda.org/docs/restore.html
> > are a little more expanded, giving more examples in:
> >
> > http://wiki.zmanda.com/index.php/Restoring_files
> >
>
> Grrr, I hate top posting.
> So hard to add inline and following
>
> Anyway, several points.
>
> We don't know it should be a ufsdump, your dumptype includes
> global that we don't see and otherwise does not define PROGRAM.
>
> You keep using a blocksize of 64k for dd, why? Amanda normally
> uses 32k.
>
> Have you read the docs refered to above for how to recover?
>
> Your dumptype says compress, presumably with gzip. I see no
> unzipping in your attempted recovery
> commentary.
>
> Following an mt rewind, the first thing a dd should see is
> the tape label header file. Your output is certainly NOT
> an amanda tape label. Are you certain this is a valid
> amanda tape? Or you showed the sequence of commands accurately?
>
> Solaris has a fine file(1) command. What does "file /tmp/data"
> tell you about what dd pulled from the tape?
>
>
> --
> Jon H. LaBadie jon AT jgcomp DOT com
> JG Computing
> 4455 Province Line Road (609) 252-0159
> Princeton, NJ 08540-4322 (609) 683-7220 (fax)
>
>
>
>>> End of included message <<<
On the surface, if that simple command failed I would say your tape
drive installation, or your hardware has a problem. Possibly the
driver, the driver configuration files (/kernel/drv/st.conf),
recognizing the drive on boot (not seeing certain scsi id's or
higher lun's), the cable, or other hardware problems.
You should check your ufsrestore manpage for info on "interactive".
When you use "fsf 1" after a rewind, you always get the same DLE
to extract. Instead of "1", use a higher number to get other DLEs.
I don't think you used amrestore to extract individual files, unless
its output was passed through some other command. Perhaps you are
thinking of amrecover.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|