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.
However, this is not the way I use archives. I use a second catalog for
archives so (a) and (b) are automatically satisfied. Files that have
been removed from disk, and hence not in the regular backup after a
cycle of the backup tapes, can still be easily retrieved from the
archives. I don't need any new features to achieve this but, as you
point out, there is some duplication in the configuration.
I do have to duplicate is the client resources as these are associated
with a single catalog. I would prefer to have clients independent of
catalog and be able to associate a volume pool with a particular
catalog. But it's not a big-deal.
I wrote:
... I use settings similar to the following for the archive pool.
Pool {
Name = MY_ARCHIVE
Pool Type = Backup
Recycle = no
Auto Prune = no
Volume Retention = 30 years
Accept Any Volume = yes
}
Arno replied:
Sure, you can do that, but it's got two problems: First, you need to
duplicate the pool.
This is true somewhat, but it's not really a duplicated pool, just
another pool whith different parameters. I prefer having archive
volumes in a separate pool as mentioned above.
... Then, when you want to reuse the archived volumes you've got to
change the pool they belong to.
If you intend to re-use archive volumes, you could set "Recycle = yes"
and the "Volume Retention" appropriately. Or you could modify the
parameters of a volume manually, setting the recycle flag to yes and
purging the volume.
I am using bacula to keep indefinitely, the large data-files generated
from high-resolution medical-image scanning. Thus I never recycle
archive volumes.
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.
OK. Different intended use. But as long as these tapes are in a
separate pool, setting "Auto Prune = No" achieves what you want.
Correct?
me:
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.
Arno:
One more thing to duplicate...
True. I have two "JobDefs" resources. One is a template for regular
backups and one a template for archive jobs.
To be able to use a single job resource for regular-backup and
archiving, you would need to be able override the above parameters in
the schedule resource. Perhaps coming up with a scheme where _any_ job
resource can be overridden in the schedule would be useful. I'm not
sure if this is compatible with the two-catalog scheme though.
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.
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
