>What influences this behaviour? ... Just to explain a bit more about this from what Jean-Louis said. Amtrmidx looks at your tapecycle value and removes index files before the level 0 that is before (or at) tapecycle+1 runs ago.
Let's say you have tapecycle set to 10 and you make one run per day. Then amtrmidx will save at least 11 files (runs), and may save a few more (back to the level 0). There are several problems with this (it doesn't account for runtapes, for instance), but is reasonably conservative. As Jean-Louis said, my suggestion would be to save several things whenever you take a tape out of the cycle: * All the associated index files. * The associated log.YYYYMMDD.NN file. * The tapelist (or at least the entry for this tape). >.. Is there a way to regenerate the index files from an existing tape? This gets requested every once in a while, but nobody has done the work. Note that (for the general case) it requires you to send the image back to the original client to do the work, then collect the results back on the server. That makes it non-trivial. The DUMPER-API adds some support to make this easier, but it's not done yet, either. >[1] Now I have to use ufsrestore off the raw tape device, >was hoping to use the easy interface of amrecover. Ummm, I assume you mean you'll use amrestore (or dd) to read the raw tape and send that into ufsrestore, right? The raw tape images are not suitable for direct processing by any restore program (see docs/RESTORE). John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
