Amanda-Users

buglets with amrestore and amfetchdump

2008-07-21 20:04:36
Subject: buglets with amrestore and amfetchdump
From: Christopher McCrory <chrismcc AT pricegrabber DOT com>
To: amanda-users AT amanda DOT org
Date: Mon, 21 Jul 2008 13:57:44 -0700
Hello...

  amanda version: 2.5.2p1
  redhat linux 5.2 64bit
  intel hardware
  LTO-4 tapes in a dell jukebox with two drives

  Recently I had to restore some data from several months ago. I ran
into the folowing bugs/buglets.

1:
[amanda@server tmp]$ amfetchdump -b 256k -d /dev/nst1   -ap  DailySet1
server /data 20080212171101 |  /sbin/restore -ivf - 
Verify tape and initialize maps
Input is from a local file/pipe

1 tape(s) needed for restoration
amfetchdump: /var/lib/amanda/DailySet1/log exists: amdump or amflush is
already running, or you must run amcleanup
/sbin/restore: Tape read error on first record


It would be nice to be able to tell amfetchdump that we are not using
the same tape drive as the running amdump process so it is OK to
continue. 


2: despite what the man page says, when compiled with
"--with-maxtapeblocksize=512" and "define tapetype LTO-4 { blocksize
256 ..."  you still must use amfetchdump -b 256k when doing a recovery.

from man amfetchdump
-b blocksize
     Force a particular block size when reading from tapes. This value
     will usually be autodetected, and should not normally need to be
     set.

( same with amrestore  )

3: ( for me at least) amrestore cannot handle (with -p) tape_splitsize
( I have tape_splitsize 10 Gb) with amcrypt-ossl-asym. 

[amanda@server tmp]$ amrestore -p  -b 256k /dev/nst1 server /data
| /sbin/restore -ivf -
Verify tape and initialize maps
Input is from a local file/pipe
amrestore: missing file header block
amrestore: WARNING: not at start of tape, file numbers will be offset
amrestore: 1: skipping otherserver._.20080212171801.0
amrestore: 2: restoring server._data.20080212171801.0.01
Checksum error 24522315214, inode 0 file (null)
/sbin/restore: Tape is not a dump tape
amrestore: restore: wrote 65536 of 262144 bytes: Broken pipe

( yes, using dump not gnutar )


not using -p will get them off the tape, but when you are trying to get
a couple files off a 1Tbyte+ filesystem it is tricky :) 

I suspect the crypto subsystem is causing the problem.  non-split
restores work fine.



-- 
Christopher McCrory
 "The guy that keeps the servers running"

To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.


<Prev in Thread] Current Thread [Next in Thread>
  • buglets with amrestore and amfetchdump, Christopher McCrory <=