Hello,
On 1/30/2006 8:17 PM, Kel Raywood wrote:
I wrote:
...
I don't think that the Archive flag is intended for the use you want.
I think that it's supposed to indicate that the volume entry will be
removed from the catalog when the volume is unmounted.
On Fri, 27 Jan 2006, Arno Lehmann wrote:
Oops... that would be not so good with my suggestion... still, I
wonder why that would be the intended use. Admittedly, my
understanding of what an archived volme is doesn't have to be coherent
with what Kern thinks.
I think that the archive is intended to be used in cases of a complete
disaster of the backup system. i.e. the catalog is lost and you have
to rebuild it from the archive tapes. In that case, I can think of a
couple of reasons why it would be useful to have archive records removed
from the catalog.
(a) So that the next partial backup (incremental/differential) is not
affected by the archive. ie. regular backups proceed normally.
(b) A normal restore to a client would come from the backup tapes which
are presumed more easily accessible than archive tapes which might be
taken offsite.
Interesting way of doing that... I never thought along that way. What
you suggest sounds quite reasonable, though I would refine it a littel
(at least *I* think this would be a refinement):
Put all the metadata into the catalog, but during regular operations,
ignore the corresponding jobs / volumes.
This might even be what happens now, by the way... This should gain the
same advantage you point out, but it would allow normal management
procedures which rely on the catalog data. We'd need a restore job which
allows setting a flag "From Archive", though.
However, this is not the way I use archives.
I guess your description of how you handle your archiving jobs is quite
detailed - I don't think it needs comments from me. Except to say
"Thanks for a complete and detailed example" ;-)
...
OK. Different intended use.
Looks like it. A good reason to discuss the intended uses, though...
But as long as these tapes are in a
separate pool, setting "Auto Prune = No" achieves what you want. Correct?
Hmm. It should, I think. I never tried it, though, and it might be that
job and file retention periods don't honor the settings from the
volumeswhere their data is stored. In other words, I guess you end up
having the data on tape, but still having the metadata for jobs and
files pruned from the catalog. At least you do have the volumes, intact,
of course, and I guess it's a clever idea to run archival jobs with some
run after job scripts that print out the actual tape contents, like
client, job, date, and perhaps a bootstrap file.
me:
...
I guess we'll have to nag Kern to implement archiving ;-)
Or, of course, we discuss this until we reach consensus on how
archiving should work, and how it can be implemented. The -devel list
would be the better place for that, once we know what people *want*.
Apart from that, I think there was a discussion where that subject -
Archiving - was touched.
The ongoing development of job migration makes that a necessity, in my
opinion, because migrating from regular pools to archiving ones might
be one of the main uses of job migration. I my opinion, of course.
Yes. I think I agree with all this. Perhaps we need to confirm the
intended use of the Archive-flag as well. If it is defined as I think
then it's not compatible with what we have been discussing and one of
these would need a different name.
Quite a good description of what "Not implemented" means :-)
Well, any other opinions on the subject of archiving, what it is, and
how you want to use it?
Arno
Kel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
IT-Service Lehmann [EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
