On Sun, Jul 23, 2006 at 08:11:02PM +0100, Laurence Darby wrote:
>
> Thanks everyone for your help, especially you Anne, as I based my
> setup on what you've done. I'm sorry it's taken so long, but there's a
> lot of stuff to know, and the documentation isn't exactly in the same
> league as NetBackup's...
>
> I set the disk length to 4400 MiB, since the ext2 fs has 4412MiB free.
> (btw, I get really cranky about people using M to mean 1048576, it's
> the same badness as trying to define PI to be 3.0)
>
> With the dumptype, I tried to give a tape_splitsize of 4400MiB so one
> whole chunk would fit, but that seemed to be ignored and it used
> fallback_splitsize instead. I noticed it allocated mememory the size
> of fallback_splitsize. I set it to 440, so there'd be exactly 10 per
> DVD.
Just to be certain there is no misunderstanding, the tape_splitsize
is not the size of the pieces your amdump run is split into. It is
the size of chunks of each individual DLE. I.e. if any individual
DLE were larger than 4400MiB, that DLE would be broken into chunks.
It is not your whole collection of DLE's is combined into chunks on
tape/disk of 4400MiB. Each DLE gets taped individually and split
if necessary.
>
> Also, with compression, I found that only got about 10% compression at
> the "best" setting, so I switched it off.
>
> define dumptype dump1 {
> compress none
> index yes
> holdingdisk no #use the vtape on disk.
> program "GNUTAR"
> tape_splitsize 4400 Mb
If you are not using a holding disk to collect the DLE's before
taping (even to virtual tape), then the maximum splitsize is
limited to available virtual memory. Unless you are on a 64-bit
system, that would be way less than 4GB.
> fallback_splitsize 440 Mb
> dumpcycle 0
> strategy noinc
> }
>
>
> So with the indexes, in NetBackup they need backing up even more than
> all your data, since they are almost critical to accessing any of it.
> Is that the case with Amanda? I just copied them to the end of the last
> dvd, where they could be manually put back in /usr/local/etc/ before
> trying a restore.
I think the main (only?) purpose of indexes in amanda is to provide
the listings you can see in amrecover.
>
> So then, restores! (only using the on-disk vtapes, haven't even tried
> reading the dvds yet) Firstly the readline interface on amrecover
> didn't work, which meant it was easier to use a real editor and paste
> commands into it. It is linked to libreadline as ldd shows:
> $ ldd /usr/local/sbin/amrecover | grep read
> libreadline.so.5 => /usr/lib/libreadline.so.5 (0xb7e8a000)
>
> Is it normal for it to scan every vtape even after it's extracted the
> one test file? I thought that's what indexes were for.
see above re index
I think this comes from tar's ability to add to an existing
tar archive. On restore it needs to be certain there is not
another, more recent copy later in the archive. Amanda does
not use this feature, but tar doesn't know that.
>
> Then it complains about:
>
> tar: Error exit delayed from previous errors
> amrecover: Extractor child exited with status 2
>
> extract_list - child returned non-zero status: 1
> Continue [?/Y/n/r]? ?
> Enter "y"es to continue, "n"o to stop or "r"etry this tape
> Continue [?/Y/n/r]?
>
> And doing a full extract gets the same message, and even *LOSSES* about
> 470 MiB. Is there any way to find what error tar is complaining
> about? It's gnu tar 1.15.1. Is it possilbe my dump split sizes
> somehow broke amdump?
>
> The size of the vtapes is 8311439625 bytes, with
>
> du --apparent-size -B 1
>
> and the orig directory is 7753562651. The size of the extracted
> directory is 7301958942. With amrecover, 'ls' shows the missing files,
> but then it gives the error message:
>
> tar: ./old/src/gcc/gcc-3.4.3-i486-1.tgz: Not found in archive
>
> So, is it possible amrecover is just broken and not seeing files in the
> archive? Or, is amdump broken and it failed to back up some data? In
> that case I think I'll go back to tar --multi-volume...
>
Given that quite a few, myself included, are using amanda, virtual tapes,
tape spanning, etc. and are able to amdump and amrecover, I doubt they
are so broken as the results you are experiencing. However, I don't
have an idea as to why you are getting your results.
--
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)
|
