Bacula-users

Re: [Bacula-users] changing the retention period to indefinite

2010-03-13 11:12:11
Subject: Re: [Bacula-users] changing the retention period to indefinite
From: John Jorgensen <jorgnsn AT lcd.uregina DOT ca>
To: Thomas Mueller <thomas AT chaschperli DOT ch>, Guy Matz <gmatz AT openfinance DOT com>
Date: Sat, 13 Mar 2010 10:08:43 -0600
>>>>> "thomas" == Thomas Mueller <thomas AT chaschperli DOT ch> writes:

    thomas> Am Fri, 12 Mar 2010 17:53:42 -0500 schrieb Guy Matz:
    >> hello, my brothers.
    >> 
    >> a machine of mine has died and i would like to keep the
    >> last set of backups "forever" . . .  can someone tell me
    >> the right way to go about making changes to the DB - or
    >> whatever it is i need to do - in order to achieve this
    >> goal?

    thomas> set the volume to state "read-only" (update volume).

Changing the volume state to "read-only" should prevent bacula
from re-using the Volume, which might be all that Guy needs.

To retain information about the contents of the volume in the
catalog, though, I think you also need to change the Retention
values associated with the Volume and the Jobs stored on it (and
the Files stored in the jobs, if you want your catalog to keep a
record of individual files stored on the volume indefinitely).

Here is what we use for tapes we archive indefinitely (comments
within the specification explain difficulties I had with
specifying "forever"; there may be a better method, but this
works for us so far):

  # 
  # A pool for archived tape cartridges.
  # Setting their individual Volume Status to
  # "Archive" would suffice to keep Bacula from reusing
  # the tape, but changing them to this pool makes
  # their status more visible.
  #
  Pool {
    Name = "Archived ML6000 Pool"
    Maximum Volumes = 0                 # no limitation
    Pool Type = Backup                  # The manual mentions an
                                        # "Archive" Pool Type, but
                                        # says it is unimplemented.
    Storage = ML6000
    Recycle = no
    Volume Retention = 38 years         # Can't find an explicit way to say 
"forever".
                                        # We use "38 years" rather than a longer
                                        # period because Bacula's pruning code
                                        # (at least in release 2.4.3) does not 
deal 
                                        # well with Job or File Retentions long 
                                        # enough to predate the UNIX epoch, Jan 
1, 1970.

    Catalog Files = yes
    AutoPrune = no                      # Bacula may automatically recycle 
Volumes
  }


We use a similar "forever" for all the Job Retention
specifications we put into Client specifications,
so that we only purge Job records as a consequence of
purging the Volume containing them).  E.g.

  Client {
    Name = "someclient-fd"
    Address = someclient.some.place.ca
    FDPort = 9102
    Catalog = MainCatalog
    Password = "some password" # password for FileDaemon
    File Retention = 2 months
    Job Retention = 38 years     # Keep Jobs until Volumes recycled; we use
                                 # "38 years" to represent "forever" because
                                 # Bacula's pruning code (at least in release
                                 # 2.4.3) does not deal well with Job or File
                                 # Retentions long enough to predate the UNIX
                                 # epoch, Jan 1, 1970.

    Autoprune = yes              # Prune expired Jobs/Files
    Maximum Concurrent Jobs = 1
  }

What I've never tried doing, though, is setting the "File
Retention" to "forever", so I don't know how you could do it for
only the files associated with the decommissioned client's last
job, rather than all the client's jobs remaining in the catalog.
I suppose you could manually purge the jobs you don't want to
retain after setting the File Retention to "forever".

Judging from our logs, Job and File records are usually purged
after new Jobs are run, so there's a chance that if you never run
another job for your decommissioned machine, the corresponding
records will never be considered candidates for purging; that I
simply don't know about.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

<Prev in Thread] Current Thread [Next in Thread>