Hi,
On 1/27/2006 6:26 PM, Kel Raywood wrote:
Arno Lehmann wrote:
...
Anyway, setting them [tapes in a pool] to status "Archive" either
manually or using a script should do what you need - it marks them as
unavailable for Bacula, and you can easily track them in the catalog.
Ralf Gross wrote:
I'll do it that way, but I'm still curious, why this option is marked
as not yet implemented. It seems that you use it that way, thus I hope
bacula honors this flag and won't overwrite my tapes by accident.
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.
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 don't recall where I saw it and I just searched the manual and
couldn't find it so I could be wrong about this. However, to be on the
safe side, I don't think that you should use it. Instead use settings
similar to the following for your archive pool.
Pool {
Name = MY_ARCHIVE
Pool Type = Backup
Recycle = no
Auto Prune = no
Volume Retention = 30 years
Accept Any Volume = yes
}
Sure, you can do that, but it's got two problems: First, you need to
duplicate the pool. Then, when you wna to reuse the archived volumes
you've got to change the pool they belong to.
These are the main reasons why I thought the volume attribute "Archive"
would best be used to mark valid volumes which shall not be pruned and
should only be requested by Bacula during a restore.
Also, in the definition of the client, set "Auto Prune = no". This will
ensure that job and file-entries are not removed from the catalog.
If you use the same client for non-archive jobs, you can specify
"Prune Jobs = yes" and "Prune Files = yes" in the job-resource.
One more thing to duplicate... 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.
Hope this helps,
Kelvin
-------------------------------------------------------
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
