->>In response to your message<<-
--received from Jon LaBadie--
>
> 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.
Thanks again for this!
I am aware I can specify multiple holding disks and will do this from
now on. I'm surprised that it has been as difficult as it has to make
the disks appear full to AMANDA, however.
I am using directories on the same RAID disk as holding "disks" and
thus first tried specifying a negative Gigabyte value that was larger
than the amount of space available on the RAID disk, for example I
specified "use -250 Gb" when there is roughly 240 Gb available.
Strangely, the next backup still used all directories on this disk. As
my understanding of specifying "use 0 Mb" means "use all space
available", the best I've been able to come with is "use 1 Mb" which
seems to be the smallest amount of space I can specify. This of course
means, not very much, but some data is undesirably written into all
holding "disks" (directories) every backup.
I feel like I'm not quite understanding how this is supposed to work.
When trying various "use" values, for instance, I don't quite understand
what amcheck is trying to tell me. If I set "use -250 Gb" on one of the
holding disks, for instance, amcheck tells me
WARNING: holding disk /backup/vtc1/cass: only 238115672 KB free
(4032823296 KB requested)
The roughly 240 G free is correct but 4 Tb requested??? How does this
relate to "use -250 Gb"?
Don't get it!
Paul
>
> --
> 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)
--
Paul Yeatman (858) 534-9896 pyeatman AT ucsd DOT edu
==================================
==Proudly brought to you by Mutt==
==================================
|
