On Thu, Apr 19, 2007 at 06:50:44PM -0700, Paul Yeatman wrote:
>
> ->>In response to your message<<-
> --received from Jean-Louis Martineau--
> >
> > Paul Yeatman wrote:
> > >So, as I continue to look at the problem, I haven't seen before
> > >that an amflush is require for the directories on holding disk to
> > >be included in a recovery yet . . . this kinda of seems to be the
> > >case now (that is as much a question as it is a statement). I see
> > >in the amindexd.###.debug log that it is trying to "gzip -dc ... "
> > >files in the amanda index directory for the disk being restored
> > >yet these files don't exist. For instance, the log says this is
> > >being executed
> > >
> > > /bin/gzip -dc '/etc/amanda/cass/index/cass246/_/20070331_6.gz'
> > > 2>/dev/null | sort > '/etc/amanda/cass/index/cass246/_/20070331_6'
> > >yet "/etc/amanda/cass/index/cass246/_/20070331_6.gz" does not exist;
> > >It is instead on the holding disk. Does it not exist because I have
> > >never run amflush? I swear I've performed tens of recoveries that
> > >included files on the holding disk that were (obviously) never
> > >amflushed. I'm so confused!
> > >
> >
> > amanda will never remove the compressed index files (.gz) while the dump
> > are still on tape or holding disk.
> > You said that you removed some dump from holding disk to debug your
> > previous problem, if you ran amdump while dump was missing, amanda has
> > removed the index file.
>
> Ah, I get it!
>
> I have another Amanda server to check with and do indeed see that all
> backups on the holding disk have an associated .gz file in the index
> directory. I CLEARLY need to change this yet, until now on this
> server, I have been filling a holding disk, leaving those backups
> there, and then changing my amanda.conf to point to a new [blank]
> holding disk. I always figured that in the event of a needed restore,
> I could change my amanda.conf to point to ALL holding disks. There was
> a reason I was doing this that I won't bore everyone with now. So now
> I see that, when changing to a new (empty) holding disk, all my
> previous, compressed, index files where flushed upon the next amdump
> run! Yikes!!! This is bad!! The good news is that the data is still
> there!!! But, boy, sure takes away the power of amrecover! I had no
> idea the consequence of this!
>
> >
> > I hope you have a backup of your index files.
>
> I suppose in a way I do but, given the current state of things, it
> seems it would be impossible to figure out what needs to be restored to
> correctly repopulate my index directory. I will hope for the time being
> that no restores will be needed until I create stable holding disks and
> repeat full backups of everything. In the meantime, should a restore
> be necessary, I will resort to an 'amadmin ... info' of the disk in
> conjuction with sequential hand-run amrestore's.
Shouldn't be too major a job as you are only talking about restoring
a single directory tree, the index directory tree. As the dumps are
on disk, once you figure an an appropriate command line, you may even
be able to automate it with a small shell script/loop.
Be aware that you can specify multiple holding disks in your config.
And as one of the holding disk parameters is "use", you could even
specify an appropriate "use value" for your old holding disk that
makes it seem full. Then no more dumps will be added there but the
old dumps will still be available for recovery.
--
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)
|
